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.
For plugins trying to access the build parts (for analyzing bytecode) there is currently no really good way to find them. For ant-based projects you can use the AntArtifactProvider, but with Maven-Projects you are out of luck there. Trying to build ClassPath.EXECUTE-ClassPath.COMPILE depends on the correct implementation inside the 3rd-Party-Project (seems somehow broken with Maven). This leads to a bunch of problems in identifying the real artifacts created in this project. I think a query may be necessary here (as pointed out by Jesse). Hopefully this gets adressed in 5.1, as it is really making difficulties adding extensions using binary artifacts.
The best way how to find out the project's output is to take the execution classpath and use SourceForBinaryQuery to find out which roots are on the source path. These roots are the output roots.
actually I just checked the maven integration sources and for maven1, the project's classes output directory should be included in the runtime classpath. actually since maven places resources in separate directory structure from the java files, I had to include also the resources root dir. Otherwise the form localization doesn't work. The runtime classpath seems to me to have quite a bit of contracts. ;( all of these undocumented. I'd prefer to have separate explicitly stated contract for each usecase. for maven2 these are not included, I'll add them.
In case of projects with antartifacts i get two hits for the source dir: the build dir and the jar. Not really what I would have expected. So now I have to ignore the one also retrieved via AntArtifactProvider and keep my fingers crossed, that other implementations work similiar. Maven1 seems o.k. so far, but I have to admit Milos has a point, that the all the contracts are quite complex. Better definition for all usecases would be helpful.
Tom Ball asked for something similar, I think for the background compiler? And I'm sure there are other places where this is used. Sven - yes after taking EXECUTE - COMPILE and filtering for SFBQ(root) == source, you could get both build/classes/ and build/*.jar. It depends on the project. IIRC all project types in NB will produce only build/classes/. You need to decide which you care about. Probably what is wanted is something like public static Result SourceForBinaryQuery.findBinaries(URL sourceRoot); Default fallback impl would use current recommended algorithm. But a project (owner of sourceRoot) could have some impl of public interface BinaryForSourceQueryImplementation { SourceForBinaryQuery.Result findBinaries(URL sourceRoot); } Standard project types (J2SE, web, J2EE, freeform, NBM) would need to implement it. It would still be up to the caller to decide what to do with this information. For example, the background compiler might want to use only flders, not JARs.
So there is work being done on a background compiler - would be nice for all byte code analysis tools to use (sounds similiar to some Eclipse feature;-)
The background compiler is currently something different. It does only parse, resolve, dataflow stages and it is used for error marking in the editor. The correct code for getting the project output for source root it not trivial and it should be as a helper method somewhere in the java/project or java/api.
Slightly off-topic, but how would people feel to Jackpot compiling classes which are out-of-date to their source files when it's run? I'm working on eliminating the "start session, transform, end session" mode, and am using class files for its symbol cache. Since I already use the project's javac options, storing the results in the build directory would eliminate redundant compiling. It might be surprising to have the project up-to-date without explicitly running a compilation task, but auto-compiling is becoming a popular requested feature in other IDEs.
Just better summary. "Artifact" is used for Ant targets specifically, and that is not what is wanted here.
Ought to be considered for 6.0.
Is this coming in 6.0? I did the trick with the ClassPaths for the aspectj module andf it worked under windows. however under linux the path that I get is interpreted differently. It is hard to find out how to get it working there without stopping it from working under windows ... We really need this.
It should be easy to introduce such an API into the NB 6.0 and add the implementation for j2se project type. Since it will be a new API and old project types will not need to implement it you probably cannot relay on it.
We can introduce a new SPI but make it optional. For cases where there is no SPI impl found, the matching API should use the currently recommended algorithm using ClassPath and SourceForBinaryQuery. See my comments of Jan 31 2006.
I think you will do the right thing. I only wanted to note that, also after having read some implementations of the adapters for the aspectj API for other IDEs, it is not very easy to know what the names of the methods here mean or what they are for compared with methods like project.getOutputPath(). My two cents worth
This API can be useful also for non java projects. I will put it rather into the projectapi than into the java/api.
"This API can be useful also for non java projects. I will put it rather into the projectapi than into the java/api." - huh? SourceForBinaryQuery is in java/api, since it is clearly specific to the Java compilation model. The proposed BinaryForSourceQuery would be nearly the exact inverse of SFBQ so it should be in the same package. What would such a query mean for a non-Java project? I cannot think of a simple, consistent definition that would not mention Java classpath semantics. (Remember that we are not looking up a general output dir for a project, e.g. $prj/build. We are looking for e.g. $prj/build/classes from $prj/src, or $prj/build/testclasses from $prj/test.)
Checking in manifest.mf; /cvs/java/api/manifest.mf,v <-- manifest.mf new revision: 1.17; previous revision: 1.16 done Checking in doc/changes/apichanges.xml; /cvs/java/api/doc/changes/apichanges.xml,v <-- apichanges.xml new revision: 1.14; previous revision: 1.13 done RCS file: /cvs/java/api/src/org/netbeans/api/java/queries/BinaryForSourceQuery.java,v done Checking in src/org/netbeans/api/java/queries/BinaryForSourceQuery.java; /cvs/java/api/src/org/netbeans/api/java/queries/BinaryForSourceQuery.java,v <-- BinaryForSourceQuery.java initial revision: 1.1 done RCS file: /cvs/java/api/src/org/netbeans/spi/java/queries/BinaryForSourceQueryImplementation.java,v done Checking in src/org/netbeans/spi/java/queries/BinaryForSourceQueryImplementation.java; /cvs/java/api/src/org/netbeans/spi/java/queries/BinaryForSourceQueryImplementation.java,v <-- BinaryForSourceQueryImplementation.java initial revision: 1.1 done RCS file: /cvs/java/api/test/unit/src/org/netbeans/api/java/queries/BinaryForSourceQueryTest.java,v done Checking in test/unit/src/org/netbeans/api/java/queries/BinaryForSourceQueryTest.java; /cvs/java/api/test/unit/src/org/netbeans/api/java/queries/BinaryForSourceQueryTest.java,v <-- BinaryForSourceQueryTest.java initial revision: 1.1 done Checking in overview.html; /cvs/java/project/overview.html,v <-- overview.html new revision: 1.6; previous revision: 1.5 done RCS file: /cvs/java/project/src/META-INF/services/org.netbeans.spi.java.queries.BinaryForSourceQueryImplementation,v done Checking in src/META-INF/services/org.netbeans.spi.java.queries.BinaryForSourceQueryImplementation; /cvs/java/project/src/META-INF/services/org.netbeans.spi.java.queries.BinaryForSourceQueryImplementation,v <-- org.netbeans.spi.java.queries.BinaryForSourceQueryImplementation initial revision: 1.1 done RCS file: /cvs/java/project/src/org/netbeans/modules/java/project/ProjectBinaryForSourceQuery.java,v done Checking in src/org/netbeans/modules/java/project/ProjectBinaryForSourceQuery.java; /cvs/java/project/src/org/netbeans/modules/java/project/ProjectBinaryForSourceQuery.java,v <-- ProjectBinaryForSourceQuery.java initial revision: 1.1 done Checking in src/org/netbeans/modules/java/j2seproject/J2SEProject.java; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java,v <-- J2SEProject.java new revision: 1.73; previous revision: 1.72 done RCS file: /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/queries/BinaryForSourceQueryImpl.java,v done Checking in src/org/netbeans/modules/java/j2seproject/queries/BinaryForSourceQueryImpl.java; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/queries/BinaryForSourceQueryImpl.java,v <-- BinaryForSourceQueryImpl.java initial revision: 1.1 done RCS file: /cvs/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/queries/BinaryForSourceQueryImplTest.java,v done Checking in test/unit/src/org/netbeans/modules/java/j2seproject/queries/BinaryForSourceQueryImplTest.java; /cvs/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/queries/BinaryForSourceQueryImplTest.java,v <-- BinaryForSourceQueryImplTest.java initial revision: 1.1 done Checking in projectapi/src/org/netbeans/api/project/Project.java; /cvs/projects/projectapi/src/org/netbeans/api/project/Project.java,v <-- Project.java new revision: 1.17; previous revision: 1.16 done