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

mremersoncod
hey,

Artifactory (http://www.jfrog.org/products.php) has the possibility to copy an artifact to another repository - about the "if and how to use it", there are smarter people here already discussing it

cheers

 

 


 

 

-----Original Message-----
From: Phillip Hellewell <[hidden email]>
To: Maven Users List <[hidden email]>
Sent: Wed, Oct 6, 2010 11:31 pm
Subject: Re: Can't specify distributionManagement in settings.xml


On Wed, Oct 6, 2010 at 1:57 PM, Anders Hammar <[hidden email]> wrote:
> Philip, have a look at the staging feature of Nexus Pro. That's what you
> want. I believe I already said this...

Thanks.  I wonder if there are any free alternatives that provide this
functionality.  You'd think you wouldn't have to pay for the ability
to copy artifacts between repositories, but anyway :)

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

mremersoncod
In reply to this post by Phillip Hellewell
> Well, at this point all I'm mainly after is the ability to copy anartifact from snapshot
> to release repo (removing -SNAPSHOT from theversion) without having to go through
> the rebuild process.
> If thatfunctionality does not exist as a free plugin or anything at themoment,
> who knows, maybe I will get time to create it :)

ok - although (due to my previous mail), artifactory allows to copy artifacts from one repo to another, this is not possible. You only can copy snapshots between snapshot repos and releases between release repos.

if you want to release your snapshot you have to go through the release plugin or ensure every single step by your own. As the others already stated, releases are far more than just cutting of the term "-SNAPSHOT"

Cheers


 

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 Wayne Fay
Bingo. I was just about to reply to say that. You generally never go from a SNAPSHOT to release as the way the artifacts are generated are very different. Not only are the names of the artifacts themselves different but the metadata in the repository is also quite different. And I am sure there are other differences as well that I am not directly aware of.

The very nature of a SNAPSHOT is different from a release. In your pom all you have to do is reference a version of 1.0-SNAPSHOT. But maven is doing a lot of work for you behind the scenes. The name of the actual artifact on the repository is more complicated as it contains a timestamp and build number right in the name.  This is why you would generally never go directly from a SNAPSHOT version to a release version as it would require rejigging of the names of the artifacts which of course could affect the way your application behaves and invalidate your testing. You can't just blinding copy a folder in a snapshot repository to a folder in your release repository.

> -----Original Message-----
> From: Wayne Fay [mailto:[hidden email]]
> Sent: Wednesday, October 06, 2010 10:42 PM
> To: Maven Users List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> > Well, at this point all I'm mainly after is the ability to copy an
> > artifact from snapshot to release repo (removing -SNAPSHOT from the
> > version) without having to go through the rebuild process.  If that
>
> As Vincent already stated, this is harder than it initially appears
> for most builds as the -SNAPSHOT tag is embedded in multiple places in
> your artifacts.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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 Phillip Hellewell
> Yeah, I'll just keep it pretty simple like this, however it will be
> even simpler because our build process will append the SVN tag name,
> so we won't ever need to manually add like "01", "02", "03", etc.

What are you using as the SVN tag name? The release plugin will create the tag for you from the GAV (GroupId, ArtifactId, Version). I suggest you look into that plugin to ensure your releases are created correctly. You will need to change your version somehow in order to create a new release.

Just be careful what you put in the version of your release as Maven does care about what you put there. For example if your first release was 1.0-BBB and your second release was 1.0-AAA, Maven would view the BBB release as the latest. This is why we specifically choose numbers as it is easy to see what the latest release build is. May also be a good idea for you to review Maven's version numbering rules ;-). The "-" in the version is significant.
Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Thiessen, Todd (Todd)
On Thu, Oct 7, 2010 at 6:51 AM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
> Bingo. I was just about to reply to say that. You generally never go from a SNAPSHOT to release as the way the artifacts are generated are very different. Not only are the names of the artifacts themselves different but the metadata in the repository is also quite different. And I am sure there are other differences as well that I am not directly aware of.

Ok, I can understand that it is more difficult than it seems because
there is more to it than just stripping off the -SNAPSHOT.

But the main thing I'm thinking about is the fact that the package
hasn't changed.  So why should I have to rebuild the code?  That not
only wastes time but more importantly it adds risks that the build may
not be identical to the snapshot build that has been tested, due to
obscure environment setting that changed on the build machine (e.g.,
suppose you installed a newer Windows SDK and that somehow affected
the build).

That's what I'm most worried about.

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

Thiessen, Todd (Todd)

> But the main thing I'm thinking about is the fact that the package
> hasn't changed.  So why should I have to rebuild the code?

But it has changed. Very much so. A SNAPSHOT is not a release.

> That not
> only wastes time but more importantly it adds risks that the build may
> not be identical to the snapshot build that has been tested due to
> obscure environment setting that changed on the build machine (e.g.,
> suppose you installed a newer Windows SDK and that somehow affected
> the build).

You give QA a release not a SNAPSHOT. That way there is no copying AT ALL. No risk. This is the advice that many have been giving you. Not sure why you keep going on about copying a snapshot. No one has EVER suggested that you copy anything.

Do your release testing on a release build and all will be well.


Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Thiessen, Todd (Todd)
On Thu, Oct 7, 2010 at 7:06 AM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
>> Yeah, I'll just keep it pretty simple like this, however it will be
>> even simpler because our build process will append the SVN tag name,
>> so we won't ever need to manually add like "01", "02", "03", etc.
>
> What are you using as the SVN tag name? The release plugin will create the tag for you from the GAV (GroupId, ArtifactId, Version). I suggest you look into that plugin to ensure your releases are created correctly. You will need to change your version somehow in order to create a new release.

So this is one aspect where our setup will differ slightly.  We don't
need the release plugin to create tags for us because our build
scripts on our build machines are already set up to create tags with
every single build (even snapshots builds).  The tag name we are using
is BRANCH_REVNUM_YYMMDD_HHMMSS, e.g., "trunk_123_101007_123055".  We
tag before each build so before running maven we will modify the
pom.xml to make the version include the tag "1.0-${tagname}-SNAPSHOT".

Of course, snapshot builds created by developers won't have a tag in
the name, so they'll just be like 1.0-SNAPSHOT.

We aren't really planning on ever changing from "1.0" on the front,
unless we find a need for it later.

Also, there is no need for the artifactId in the tag name because the
tag in SVN already lives below the component (e.g.,
/components/<artifactId>/tags/<tagname>).

> Just be careful what you put in the version of your release as Maven does care about what you put there. For example if your first release was 1.0-BBB and your second release was 1.0-AAA, Maven would view the BBB release as the latest. This is why we specifically choose numbers as it is easy to see what the latest release build is. May also be a good idea for you to review Maven's version numbering rules ;-). The "-" in the version is significant.

Ok, I will review those.  I'm hoping that for our setup there is no
problem.  For dependencies we plan to always use exact versions (in
brackets), and never work with ranges.

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

Thiessen, Todd (Todd)
> So this is one aspect where our setup will differ slightly.  We don't
> need the release plugin to create tags for us because our build
> scripts on our build machines are already set up to create tags with
> every single build (even snapshots builds).

I think we may be getting to crux of your.

SNAPSHOTS are never tagged. I think most would consider this a bad maven practice.  This isn't what a SNAPSHOT is for. A SNAPSHOT is meant to reflect the source in your trunk, not a tag.

If you wish to create a tag of something, create that build as a release. You get around that, and I think all will be well for you.


Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Phillip Hellewell
In reply to this post by Thiessen, Todd (Todd)
On Thu, Oct 7, 2010 at 10:43 AM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
>
>> But the main thing I'm thinking about is the fact that the package
>> hasn't changed.  So why should I have to rebuild the code?
>
> But it has changed. Very much so. A SNAPSHOT is not a release.

Why would the package change?  Were' using the assembly plugin to
create a zip of the binaries (dlls, libs, and headers).  Why should
that change if the code it's built from hasn't changed?

>> That not
>> only wastes time but more importantly it adds risks that the build may
>> not be identical to the snapshot build that has been tested due to
>> obscure environment setting that changed on the build machine (e.g.,
>> suppose you installed a newer Windows SDK and that somehow affected
>> the build).
>
> You give QA a release not a SNAPSHOT. That way there is no copying AT ALL. No risk. This is the advice that many have been giving you. Not sure why you keep going on about copying a snapshot. No one has EVER suggested that you copy anything.

Actually, this is the first time I think I have heard someone
specifically mention not giving SNAPSHOTs to QA.

> Do your release testing on a release build and all will be well.

Ok, I think you are on to something, but I still have a problem.  The
root of my problem is that our build machines will be creating a lot
of builds all the time, maybe even automatically every time a piece of
code is checked in.  Since there are so many builds, and only some of
them will go to QA, we don't really know beforehand if a given build
is a release candidate.  So that is why I was thinking I should make
them snapshots, but once one is approved by QA it needs to be promoted
to release.

I could make it so all the builds made by build machines are release
builds, and then never worry about copying, but that would:
1. Clutter up the release repo a ton, and cleaning up a lot of unused
release builds could be painful.
2. In the depenencies section we only want to depend on release builds
that are approved by QA.  Having all builds made by build machines go
to the release repo means we no longer have an easy way to see in the
pom.xml if it is depending on a build approved by QA.

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 Thiessen, Todd (Todd)
On Thu, Oct 7, 2010 at 11:08 AM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
>> So this is one aspect where our setup will differ slightly.  We don't
>> need the release plugin to create tags for us because our build
>> scripts on our build machines are already set up to create tags with
>> every single build (even snapshots builds).
>
> I think we may be getting to crux of your.

Yeah, I think we are getting closer...

> SNAPSHOTS are never tagged. I think most would consider this a bad maven practice.  This isn't what a SNAPSHOT is for. A SNAPSHOT is meant to reflect the source in your trunk, not a tag.
>
> If you wish to create a tag of something, create that build as a release. You get around that, and I think all will be well for you.

I don't think the existence or not of tags in SVN is a problem
exactly, but rather the crux of the problem is what do I do with all
these builds created by our build machines continuously?  Some of them
will end up going to QA; many of them won't.  And we don't know
beforehand.  So if I make them snapshot builds, I end up later wanting
the ability to copy them from the snapshot to the release repo, which
unfortunately I have found out is not trivial.  But if I make them
release builds, then I have a whole lot of builds in the release repo,
many of which never even went to QA, hard to clean up, and there is no
way to see in the <dependency> sections of the poms whether they are
depending on QA approved builds or not.

So is my problem becoming more clear now?  What's the best solution for this?

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

Jon Paynter
somethign that occurrs to me...
Take a step back and look at your processes... what determines when a build
goes to QA?  Look for a way to have that trigger a "mvn release" which will
push the build to your release repo

On Thu, Oct 7, 2010 at 10:26 AM, Phillip Hellewell <[hidden email]> wrote:

> On Thu, Oct 7, 2010 at 11:08 AM, Thiessen, Todd (Todd)
> <[hidden email]> wrote:
> >> So this is one aspect where our setup will differ slightly.  We don't
> >> need the release plugin to create tags for us because our build
> >> scripts on our build machines are already set up to create tags with
> >> every single build (even snapshots builds).
> >
> > I think we may be getting to crux of your.
>
> Yeah, I think we are getting closer...
>
> > SNAPSHOTS are never tagged. I think most would consider this a bad maven
> practice.  This isn't what a SNAPSHOT is for. A SNAPSHOT is meant to reflect
> the source in your trunk, not a tag.
> >
> > If you wish to create a tag of something, create that build as a release.
> You get around that, and I think all will be well for you.
>
> I don't think the existence or not of tags in SVN is a problem
> exactly, but rather the crux of the problem is what do I do with all
> these builds created by our build machines continuously?  Some of them
> will end up going to QA; many of them won't.  And we don't know
> beforehand.  So if I make them snapshot builds, I end up later wanting
> the ability to copy them from the snapshot to the release repo, which
> unfortunately I have found out is not trivial.  But if I make them
> release builds, then I have a whole lot of builds in the release repo,
> many of which never even went to QA, hard to clean up, and there is no
> way to see in the <dependency> sections of the poms whether they are
> depending on QA approved builds or not.
>
> So is my problem becoming more clear now?  What's the best solution for
> this?
>
> 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

Thiessen, Todd (Todd)
In reply to this post by Phillip Hellewell
> Why would the package change?  Were' using the assembly plugin to
> create a zip of the binaries (dlls, libs, and headers).  Why should
> that change if the code it's built from hasn't changed?

The names of the artifacts would change. The meta data used to retrieve the artifacts is also different. Its just the way maven works.
 
> Actually, this is the first time I think I have heard someone
> specifically mention not giving SNAPSHOTs to QA.

Depends on what you mean by QA. I am using the term rather loosely here.

In our organization, we have different "levels" of QA. For each interation during development we will actually do QA on SNAPSHOT builds.

But for builds that are a candidate release, these are built and tested as releases. These are the builds that would go to an a larger scale QA. Could be an internal team within your org or perhaps even an alpha trial site. This will vary depending on your org.

So you are right no one said you can't do any QA on a SNAPSHOT build. And to make my point clear, I am only saying you only do your RELEASE QA on a RELEASED build. What you define as "release QA" will of course vary but I think it is reasonable to say that you do it when you get close to a release candidate build.

> Ok, I think you are on to something, but I still have a problem.  The
> root of my problem is that our build machines will be creating a lot
> of builds all the time, maybe even automatically every time a piece of
> code is checked in.

Yes. This is the root of your problems ;-). The solution I think is fairly simple though. You would need to have two build plans on you CI machine. The primary one would be a SNAPSHOT build that would fire off of every commit. NO TAG would be created as part of this build. Do your early QA testing on these SNAPSHOT builds.

Then have a second plan you could fire manually as you approach release. This build would be deployed to your release repository and of course have a tag. Tell your QA team to switch to the released version of your product for testing.

Reply | Threaded
Open this post in threaded view
|

Re: Can't specify distributionManagement in settings.xml

Benson Margulies
In reply to this post by Phillip Hellewell
This conversation turns on a classic dilemma in release management.

1. The important thing is to ship exactly the bits that have been
tested. Prepare a package, give it to QA. If they like it, ship it. If
they don't, rinse, lather, and repeat.

2. The important thing is to never, ever, ever create an artifact
named 'release x.y' until *after* QA has approved it.

Followers of the second religion like to rename things. They like to
build things that are labelled 'release candidate N', and then use
some surgical instrument or another to rename at the very end.

'Build numbers' as used by Microsoft (and supported in Maven) are a
sop to the #2 committee. If every build has a unique number, you can
start labelling something 'release 5' at an early phase in the release
process, and detect escaped early components via build numbers.

Maven is not very friendly to the followers of tendency #2. Maven aids
and abets you in injecting the version number all over the place. If
you want the package to be called 'release 5', you have to run the
build as 'release 5'. If you want it to be called 'release 5 candidate
1', you call it that -- and you're stuck with it.

Snapshots are a red herring, in my opinion. Since they don't
correspond to a tag, they don't make anyone happy.

In environments that follow the tendency of #2, I would suggest asking
yourself why you are using a maven repository *at all* when pushing
releases to QA and then out the door. If you are using the assembly
plugin, why not turn off 'attaching' altogether. That means that
nothing goes onto the repo until someone puts it there (with, say, the
deploy plugin by hand). So, you can set the version to a release
version, run a build, keep the results in a secret place where only QA
can get to them, and only burn white straw and push them out when QA
approves them.

---------------------------------------------------------------------
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 Thu, Oct 7, 2010 at 11:34 AM, Benson Margulies <[hidden email]> wrote:
> This conversation turns on a classic dilemma in release management.
>
> 1. The important thing is to ship exactly the bits that have been
> tested. Prepare a package, give it to QA. If they like it, ship it. If
> they don't, rinse, lather, and repeat.
>
> 2. The important thing is to never, ever, ever create an artifact
> named 'release x.y' until *after* QA has approved it.

I think you hit the nail on the head.

Thanks to everyone for their comments in this thread.  I think we are
going to be able to make it work with two build plans.  The continuous
builds will always create snapshots, and no tagging is necessary.  The
requested builds will be release builds if there is any chance we plan
on having QA test and approve them.

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

cicidi
This post has NOT been accepted by the mailing list yet.
In reply to this post by Phillip Hellewell
hey phil,this resoltion is awesome, i have been work on this issue for couple days, thank you so much
Reply | Threaded
Open this post in threaded view
|

RE: Can't specify distributionManagement in settings.xml

xgecemx
This post has NOT been accepted by the mailing list yet.
In reply to this post by Thiessen, Todd (Todd)
I totally agree with you.


Reply | Threaded
Open this post in threaded view
|

RE: Can't specify distributionManagement in settings.xml

shawnmendes
This post has NOT been accepted by the mailing list yet.
I think the same.
1234