maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Can't specify distributionManagement in settings.xml
Date Mon, 04 Oct 2010 20:50:11 GMT
One of the absolutely best way to understand some of the patterns/best
practice is to look at examples.
For instance, look at how things (like parent poms) are structured at
Apache, Codehaus or even Sonatype.

One example:
http://repo2.maven.org/maven2/org/codehaus/codehaus-parent/3/codehaus-parent-3.pom

/Anders

On Mon, Oct 4, 2010 at 22:33, Ron Wheeler <rwheeler@artifact-software.com>wrote:

>  On 04/10/2010 3:46 PM, Phillip Hellewell wrote:
>
>> On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd)
>> <tthiessen@avaya.com>  wrote:
>>
>>> I don't think it is arbitary. Where you deploy your artifacts TO, I think
>>> should be fixed. I think that is the intent. It is a one off thing that is
>>> applicable to the build at hand and isn't something you will want to try and
>>> reproduce at a later date (like building from a tag).
>>>
>>> In this case it is good to know that if you run a mvn deploy, you'll know
>>> exactly where the artifact will go. Using it as a property or variable in
>>> this case I think isn't a good thing.
>>>
>> I can see where you're coming from, and of course I don't plan on
>> having where we deploy to change very often, but I don't see any big
>> reason to prevent an override.
>>
>> But anyway, that is neither here nor there for me.  The big problem
>> issue for me right now is why should I be forced to do everything
>> through a parent pom instead of in a settings.xml file?  I don't
>> understand why certain settings should have to be in a pom that has to
>> be deployed.
>>
>> Phillip
>>
>>  I did warn you that you were going to get help from some very smart
> people with a lot of experience!!!
>
> As a less qualified person, I found it pretty easy to think of this problem
> as follows:
> 1) I use the dependency repository to specify where any external or
> internal artifact comes from.
> Their source for dependencies does not depend on which project one is
> working on.
> It depends on where the dependency lives.
> This is immutable and not project specific.
>
> Nexus proxies all sources so people only have to specify Nexus to get any
> dependency regardless of whether it is our code, an artifact from Maven
> Central, an artifact from a third party Maven repository or a dependency
> that I had to download and manually add to my repo because of licensing
> issues.
>
> Thus the dependency repository information goes in settings.xml since that
> is used for all projects and contains the developers credentials to access
> the Nexus repo.
>
> 2) Deployment could be project specific so it goes in the project's parent
> POM which is almost immutable for the entire release and the deployment
> management is completely immutable in our case, since we deploy to our Nexus
> repo in either the SNAPSHOT repo or the release repo.
> Both deployment destinations are defined in the POM and Maven knows what to
> do without being told.
> Maven uses the person's credentials from their settings.xml so they are not
> in the project POM.
>
> We are not using Hudson, so we do not have to worry about that.
>
>
> Ron
>
>
>  ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message