I have an infrastructure project that contains other projects as resources. (Because it compiles them on the fly). One of those contained projects is deliberately one that fails to compile.
This makes the entire project show in eclipse as "with errors".
How can I make sbt-eclipse configure eclipse such that e.g. anything under src/main/resources/foo should be ignored?
Of course this isn't exactly the scenario eclipse was built for, but might there be some clean way around it? as much as it matters, sbt itself does not try to compile these resources.
If not, maybe a way to tell eclipse to not even load source
directories under src/main/resources?
Thanks!
Related
I have exactly the same problem as in this question: Eclipse: Using "Open Declaration" ... in a Scala project
However, I'm using the latest Scala IDE in version 3.0.2 (I have downloaded the Eclipse bundle from the site), and I would assume such basic functionality works by now, and apparently it's me who have something misconfigured.
I have created a new Scala project. Then I open some standard library class/trait/whatever, let's say scala.util.parsing.combinator.JavaTokenParsers. The source is neatly displayed, but when I try to show class hierarchy, I get the message: The resource is not on the build path of a Java project.
Also, searching for references etc. won't work.
I guess it is a matter of properly configuring the build path? Or maybe I should somehow attach Scala library sources to my project? But I can see the source, so aren't they attached already?
Here is the snapshot of my project configuration:
UPDATE:
By playing a bit with setting/resetting build path stuff, I managed to get rid of pop-up warning but the class hierarchy comes up empty and when searching for references I get only hits from my own sources, nothing from standard library.
In another workspace I also tried randomly adding and removing scala-library jars and got it work almost, but the type hierarchy comes up only with super-classes, without any sub-classes (which renders it quite useless). Searching for references works ok though.
Funny thing, I cannot make it work in my original workspace...
Gotta love Eclipse.
Your build path is not configured properly.
If you take a look under Scala Library[...] you have scala-library.jar we can only see one top-level package scala. There should be numerous other packages besides that. (Ruled Out)
I would recommend you follow these steps
Right-click project, build-path, Java-build-path, Libraries and make sure that the correct library is referenced there.
If it is the one you need, Try to remove this library and add it again, then clean and re-fresh the project. Also try this step in a fresh workspace.(something must have messed up this workspace )
Lastly. Goto the path D:\Eclipse For Scala\configuration\org.eclipse.osgi\bundles\286\1\.cp\lib and verify the sizes of the jars there. There should be 6 jars there and the size of scala-library jar should be around 6.8M. If size is smaller, consider re-downloading
I have a netbeans project that is under mercurial. What I would like to do is to strip down everything that makes this project netbeans project to only to leave code in there so that I can easily import it in say eclipse.
Is there some automated way to do this or do I have to remove manually this?
What approach would you recommend.
Cheers
You only have to add the nbproject folder to ignore (= don't check in). All NetBean-settings are placed in this folder. Dont check in the build and dist folder as well, because these contain the compiled code (but they are ignored per default).
The best way to do "IDE neutral projects" is to use Maven !
In NetBeans when the project is Maven-based (as opposed to Ant-based) you'll see that all those NetBeans-specific files that you normally see in nbproject folder are just not there. The nbproject folder doesn't even exist. The reason is that for a Maven-based project NetBeans essentially uses the pom.xml as the definition of the project and that's a good thing because the POM is portable and directly understood by other IDEs.
Even for a Maven-based project NetBeans will still store some IDE-specific stuff in a file called nb-configuration.xml but you can include all of the contents of this file as properties inside the pom.xml. These properties will then be ignored by other IDEs when they load the POM. This way you can pretty much avoid altogether to check any IDE-specific files into the VCS. Also it is worth mentioning that the stuff in nb-configuration.xml is never needed for someone else (using NetBeans or another IDE) to be able to build your project. Another way to put it is that it contains non-essential data. The POM - by virtue - is always guaranteed to be a complete description of how to build the project.
Contrary if your NetBeans project is Ant-based then at least in my experience you cannot avoid checking NetBeans specific files into the VCS ... because otherwise even those using NetBeans won't be able to correctly open your project.
However even with Maven there's one area where you'll be forced to have NetBeans-specific files in the VCS and that is if you use the Matisse GUI builder in NetBeans. The Matisse GUI builder produces some proprietary files with .form extension and you really need to have those in your VCS. But this is the only example I can come up with where NetBeans-specific files will need to go into the VCS assuming your project is Maven-based.
If the project indeed is Maven-based and you still feel that there are NetBeans-specific files that you need to have in the VCS then let us know exactly which files you're thinking of. Then we can take it from there. :-)
I want my Ant build to take all Java sources from src/main/*, compile them, and place them inside bin/main/. I also want it to compile src/test/* sources to bin/test/. I wan this behavior because I want to package the binaries into different JARs, and if they all just go to a single bin/ directory it will be impossible* (extremely difficult!) to know which class files belong where.
When I go to configure my build path and then click the Source tab I see an area toward the bottom where it reads Default output folder: and then allows you to browser for its location.
I'm wondering how to create bin/main and bin/test in an existing project without "breaking" Eclipse (it happens). I'm also wondering that if I just have my Ant build make and delete those directories during the clean-n-build process, that Eclipse might not care what the default output is set to. But I can't find any documentation either way.
Thanks in advance for any help here.
In Eclipse, you can only have one output folder per project for your compiled Java files. So you cannot get Eclipse to do the split you want (i.e. compile src/main to bin/main and src/test to bin/test).
You can, if you want, create two Eclipse projects, one main project and one test project, where the test project depends on (and tests) the main project. However, in that case, each project should be in its own directory structure, which is not what you are asking for. But this is a common approach.
Another way, which I would recommend, would be to not mix Ant compilation and Eclipse's compilation. Make the Ant script the way you describe (i. e. compile the main and test directories separately and create two separate jar files). Change the Eclipse compile directory to something different, for instance bin/eclipse. Use the Ant script when making official builds or building for release. Use Eclipse's building only for development/debugging. This way, your two build systems will not get in each other's way and confuse each other.
Hope this answers your question and I understood it correctly. Good luck!
i am looking to make our deployments here not suck and i need some help, if you can help me with these few things i owe you beer
right now whenever i make a change thats not to the jsps i need to clean-including-tomcat otherwise my change doesnt take. this is really annoying.
any clues as to what i can change to make it work?
my current build is really simple, just the regular old, javac, war, deploy
one thing that isnt done is that there is no build dir, the project itself contains a web-inf and the javac is done in place, then the war excludes all the .java resources and wars the project.
edit:
I am looking to fix this problem with least amount of effort - so while switching to maven and learning how to use it might solve this problem, but it will create another problem ;)
You've already identified some of the weaknesses, in your current build.
The easiest way that I can suggest to clean it up would be to start with the directory structure.
I highly recommend using the maven directory structure, I would go further to suggest using maven as a build tool instead of ant, however for some folk that remains open for debate.
The maven directory structure has been well thought out, I really like working on projects that use the maven directory structure, because they follow a convention that allows me to save a lot of time, by knowing from previous experience where to find the application components
java source
unit test source
resources etc.
Also by following the convention, the maven plugins work with less configuration required.
Another useful advantage that I get from working on maven based projects is good code metrics, to measure the health of the application. There are various report available as maven plugins, which will give you new insight into your codebase, including:
checkstyle
pmd
findbugs
and more.
Created a build directory where everything got copied before build
Added some flags to not copy over things that rarely change, like images (also to not remove them on clean)
Started using ant-reload task after deploying code
Now i don't need to restart tomcat on every build, and build takes much less time.
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.
The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
Why not use access rules to keep your code clean?
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.