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.
We have a scenario in which we have generated code and hand edited code in a module. We want to keep the generated source separate from the hand edited source in separate source root for several reasons: 1. Accidental editing of generated code (I know this can be handled by other means). 2. Use a simple .cvsignore to prevent generated source root from being checked in.
You can already do this by editing project.xml. See harness/README as well as numerous examples in netbeans.org. No plans to support this in the GUI, since you will anyway certainly need to make idiosyncratic build.xml additions.
Basically this is what we want to achive: Module Project/ src/ sources... gen/ sources... build/ classes/ classes from src/ classes from gen/ module NBM containing the classes from src/ and gen/ and exported using <public-packages>. Can you point us to an analogous example in netbeans.org? BTW: harness/README is not harness/release/README correct?
The README file seems to talk about something else, like class path extension and additional jars building (like from antsrc), which is not what we are talking about. We need to build the module jar from more that one source dirs (not only from src). There doesn't seem to be a dev (GUI) support for having more than one source directory (beside src), also in the project itself (when you open it in the IDE). Also it is important that if you make other project dependent on this one (which has more than one source dir), that the classes from the all the source dirs are made visible in the dependent projects, which doesn't seem to be there either. If there is such example, please point to it concretely. We couldn't find it,
harness/README in distro, not sources. These modules have multiple source dirs, which appear in the Projects tab: $ fgrep -l extra-compilation-unit */{,*/,*/*/}nbproject/project.xml ant/nbproject/project.xml autoupdate/nbproject/project.xml db/nbproject/project.xml jemmysupport/nbproject/project.xml monitor/nbproject/project.xml scripting/nbproject/project.xml utilities/nbproject/project.xml ant/browsetask/nbproject/project.xml ant/project/nbproject/project.xml apisupport/ant/nbproject/project.xml apisupport/harness/nbproject/project.xml apisupport/project/nbproject/project.xml contrib/mount/nbproject/project.xml debuggerjpda/ant/nbproject/project.xml java/j2seplatform/nbproject/project.xml jemmy/idemodule/nbproject/project.xml performance/insane/nbproject/project.xml web/jspparser/nbproject/project.xml web/project/nbproject/project.xml websvc/core/nbproject/project.xml websvc/registry/nbproject/project.xml xml/tax/nbproject/project.xml contrib/editorhints/spi/nbproject/project.xml though I don't know if any exactly match what you (Sandip) are talking about. Probably you don't actually need an <extra-compilation-unit> since you do not expect the sources to be hand-editable, though it may be useful for source stepping during debugging. Probably you want to make 'compile' depend on a custom source gen & compile step and then include the output in ${cp.extra}; you may also need to override 'jar' to include the extra classes. Or it may suffice to compile gen src to regular build/classes (and put that in ${cp.extra}) in which case no need to override 'jar', though this is a bit of a hack. If you work it out feel free to write it up as a FAQ. There are some nb.org projects using <schema2beans> but all currently generate sources to the main source dir, which is bad but no one has gotten around to fixing them. "if you make other project dependent on this one (which has more than one source dir), that the classes from the all the source dirs are made visible in the dependent projects, which doesn't seem to be there either." - works for xml/tax AFAIK. There is intentionally no GUI support for configuring multiple source roots, since the GUI could not properly set up everything incl. build support. There is planned GUI support for configuring <class-path-extension>s but this will be limited to either prebuilt JARs or (perhaps) independent Java projects.
Yeah, those modules use the extra-compilation unit, which is different from what do we need. We need to compile the sources into the module jar, not to extra jar... and to compile them at the same time... we just want to keep them separated from the hand-edited ones.... your modules using the generated code put them into the same dir.... and the extra-compilation unit produces some extra jar... so we need the support for another source directory, let say gensrc, while the sources from src and gensrc are compiled together into the module jar. Is that clear now?
Please reread "Probably you want to make 'compile' depend...". There are no existing examples because no one has tried to do precisely this before. You will need to work out the details for yourself. Feel free to modify the build systems of one of the schema2beans-using modules to serve as a permanent example.
Sorry for constant reopening (probably too hight priority set), but it seems we are misunderstanding each other. No, we don't want to do the compilation of the generated sources into some extra jar, that would be covered by the extra-compilation unit. But that is not what we need. We need to have the sources compiled in the same (not extra!) compilation unit like the default ones. I.e. to compile the sources from the generated dir (e.g. gensrc), and the default source dir (src) together, at the same time, into the same module jar. There is probably a need to specify source dirs for the project, which would be used by the default targets. Currently it seems it is possible to specify only one such dir (via src.dir property I think). Of course we probably could achieve the above by heavy hacking/overriding of the build script, but that is what we want to avoid. We'd like to have a full dev support (apisupport) for this too. We think that it is a quite legitimate demand to have more than one source dirs for the module jar, (please, don't mix it with the extra comp units). And that it will be demanded also by other third party users sooner or later. Is it better explained now? Or I is it me who is missing something?
1. If you really need to have src and gensrc depend *on each other* (i.e. references can go in either direction) then you will need to override 'compile' to do this instead of the regular call to <javac>. 2. More likely, you want to create gensrc first and then have src compile against it; or vice versa. Either way, you would override 'compile' to do extra steps in addition to the regular call. That I said before. 3. Sorry, you just need to override build targets. That is what they are there for. I do not expect the overrides to be "heavy"; probably one or two targets, depending on what exactly you are doing. No changes to the harness are planned. I don't dispute that a significant number of module projects (though clearly a minority) will need either additional source roots or generated sources - but the details are likely to be idiosyncratic enough that out-of-the-box harness and GUI support is impractical. Should the harness come with built-in support for schema2beans? Hibernate? RMI? JAX-WS 1.0? Backport177? All of the above? Note: <extra-compilation-unit> has no effect on the build whatsoever. It is merely a declaration of editable sources in the project, to be displayed in Projects with proper code completion acc. to your declared classpath. Much like a <compilation-unit> in a freeform project. For generated sources it is probably inappropriate. Again, a good permanent example would be one of the schema2beans-using modules, which as I understand it is similar to your case.
In our case it is the No 1 scenario, there are the dependenciess on each other... Hm, you are saying to override the compile target entirelly. I don't like that kind of solution, that is a hack from my point of view, not a support. It would mean to maintain such overriden target, in the sense of all other properties, dependencies on other targets, which you will certainly change in the future and other things. Also I am not sure it would have the full support from GUI point of view. By full support, I don't mean supporting of schema2bean, hibernate or anything such from building system point of view. I just need a support to have more than one source dir in the project and at the same time the ability to work with the sources (in the IDE) like they would be in the default src dir. Also those classes from those additional source dirs should be visible in other projects, if those projects will depend on that one (with regards of the public packages), and that also the packages will be offered in the GUI wizard.. (to make them public etc) etc., there are for sure more things as well. I am not sure that would work with your suggested solution, at least it didn't seem when we were trying it (, because we were trying to use it the way to override the targets and using the extra-comp units). The schema2beans is not a good example for us, all the modules, which use it, (AFAIK) generate the sources into the default src dir, not to separate one. OK, but I am giving up this. Let give a chance to others to explain it too.
"you are saying to override the compile target entirelly. I don't like that kind of solution, that is a hack from my point of view, not a support. It would mean to maintain such overriden target, in the sense of all other properties, dependencies on other targets, which you will certainly change in the future and other things." - right; sorry, but I don't see any way around that. You want custom build steps, you have to write them. We do try to avoid making harness changes which would break existing override targets, though it's not always going to be possible. Maybe some clever usage of <presetdef>s would reduce the maintenance overhead. "I just need a support to have more than one source dir in the project and at the same time the ability to work with the sources (in the IDE) like they would be in the default src dir." - that is <extra-compilation-unit>. "Also those classes from those additional source dirs should be visible in other projects, if those projects will depend on that one (with regards of the public packages)" - if by "visible" you mean "popup Javadoc available in code completion" then again you would need to use <extra-compilation-unit>. If by "visible" you mean "accessible to the compiler" then you simply need to make sure you build the extra classes into the right JAR and set the right public packages. "the packages will be offered in the GUI wizard" - packages in <e-c-u>s are made available in the New File wizard. "(to make them public etc)" - but they are intentionally excluded from the GUI customizer for public packages. If you are actually building them into the module JAR then of course you can edit project.xml to include the right public packages yourself. The properties dialog is intended to handle usual cases that would be routinely tested, not exotic modifications to project structure. Note: there is not currently a way to provide an <e-c-u> which provides only a JAR -> source association but doesn't display its packages in the GUI. You can either use an <e-c-u> and just remember not to edit anything in it; or use e.g. Library Manager to do the association (will be sharable in a future NB version). Would be easy enough to fix but would require an apisupport schema change which is not really an option in the near future. "The schema2beans is not a good example for us, all the modules, which use it, (AFAIK) generate the sources into the default src dir, not to separate one." - exactly my point. They generate sources into ${src.dir} because the maintainers of these modules failed to cleanly separated the generated sources. So if you fix one of them then the fixed configuration will serve as an example to others. However if your modules involve 2-way interdeps between generated and primary sources then the analogy would not be useful to you anyway.