This is getting tedious. I created a test project, simple java hello, to test a problem I have in another project. Having created the project, I could run it and build it to a jar.
Then I added some ivy stuff and tried a build which did not work. The ivy stuff consisted of ivy.xml ivysettings.xml and 2 tasks added to the otherwise default netbeans build.xml.
So then I removed the ivy files and the ivy sections from build.xml. I then did a diff on that and the previous unedited build.xml file and they are identical.
So now why after a clean build do I get this error?
/home/tester/WORKSPACE/NetBeans/Foo/nbproject/build-impl.xml:63: Source resource does not exist: /home/tester/WORKSPACE/NetBeans/Foo/lib/nblibraries.properties
Correct that file does not exist and it does not exist in any other project I have access to whether they use ivy or not.
I have reset everything I did yet Netbeans cannot continue. I have tried to work out how the hell nb actually builds a project but got lost. Just don't know what to say.
I guess nb and myself differ on what clean actually means and also on whether a task should be able to produce exact same results everytime given the same input, something that nb does not seem to be able to do. That or it cannot recover from the real world or their documentation just hides the useful information like how to reset a project.
I'm assuming there is some nb state that needs to be cleaned up manually but have no idea where to start. Any ideas please?
#Tim Biegeleisen, your comment got me thinking.
I shut down/restarted netbeans then tried the build again and it worked. So it seems that ivy is still running inside netbeans and has some form of state for my project that it will not release. I'll have to dig around to see if there is a way to reset ivy state without restarting nb but this whole process is turning in to a very tedious onerous task. I seem to be spending more time on the dev tools than I am on solving my coding tasks.
So the solution/workaround to my problem seems to be to restart netbeans to clear ivy state.
Related
First a tiny bit of background:
I'm working on a large application for which the development started around 2008 (so as you can imagine, it's huge with loads of dependencies of which part are already unsupported/outdated)
I have a git branch with the current (developer) version, as well as a bunch of other branches with earlier versions (and some other branches like master and such, but those are irrelevant for now)
These days, every time I switch from the current branch to an older branch to do some hotfixes, the Maven update and Clean build work fine. However, when I switch back after the hotfix is done to the current branch, and do a Maven update, I get the following error:
This is a pretty well-known error based on some earlier stackoverflow questions I saw. Most answers you'd find will say to remove the entire .settings and .project files, and re-import the project; or to remove the .metadata of your workspace, and restart Eclipse. In the past I remembered using this solution of only deleting the .metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi file of the workspace, so the damage to your Eclipse project settings is limited. However, it doesn't always work, and I'm also getting a bit tired of getting this exception every single time I switch back and forth from a branch..
Note that I've already tried a bunch of other things without much avail:
Removing my entire .m2 folder and letting it download everything from our Nexus again
Looked in the Maven Console to see what is being logged, which isn't anything related to this NPE unfortunately
Do the Maven Update Project both with or without "Force Update of Snapshots/Releases" enabled
Do a Clean Build with the "Update Snapshots" enabled
What I'm mainly looking for right now is a stacktrace of this NullPointerException, so I can (hopefully) fix this issue at the core of the problem, instead of using all these workarounds like deleting Eclipse/Maven folders and/or settings (which only work halve of the time anyway)..
It gives a NullPointerException, so I assume I should be able to see the stacktrace of this NullPointerException to determine the cause somewhere in an Eclipse log or console, shouldn't I?
Is there perhaps a mvn command flag/argument I could use? Or is this NullPointerException an issue of Eclipse rather than Maven?
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!
Introduction
I have spend a lot of time to fix this bug
In our application we have a lot of generated code by cxf and jaxb which produces tons of warnings. We use the maven-build-helper plugin to add this code to our projects automatically.
By adding this enhancement, eclipse JDT enabled the possibility to set the javac -nowarn flag for specific source folders. Unluckily, by updating the maven project the flag gets lost. There are a few threads on SO where users got bugged by bug.
What I have tried so far
So i came up with a clever solution, javac has a nowarn flag. I set it to my maven-compiler-plugin and specified the directory. My maven build was fine, but my eclipse build wasn't. My research told me, that eclipse jdt does only use the maven-compiler-plugin source and target version. So my next step was to try to configure the EclipseCompiler, but this is not possible, because there is no possibility to add custom compiler Arguments in eclipse JDT.
Next Step. Inside of the .classpath file, eclipse JDT adds an ignore_optional_problems attribute for each ignored path. By updating the maven project inside of eclipse, this entry gets lost. So i started to write a maven "ignore-source-folder" plugin which should add the missing attribute. To run the plugin each time eclipse starts a build, i also created a m2e connector to refresh the .classpath file and everything should be fine.
By testing my plugin with my connector i realized, it works, but only 70% of the repetitions.
What happened?
Every time eclipse m2e/Jdt starts a new build, all classpath entries will be removed and populated again. When my maven plugin gets triggered by eclipse, a race condition starts.
So I started to analyze the code of jdt and m2e jdt. The ignore_optional_problems flag gets only once set manually inside of the patch which was provided to JDT and isn't stored somewhere else. By triggering a new build via m2e-jdt this information gets lost.
How to fix this problem
To fix this problem, some element has to be added or extended in jdt which contains all ignored folders. If a new build gets triggered and the classpath file gets newly generated by m2e-jdt this element should be checked for ignored paths. ClasspathEntryDescriptor seems to be a good place for it.
My problem
I checked out jdt and m2e jdt, but i have tons of errors inside of my IDE and i have no idea how to start. And even if I fix the code, I have no idea how to build and test it. I think my effort will be to high and we talk about 20 or 30 simple lines of code.
I am afraid if I add my results to the filed bug at eclipse, no one will care about it.
So, is there any developer able and willing to help me for this tiny job?
You need to "fix" the M2E's JDT project configurator. Probably somewhere in the m2e-core project. So, your change should obtain some kind of configuration flag from the project pom and create corresponding classpath entries for JDT.
I'm working with project in intellij IDEA IDE based in maven. I can perform all maven goals but IntelliJ is showing a lot of errors in the source code like bellow:
Everything worked fine a few hours ago. I don't understand why the IDE continue
showing errors. When I rebuild or compile the entire project (CTRL + F9) or a single
scala class I always receive a success message like that:
I already had configured scala plugin before, so I don't know what is happen.
thanks for your help
Sometimes the IntelliJ cache gets corrupted. You can fix this by the following:
File > "Invalidate Caches / Restart"
After choosing "Invalidate and Restart" when prompted, IntelliJ will restart and rebuild its cache.
If IDEA has lost track of obviously correct types such as Database or DateTime it probably means the configuration of the project is wrong or corrupted. Most commonly it does not have the required 3rd part dependencies such as Joda Time.
If you're not already doing so, define your project solely in SBT and use the sbt-idea plug-in to produce your IDEA project definition. Then whenever you change the project dependencies, re-run gen-idea to regenerate your IDEA project files. No muss, no fuss.
There are many bugs raised in jetbrains's bug tracker for this. I suggest you raise some bugs or vote for existing ones.
It loos like the problem you have is with the type aware highlighting which is worse than useless.
thanks for your responses.
I solved this problem importing the project again.
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.