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.

Bug 138661 - Override the javac.classpath property in -do-compile task
Summary: Override the javac.classpath property in -do-compile task
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 1 vote (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-30 20:47 UTC by lforet
Modified: 2011-08-31 14:07 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
My proposal for this issue (706 bytes, text/plain)
2008-06-30 21:42 UTC, lforet
Details
The good patch is there (1.07 KB, text/plain)
2008-06-30 22:22 UTC, lforet
Details
Add the same suggestion for -do-single-commit target (1.55 KB, patch)
2008-07-12 11:31 UTC, lforet
Details | Diff
please install the http://ivybeans.googlecode.com/files/ivybeans-1.0-M3.zip and try this project (11.28 KB, application/x-compressed)
2008-07-31 09:28 UTC, lforet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lforet 2008-06-30 20:47:31 UTC
As a third party plugin developer I would like to have the possibility to override classpaths (ex: javac.classpath
property) used in macrodef-xxx targets.

Indeed the actual classpath resolution scenario is :

1 -init-project set the javac.classpath property with values taken from project.properties
2 -init-macrodef-javac use this javac.classpath property as a default value
3 -do-compile use the default value set in 2 and launch the jseproject3:javac macro.

In order to make a third party javac.classpath override effective in the -do-compile task, the <j2seproject3:javac/>
call has to be changed like this :

<j2seproject3:javac classpath="${javac.classpath}"/>
Comment 1 lforet 2008-06-30 21:42:05 UTC
Created attachment 63712 [details]
My proposal for this issue
Comment 2 lforet 2008-06-30 22:22:33 UTC
Created attachment 63715 [details]
The good patch is there
Comment 3 Jesse Glick 2008-07-01 01:44:11 UTC
Needed for Ivy support, I heard.
Comment 4 lforet 2008-07-12 11:29:43 UTC
I exactly have the same problem with the -do-single-compile target.
Comment 5 lforet 2008-07-12 11:31:47 UTC
Created attachment 64378 [details]
Add the same suggestion for -do-single-commit target
Comment 6 Jesse Glick 2008-07-30 22:53:22 UTC
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).
Comment 7 Tomas Zezula 2008-07-31 07:21:34 UTC
See Jesse's comment above.
Comment 8 Milos Kleint 2008-07-31 07:28:28 UTC
"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?
Comment 9 lforet 2008-07-31 09:22:55 UTC
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. 
Comment 10 lforet 2008-07-31 09:28:10 UTC
Created attachment 66146 [details]
please install the http://ivybeans.googlecode.com/files/ivybeans-1.0-M3.zip and try this project
Comment 11 lforet 2008-07-31 09:36:47 UTC
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.