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.
It is not clear from the requirements (http://jarpackager.netbeans.org/requirements.html) why jarpackager should have dependency on java module. This is a design flaw and this needs to be removed.
Well, than it's a design flaw in the project apis, as it is not possible to create a remote Java resource without using Java's specific JavaDescriptor. But , it seems quite natural to me for a module for JARs to depend on JAVA as JAR is an integral part of Java. Or JarPackager would have to be split into a generic Packager and java specific JAR Packager. But nobody wants a generic Packager.
I partly agree. It is flaw in Java module that it requires a build target to provide JavaDescriptor to make it possible to add it as a RemoteResource. Instead the Java module should allow to create a resource that is added to classpath from any build target. The user is responsible for making sure that that build target produces something that can be added to classpath. This is the same as when you are adding a folder to classpath -- the java module also does not ensure that the folder contains classes and it does not prevent you to add it as classpath root. Also note that the fact that it is a jar build target does -not- mean that it can be added to classpath anyway. Reopening, please fix this.
Sorry, but I missed what should be fixed then. Could you please restate the problem?
I will try to. Remove the registration of JavaDescriptor on jarpackager build target. Let java module to solve the problem with remote resource pointing to jarpackager build target. This is the same as when java creates a (non-remote) resource from jar file -- they should handle adding it to classpath. Eventually also remove the dependency on RootedFileSet when 33905 gets fixed. The user requirements published at jarpackager.netbeans.org do not make it clear why jarpackager is conntected to java in this way. Still missing api-level requirements. I guess that there are modules that want generic packager. E.g. the web module does.
closing according to proposed changes to 4.0 plan