Bug 197577

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?

*** Bug 198251 has been marked as a duplicate of this bug. ***

*** Bug 200797 has been marked as a duplicate of this bug. ***

(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.

*** Bug 203465 has been marked as a duplicate of this bug. ***

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.

Please do not move the Version field of an issue forward (only backward).

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?

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.

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?

(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.

(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.

 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

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.

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

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.

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.