On Friday 14 October 2016, Robert Scholte wrote:
> On Fri, 14 Oct 2016 00:09:26 +0200, Christian Schulte
> wrote:
>
> Am 10/13/16 um 21:52 schrieb Robert Scholte:
>>
>>> On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte
>>>
On Fri, 14 Oct 2016 00:09:26 +0200, Christian Schulte
wrote:
Am 10/13/16 um 21:52 schrieb Robert Scholte:
On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte
Should I change the order of the effective settings so that things from
the global settings
Am 10/13/16 um 21:52 schrieb Robert Scholte:
> On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte
>> Should I change the order of the effective settings so that things from
>> the global settings always come before the user settings? Will that blow
>> up somewhere else. We
Am 10/13/16 um 21:52 schrieb Robert Scholte:
> I'd say revert these changes. We see that this "hack" doesn't always work.
> Better look for a more solid solution with another release in the future.
The better solution would be to completely remove repositories from the
poms and from all
Hello,
reverting seems safer. As settings always override stuff in poms, my guess
would be that having global defining stuff for central will blow stuff for
lots of people. Overriding central seems very natural. And user's settings
will survive updates of Maven it self.
Regards
Mirko
--
Sent
On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte
wrote:
Am 10/12/16 um 23:17 schrieb Robert Scholte:
It is a bit different: the *effective* settings are the global settings
where parts can be overridden with the user settings. This means that
all
profiles will be
Am 10/12/16 um 23:17 schrieb Robert Scholte:
> It is a bit different: the *effective* settings are the global settings
> where parts can be overridden with the user settings. This means that all
> profiles will be there, during build the content of profiles will keep
> overriding each other.
It is a bit different: the *effective* settings are the global settings
where parts can be overridden with the user settings. This means that all
profiles will be there, during build the content of profiles will keep
overriding each other. So is the order of profiles correct in the
Am 10/10/16 um 20:49 schrieb Igor Fedorenko:
> Are repositories and other configuration defined in user settings.xml
> take precedence over global settings.xml?
Don't know for sure but would assume so. The current master 4.0.0 super
pom has already been reverted to not change in any way in 3.4.0.
But why would the server settings override the values of the user's
settings? I thought the latter ones always had precedence.
Regards
Mirko
--
Sent from my mobile
Am 10.10.2016 22:57 schrieb "Robert Scholte" :
> so this is the first change:
>
so this is the first change:
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=1b00a9e1
removing it from the POM (I assumed it was really in the Java code)
Maybe this is a candidate to add to a new version of the settings.xml
This file is a Maven-only file, which makes is easier
Hello everyone,
this is basically my settings.xml (stripped servers section and a few
sonarqube related properties):
central
*
Internal mirror of all needed dependencies
https://inhouse.server/artifactory/internal-central/
Not just the url, but all aspect of "central" repository are
configurable in user settings.xml today. Even if we provide a better way
to express this configuration, I believe the old way should continue to
work for a few releases to allow graceful migration. Many users will use
multiple versions
Are repositories and other configuration defined in user settings.xml
take precedence over global settings.xml?
--
Regards,
Igor
On Mon, Oct 10, 2016, at 10:16 AM, Christian Schulte wrote:
> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> > It is common to use repository with id=central in
On Mon, 10 Oct 2016 16:22:20 +0200, Christian Schulte
wrote:
Am 10.10.2016 um 16:16 schrieb Christian Schulte:
Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
It is common to use repository with id=central in settings.xml to
override central location. This functionality
Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> It is common to use repository with id=central in settings.xml to
> override central location. This functionality should continue to work,
> regardless how it is implemented in Maven internally.
>
Do you have a wildcard mirror in the settings as
Am 10.10.2016 um 16:16 schrieb Christian Schulte:
> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
>> It is common to use repository with id=central in settings.xml to
>> override central location. This functionality should continue to work,
>> regardless how it is implemented in Maven internally.
Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> It is common to use repository with id=central in settings.xml to
> override central location. This functionality should continue to work,
> regardless how it is implemented in Maven internally.
>
Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> It is common to use repository with id=central in settings.xml to
> override central location. This functionality should continue to work,
> regardless how it is implemented in Maven internally.
>
That is what has become the default. Did you look
It is common to use repository with id=central in settings.xml to
override central location. This functionality should continue to work,
regardless how it is implemented in Maven internally.
--
Regards,
Igor
On Mon, Oct 10, 2016, at 09:10 AM, Christian Schulte wrote:
> Am 10/10/16 um 14:45
Am 10/10/16 um 14:45 schrieb Mirko Friedenhagen:
> Hello,
>
> I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml"
> on one of our inhouse projects once with 3.3.9 and once with
> 3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa;
> 2016-10-09T21:16:52+02:00)
>
> 3.4.0
Hello,
I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml"
on one of our inhouse projects once with 3.3.9 and once with
3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa;
2016-10-09T21:16:52+02:00)
3.4.0 seems not to incorporate settings correctly (or I misconfigured
22 matches
Mail list logo