This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Override the javac.classpath property in -do-compile task | ||
---|---|---|---|
Product: | java | Reporter: | lforet <lforet> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | NEW --- | ||
Severity: | blocker | CC: | jglick, mkleint |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: |
My proposal for this issue
The good patch is there Add the same suggestion for -do-single-commit target please install the http://ivybeans.googlecode.com/files/ivybeans-1.0-M3.zip and try this project |
Description
lforet
2008-06-30 20:47:31 UTC
Created attachment 63712 [details]
My proposal for this issue
Created attachment 63715 [details]
The good patch is there
Needed for Ivy support, I heard. I exactly have the same problem with the -do-single-compile target. Created attachment 64378 [details]
Add the same suggestion for -do-single-commit target
Probably WONTFIX. This is not going to work well because 1. Overriding the target will not help the IDE's code completion be correct. 2. Nor will it have any effect on projects using Compile on Save in 6.5. There is a method described in http://wiki.netbeans.org/FaqIvy which is a little hackish but does not suffer from problem #1, and is better for problem #2 (you will need to "Clean & Build" after changing Ivy config but that is all). If you are writing a module, and not just relying on build.xml editing scripts, then you can go further and have ivy.classpath be defined in private.properties, updated automatically when the project is opened or ivy.xml is edited (no need to wait for an Ant build). See Jesse's comment above. "If you are writing a module, and not just relying on build.xml editing scripts, then you can go further and have ivy.classpath be defined in private.properties, updated automatically when the project is opened or ivy.xml is edited (no need to wait for an Ant build)." this might help for classpath maintainance (but from a module it's done easier by additional ClassPathProvider impl IMHO) but how will that work with sharable projects and builds outside of the IDE? The method describe in the http://wiki.netbeans.org/FaqIvy works only on the init phase or because it has been resolved once before . I think it was that happened in the faq demonstration the ivy.classpath was already resolved before the retrieve (it is a fake ;)). Indeed, if you want to use in "javac.classpath=${ivy.classpath}" The ivy.classpath should have to be evaluated before the javac.classpath property. That means in the init section not in the compile one. I am going to put a sample application that shows how it works. It is too hard to explain. Further more you already use that kind of classpath initialisatioon in the junit section : <j2seproject3:javac classpath="${javac.test.classpath}" Please reconsider this issue. Created attachment 66146 [details] please install the http://ivybeans.googlecode.com/files/ivybeans-1.0-M3.zip and try this project Something I have forgot to mention. I do not change anything in the project.properties I do it all in memory . Also, as Milos has already written, I use the ClassPathProviderImpl to change the classpath used for the completion in the IDE. Then the risk #1 is none. I think that the answer for the #2 is the same. best regards. |