[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2e-dev] maven installation support rework
|
Unless I am missing something (which is possible) m2e only read
<default_maven_installation>/conf/settings.xml when it calculated local
repository path. I removed this logic from m2e. Local repository
location only depends on user settings.xml now.
<maven_installation>/conf/settings.xml was also used by maven during
RunAs->MavenBuild. This is part of standard maven behaviour and is not
affected.
Latest m2e 1.5 snapshot can be installed from [1], give it a try and let
me know if this change causes problems in your environment. You probably
want to test with fresh/clean workspace, m2e preferences format changed
and m2e 1.4 will not be able to read installation configuration from 1.5
workspace (1.5 can read 1.4 preferences).
[1]
http://repository.takari.io:8081/nexus/content/sites/m2e.extras/m2e/1.5.0/N/LATEST/
--
Regards,
Igor
On 2014-04-22, 10:11, Marcel Schutte wrote:
Hi Igor,
It depends on what you mean by 'removed support for global user
settings.xml': did you just remove the path and open file preference
elements, or won't m2e be reading the
<maven_installation>/conf/settings.xml anymore?
The latter would be a problem for us: we have standardized maven
installation packages where the global settings.xml contains the (non
standard) path to the local repository and also the mirror and
repository setup for our nexus instance.
In doing this, our user settings.xml can be a minimal setup with just a
source control username and one or two properties containing paths.
Regards,
Marcel
On Tue, Apr 22, 2014 at 3:53 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:
I've just pushed relatively big rework of how m2e handles Maven
installations. The core of this change is to give installations logical
names and make it possible to configure individual installations.
Currently only custom core extensions can be configured (something I
needed for my maven core development work), but we can add things like
default parameters relatively easily now.
Using runtime names also makes launch configuration little easier to
share. Different developers still need to manually configure maven
installations used by shared launch configurations, but at least these
runtimes do not have to be installed at exactly the same location on all
development machines.
Somewhat controversially, I removed support for global user settings.xml
file. It was only used to calculate location of maven local repository,
which didn't make much sense, and it was getting in the way of the
changes I needed to make to the maven installation ui. I do not believe
anyone is affected by this, but let me know if I missed a usecase and
we'll figure out how to bring this back.
--
Regards,
Igor
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
--
Fotografie
http://schutte.name/
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev