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.
As stated at issue #230188, we have some limitations during lookup of JavaEE version for Maven projects, mainly Web projects. The most interesting idea is resumed at comment #6 as reproduced below. (In reply to comment #16) > (In reply to comment #14) > > I was wondering if at least for Maven projects this lookup couldn't > > be improved (probably using dependencies versions) > > This is an interesting idea and I think it should be possible. It's not > complicated to go through the project dependencies and lookup if there is an > javaee version specified. But from what I remember this operation can be > possibly expensive so I would say we can check if there is a > netbeans.hint.j2eeVersion and if not, run a background task looking up for > javaee version and set the netbeans.hint.j2eeVersion for the future usages. > What do you think? > > > I am wondering because since we have transparent support for Maven, people can > > freely create JavaEE 7 projects outside the IDE and when the user open it > > inside the IDE we can have issues if we assume JavaEE 6 as default. > > Agree, if we can find some elegant solution I'm 100% for it.. I am sure we need to improve it for the next version already thinking about the evolution of JavaEE for next versions.
Thanks Michel ! Targeting to 7.4.
Fixed in: web-main #fe6694212e3c
Additional improvement done in: web-main #710975731172
Integrated into 'main-golden', will be available in build *201306132301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fe6694212e3c User: Martin Janicek <mjanicek@netbeans.org> Log: #230447 - Improved lookup for JavaEE version for Maven projects
How do you think about this issue [1]? Unfortunately your patch won't work for most projects since today most projects are Java EE 6 and probably are using some specific implementarion :( [1] http://java.dzone.com/articles/trouble-crippled-java-ee-6
(In reply to comment #5) > How do you think about this issue [1]? I probably don't understand the problem here. Could you try to explain, please? > Unfortunately your patch won't work for most projects since today most projects > are Java EE 6 and probably are using some specific implementarion :( Feel free to share any idea how to improve it to work more generically.
(In reply to comment #6) > (In reply to comment #5) > > How do you think about this issue [1]? > > I probably don't understand the problem here. Could you try to explain, please? The issue here is basically that for Java EE 6 we need to use some implementation explicitly. For example, here at work we use the JBoss implementation as follow: <dependency> <groupId>org.jboss.spec</groupId> <artifactId>jboss-javaee-6.0</artifactId> <type>pom</type> </dependency> instead of <dependency> <groupId>javax</groupId> <artifactId>javaee-web-api</artifactId> <version>6.0</version> <scope>provided</scope> </dependency> In these cases, the implemented patch won't work. As you can see in the article, there are others implementations. > > Unfortunately your patch won't work for most projects since today most projects > > are Java EE 6 and probably are using some specific implementarion :( > > Feel free to share any idea how to improve it to work more generically. To it work more generically, I think NB could identify it by keeping a internal mapping between implementations and Java EE spec version (not fancy at all), or maybe NB could simply ask about the right version when it is not possible to determine for sure it The only certainty is that NB should not do any assumption risking to assume some incorrect Java EE version. I will think more about the subject and maybe I can help with some better idea. Do you think I need to file another issue?
I see, thanks for the explanation. Based on your suggestions I'm for: 1/ Create mapping between specific. implementation and their Java EE version 2/ If user works with a different (non-listed) implementation and also other recognition mechanism fails then ask user about Java EE version What do you think? With respect to the point 1/ do you know about some existing list of mostly used implementations? No need to create new ticket, I'm reopening this one.
(In reply to comment #8) > I see, thanks for the explanation. Based on your suggestions I'm for: > > 1/ Create mapping between specific. implementation and their Java EE version > 2/ If user works with a different (non-listed) implementation and also other > recognition mechanism fails then ask user about Java EE version > > What do you think? I think it is awesome. > With respect to the point 1/ do you know about some existing > list of mostly used implementations? I am sorry but I don't have such a list, specially the artifactId's but I found a list [1] where we have (all?) the compatible servers with each Java EE version. AFAIK, the problem is about just Java EE 6, since the original issue are supposed to be fixed for Java EE 7 artifacts. I am not sure if you need to implement something for every compatible server, but probably some of the listed ones are necessary. Personally speaking I think at least all the projects sponsored by Oracle (GF and Weblogic) should be supported as well JBoss, TomEE, Jonas and Geronimo (all the open source basically). I am not sure with all of them have specific maven artifacts, I am just guessing here. I am sorry I can't be more specific :( Thanks in advance. [1] http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html
Thanks a lot !.. I'll take a look at it.
Fixed for servers that are officially supported by NB (Glassfish, WebLogic and JBoss).. http://hg.netbeans.org/web-main/rev/6c5aabc3cb8c
Regarding: > javaEE5.add(new DependencyDesc("javax", "javaee-api", "5.0")); > javaEE5.add(new DependencyDesc("javax", "javaee-web-api", "5.0")); Is that correct? I don't think there is any javaee-api 5.0 artifact, EE 5 APIs work differently: http://central.maven.org/maven2/javax/javaee-api/ Also for glassfish-embedded - did this exist in EE 5? http://central.maven.org/maven2/org/glassfish/main/extras/glassfish-embedded-all/
(In reply to Petr Jiricka from comment #12) > Is that correct? Obviously not, they are not in maven central. > I don't think there is any javaee-api 5.0 artifact Now I have found this one for full profile: http://central.maven.org/maven2/javaee/javaee-api/ > EE 5 APIs work differently So, do you know similar artifact for Java EE 5 Web profile? It's actually quite hard to find information about what is the correct and recommended dependency for a certain application server. I'm not completely sure about weblogic artifact as well, but some articles were pointing to such dependencies and thus I used that one. I simply didn't find anything better. > Also for glassfish-embedded - did this exist in EE 5? Obviously not. I just check what is within Maven central and there is so many "glassfish" related artifacts that I have absolutely no idea what to use for GF v2
> Now I have found this one for full profile: > http://central.maven.org/maven2/javaee/javaee-api/ Good, sounds fine. > So, do you know similar artifact for Java EE 5 Web profile? No, I think the one above that you found is the best. > It's actually quite hard to find information about > what is the correct and recommended dependency I agree - I think we have to live with the knowledge that this detection will be heuristic and approximate. It's not worth to invest too much time into this.
>> It's actually quite hard to find information about >> what is the correct and recommended dependency > > I agree - I think we have to live with the knowledge that this detection will be heuristic and approximate. It's not worth to invest too much time into this. I agree. My only advice is that, if it is not possible to determine it is a safe way, the user just be asked which version the IDE should assume. Any assumption here could be disastrous.
Agree but I think it would make sense to implement it separately. I'll create a new ticket for it. Thanks