al purpose. They seem to do this without breaking anything or interfering
with the existing classpaths.. There can be more than one special purpose.
There is more than just Java.
Stan
Stan Devitt, Platform Group
-
This tr
Stan Devitt, Platform Group
- Original Message -
From: Jörg Schaible [mailto:joerg.schai...@scalaris.com]
Sent: Tuesday, June 28, 2011 02:40 AM
To: dev@maven.apache.org
Subject: Re: peri
Brett Porter wrote:
>
> On 28/06/2011, at 7:46 AM, Benson Margulies wrote:
>
>>
The only thing preventing changing the groupId/ArtifactId is that if you
do, it breaks dependency resolution and hence the maven model. That is
pretty serious.
Now, ... perhaps if there were some sort of alias facility so that
dependency resolution could be told that two different
Artifact coordi
Here is some feedback on
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor
y+discovery
Of the 4 requirements listed:
1. ability to checkout and build with no prior setup (extremely
important)
3. separate plugin dependency resolution from project dependency
Subject: Re: Depending on Artifacts not in central
On 8-Jul-09, at 6:57 PM, Stan Devitt wrote:
> The only thing that halfway works for rebuilt / modified artifacts
> is to modify the version number (e.g. 3.5-mod-by-NameOModifier).
>
I agree.
As once the patches reach the OSS project i
The only thing that halfway works for rebuilt / modified artifacts is to modify
the version number (e.g. 3.5-mod-by-NameOModifier).
Stan
- Original Message -
From: Brian Fox
To: Maven Developers List
Sent: Wed Jul 08 17:36:55 2009
Subject: Re: Depending on Artifacts not in central
BT
A major difference is that the settings.xml file is not stored with the project
source.
If your project depends on the profile(s) in some crucial way the information
should be archived with the project. In that case the settings.xml is not an
option.
Stan
- Original Message -
From: B
