Can't specify distributionManagement in settings.xml

classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

RE: Can't specify distributionManagement in settings.xml

Eric Haszlakiewicz
>-----Original Message-----
>From: Thiessen, Todd (Todd) [mailto:[hidden email]]
>
>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.
>
>Think of this way. You want to have complete control over the artifacts
>that your build produces. Something fixed... predicatable. The
artifacts
>that are produced by some other project that you need as
depedendencies;
>you should have control over where they will be found and that may
change
>over time. These are thus not fixed.

Sure, it makes sense to have complete control for what actually gets
created as the artifact.  Where you deploy it to can depend on where you
happen to be building.  
For instance, where I work we recently starting using a new set of
servers for our development environment.  The url that our nexus server
is at is different for one environment than the other.  (in one
environment it's actually a transparent proxy that forwards connections
over a tunnel that was only available for use by that one server)
To get things to work, we had to change every single project that we
have to use a new parent pom.  And once we changed a project, we could
no longer build in the old environment.  We still ended up with the
exact same artifacts as before, but we were just deploying them to a
different server.  We had no need to perform a new release of any of our
projects for any other reason, but we still needed to change everything.
That sucks.

Anyway, it sounds like Phillip's solution with the property references
would eliminate these issues.

eric

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Arnaud Héritier
In reply to this post by Thiessen, Todd (Todd)
It is interesting to have it variable in several cases :
- You want to validate your builds on several environments. I'm just moving my infrastructure and I'm very happy to have that because I'm able to run a secondary build environment (svn/hudson/nexus) without touching our production used by developers
- You want to deploy the project in another repository because you are forking it (for an OSS project) and you can redefine this property instead of using the -DaltDeploymentRepository of the deploy plugin which has severals bugs.


On Oct 4, 2010, at 9:43 PM, Thiessen, Todd (Todd) wrote:

> Hehe. It always gets back to that.
>
> Not sure why your hung up over it ;-).
>
> What Arnaud is saying does make more sense to me. There is at least a fixed place in some POM in source control which defines the default location of where to deploy to. At least this is tracable.
>
> I am not really all that found of making it a variable though. That just sounds like extra work for very little gain.
>
>> -----Original Message-----
>> From: Phillip Hellewell [mailto:[hidden email]]
>> Sent: Monday, October 04, 2010 3:40 PM
>> To: Maven Users List
>> Subject: Re: Can't specify distributionManagement in settings.xml
>>
>> On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell <[hidden email]>
>> wrote:
>>> 2010/10/4 Arnaud Héritier <[hidden email]>:
>>>> Wrong :-)
>>>> Let me try to explain ...
>>>> Your approach to allow to override this parameter using a property is
>> good.
>>>> I'm doing it to validate a new version of my repository manager and so
>> on.
>>>> But how you are doing it is wrong.
>>>
>>> I didn't know I could define properties outside of a profile section.
>>> Let me give it a try...
>>
>> Crap, you can't do that in a settings.xml.  To do it outside of a
>> profile section it has to be in a pom, so that leads me back to having
>> to use a parent or "corporate" pom :(
>>
>> Phillip
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Anders Hammar
In reply to this post by Eric Haszlakiewicz
The pattern I was talking about was all the issues Philip runs into as he
was trying to not follow the Maven way.

/Anders

On Mon, Oct 4, 2010 at 21:07, Haszlakiewicz, Eric <[hidden email]>wrote:

> >-----Original Message-----
> >From: [hidden email] [mailto:[hidden email]] On
> >
> >Are you seeing the pattern yet? Don't fight Maven!
>
> So what IS the pattern here?  How do you actually configure the
> distribution management if you're not going to put it in a parent pom?
>
> Saying "don't fight maven" is rather useless if you don't explain how
> you're actually supposed to get things to work.
>
> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Arnaud Héritier
In reply to this post by Phillip Hellewell
mvn deploy -DaltDeploymentRpository=...
But some times ago there was a bug which disallow to use it without a distribMgt part in the pom :(


Arnaud Héritier
Software Factory Manager
http://www.exoplatform.com

Phone : +33 (0)6 89 74 64 24
Skype : aheritier
Twitter : @aheritier
Blog : http://aheritier.net

On Oct 4, 2010, at 9:48 PM, Phillip Hellewell wrote:

> On Mon, Oct 4, 2010 at 1:43 PM, Thiessen, Todd (Todd)
> <[hidden email]> wrote:
>> Hehe. It always gets back to that.
>>
>> Not sure why your hung up over it ;-).
>
> Well, I'm going to do some more tests now to see if I can get this
> working with a parent pom.  If I run into an error that I can't figure
> out you'll probably hear from me :)
>
> But I do have one question first.  Is there any possible way to do a
> deploy without any <distributionManagement> section in your pom, and
> to just pass the URL on the command-line?
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Can't specify distributionManagement in settings.xml

Thiessen, Todd (Todd)
In reply to this post by Arnaud Héritier
That makes sense to me (to a certain extent). It is nice to have it as an "override" feature.

But in my view I think it important to have that default deploy location defined in a pom somewhere. We went through a very similar "transition" scenario that you explain here and I found it very useful to keep this information in the parent pom and simply use a SNAPSHOT version for a while until the bugs were ironed out. It was good to know that version X of our project was deploying to repository A and version X+1 was deploying repository B. You make this a variable and you don't know what version of your software deployed to where. This I think can making debugging more difficult and confusing.

> -----Original Message-----
> From: Arnaud Héritier [mailto:[hidden email]]
> Sent: Monday, October 04, 2010 3:52 PM
> To: Maven Users List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> It is interesting to have it variable in several cases :
> - You want to validate your builds on several environments. I'm just
> moving my infrastructure and I'm very happy to have that because I'm able
> to run a secondary build environment (svn/hudson/nexus) without touching
> our production used by developers
> - You want to deploy the project in another repository because you are
> forking it (for an OSS project) and you can redefine this property
> instead of using the -DaltDeploymentRepository of the deploy plugin which
> has severals bugs.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Arnaud Héritier
2010/10/4 Arnaud Héritier <[hidden email]>:
> mvn deploy -DaltDeploymentRpository=...
> But some times ago there was a bug which disallow to use it without a distribMgt part in the pom :(

Thanks.  Unfortunately, it appears that Maven 2.2.1 still has this bug :(

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Can't specify distributionManagement in settings.xml

Eric Haszlakiewicz
In reply to this post by Anders Hammar
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On
>
>The pattern I was talking about was all the issues Philip runs into as
he
>was trying to not follow the Maven way.

So, again, I ask: what IS the pattern?  What IS the "Maven way" in this
situation?  It is not at all clear.  
You're claiming he's not following it, but you haven't explained just
what it is about what he is doing that you think deviates from the way
things are supposed to work.

eric


>On Mon, Oct 4, 2010 at 21:07, Haszlakiewicz, Eric
><[hidden email]>wrote:
>
>> >-----Original Message-----
>> >From: [hidden email] [mailto:[hidden email]]
On
>> >
>> >Are you seeing the pattern yet? Don't fight Maven!
>>
>> So what IS the pattern here?  How do you actually configure the
>> distribution management if you're not going to put it in a parent
pom?
>>
>> Saying "don't fight maven" is rather useless if you don't explain how
>> you're actually supposed to get things to work.
>>
>> eric

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
On Mon, Oct 4, 2010 at 2:24 PM, Haszlakiewicz, Eric
<[hidden email]> wrote:

>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]] On
>>
>>The pattern I was talking about was all the issues Philip runs into as
> he
>>was trying to not follow the Maven way.
>
> So, again, I ask: what IS the pattern?  What IS the "Maven way" in this
> situation?  It is not at all clear.
> You're claiming he's not following it, but you haven't explained just
> what it is about what he is doing that you think deviates from the way
> things are supposed to work.

Yeah, part of the problem is I still haven't got this working with a
"parent" pom, and I don't even know exactly what is meant by a parent
pom (I assume it was using the <parent> tag, but I'm running into
issues there...)

I do appreciate everyone's responses, and I do want to follow the
"Maven way" as much as possible, but I also want to avoid making
things more difficult for no reason.

I am getting a better picture now of how many feel it is good to have
the default deploy location in a pom somewhere, but I still haven't
been convinced that it is absolutely necessity, and I'm not sure it is
worth dealing with the hassle when moving the repository to a new
server.

I'll play with it some more to see if I can get it working.  But at
the moment I'm still leaning towards just putting a property in
settings.xml, since that seems easy and I don't see any problem.  And
as long as I use the activatedProfiles instead of activateByDefault
(as Arnaud suggested) I can avoid the issue of that profile not being
active.

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Ron Wheeler
In reply to this post by Phillip Hellewell
  On 04/10/2010 3:46 PM, Phillip Hellewell wrote:

> On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd)
> <[hidden email]>  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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Wendy Smoak
In reply to this post by Phillip Hellewell
On Mon, Oct 4, 2010 at 4:28 PM, Phillip Hellewell <[hidden email]> wrote:
> I am getting a better picture now of how many feel it is good to have
> the default deploy location in a pom somewhere, but I still haven't
> been convinced that it is absolutely necessity, and I'm not sure it is
> worth dealing with the hassle when moving the repository to a new
> server.

How often do you expect that to happen?

The repository is central to the build infrastructure and needs to be
very, very stable.  Not only uptime, but as you're anticipating, not
moving around too much.

In practice though, changing the repo url once every few years
provides an excuse to force projects who are lagging behind to update
to the latest corporate parent pom and pick up all the new
configuration you've tried to impose on them. ;) )

In any case you can reduce the need to change the repo url by putting
something in front of it (VIP device, httpd as a proxy, etc.)

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Anders Hammar
In reply to this post by Ron Wheeler
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 <[hidden email]>wrote:

>  On 04/10/2010 3:46 PM, Phillip Hellewell wrote:
>
>> On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd)
>> <[hidden email]>  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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Ron Wheeler
In reply to this post by Phillip Hellewell
  On 04/10/2010 4:28 PM, Phillip Hellewell wrote:

> On Mon, Oct 4, 2010 at 2:24 PM, Haszlakiewicz, Eric
> <[hidden email]>  wrote:
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]] On
>>>
>>> The pattern I was talking about was all the issues Philip runs into as
>> he
>>> was trying to not follow the Maven way.
>> So, again, I ask: what IS the pattern?  What IS the "Maven way" in this
>> situation?  It is not at all clear.
>> You're claiming he's not following it, but you haven't explained just
>> what it is about what he is doing that you think deviates from the way
>> things are supposed to work.
> Yeah, part of the problem is I still haven't got this working with a
> "parent" pom, and I don't even know exactly what is meant by a parent
> pom (I assume it was using the<parent>  tag, but I'm running into
> issues there...)
>
??? Should not be any there.
> I do appreciate everyone's responses, and I do want to follow the
> "Maven way" as much as possible, but I also want to avoid making
> things more difficult for no reason.
>
You shouldn't have to pioneer any of this.
It does not appear that your environment or development goals are really
outside of normal practice so you should not have to derive new ways to
get your projects built.
> I am getting a better picture now of how many feel it is good to have
> the default deploy location in a pom somewhere, but I still haven't
> been convinced that it is absolutely necessity, and I'm not sure it is
> worth dealing with the hassle when moving the repository to a new
> server.
If you use a virtual hostname for addressing your Nexus, you can move
your repo without changing everyone's settings.xml.
Not something that happens every year anyway.

> I'll play with it some more to see if I can get it working.  But at
> the moment I'm still leaning towards just putting a property in
> settings.xml, since that seems easy and I don't see any problem.  And
> as long as I use the activatedProfiles instead of activateByDefault
> (as Arnaud suggested) I can avoid the issue of that profile not being
> active.
>
Never used profiles.

> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
On Mon, Oct 4, 2010 at 2:58 PM, Ron Wheeler
<[hidden email]> wrote:
>  On 04/10/2010 4:28 PM, Phillip Hellewell wrote:
>>
>> Yeah, part of the problem is I still haven't got this working with a
>> "parent" pom, and I don't even know exactly what is meant by a parent
>> pom (I assume it was using the<parent>  tag, but I'm running into
>> issues there...)
>>
> ??? Should not be any there.

Just tried using a parent pom tonight and it worked fine.  Not sure
what was going on earlier today.

I'm still not fully convinced of the necessity of persisting an
artifact's default deploy location, but I'm going to take your guys'
word for it and do it the "Maven way".  And I'll try to do whatever I
can with DNS or virtual hosts or whatever to make it so that doesn't
have to change unnecessarily.

BTW, I'm thinking that we will probably have two main repositories, a
"staging" one and a "release" one.  Any build that succeeds and unit
tests pass will be deployed automatically to the staging repo (which
will be the default repo referenced by all the poms, well, the parent
pom).  Then after QA approval it will be deployed to the "release"
repo.  But if -DaltDeploymentRepository is buggy, maybe I should put a
variable in there.  Or can I just use the stage plugin to copy an
artifact from the staging to release repo?

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Ron Wheeler
  On 05/10/2010 12:45 AM, Phillip Hellewell wrote:

> On Mon, Oct 4, 2010 at 2:58 PM, Ron Wheeler
> <[hidden email]>  wrote:
>>   On 04/10/2010 4:28 PM, Phillip Hellewell wrote:
>>> Yeah, part of the problem is I still haven't got this working with a
>>> "parent" pom, and I don't even know exactly what is meant by a parent
>>> pom (I assume it was using the<parent>    tag, but I'm running into
>>> issues there...)
>>>
>> ??? Should not be any there.
> Just tried using a parent pom tonight and it worked fine.  Not sure
> what was going on earlier today.
>
> I'm still not fully convinced of the necessity of persisting an
> artifact's default deploy location, but I'm going to take your guys'
> word for it and do it the "Maven way".  And I'll try to do whatever I
> can with DNS or virtual hosts or whatever to make it so that doesn't
> have to change unnecessarily.
>
> BTW, I'm thinking that we will probably have two main repositories, a
> "staging" one and a "release" one.  Any build that succeeds and unit
> tests pass will be deployed automatically to the staging repo (which
> will be the default repo referenced by all the poms, well, the parent
> pom).  Then after QA approval it will be deployed to the "release"
> repo.  But if -DaltDeploymentRepository is buggy, maybe I should put a
> variable in there.  Or can I just use the stage plugin to copy an
> artifact from the staging to release repo?
>

Releases and SNAPSHOTs is the way to do this.
You deploy SNAPHOTS until you have the bugs all out.
Releases are immutable. Once you release an artifact, you should not
release it again.

Maven will do this automatically for you. Just set the version to
X.Y-SNAPSHOT and Maven will deploy it to your SNAPSHOT repository as
defined in your parent POM.
If a dependency is on a SNAPSHOT version, Maven will check the SNAPSHOT
repo for the latest deployed SNAPSHOT so you can work as a team without
having to change your artifact's POM each time a team member deploys a
new SNAPSHOT.
The free version of Nexus will give you a Release and SNAPSHOT
deployment repo by default.

Remember, Maven knows how to build "normal" applications without doing
anything special.
It incorporates "Best Practices".

It just does not document them in a simple way.
You have to read ALL the documentation and then try to do it wrong and
finally describe the problem that this causes in this forum before the
secrets are revealed.
It is an Apache standard process (Free, high quality software in return
for minimal documentation written by insiders with an enthusiastic group
of experts to help you).


Ron



> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Anders Hammar
In reply to this post by Phillip Hellewell
Have a look at this parent:
http://repo2.maven.org/maven2/org/sonatype/forge/forge-parent/6/forge-parent-6.pom

There you see that properties are used for both the repo name and url. This
makes it possible to override these values from command line. This is
normally not anything you do, but it's very handy when you want to e.g.:
* deploy somewhere else (like to a test repo when you're doing some
experiments and want to use some test repo)
* want to use some other repo id for your cred matching in settings.xml
(maybe you have the same credentials everywhere, but instead of having 10-20
server elements you just want to use one single)

Regarding staging: If you're serious about your Maven implementation I would
recommend having a look at the staging support of Nexus Pro. Sure, it's not
free but it is superior to the stage plugin and gives you the possibility to
also add automated checks. As Apache and Codehaus now uses Nexus Pro, I
would guess that nobody is working on the stage plugin any more. Which kind
of makes you on your own should you run into any issues. Well, just my
thoughts.

/Anders

On Tue, Oct 5, 2010 at 06:45, Phillip Hellewell <[hidden email]> wrote:

> On Mon, Oct 4, 2010 at 2:58 PM, Ron Wheeler
> <[hidden email]> wrote:
> >  On 04/10/2010 4:28 PM, Phillip Hellewell wrote:
> >>
> >> Yeah, part of the problem is I still haven't got this working with a
> >> "parent" pom, and I don't even know exactly what is meant by a parent
> >> pom (I assume it was using the<parent>  tag, but I'm running into
> >> issues there...)
> >>
> > ??? Should not be any there.
>
> Just tried using a parent pom tonight and it worked fine.  Not sure
> what was going on earlier today.
>
> I'm still not fully convinced of the necessity of persisting an
> artifact's default deploy location, but I'm going to take your guys'
> word for it and do it the "Maven way".  And I'll try to do whatever I
> can with DNS or virtual hosts or whatever to make it so that doesn't
> have to change unnecessarily.
>
> BTW, I'm thinking that we will probably have two main repositories, a
> "staging" one and a "release" one.  Any build that succeeds and unit
> tests pass will be deployed automatically to the staging repo (which
> will be the default repo referenced by all the poms, well, the parent
> pom).  Then after QA approval it will be deployed to the "release"
> repo.  But if -DaltDeploymentRepository is buggy, maybe I should put a
> variable in there.  Or can I just use the stage plugin to copy an
> artifact from the staging to release repo?
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Ron Wheeler
On Mon, Oct 4, 2010 at 11:26 PM, Ron Wheeler
<[hidden email]> wrote:
>
> Maven will do this automatically for you. Just set the version to
> X.Y-SNAPSHOT and Maven will deploy it to your SNAPSHOT repository as defined
> in your parent POM.

Thanks Ron.  I was thinking about snapshots, but wasn't quite sure if
I wanted equate "staging repository" with "snapshot repository",
because I was actually thinking of having 3 levels:
1. Snapshot repository: developers can commit snapshots here.
2. Staging repository: build machine commits here automatically after
a build (incl unit tests) succeeds.
3. Release repository: Copy artifact from #2 to #3 after QA testing approves it.

For #2 I was planning to have X.Y-SVNTAG for the version number.  The
build machines will automatically get the SVN tag and append that to
create a unique name that will be even more useful to us than having a
timestamp that comes from SNAPSHOT.

Since the artifact won't change (not even the ver #) between #2 and
#3, I was thinking I should just be able to do a stage:copy to copy it
from one repository to the other.

Maybe I can combine #1 and #2, so snapshot repo == staging repo.  I
can deploy an artifact without SNAPSHOT in the name to a snapshot
repository, right?

Speaking of snapshots, is there an easy way to delete all snapshots
older than a given date to free up disk space?  Since snapshots are
temporary, yet plentiful, deleting old ones seems like it would be a
common need.

Thanks,
Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Anders Hammar
On Tue, Oct 5, 2010 at 12:29 AM, Anders Hammar <[hidden email]> wrote:
> Have a look at this parent:
> http://repo2.maven.org/maven2/org/sonatype/forge/forge-parent/6/forge-parent-6.pom
>
> There you see that properties are used for both the repo name and url. This
> makes it possible to override these values from command line. This is

Yeah, I think I would like to have the ability to override it easily,
but based on many comments it sounds like this kinda violates the
principle that we should be able to tell by looking at the pom (or
parent pom) what repository it was deployed to.

Perhaps I will go with a compromise.  I can use variables in there to
make it easily override-able, but I can also define default values in
there.

> Regarding staging: If you're serious about your Maven implementation I would
> recommend having a look at the staging support of Nexus Pro. Sure, it's not

Thanks.  I may take a look at that later.  At the moment I am not sure
I'll need it because I may be able to as Ron suggested just use the
snapshot repository for my staging repository.

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Anders Hammar
In reply to this post by Phillip Hellewell
Please, please, please have a look at a repo manager. It has these type of
features. That's why it's called a manager.

/Anders (mobile)
Den 2010 10 6 17:19 skrev "Phillip Hellewell" <[hidden email]>:
> On Mon, Oct 4, 2010 at 11:26 PM, Ron Wheeler
> <[hidden email]> wrote:
>>
>> Maven will do this automatically for you. Just set the version to
>> X.Y-SNAPSHOT and Maven will deploy it to your SNAPSHOT repository as
defined
>> in your parent POM.
>
> Thanks Ron. I was thinking about snapshots, but wasn't quite sure if
> I wanted equate "staging repository" with "snapshot repository",
> because I was actually thinking of having 3 levels:
> 1. Snapshot repository: developers can commit snapshots here.
> 2. Staging repository: build machine commits here automatically after
> a build (incl unit tests) succeeds.
> 3. Release repository: Copy artifact from #2 to #3 after QA testing
approves it.

>
> For #2 I was planning to have X.Y-SVNTAG for the version number. The
> build machines will automatically get the SVN tag and append that to
> create a unique name that will be even more useful to us than having a
> timestamp that comes from SNAPSHOT.
>
> Since the artifact won't change (not even the ver #) between #2 and
> #3, I was thinking I should just be able to do a stage:copy to copy it
> from one repository to the other.
>
> Maybe I can combine #1 and #2, so snapshot repo == staging repo. I
> can deploy an artifact without SNAPSHOT in the name to a snapshot
> repository, right?
>
> Speaking of snapshots, is there an easy way to delete all snapshots
> older than a given date to free up disk space? Since snapshots are
> temporary, yet plentiful, deleting old ones seems like it would be a
> common need.
>
> Thanks,
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Wendy Smoak
In reply to this post by Phillip Hellewell
On Wed, Oct 6, 2010 at 11:19 AM, Phillip Hellewell <[hidden email]> wrote:
> Speaking of snapshots, is there an easy way to delete all snapshots
> older than a given date to free up disk space?  Since snapshots are
> temporary, yet plentiful, deleting old ones seems like it would be a
> common need.

Some of the repository managers (Archiva at least) have a purge
feature to 'delete released snapshots'.

(If you're asking about the local repo, your CI server might have a
similar feature, and for local builds you'll probably find that
deleting your local repo occasionally works fine.)

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Anders Hammar
On Wed, Oct 6, 2010 at 9:28 AM, Anders Hammar <[hidden email]> wrote:
> Please, please, please have a look at a repo manager. It has these type of
> features. That's why it's called a manager.

I'm sure a repo manager can do fancy things with multiple repositories
for downloading, and I am already working on getting Nexus set up
today.  But I don't see how a repo manager will solve my problem with
deployment.  You can't deploy with the HTTP protocol, can you?  It has
to be something like scp://, ftp://, or file://.  Are there repo
manageres that interject somehow in the deployment phase.

Since the <distributionManagement> can only specify two kinds of
repositories, snapshot and normal (release), I am thinking that I need
to decide that (from a deployment perspective at least) there are only
two repositories, so I should probably combine my idea of a "staging"
repository with the snapshot repository.

But I'll still need to copy between repositories (copy a non-snapshot
artifact from the snapshot repository to the release repository), so
if stage:copy is not the best way to do this, I'm hoping to find that
this is something Nexus or another repo manager can do easily.

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234