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 167208 - Load <MAVEN_HOME>/conf/settings.xml from embedder
Summary: Load <MAVEN_HOME>/conf/settings.xml from embedder
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: PLAN
: 197561 200617 (view as bug list)
Depends on:
Blocks: 206750
  Show dependency tree
 
Reported: 2009-06-17 09:56 UTC by ryders
Modified: 2012-06-05 17:01 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
ppt showing issue and netbeans (mis?)generated files (549.27 KB, application/octet-stream)
2010-04-09 22:18 UTC, jason3421
Details
run configuration for long classpath (71.14 KB, image/jpeg)
2011-04-21 14:22 UTC, onmomo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ryders 2009-06-17 09:56:39 UTC
Hi guys, 

Turns out I had the wrong bug tracking to report onto; http://jira.codehaus.org/browse/MEVENIDE-682

In short it seems the maven integration is not finding local repository properly when using a custom userdir (in
etc/netbeans.conf -> netbeans_default_userdir), here's why;

- When using the embedded maven (3.0-SNAPSHOT, bundled), repository settings are still stored in Documents and
Settings\<user>\.m2, which is incorrect since this should be in the custom userdir defined (other nb plugins do this fine).

- When using and external maven (2.0), the Documents and Settings\<user>\.m2 directory still gets created, the external
maven settings are not read, and Docs & Settings\<user>\settings.xml still stores data.

This happens in Win XP and 7, using netbeans 6.5.1 (up-to-date) and jdk1.6.0_u14.

As suggested by the issue above, I've also tested nb6.7rc3 and while the localRepository settings are not stored in Doc
and Settings\.m2 (using 3.0-SNAPSHOT, bundled), the external maven settings (using ext maven home) are not taken into
considerations.

Happy to provide additional details if need be.

btw, selecting subcomponent 'embedder', but I'm not so sure about this really..
Comment 1 Milos Kleint 2009-06-17 10:25:55 UTC
external maven home field in Tools/Options is meant to contain the location of external Maven *installation* (eg. 2.0.9
version), not the location of ~/.m2

the ~/.m2/settings.xml will be used by both the project loading embedder and the external maven execution. That's the
Maven's idea of user settings location.

The global maven/conf/settings.xml setting in a Maven binary installation will be used by the external build, but not
the embedder used to load projects. <nb_installation>/javaX/maven2/settings.xml is the location of the settings file
used by the embedder. The reason for this behaviour is that in some circumstances (when maven home not explicitly set,
but reusing value from PATH) it's not possible to pinpoint the location of the global settings file. Therefore the
current behaviour is more consistent than selectively using it when available.

Theoretically you could set the "--settings <settings file>" option in the Tools/Options window in the Global Execution
Options, but currently it will only be used by the build, not the project loading. That could be possibly reused, but I
don't see why having the ~/.m2/settings.xml file is a problem. What is the reason for wanting to use a different file?
Comment 2 Milos Kleint 2009-06-17 10:33:47 UTC
in a way related to 158646
Comment 3 ryders 2009-06-17 13:07:47 UTC
Tools->Options, External Maven Home = F:\programs\apache-maven-2.1.0, I got that right

Using the ~/.m2/settings.xml file is fine, however when nb is configured to run with a 'different' userdir, ~/ should be
left alone, instead the specified userdir should be used (all other netbeans modules work that way, except for the
registration module which creates .netbeans-registration directory in ~/, for some reason)
This said, I agree all 'settings' should be stored in the specified --userdir, specially since this is one of the
supported 'lookup' directories for maven the maven settings.xml

ref http://blogs.sun.com/karthikr/entry/jse_directories,
http://blogs.sun.com/NetBeansSupport/entry/directories_in_netbeans_install_user and http://maven.apache.org/settings.html

This is now a non issue since 6.7 seems to have fixed this, partially. (~/.m2 gets created, but nothing is written to it)

I sort of understand the point that the embedder cannot use the env M2_HOME, and I agree the project loader cannot find
the information. (I don't know enough about the nb underpinnings..)

However when an External Maven Home is specified as above, it's clear that the config is in <external maven
home>/conf/settings.xml, so why not use it?

I can confirm your theory on the "--settings <settings file>" global exec option; works for build, not project loading.
Also, I've tried creating a <nb installation>/javaX/maven2/settings.xml with my configs in it, and that didn't seem to work.

--

The idea is so, I already have a maven installation configured with many additional repositories (a local, privates and
public ones) and I cannot use it properly without having to reconfigure an other instance of maven. While I can get nb
to compile it all, I can't get rid of the warning messages / icon overlays saying there are unresolved dependencies.

Hope this helps,

Cheers,


Comment 4 jason3421 2010-04-09 22:18:32 UTC
Created attachment 97000 [details]
ppt showing issue and netbeans (mis?)generated files

I'm still having this issue with 6.8. I have to manually put in a shorter repo location due to extraordinary an nasty long classpath that is preventing me from running mains from netbeans (somehow eclipse handled it, don't know what gives there).
Comment 5 Antonin Nebuzelsky 2010-07-30 15:17:16 UTC
Reassigning to default owner.
Comment 6 Jesse Glick 2010-08-02 16:26:23 UTC
Long discussion here which I don't really follow. Can anyone provide a quick summary of what this bug is about and how to reproduce it? What you did, what you expected the IDE to do and why, what it did instead.
Comment 7 jason3421 2010-08-13 20:58:14 UTC
The problem I had was that some part of netbeans wasn't honoring the mvn home that is defined in the apache 'apache-maven-2.2.1\conf\settings.xml' file unless I explicitly specified my modified mvn home directory in netbeans (via Tools -> Options -> Miscellaneous -> Maven -> Local Repository) even though netbeans said it was honoring the mvn home specified by settings.xml). That's explained in the ptt I attached. 

I also had difficulty launching my code from netbeans since I have a ridiculously long classpath.

I would be happy to do a screen sharing session with someone from netbeans to explain some issues that I see. I'm in the US on EST. E-mail me if you are interested.
Comment 8 Jesse Glick 2011-03-07 17:08:19 UTC
(In reply to comment #1)
> in some circumstances (when maven home not explicitly set,
> but reusing value from PATH) it's not possible to pinpoint the location of the
> global settings file.

Note that in 7.0 $PATH is not scanned, so you can either use the bundled Maven or an other complete installation. Thus it would be possible to load conf/settings.xml. At the same time it would be preferable to remove the "Local Repository" field in Maven options, which currently has no effect on the embedder (just passes -Dmaven.repo.local=... to external Maven commands).

But better is just to specify your desired settings in ~/.m2/settings.xml, where they will be honored by any Maven installation. You can specify an alternate local repository location, mirrors, etc. (Specifying remote repositories here is a poor idea; use the parent POM so the build is reproducible on another machine!) And you need not worry about copying config files around if you install a different version of Maven.
Comment 9 Jesse Glick 2011-04-21 13:37:20 UTC
*** Bug 197561 has been marked as a duplicate of this bug. ***
Comment 10 onmomo 2011-04-21 14:20:11 UTC
(In reply to comment #7)

> I also had difficulty launching my code from netbeans since I have a
> ridiculously long classpath.
> 
> I would be happy to do a screen sharing session with someone from netbeans to
> explain some issues that I see. I'm in the US on EST. E-mail me if you are
> interested.

For launching code with very long classpath change your "run project" action of your starter project. It's necessary to add a property: exec.longClasspath=true which will create an additional .jar archive which contains your classpath in the manifest. For more information, please check the attached screenshot.
Comment 11 onmomo 2011-04-21 14:22:55 UTC
Created attachment 107884 [details]
run configuration for long classpath

Screenshot for comment #7

Perhaps a checkbox do enable / disable this property in NB would be quite convenient.
Comment 12 Jesse Glick 2011-04-21 15:22:56 UTC
(In reply to comment #7)
> I also had difficulty launching my code from netbeans since I have a
> ridiculously long classpath.

Sounds like a completely unrelated issue. If some change in NB is needed, it should be filed separately.
Comment 13 Jesse Glick 2011-08-15 14:54:14 UTC
*** Bug 200617 has been marked as a duplicate of this bug. ***
Comment 14 Jesse Glick 2011-08-29 23:29:42 UTC
core-main #99a56a388438
Comment 15 Quality Engineering 2011-08-30 14:23:56 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/99a56a388438
User: Jesse Glick <jglick@netbeans.org>
Log: #167208: Load <MAVEN_HOME>/conf/settings.xml from embedder
Comment 16 bmaras 2012-02-29 13:13:18 UTC
For information,

I managed to backport manually this fix in 7.0.1. I did it quickly and probably not in a very clean way. But it looks like it fixes the problem.

If you cannot upgrade to 7.1 like me, it might be a workaround (in my case, it's because I use SAF, that is no longer supported in 7.1 : http://netbeans.org/bugzilla/show_bug.cgi?id=204661)