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.
The create RESTful Web Services from Patterns wizard does not work correctly when using Maven. The project is created, but the POM file has links to unknown binaries, and it adds an unknown binary repository. The application will deploy since it uses the javaee-web-api which includes a version of JAX-RS on GlassFish 3.1.2. As a result, I marked it as a P2. The error is only present when you select an EE 6 server: GlassFish 3+. If you use the same wizard for GlassFish 2.1.1 and Java EE 5, it works as expected. I have created a screencast, attached logs, and projects.
Created attachment 116722 [details] messages.log
Created attachment 116723 [details] pom.xml This is the generated POM with errors.
Created attachment 116724 [details] Example Generated Project w/Errors
Added video to Vimeo https://vimeo.com/38507897
*** Bug 209592 has been marked as a duplicate of this bug. ***
*** Bug 209595 has been marked as a duplicate of this bug. ***
I can reproduce this bug with 7.1.1 : pom has wrong content. I cannot reproduce it with 7.2 dev: pom has correct dependencies to Jersey. The pom content is not JAX-RS component issue. JAX-RS client code just uses ProjectClassPathModifier to extend classpath. So it's the Maven area issue. Reassigning to evaluate. Some additional details: 7.1.1 behavior differs from 7.2 behavior. - In case JEE6 profile 7.2 doesn't add Jersey into the classpath at all ( JAX-RS is a part of JEE6 spec ). - 7.1.1 adds Jersey into the project's classpath . On the other hand if 7.2 project has no chosen target GF server then Jersey will be added into the project's classpath. So 7.2 has no the issue in both cases: - Project with target J2EE server because Jersey libs are not added to the CP. - Project without target J2EE server because Jersey deps are added CORRECTLY into the pom.
(In reply to comment #7) > I can reproduce this bug with 7.1.1 : pom has wrong content. > I cannot reproduce it with 7.2 dev: pom has correct dependencies to Jersey. > The pom content is not JAX-RS component issue. > JAX-RS client code just uses ProjectClassPathModifier to extend classpath. > So it's the Maven area issue. Reassigning to evaluate. "unknown.binary" is added when the maven support cannot reliably figure out the maven coordinates for the binary/library supplied in the ProjectCPModifier. So either the library definition is most likely missing "maven-pom" volume with proper reference to the maven repository coordinates. All libraries by default in netbeans should have this volume configured. As a fallback we also check the SHA1 and compare it to our index of central repository. Please note that this is just a fallback and should not be relied on. But in this case it also failed.
reassigning back to webservices for further evaluation.
(In reply to comment #9) > reassigning back to webservices for further evaluation. I'm not an expert in maven. I just know the following: - As I already said : all works fine in 7.2 dev - There were no changes in Jersey lib module since Jersey 1.8 lib update. So please investigate the problem from Maven point of view and point me WHAT EXACTLY wrong in Jersey lib. You comments is not an evaluation. It is just an thoughts why it works as bug states.
One more thing I forgot to say : there are two options for Jersey libraries. - Nb bundled Jersey - Set of jar files bundled with GF server. NB bundled Jersey lib is used when no server is chosen. That's why 7.2 dev has a correct pom file. Default option is use server bundled Jersey and it means that Jersey related jars INSIDE GF server distribution is used . It means that there is NO NB library at all . And it is impossible to provide "maven-pom" volume : added jars are unknown for NB.
I'll investigate further, however please note that using the CP Modifier is inherently unreliable (especially without a maven-pom volume for libraries), and as such it would be better in the long term if the web services support would add relevant maven dependencies (maven dependency coordinates directly) through the maven support api).
P1->P2, some dependency is added (and unknown binary is designed to be a working backup solution so frankly it could even be P3, but...) , reporter himself claims it's filed as P2..
If I try to search for jackson-core-asl.jar from glassfish-3.1.2/glasshfish/modules/ on search.maven.org by the sha1 checksum, I get no results. but there appear to be *some* versions of jackson-core-asl on central though: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.codehaus.jackson%22%20AND%20a%3A%22jackson-core-asl%22 Now let me elaborate why relying on repository search (by sha1) is inherently unreliable. 1. We search across all known repositories. By default only central is known only by default, but based on opened maven projects, the list of repositories can expand. Therefore you have mutable search domain even for a single user. 2. Local repository is also scanned, content of local repository cache is based on previous user history, therefore mutable from user to user and in time for a single user. 3. Downloading the index from central takes forever to download, if user exits before the index is downloaded and processed, the local index cache will be empty lucene document (and return no results), until tried again. Default time to try again is 1 week later. 4. even if you get the same "version" of the artifact locally, but the maven version is not *exactly* the same, you get no hits. That often happens when LICENSE file or something similar is injected into the maven version and not the product version and vice versa.. the way of uniquely recognizing a maven dependency is to provide repository url, groupId, artifactId, version (and optional classifier, type). Anything else is just guesswork bound to fail occasionally. That's what happened here I believe. The most likely causes of the failure here are 1. and 4. Please verify that the artifacts you want to add to the maven project are actually present in any maven repository (apparently they are not in central). Then the cause of the problem is 1. Otherwise it's probably 4. reassigning back to webservices, I don't see what can be done on maven side to fix the issue. BTW is anything else broken with the project apart from the "unknown.binary" maven coordinates?
(In reply to comment #14) > If I try to search for jackson-core-asl.jar from > glassfish-3.1.2/glasshfish/modules/ on search.maven.org by the sha1 checksum, I > get no results. > but there appear to be *some* versions of jackson-core-asl on central though: > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.codehaus.jackson%22%20AND%20a%3A%22jackson-core-asl%22 > > Now let me elaborate why relying on repository search (by sha1) is inherently > unreliable. > 1. We search across all known repositories. By default only central is known > only by default, but based on opened maven projects, the list of repositories > can expand. Therefore you have mutable search domain even for a single user. > 2. Local repository is also scanned, content of local repository cache is based > on previous user history, therefore mutable from user to user and in time for a > single user. > 3. Downloading the index from central takes forever to download, if user exits > before the index is downloaded and processed, the local index cache will be > empty lucene document (and return no results), until tried again. Default time > to try again is 1 week later. > 4. even if you get the same "version" of the artifact locally, but the maven > version is not *exactly* the same, you get no hits. That often happens when > LICENSE file or something similar is injected into the maven version and not > the product version and vice versa.. > > the way of uniquely recognizing a maven dependency is to provide repository > url, groupId, artifactId, version (and optional classifier, type). Anything > else is just guesswork bound to fail occasionally. That's what happened here I > believe. The most likely causes of the failure here are 1. and 4. > > Please verify that the artifacts you want to add to the maven project are > actually present in any maven repository (apparently they are not in central). > Then the cause of the problem is 1. Otherwise it's probably 4. > > reassigning back to webservices, I don't see what can be done on maven side to > fix the issue. BTW is anything else broken with the project apart from the > "unknown.binary" maven coordinates? Why do you describe me Maven related details ? Here are the facts: - There are some set of jar files on the local filesystem ( they are part of GF installation ). - It is not NB library. So I cannot provide any additional information. - ProjectClassPathModifier is used to extend classpath. The ProjectClassPathModifier API is used and I don't need to know the project essence : I just need to have jar files in the project's classpath. The result is invalid pom file ( as I understand ) . So what can I do from my side ? There are two problems: - Invalid pom file . This is definitely the Maven area issue. If pom file is valid then issue could be closed. - Deps cannot be identified. ProjectClassPathModifier should throws some exception or do something else to deny claspath modification if there is no possibility to add jars. As I understand it is possible to add jar files into the CP without having them in some external repository ( refer them locally ). I lower the priority if the bug: it is just a question of pom file. The resulting application worked as expected ( JEE6 doesn't require Jersey specific jars ). So there is no real problem on WS side. It's just a question of pom.xml file validness.
(In reply to comment #15) > (In reply to comment #14) > > If I try to search for jackson-core-asl.jar from > > glassfish-3.1.2/glasshfish/modules/ on search.maven.org by the sha1 checksum, I > > get no results. > > but there appear to be *some* versions of jackson-core-asl on central though: > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.codehaus.jackson%22%20AND%20a%3A%22jackson-core-asl%22 > > > > Now let me elaborate why relying on repository search (by sha1) is inherently > > unreliable. > > 1. We search across all known repositories. By default only central is known > > only by default, but based on opened maven projects, the list of repositories > > can expand. Therefore you have mutable search domain even for a single user. > > 2. Local repository is also scanned, content of local repository cache is based > > on previous user history, therefore mutable from user to user and in time for a > > single user. > > 3. Downloading the index from central takes forever to download, if user exits > > before the index is downloaded and processed, the local index cache will be > > empty lucene document (and return no results), until tried again. Default time > > to try again is 1 week later. > > 4. even if you get the same "version" of the artifact locally, but the maven > > version is not *exactly* the same, you get no hits. That often happens when > > LICENSE file or something similar is injected into the maven version and not > > the product version and vice versa.. > > > > the way of uniquely recognizing a maven dependency is to provide repository > > url, groupId, artifactId, version (and optional classifier, type). Anything > > else is just guesswork bound to fail occasionally. That's what happened here I > > believe. The most likely causes of the failure here are 1. and 4. > > > > Please verify that the artifacts you want to add to the maven project are > > actually present in any maven repository (apparently they are not in central). > > Then the cause of the problem is 1. Otherwise it's probably 4. > > > > reassigning back to webservices, I don't see what can be done on maven side to > > fix the issue. BTW is anything else broken with the project apart from the > > "unknown.binary" maven coordinates? > > Why do you describe me Maven related details ? Because I thought your interest is not only to get rid of the issue from your dashboard. > Here are the facts: > - There are some set of jar files on the local filesystem ( they are part of > GF installation ). > - It is not NB library. So I cannot provide any additional information. > - ProjectClassPathModifier is used to extend classpath. The mentioned "facts" are the reason why the end result sucks and it's your fault. > > The ProjectClassPathModifier API is used and I don't need to know the > project essence : I just need to have jar files in the project's classpath. > The result is invalid pom file ( as I understand ) . > So what can I do from my side ? > > There are two problems: > - Invalid pom file . This is definitely the Maven area issue. If pom file is > valid then issue could be closed. I don't see invalid pom in my IDE, all I see is a bunch of artifacts with made up maven coordinates. > - Deps cannot be identified. ProjectClassPathModifier should throws some > exception or do something else to deny claspath modification if there is no > possibility to add jars. > As I understand it is possible to add jar files into the CP without having them > in some external repository ( refer them locally ). > that's what the implementation is doing. > I lower the priority if the bug: it is just a question of pom file. > The resulting application worked as expected ( JEE6 doesn't require Jersey > specific jars ). So there is no real problem on WS side. It's just a question > of pom.xml file validness. Closing as wontfix as there is nothing we can do on maven side and there's no interest to fix on webservices side.
I am looking for solutions, and not finger pointing. Closing it out of hand is not a solution.
(In reply to comment #17) > I am looking for solutions, and not finger pointing. Closing it out of hand is > not a solution. Solution for what? to get rid of "unknown.binary"? Then glassfish folks need to publish their bits to central (same bits as then in product), webservices folks need to stop adding random jars to projects and use maven-specific APIs to add well known maven coordinates as dependencies.
Previous versions of the IDE worked fine. I am not an expert on the internal workings of the IDE, but I use it extensively, and my team relies on it working. It is a great product. I am really turned off at the idea that me as a user (customer if you like that term better), gets a WONTFIX response with a bunch of finger pointing responses attached. This is not a vote of confidence. I love the IDE and write about it, use it for my team, train people with it, etc. I want folks to come to the NetBeans product because I tell them that the NetBeans team is responsive to their needs, and solve issues quickly when they arise. Although I don't know the internal technical details, superficially this does not seem to be a difficult issue to fix since it worked previously, and it now does not.
(In reply to comment #19) > Previous versions of the IDE worked fine. I am not an expert on the internal > workings of the IDE, but I use it extensively, and my team relies on it > working. It is a great product. > did previous versions of the IDE use the same version of glassfish? did the webservices support in previous versions add the jars from glassfish or netbeans? Have you read my comments about what all can go wrong? Is my observation about everything working apart the "unknown.binary" groupids correct? > I am really turned off at the idea that me as a user (customer if you like that > term better), gets a WONTFIX response with a bunch of finger pointing responses > attached. This is not a vote of confidence. > We have a saying here that applies to the current situation: "you are crying at the wrong grave". I've explained to webservices what the problem is, there is NO way to FIX it on the maven side and any attempts made to reassign to them was met with resistance . Even if it sounds weird to you by closing it, I've done the fair thing to do. The alternative is to keep the issue open for the next few years. > I love the IDE and write about it, use it for my team, train people with it, > etc. > > I want folks to come to the NetBeans product because I tell them that the > NetBeans team is responsive to their needs, and solve issues quickly when they > arise. > > Although I don't know the internal technical details, superficially this does > not seem to be a difficult issue to fix since it worked previously, and it now > does not. No, it's not that easy. Given that the problem is caused by glassfish jars (with precise SHA1 checksums) not being in central, then the *fix* includes making glassfish folks re-release glassfish for example.
As John says - guys, please refrain from finger pointing, accusations and personal attacks, this is not professional. Now to the issue - same as Denis, I was able to reproduce with NetBeans 7.1.1, but not with 7.2. So isn't this issue fixed in 7.2? John, can you please try if NB 7.2 dev builds behave as expected, or whether there are still issues? I don't understand why this issue was closed as WONTFIX (and later reopened) - shouldn't it be closed as FIXED?
(In reply to comment #21) > As John says - guys, please refrain from finger pointing, accusations and > personal attacks, this is not professional. > > Now to the issue - same as Denis, I was able to reproduce with NetBeans 7.1.1, > but not with 7.2. So isn't this issue fixed in 7.2? John, can you please try if > NB 7.2 dev builds behave as expected, or whether there are still issues? > The different result is only based on what webservices codebase adds into the project (as I have tried to explained above). The maven codebase algorithm hasn't changed for a while (however it does have a few spots that can fail - which I have outlined above - which can explain the failure in 7.1.1 and success in 7.2) > I don't understand why this issue was closed as WONTFIX (and later reopened) - > shouldn't it be closed as FIXED? because "unknown.binary" is a correct result for the usage of the project modifier in the cases I've described above. In case you (meaning webservices codebase) want a better result, you need to use a different means of adding dependencies to maven projects..
> because "unknown.binary" is a correct result Well, for the web services use case, I would consider "unknown.binary" to be incorrect - we should be able to provide a better id. So, IMO this is a valid issue against 7.1.1, and the behavior is correct in 7.2 - marking as fixed. The workaround for 7.1.1 is to use a "IDE-bundled Jersey library" option in the configuration dialog. BTW, see also related issues 206529 and 207682 which aim to improve the behavior in 7.2: the server-bundled library should be added with provided scope. So while addressing these issues, we will need to keep this issue in mind and make sure that we use correct artifact ids; this may need to be implemented on the side of the GlassFish plugin.
Denis, do you know which change/bugfix fixed this issue in 7.2 trunk? Tonda Nebuzelsky suggests we may want to include this in NB 7.1.2 (i.e. the next 7.1 patch).
(In reply to comment #24) > Denis, do you know which change/bugfix fixed this issue in 7.2 trunk? Tonda > Nebuzelsky suggests we may want to include this in NB 7.1.2 (i.e. the next 7.1 > patch). See issue #206527. There are a number of changes. I don't see a reason to port fix from NB7.2 codeline to 7.1.1 because this issue is not really a problem ( and has no a high priority ). As I already said : project works at runtime without problem ( Jersey is not required in the classpath because it is on the server ). The pom file is also correct as I understand. It just has minor issue with its content. Nothing is affected as result. There is also simple workaround ( to prevent change pom file ) : uncheck "Add Jersey library" checkbox.