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

Siegmann Daniel, NY
Phillip,

Nexus supports deployment via HTTP. Probably other repo managers do too.

Using Maven in a corporate setting without having a repository manager
is like working in a team without a version control system. You could do
it but you're going to suffer.

~Daniel

-----Original Message-----
From: Phillip Hellewell [mailto:[hidden email]]
Sent: Wednesday, October 06, 2010 11:55 AM
To: Maven Users List
Subject: Re: Can't specify distributionManagement in settings.xml

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]


---------------------------------------------------------------------
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 Wed, Oct 6, 2010 at 12:42 PM, Siegmann Daniel, NY
<[hidden email]> wrote:
> Phillip,
>
> Nexus supports deployment via HTTP. Probably other repo managers do too.

Yeah, I just figured that out.  But I'm still getting a 401 error
because I haven't set my credentials yet.   I haven't figured out yet
if it is Tomcat or Nexus that is supposed to specify how
authentication works.

> Using Maven in a corporate setting without having a repository manager
> is like working in a team without a version control system. You could do
> it but you're going to suffer.

No worries.  I've already got Nexus installed (just dropped the WAR
into Tomcat; almost too easy).  I just haven't played with it enough
yet to make sure it can do everything I need it to (like copy
artifacts between repositories).

Also, nothing changes the fact that <distributionManagement> can only
specify two types of repositories.  So to keep things easy I think
from a deployment perspective I should only worry about two
repositories (snapshot and release).

Lastly, I have not found out yet if Nexus or any other repo manager
out there supports SPNEGO.  I may not need any security for
downloading, but for upload/deploy it's an absolute necessity to
restrict it to specific domain users.  One potential solution I'm
hoping will work is to use Nexus only for download, and for deployment
bypass Nexus and deploy to the snapshot or release folder directly
using the file:// protocol with a UNC path.

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 Siegmann Daniel, NY
  On 06/10/2010 2:42 PM, Siegmann Daniel, NY wrote:
> Phillip,
>
> Nexus supports deployment via HTTP. Probably other repo managers do too.
>
> Using Maven in a corporate setting without having a repository manager
> is like working in a team without a version control system. You could do
> it but you're going to suffer.
+1
It makes Maven so much easier to understand and gives you lots of nice
features for managing and controlling your use of dependent libraries
besides a good visual interface into your own artifacts:
For example:
  browse Maven Central proxy in your repo to find the right artifactId
and groupId and latest versions for third party stuff.
  upload a third party package that is not distributed through Maven
Central so that your team gets it without adding anything to their
settings.xml
  add a new repo for a special package without touching everyone's
settings.xml just by adding it to your central proxy definition.
  quickly find the latest version of a library that is available just by
looking in the index of your repo's proxy.
  developers can delete their own local Maven cache without having a
huge penalty since the repo has a copy of everything that you have on
your workstation and only gets new things from the Internet, once.

Much better sense of being in control of Maven artifacts.

Ron

> ~Daniel
>
> -----Original Message-----
> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Wednesday, October 06, 2010 11:55 AM
> To: Maven Users List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> 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]
>
>
> ---------------------------------------------------------------------
> 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 Wed, Oct 6, 2010 at 1:17 PM, Ron Wheeler
<[hidden email]> wrote:

>  On 06/10/2010 2:42 PM, Siegmann Daniel, NY wrote:
>>
>> Using Maven in a corporate setting without having a repository manager
>> is like working in a team without a version control system. You could do
>> it but you're going to suffer.
>
> +1
> It makes Maven so much easier to understand and gives you lots of nice
> features for managing and controlling your use of dependent libraries
> besides a good visual interface into your own artifacts:

Yeah, I've been playing with it some more and it is really nice.  I
like the searching functionality.  Also, I found the security settings
and LDAP is there, so I'm going to read some more documentation to
figure out how to set up roles so that, e.g., anyone can download but
only certain users can upload/deploy.

I'm going to forget the idea of bypassing Nexus by using a network
share to upload to a repository directly.  I think it's better to
retain more control and have everyone always go through the Nexus MRM.

Lastly, I'm going to put off worrying about GSSAPI/Kerberos support.
I'll just hard-code my password in my settings file, or pass it on the
command-line if that's supported.

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 06/10/2010 3:14 PM, Phillip Hellewell wrote:

> On Wed, Oct 6, 2010 at 12:42 PM, Siegmann Daniel, NY
> <[hidden email]>  wrote:
>> Phillip,
>>
>> Nexus supports deployment via HTTP. Probably other repo managers do too.
> Yeah, I just figured that out.  But I'm still getting a 401 error
> because I haven't set my credentials yet.   I haven't figured out yet
> if it is Tomcat or Nexus that is supposed to specify how
> authentication works.
>
>> Using Maven in a corporate setting without having a repository manager
>> is like working in a team without a version control system. You could do
>> it but you're going to suffer.
> No worries.  I've already got Nexus installed (just dropped the WAR
> into Tomcat; almost too easy).  I just haven't played with it enough
> yet to make sure it can do everything I need it to (like copy
> artifacts between repositories).
>
Should never need to do this.
> Also, nothing changes the fact that<distributionManagement>  can only
> specify two types of repositories.  So to keep things easy I think
> from a deployment perspective I should only worry about two
> repositories (snapshot and release).
That is a good start.

You do have version numbers. Can use RC and Mn in your release version
to show staging status.


> Lastly, I have not found out yet if Nexus or any other repo manager
> out there supports SPNEGO.  I may not need any security for
> downloading, but for upload/deploy it's an absolute necessity to
> restrict it to specific domain users.  One potential solution I'm
> hoping will work is to use Nexus only for download, and for deployment
> bypass Nexus and deploy to the snapshot or release folder directly
> using the file:// protocol with a UNC path.
>
Try the Nexus forum. Good guys there as well.

> 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 Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
<[hidden email]> wrote:
>>
>> No worries.  I've already got Nexus installed (just dropped the WAR
>> into Tomcat; almost too easy).  I just haven't played with it enough
>> yet to make sure it can do everything I need it to (like copy
>> artifacts between repositories).
>>
> Should never need to do this.

When you say "Should never need to do this", are you also saying that
it is not supported?

If I deploy non-snapshot builds to the snapshot repository first
(because I don't consider them released until QA approval), then I
want to move those to the release repo after QA approval, why would I
want the hassle with finding where I checked out the project (or
worse, check it out again and rebuild it), just so I can deploy it to
another repo when it's going to be identical, even the version number?

Speaking of copying between repositories, is there also a way to
delete artifacts in a repository (I need to "move", which means copy +
delete).

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
Philip, have a look at the staging feature of Nexus Pro. That's what you
want. I believe I already said this...

/Anders

On Wed, Oct 6, 2010 at 21:42, Phillip Hellewell <[hidden email]> wrote:

> On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
> <[hidden email]> wrote:
> >>
> >> No worries.  I've already got Nexus installed (just dropped the WAR
> >> into Tomcat; almost too easy).  I just haven't played with it enough
> >> yet to make sure it can do everything I need it to (like copy
> >> artifacts between repositories).
> >>
> > Should never need to do this.
>
> When you say "Should never need to do this", are you also saying that
> it is not supported?
>
> If I deploy non-snapshot builds to the snapshot repository first
> (because I don't consider them released until QA approval), then I
> want to move those to the release repo after QA approval, why would I
> want the hassle with finding where I checked out the project (or
> worse, check it out again and rebuild it), just so I can deploy it to
> another repo when it's going to be identical, even the version number?
>
> Speaking of copying between repositories, is there also a way to
> delete artifacts in a repository (I need to "move", which means copy +
> delete).
>
> 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
Phil. I think you just need to try it and read the Nexus docs.  Sounds like you are really making things complicated for yourself.

> -----Original Message-----
> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Wednesday, October 06, 2010 3:43 PM
> To: Maven Users List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
> <[hidden email]> wrote:
> >>
> >> No worries.  I've already got Nexus installed (just dropped the WAR
> >> into Tomcat; almost too easy).  I just haven't played with it enough
> >> yet to make sure it can do everything I need it to (like copy
> >> artifacts between repositories).
> >>
> > Should never need to do this.
>
> When you say "Should never need to do this", are you also saying that
> it is not supported?
>
> If I deploy non-snapshot builds to the snapshot repository first
> (because I don't consider them released until QA approval), then I
> want to move those to the release repo after QA approval, why would I
> want the hassle with finding where I checked out the project (or
> worse, check it out again and rebuild it), just so I can deploy it to
> another repo when it's going to be identical, even the version number?
>
> Speaking of copying between repositories, is there also a way to
> delete artifacts in a repository (I need to "move", which means copy +
> delete).
>
> 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 06/10/2010 3:42 PM, Phillip Hellewell wrote:

> On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
> <[hidden email]>  wrote:
>>> No worries.  I've already got Nexus installed (just dropped the WAR
>>> into Tomcat; almost too easy).  I just haven't played with it enough
>>> yet to make sure it can do everything I need it to (like copy
>>> artifacts between repositories).
>>>
>> Should never need to do this.
> When you say "Should never need to do this", are you also saying that
> it is not supported?
>
Can not imagine a use case for it.
> If I deploy non-snapshot builds to the snapshot repository first
How. I do not think that this can be done.
> (because I don't consider them released until QA approval), then I
> want to move those to the release repo after QA approval, why would I
> want the hassle with finding where I checked out the project (or
> worse, check it out again and rebuild it), just so I can deploy it to
> another repo when it's going to be identical, even the version number?
Different version number   2.4.1-SNAPSHOT would be rebuilt as 2.4.1 when
it is ready for release.
A SNAPSHOT is meant to be mutable. It is only considered to be the
latest in a series of attempts to build a release.
Releases are forever. You are not supposed to ever rerelease an released
artifact.
It requires notification of anyone that might have possibly ever seen
the artifact in a repository. Usually comes with apologies and promises
of being more careful in the future.
If you build with SNAPSHOT dependencies, you expect that your build is
not repeatable but if you build with released artifacts as dependencies,
the "Maven way"
insists that any changes to the behaviour of the built package is a
result of code in the project not in a dependency.

> Speaking of copying between repositories, is there also a way to
> delete artifacts in a repository (I need to "move", which means copy +
> delete).

> You should never have to delete a release. Maven can not but Nexus can.

> 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
In reply to this post by Anders Hammar
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

Phillip Hellewell
In reply to this post by Thiessen, Todd (Todd)
On Wed, Oct 6, 2010 at 2:00 PM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
> Phil. I think you just need to try it and read the Nexus docs.  Sounds like you are really making things complicated for yourself.

Yeah, you are probably right.

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 a plugin for the open source version of nexus. I'd bet it isn't quite as straight forward as you might think ;-)

> -----Original Message-----
> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Wednesday, October 06, 2010 5:31 PM
> To: Maven Users List
> 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

Thiessen, Todd (Todd)
Err mean to say "Write a plugin for Nexus". Bah sorry. Hate it when I make typos like that. Reply too fast. ;-)

> -----Original Message-----
> From: Thiessen, Todd (Todd) [mailto:[hidden email]]
> Sent: Wednesday, October 06, 2010 5:33 PM
> To: Maven Users List
> Subject: RE: Can't specify distributionManagement in settings.xml
>
> Why a plugin for the open source version of nexus. I'd bet it isn't quite
> as straight forward as you might think ;-)
>
> > -----Original Message-----
> > From: Phillip Hellewell [mailto:[hidden email]]
> > Sent: Wednesday, October 06, 2010 5:31 PM
> > To: Maven Users List
> > 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

Phillip Hellewell
On Wed, Oct 6, 2010 at 3:34 PM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
> Err mean to say "Write a plugin for Nexus". Bah sorry. Hate it when I make typos like that. Reply too fast. ;-)

The file structure of a repository seems to make it look like copying
artifacts is almost trivial.

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 Wed, Oct 6, 2010 at 2:04 PM, Ron Wheeler
<[hidden email]> wrote:
>  On 06/10/2010 3:42 PM, Phillip Hellewell wrote:
>>
>> If I deploy non-snapshot builds to the snapshot repository first
>
> How. I do not think that this can be done.

I asked earlier if non-snapshot builds can be deployed to a snapshot
repository, and no one answered so I've been assuming/hoping it is
possible.

>> (because I don't consider them released until QA approval), then I
>> want to move those to the release repo after QA approval, why would I
>> want the hassle with finding where I checked out the project (or
>> worse, check it out again and rebuild it), just so I can deploy it to
>> another repo when it's going to be identical, even the version number?
>
> Different version number   2.4.1-SNAPSHOT would be rebuilt as 2.4.1 when it
> is ready for release.

No, there are basically there types of builds I want to do.  Most
people don't have a stage between snapshot and release, so I'm
guessing that is why I am not getting any clear direction about the
best way to do this.
1. A snapshot build made by a developer that can be deployed to a
snapshot repo.  Ver = "1.0-SNAPSHOT".
2. A "staging" build made by a build machine.  Can this go into the
snapshot repo?  Ver = "1.0-tag-TAGNAME".
3. A release build.  Will be deployed to a release repo. Ver =
"1.0-tag-TAGNAME".

The artifact will not change at all between #2 and #3.  So no, it is
not a different version number, and no I do not want to go hunt down
where I created the build or have to check it out and build it again
so I can redeploy it.

So the questions are:
* Can I not put it a "staging" build into the a snapshot repository
because it does not have SNAPSHOT in the name?
* If a "staging" build goes into the snapshot repository, how can I
easily move it to the release repo.  I believe Anders has already
answered that Nexus Pro can provide this functionality, but I do find
it odd that copying artifacts between repositories has to be so hard.

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
On Wed, Oct 6, 2010 at 3:50 PM, Phillip Hellewell <[hidden email]> wrote:

>
> No, there are basically there types of builds I want to do.  Most
> people don't have a stage between snapshot and release, so I'm
> guessing that is why I am not getting any clear direction about the
> best way to do this.
> 1. A snapshot build made by a developer that can be deployed to a
> snapshot repo.  Ver = "1.0-SNAPSHOT".
> 2. A "staging" build made by a build machine.  Can this go into the
> snapshot repo?  Ver = "1.0-tag-TAGNAME".
> 3. A release build.  Will be deployed to a release repo. Ver =
> "1.0-tag-TAGNAME".

Sorry to reply to myself, but I have a guess what you are all
thinking.  #2 builds are snapshots so just name them as such, e.g.,
"1.0-tag-TAGNAME-SNAPSHOT".

I think that does make the most sense, since it makes it more clear
that these are not release artifacts.

So I'm only left with one question.  Once a snapshot is approved for
release, why should I have to go check out the project and rebuild it
and everything with the -SNAPSHOT removed?  Is there a mechanism or
tool (Nexus Pro perhaps?) that can copy an artifact from the snapshot
repo to the release repo while removing the -SNAPSHOT from the
version?

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

vlatombe
In Maven/Nexus terminology, you deploy a release candidate to a staging area
(#2) in your example. This artifact (or group of artifacts) is then made
available to a group of people for validation (it can be automated or
manual). Once it's validated it is promoted and copied to the release
repository.

In most Maven artifacts you'll find the version embedded within the artifact
itself (by default, in java archives it will embed the pom.xml). It is also
useful to fill in files like MANIFEST.MF with the artifact information so
these can be retrieved at runtime. That's why once deployed, an artifact
coordinates are immutable.

I hope it answers your question,

Vincent

2010/10/7 Phillip Hellewell <[hidden email]>

> On Wed, Oct 6, 2010 at 3:50 PM, Phillip Hellewell <[hidden email]>
> wrote:
> >
> > No, there are basically there types of builds I want to do.  Most
> > people don't have a stage between snapshot and release, so I'm
> > guessing that is why I am not getting any clear direction about the
> > best way to do this.
> > 1. A snapshot build made by a developer that can be deployed to a
> > snapshot repo.  Ver = "1.0-SNAPSHOT".
> > 2. A "staging" build made by a build machine.  Can this go into the
> > snapshot repo?  Ver = "1.0-tag-TAGNAME".
> > 3. A release build.  Will be deployed to a release repo. Ver =
> > "1.0-tag-TAGNAME".
>
> Sorry to reply to myself, but I have a guess what you are all
> thinking.  #2 builds are snapshots so just name them as such, e.g.,
> "1.0-tag-TAGNAME-SNAPSHOT".
>
> I think that does make the most sense, since it makes it more clear
> that these are not release artifacts.
>
> So I'm only left with one question.  Once a snapshot is approved for
> release, why should I have to go check out the project and rebuild it
> and everything with the -SNAPSHOT removed?  Is there a mechanism or
> tool (Nexus Pro perhaps?) that can copy an artifact from the snapshot
> repo to the release repo while removing the -SNAPSHOT from the
> version?
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Vincent
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
What you are asking for definitely is not recommended. The release plugin already has a "staging" feature but it is not the recommended way to do.

Putting a "staging" build into the release repo is not recommended from my perspective either. That isn't what a snapshot is for.  They are meant to hold only the latest version of your build. Old artifacts are usually nuked.

Besides, to do what you want you don't HAVE to have a staging repository anyway. You can still release artifacts just fine and not have to copy anything. You just don't announce that a release is ready until it has passed testing.

It is rather simple....

1. Work with SNAPSHOTS until you start approaching a release. Example version 1.0-01-SNAPSHOT.
2. Cut a release milestone build to send to alpha trials or extended QA. 1.0-01.
3. Continue to do work on your SNAPSHOT version and fix any bugs found. All fixes go into 1.0-02-SNAPSHOT.
4. Release 1.0-02 at an appropriate time.
5. Repeat.

You'll eventually release 1.0-xy. Hopefully, if your release is not that buggy, xy never gets to two digits ;-). And if you are agile and doing a lot of QA during each iteration, you'll have a final release of 02 or 03.

So if you released with version 1.0-05 for example, it is a bit annoying that everyone can see and download 1.0-01 to 1.0-05.  1.0-01 to 1.0-04 are all basically dead releases and you really don't want anyone to use them. Staging keeps this from happening.  You can also of course do this by simply saying to your QA and/or release team "don't use releases 01 to 04" ;-).

Staging is a nice to have, but hardly a show stopper.  Which is likely why is does not exist freely. At least not yet.

You seem to be passionate about it though so by all means volunteer some of your time to create such a plugin. I am sure the Nexus community would be happy for your contribution. Nothing helps ones understand like actually doing.

> -----Original Message-----
> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Wednesday, October 06, 2010 5:51 PM
> To: Maven Users List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> On Wed, Oct 6, 2010 at 2:04 PM, Ron Wheeler
> <[hidden email]> wrote:
> >  On 06/10/2010 3:42 PM, Phillip Hellewell wrote:
> >>
> >> If I deploy non-snapshot builds to the snapshot repository first
> >
> > How. I do not think that this can be done.
>
> I asked earlier if non-snapshot builds can be deployed to a snapshot
> repository, and no one answered so I've been assuming/hoping it is
> possible.
>
> >> (because I don't consider them released until QA approval), then I
> >> want to move those to the release repo after QA approval, why would I
> >> want the hassle with finding where I checked out the project (or
> >> worse, check it out again and rebuild it), just so I can deploy it to
> >> another repo when it's going to be identical, even the version number?
> >
> > Different version number   2.4.1-SNAPSHOT would be rebuilt as 2.4.1
> when it
> > is ready for release.
>
> No, there are basically there types of builds I want to do.  Most
> people don't have a stage between snapshot and release, so I'm
> guessing that is why I am not getting any clear direction about the
> best way to do this.
> 1. A snapshot build made by a developer that can be deployed to a
> snapshot repo.  Ver = "1.0-SNAPSHOT".
> 2. A "staging" build made by a build machine.  Can this go into the
> snapshot repo?  Ver = "1.0-tag-TAGNAME".
> 3. A release build.  Will be deployed to a release repo. Ver =
> "1.0-tag-TAGNAME".
>
> The artifact will not change at all between #2 and #3.  So no, it is
> not a different version number, and no I do not want to go hunt down
> where I created the build or have to check it out and build it again
> so I can redeploy it.
>
> So the questions are:
> * Can I not put it a "staging" build into the a snapshot repository
> because it does not have SNAPSHOT in the name?
> * If a "staging" build goes into the snapshot repository, how can I
> easily move it to the release repo.  I believe Anders has already
> answered that Nexus Pro can provide this functionality, but I do find
> it odd that copying artifacts between repositories has to be so hard.
>
> 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
On Wed, Oct 6, 2010 at 4:19 PM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
> What you are asking for definitely is not recommended. The release plugin already has a "staging" feature but it is not the recommended way to do.

Good to know, thanks.

> Putting a "staging" build into the release repo is not recommended from my perspective either. That isn't what a snapshot is for.  They are meant to hold only the latest version of your build. Old artifacts are usually nuked.
>
> Besides, to do what you want you don't HAVE to have a staging repository anyway. You can still release artifacts just fine and not have to copy anything. You just don't announce that a release is ready until it has passed testing.

Yeah, I'm thinking I don't REALLY need a staging repository.  I can do
most builds as SNAPSHOTs (even builds created by build machines).
Only builds approved by QA will be deployed to the release repository.

> It is rather simple....
>
> 1. Work with SNAPSHOTS until you start approaching a release. Example version 1.0-01-SNAPSHOT.
> 2. Cut a release milestone build to send to alpha trials or extended QA. 1.0-01.
> 3. Continue to do work on your SNAPSHOT version and fix any bugs found. All fixes go into 1.0-02-SNAPSHOT.
> 4. Release 1.0-02 at an appropriate time.
> 5. Repeat.

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.

> You'll eventually release 1.0-xy. Hopefully, if your release is not that buggy, xy never gets to two digits ;-). And if you are agile and doing a lot of QA during each iteration, you'll have a final release of 02 or 03.
>
> So if you released with version 1.0-05 for example, it is a bit annoying that everyone can see and download 1.0-01 to 1.0-05.  1.0-01 to 1.0-04 are all basically dead releases and you really don't want anyone to use them. Staging keeps this from happening.  You can also of course do this by simply saying to your QA and/or release team "don't use releases 01 to 04" ;-).

Yeah, we may end up with artifacts in the release repo that are never
actually delivered to customers or dependend on by other artifacts,
but I don't think that will be a problem for us.

> Staging is a nice to have, but hardly a show stopper.  Which is likely why is does not exist freely. At least not yet.
>
> You seem to be passionate about it though so by all means volunteer some of your time to create such a plugin. I am sure the Nexus community would be happy for your contribution. Nothing helps ones understand like actually doing.

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
functionality does not exist as a free plugin or anything at the
moment, who knows, maybe I will get time to create it :)

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

Wayne Fay
> 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]

1234