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.

Bug 214674 - Maven dependencies are not added using netbeans.version maven property but instead hard code version on new item actions which update dependencies
Summary: Maven dependencies are not added using netbeans.version maven property but in...
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.3
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Milos Kleint
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-24 11:32 UTC by _ wadechandler
Modified: 2012-11-28 02:36 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ wadechandler 2012-06-24 11:32:23 UTC 
I created a new project. The dependencies had as their version numbers ${netbeans.version} for the NB RCP dependencies. Next, I added a new top component by right clicking on a package, New|Window Action, and finishing the wizard. My pom.xml then looked like:
        <dependency>
            <groupId>org.netbeans.api</groupId>
            <artifactId>org-netbeans-api-annotations-common</artifactId>
            <version>${netbeans.version}</version>
        </dependency>
        <dependency>
            <groupId>org.netbeans.api</groupId>
            <artifactId>org-openide-windows</artifactId>
            <version>RELEASE712</version>
        </dependency>

Where the org-openide-windows dependency was added by the form support the common annotations were setup by the new project wizard. This issue causes problems if one forgets to go back and edit their pom and then later need to change the NB version (netbeans.version maven property). This makes it more time consuming to upgrade a maven project where one has multiple modules.
Comment 1 mbastian 2012-07-08 19:54:43 UTC 
I'm having the same issue. Modules should depend on the platform using the netbeans.version parameter instead of hardcoding the current version.

My project has over 100 modules so this is an important issue. Please advise.
Comment 2 _ wadechandler 2012-11-09 21:13:11 UTC 
Milos, I'm adding you to the CC to see if maybe this is something that you would be more suited to look at. The issue isn't just affected by the form module. If one creates an installer (Install.java) for their module it will do the same thing.
Comment 3 _ wadechandler 2012-11-16 08:54:55 UTC 
I noticed that my IDE apparently has some kind of a reference to RELEASE701 platform which my projects did use to use at some point in the past. I'm using 7.2 (all the updates). My project depends on RELEASE721 platform in the netbeans.version property now. So, I apparently haven't registered any actions using annotations on this project. I just used the wizard to create an action, and it added the missing artifacts with RELEASE701. So, I had a mismatch of RELEASE721 by way of netbeans.version and these 701 artifacts.

I didn't manually open pom.xml and look right away. I tried to build. I kept getting these crazy signature mismatches under the hood from the annotation processor. I decided to look in pom.xml after I sucked up a bunch of time, silly me I know, trying to comment out annotations in the new action I just created thinking it was something related to that since this was the only change I was mentally aware and thinking about. About 30+ minutes later I was like...surely something is hosed in my POM, and sure enough there were the 701 artifacts. I changed those to the 721 and everything built fine, but what a PITA to track down.
Comment 4 Milos Kleint 2012-11-22 08:51:14 UTC 
the way we map module's codenamebase to maven GAV, it's a miracle we even find the proper artifact and proper version.

1. we attempt to find an open nbm-application project containing the current project, if found, we try to extract the dependency module jar from the assembled application there. If found, we use it's SHA1  to query the netbeans.org index to find a match.
2. if one fails, we assume groupID to be org.netbeans.api as that's what vast majority of api modules have, and file templates use public apis mostly. The version either comes from the template (rare) or we try to iterate existing dependencies and use the same version with fingers crossed.
3. then there is more backup there, but apparently that hardly ever happens or someone would report it as bug.. 

finding the effective version is significantly easier than the actual value written in the pom file. The effective one is just at one place, the unresolved value can be more or less anywhere. Current pom's <dependencies> section, current pom's <dependencyManagement> section, parent pom's <dependencies> or <dependencyManagement>, <profiles> section in any of the files as well.
Cannot rely on the netbeans.version either, could be named in any way.

we use hardcoded version as it works most of the time, and that's the general approach we take for any pom.xml file editing. The rules are 1. only edit the current file, never parents, 2. also write the simple thing that works, as the realities of user edited poms are endless.
Comment 5 Milos Kleint 2012-11-23 15:12:42 UTC 
I'm proposing the following heuristics.
The version evaluation will continue to be done the same way, once we have a version, we will check if netbeans.version property exists in resolved pom and if the value equals to the version we have deduced. if so, we use the $[netbeans.version} expression. The downside here is that it will work exactly for netbeans.version property only, not for arbitrary property that could have been used by the user. But given that the  majority of users is likely sticking to what we generate in the archetypes, it's probably a safe bet with more winners than loosers.
Comment 6 Milos Kleint 2012-11-26 12:29:07 UTC 
http://hg.netbeans.org/core-main/rev/95b17e627457
Comment 7 Quality Engineering 2012-11-28 02:36:11 UTC 
Integrated into 'main-golden', will be available in build *201211280002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/95b17e627457
User: Milos Kleint <mkleint@netbeans.org>
Log: #214674 when resolved version equals value of netbeans.version, use the expression instead of the real value.