Bug 197577 - Per-Project Group Maven version
Per-Project Group Maven version
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Maven
6.x
All All
: P1 with 5 votes (vote)
: 7.4
Assigned To: Milos Kleint
issues@projects
: PLAN
: 198251 200797 203465 (view as bug list)
Depends on: 91031
Blocks: 218145
  Show dependency treegraph
 
Reported: 2011-04-08 14:09 UTC by pekarna
Modified: 2013-04-18 02:22 UTC (History)
7 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pekarna 2011-04-08 14:09:08 UTC
Maven 2 and 3 are not compatible in many aspects (try Hibernate Core 3.3.2 with Maven 3.x).

So I suggest that NetBeans allows setting Maven version per project.
The version to be used would be determined using parents' settings:

1) Each project would have Maven version unset or set.
2) If given project has unset, check it's parent. Recurse.
3) If no parent has Maven version set, use default (global setting).

I guess such recursive options overriding is something to be done for whole project management. Is this being worked on or in plan for 7.x?

Thanks
Comment 1 Jesse Glick 2011-04-08 21:49:07 UTC
There is no such plan.

Inheriting from the parent as you suggest will not necessarily work, since determining what the parent _is_ requires using the Maven embedder, which is 3.x.

What is the particular problem with Hibernate and is it being solved or not?
Comment 2 Jesse Glick 2011-05-05 17:48:20 UTC
*** Bug 198251 has been marked as a duplicate of this bug. ***
Comment 3 Jesse Glick 2011-08-10 20:57:30 UTC
*** Bug 200797 has been marked as a duplicate of this bug. ***
Comment 4 Jesse Glick 2011-10-13 15:42:57 UTC
(In reply to comment #1)
> Inheriting from the parent as you suggest will not necessarily work, since
> determining what the parent _is_ requires using the Maven embedder

There would also be problems using the embedder's model to find the parent when some projects are unloadable (e.g. fresh local repo, build extensions required). Probably need to do a simpler check which can be implemented without the embedder: search up the directory tree until you either find relevant configuration, or no longer find a pom.xml.

This feature should also let you add extra Maven options, similar to Global Execution Options. Needed for some use cases, such as defining a custom localRepository per branch checkout.
Comment 5 Jesse Glick 2011-10-29 00:37:23 UTC
*** Bug 203465 has been marked as a duplicate of this bug. ***
Comment 6 tbrantb 2012-03-20 00:42:37 UTC
I too need per project maven settings. I work for several different clients. Each client has multiple projects. Many of these clients have a custom settings.xml which I must use. Also some legacy projects will not build with maven 3, so client continues to use maven 2. It would be very useful to be able to override the global maven version and settings.xml on a per project basis.
Comment 7 Jesse Glick 2012-03-26 20:27:53 UTC
Please do not move the Version field of an issue forward (only backward).
Comment 8 todorst 2012-07-19 07:52:43 UTC
I also think it would be very helpful to have:

 1. settings.xml in addition to maven home setting in Tools>Options>Java>Maven
 2. possibility to select which maven home and settings.xml is used per project 

Do you plan to implement this functionality in future NetBeans versions?
Comment 9 Milos Kleint 2012-07-19 08:04:49 UTC
the major unknown here is consistency and inter-project dependencies.

 if we had a concept of workspace, the custom maven and settings would be ideal at this level. we only have project-groups however and so far there are no settings associated with that. Setting the right settings file on each project separate is both cumbersome and error prone.
Comment 10 javydreamercsw 2012-07-25 21:56:00 UTC
I still believe that global Maven settings are not the correct way. Is like having java projects compile on Java6 or Java7. There are projects that are not setup to run on maven 2 or 3 so they need to work on their own.

You can specify a java home with maven.repo.local=<path to repo> as seen here: http://stackoverflow.com/questions/6823462/specifying-mavens-local-repository-location-as-a-cli-parameter

That can be handled on a project basis already. Just the need the ability to specify maven home at a project level. Inheritance can be left out of the request as it needs more thoughts?

Any idea?
Comment 11 Milos Kleint 2012-07-26 05:33:33 UTC
(In reply to comment #10)
> 
> You can specify a java home with maven.repo.local=<path to repo> as seen here:
> http://stackoverflow.com/questions/6823462/specifying-mavens-local-repository-location-as-a-cli-parameter

apparently close to noone is using it, otherwise we would get tons of bug reports for things like "I make a change in project A and project B depending on it doesn't see the change in editor" 

> 
> That can be handled on a project basis already. Just the need the ability to
> specify maven home at a project level. Inheritance can be left out of the
> request as it needs more thoughts?

without inheritance or some other bulk concept the feature breaks apart once you reach a certain number of projects opened. 

> 
> Any idea?

there's a perfect workaround even in current released versions, use the --userdir cmd line switch when starting netbeans and use the userdir as you would eclipse workspaces.
Comment 12 Jesse Glick 2012-07-26 13:27:18 UTC
(In reply to comment #8)
> settings.xml in addition to maven home setting in Tools>Options>Java>Maven

Could be done as a convenience, though not strictly necessary as you can place per-installation settings in $MAVEN_HOME/conf/settings.xml, retaining ~/.m2/settings.xml for per-user/machine settings. Mainly useful if you want to have multiple settings.xml setups with the same physical Maven installation.


(In reply to comment #11)
> --userdir cmd line switch

This will generally switch much more than you need: plugins, font settings, etc.


I think pekarna's original request from comment #0 is still the most sensible. We already allow netbeans.hint.jdkPlatform to be defined in a parent POM, so netbeans.hint.maven could be too (giving some kind of portable identifier like "2.2.1" rather than a filesystem path). (For "initial checkout" scenarios, has to be fairly forgiving: if the model is unloadable, fall back to scanning {../}*pom.xml and parsing XML directly assuming no variable references are in use.)

But first we should check for /projects/prerequisites/maven and/or requireMavenVersion configuration of maven-enforcer-plugin. If these settings prohibit the currently selected global Maven installation, pick the newest available installation which is not prohibited, if any (else show a warning badge). This would make it easy for users to add a 2.2.1 installation in addition to the bundled 3.0.4 and rest easy that any project explicitly requesting M2 (possibly in a parent POM) will automatically use it with no IDE-specific configuration.

Of course defining a Maven version is of no help for projects which require a custom settings.xml; this could I guess be a filesystem attribute on the reactor root folder (i.e. stored in IDE userdir) pointing to settings.xml location, which could be maintained using the Properties dialog.
Comment 13 Milos Kleint 2012-08-15 12:22:08 UTC
 disagree. maven executable maybe, but anything that can touch the location of
local repository is suspicious and needs to be handled en-block for all opened
projects. (and maven executable contains a setting file)

Forgot to mention that MavenFileOwnerQueryImpl should probably keep the
persistent caches on project group level as well. It solves the problem with 
multiple branch checkouts pointing to the same spot in local repository
Comment 14 Milos Kleint 2012-08-28 09:54:12 UTC
https://hg.netbeans.org/core-main/rev/afd38b1ed135

updates the backend to allow per project group maven home settings. No ui for 7.3. To manually set, create embedder.properties file in Preferences/org/netbeans/modules/projectui/groups/FOO/org/netbeans/modules/maven folder in the user directory where FOO is the name/id of the group.

the content should have something like:
commandLineMavenPath=C:\\Users\\mkleint\\apache-maven-2.2.1

The global settings (Tools/Options) will not see value, but it will be used at project loading (conf/settings.xml) and maven build execution.

UI will be added for the next version, too late for this one unfortunately.


We should also consider having global options and user settings file locations configurable on the project group level.
Comment 15 Quality Engineering 2012-08-29 02:42:07 UTC
Integrated into 'main-golden', will be available in build *201208290001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/afd38b1ed135
User: Milos Kleint <mkleint@netbeans.org>
Log: #197577 a project group based getter for maven home (installation root), allows maven install per project group
Comment 16 Milos Kleint 2013-04-16 12:16:42 UTC
https://hg.netbeans.org/core-main/rev/ba241a7a6443 adds an extensible project group editing panel and within the maven binary editing as well. Project Group value overrides the default.

consider this fixed, no further plans for per-project binary or settings files.
Comment 17 Quality Engineering 2013-04-18 02:22:48 UTC
Integrated into 'main-golden', will be available in build *201304172301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ba241a7a6443
User: Milos Kleint <mkleint@netbeans.org>
Log: #197577 declarative project group customizer added,  same ui as project customizer, also same api.
implemented the maven panel whcih allows setting maven binary to use within the group.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo