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.
-create new web application (check "Use dedicated folder for storing libraries" and set the folder to be "./libs2") -d'n'd Amazon S3 Buckets service -> itemSearch into JSP => AmazonS3Bucket.jar is added to project libraries, but: -it's not in the defined shared "./libs2" folder -removing the jar from the project does not remove it from the file system -it's compiled by the JDK on which the IDE is running regardless of which JDK is set for project - this can lead to serious issues when someone tries to send his project to someone else - there's no way how can one easily refresh the jar in the project without doing another d'n'd
Lukas, is this really a p1? Also, can we change this into an enhancement request? The reason being is that the proper way to do what you are asking for in the bug is to integrate with the jaxb binding feature which we were thinking about implementing but didn't have the time. We can then take advantage of the refresh capability from jaxb binding.
Is there some simple answer on what do we expect from a user who runs IDE on jdk6 and the server on jdk5 to be able to use that jar? What should user do if I he is running the IDE on jdk5 and someone else sends him project created in the IDE running on jdk 6? Should we prepare two versions of a sample in our tutorials (one for users on jdk5, second for those using jdk6) - if there will be any? What I did today to run a sample I received by email was: -clean the project -remove the jar from libraries -d'n'd service which was used by the project to some dummy class -run project => failed -again remove the jar from libraries -delete it from ./lib directory -again d'n'd service which was used by the project to the dummy class -run project => succeed Could we at least somehow simplify these required steps? Or do we want to point users to some FAQ so they get to know what to do? Note that package-info.java compiled on jdk6 with target=1.5 is not compatible with jdk5
The jdk mismatch issue between the IDE and appserver is really a generic issue and we can work around this by telling users to use the same jdk on both sides. So, I am not too concern about this. As for the sample projects for the tutorial, we can always just include a skeleton project without any generated code and libraries and tell the users to fill in the blanks via DnD. So, I don't think this is a big issue, either. Also, we can add a trouble shooting section at the end of tutorial to tell the users how to clean up the jaxb libraries. As I mentioned earlier, to fix this properly, we need to integrate with the jaxb binding feature (which doesn't solve the jdk issue between ide and appserver) but will solve the issue with sharing the project. This will also require Girish to implement an api for the jaxb binding feature. This is just not going to happen for 6.1.
re jdk mismatch issue - NetBeans projects as well as JAX-RPC and JAX-WS support are able to handle this by using java/javac from project defined JDK (Java Platform in project properties -> libraries) - user can run IDE some JDK (5, 6, 7) but he is allowed to develop particular application against any arbitrary JDK (well only versions >= 5 are important for us) - so I'm afraid that it is not only about jdk vs appserver case btw: JAXB is not able to handle this correctly - issue 131878 re samples and trouble shooting - possible solution but I personally would not like to see there more than 2-3 required steps re integration with the jaxb binding feature - is somewhere described how this should work? I'd be very interested in checking/reviewing it if you want
Here is what I think how the feature should work using the jaxb binding feature: If a schema is required for a drop operation, we would programmatically add a jaxb node to the project with the required schema. Then the generation of the jaxb jar file would be done by the project and not by the web service manager. This would solve the jdk version issue you mentioned. In addition, you don't need to delete the existing jaxb jar manually. Instead, you just do a clean build and the jaxb jar file will be regenerated using the project-specific jdk.
Yes, that's exactly how I think it should work and it is clear that proper solution depends also on issue 131878. Anyway for 6.1 could we, for building jaxb artifacts, do ie sth like: -check <userdir>/build.properties for "platforms.JDK_1.5.home" (that's default name, correct name - if any - can be found using Java Platform API) if (found) then use jdk5 for jaxb jar build (see ie javac macro in javase project's build-impl) else use what's default this way the "trouble shooting" would be to register jdk5 in the IDE and call refresh on the node (before doing d'n'd) - I think this could help us to cover at least some possible cross platform issues. What do you think?
I think we are already doing that. We are using enterprise5/modules/ext/build-jaxb.xml to build the jaxb jars. The build script already take into account the build.properties under userdir.
Created attachment 59616 [details] improvement for build-jaxb.xml to compile against jdk5 if available, fallback to default jdk
No, we aren't. We use build.props only for finding out correct path for JAX-WS library. Build script with applied patch I attached would be able to compile jaxb artifacts against default JDK 5 (if available) and against the JDK on which IDE is running (as a fallback). Second part of the fix would be to not use "platforms.JDK_1.5.home" but "platforms.${name}.home" where "name" would be passed to the script by an action which runs it and would be set to the name of some jdk5 platform name found using Java Platform API. Similar patch should be applied also to "build-ws.xml" script with one difference - we should make sure that we will generate JAX-WS 2.0 compatible artifacts
I am reassigining this issue to Girish to get his input. Girish, please let us know if you are ok with this patch. After you are done, please reassign the issue to Rico so he will check to see if the same patch is ok for build-jaxws.xml.
Actually I am not sure which module owns "enterprise5\modules\ext\build-jaxb.xml" . JAXB Wizard module creates build scripts inside each user project at <project>/nbproject. JAXB Wizard always uses JAXB Jar's packaged with Netbeans IDE, user can override it by changing the project properties. Ex: jaxbwiz.xjcdef.classpath=${libs.jaxb21.classpath} jaxbwiz.xjcrun.classpath=${libs.jaxb21.classpath} To compile it uses IDE JDK as Java SE project does for compiling other sources. Java SE project uses JDK platform associated with project to run the application. When plat for is JDK 6, endorsed directly mechanism is used to override platform JAXB libraries.
Girish, I just realized that this is a new script that Nam put into saas.websvc.api module. Thanks for looking into it.
Though I do not own "enterprise5\modules\ext\build-jaxb.xml", below are some comments, other than these changes looks Ok to me. In ${platforms.JDK_1.5.bootclasspath} , "JDK_1.5" is may not be constant if user more than one JDK 1.5? Also will this allow user to override JDK 6 JAXB Jars with NB IDE, especially early version of JDK 6 has JAXB 2.0.
re To compile it uses IDE JDK as Java SE project - this is not true - java se project defines its own javac/java macro which is later used instead of Ant's javac/java task. This macro calls Ant's javac/java task with "executable" attribute pointing to javac/java binaries from JDK associated with particular project - so project sources are always compiled/run by project defined JDK. re "JDK_1.5" - that's a default name for JDK 5 Java Platform Manager suggests to use if one is registering jdk 5 in the IDE running on jdk 6 (or 7...) - therefore I suggested to pass correct name of the platform in the action which runs the script. OTOH I could live with a check for the defaults only. re possible JAXB version conflict - great feature of xjc/JAXB is that it is backward compatible - you can generate artifacts by 2.1 and it is guaranteed that they will run on 2.0[1] (best would be to always generate 2.0 artifacts and compile them by jdk5 by default) [1]: source attribute - Specify which version of the schema compiler to use. Must be either "1.0", "2.0", or "2.1". The compiler will parse XML Schema and bind them according to the rules specified by the given version of the specification. Note that 2.1 is backward compatible with 2.0, so these two flags won't make any difference. from: https://jaxb.dev.java.net/nonav/2.1.6/docs/xjcTask.html
The patch looks good and I just checked in Lukas suggest patch into the trunk: http://hg.netbeans.org/main/rev/40e006b05601 Lukas verify and let me know if it is ok to transplant it to the release61 branch.
v. in trunk (I'd only remove verbose="true" from the patch for 6.1)
Fix merged into release61 http://hg.netbeans.org/release61/rev/3eae11a2a11c
v.