buildnumber value not making it to local repo

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

buildnumber value not making it to local repo

Brad Harper
I've configured the buildnumber plugin to attach a timestamp thusly

 
<finalName>${project.artifactId}-${project.version}-${buildNumber}</fina
lName>

and the [jar] artifact is produced in the target/ directory as expected.

But the build number is not carried into the local repo when installing
the artifact.

If the command '% mvn clean install' produces

   framework-1.2.3-SNAPHOT-20081113155701.jar

in target/, the artifact appearing in the local repo is

   framework-1.2.3-SNAPSHOT.jar

I haven't tried, but I expect that the results would be the same for
'deploy', as well. Ideas anyone?

Thanks and regards,
Brad

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

Reply | Threaded
Open this post in threaded view
|

Re: buildnumber value not making it to local repo

Wendy Smoak
On Thu, Nov 13, 2008 at 5:14 PM, Harper, Brad <[hidden email]> wrote:
> I've configured the buildnumber plugin to attach a timestamp
...
> But the build number is not carried into the local repo when installing
> the artifact.

The finalName in the pom does not affect the filename in the repository.

The repository format is fixed so that Maven understands how to
retrieve artifacts.  That's not to say it *couldn't* be changed, but
currently there is just the one implementation.

And we really need to put this in the FAQ. :)

--
Wendy

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

Reply | Threaded
Open this post in threaded view
|

RE: buildnumber value not making it to local repo

Brad Harper
So I've been mis-interpreting the way the build number would be used.

My organization has separate UAT [user acceptance test] and production
environments. Nothing gets to production that hasn't been through UAT.

The development group distributes artifacts to the group responsible for
deployment into these environments via an internal remote maven
repository. Generally, we convey the artifacts to the repo using the
'release' plugin, which I understand relies on the 'deploy' plugin.

We've been forced to advance version numbers when deploying successive
fixes/refinements in UAT so that the artifacts can be differentiated.
I.e. we can't release 1.2.3, have it placed in UAT, and then release
another 1.2.3 with very minor tweaks because it can't be [easily]
distinguished from the first one. So we release 1.2.4, even though 1.2.3
was never a true production version. UAT is effectively an extension of
the QA process.

I was hoping that build number would let us iteratively refine an
artifact in UAT without relying on version number alone.

It sounds like the best that can be done is to inject the build number
into jar/war manifest files.

Brad

> -----Original Message-----
> From: Wendy Smoak [mailto:[hidden email]]
> Sent: Thursday, November 13, 2008 6:19 PM
> To: Maven Users List
> Subject: Re: buildnumber value not making it to local repo
>
> On Thu, Nov 13, 2008 at 5:14 PM, Harper, Brad
> <[hidden email]> wrote:
> > I've configured the buildnumber plugin to attach a timestamp
> ...
> > But the build number is not carried into the local repo when
> > installing the artifact.
>
> The finalName in the pom does not affect the filename in the
> repository.
>
> The repository format is fixed so that Maven understands how
> to retrieve artifacts.  That's not to say it *couldn't* be
> changed, but currently there is just the one implementation.
>
> And we really need to put this in the FAQ. :)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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: buildnumber value not making it to local repo

Wendy Smoak
On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad <[hidden email]> wrote:

> I was hoping that build number would let us iteratively refine an
> artifact in UAT without relying on version number alone.

Do you require the full release process with a tag for every one of
these versions, or would unique snapshots (with the revision number
baked inside) work for you?

Here's an example of the version numbers:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/tiles/tiles-core/2.0.7-SNAPSHOT/

> It sounds like the best that can be done is to inject the build number
> into jar/war manifest files.

This is a good idea regardless. :)

--
Wendy

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

Reply | Threaded
Open this post in threaded view
|

Re: buildnumber value not making it to local repo

Nick_S
You could start a release branch with the release plugin and start
releasing release candidates, like 1.2.3-RC1, 1.2.3-RC2, etc, until
you have a final release and release that as 1.2.3.

Hth,

Nick Stolwijk
~Java Developer~

Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl



On Fri, Nov 14, 2008 at 1:44 AM, Wendy Smoak <[hidden email]> wrote:

> On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad <[hidden email]> wrote:
>
>> I was hoping that build number would let us iteratively refine an
>> artifact in UAT without relying on version number alone.
>
> Do you require the full release process with a tag for every one of
> these versions, or would unique snapshots (with the revision number
> baked inside) work for you?
>
> Here's an example of the version numbers:
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/tiles/tiles-core/2.0.7-SNAPSHOT/
>
>> It sounds like the best that can be done is to inject the build number
>> into jar/war manifest files.
>
> This is a good idea regardless. :)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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: buildnumber value not making it to local repo

Brad Harper
In reply to this post by Wendy Smoak
> Do you require the full release process with a tag for every
> one of these versions, or would unique snapshots (with the
> revision number baked inside) work for you?

We don't *require* tags at each iteration, but since its been our
practice to use the 'release' plugin to deploy, extra tags are a
by-product. The tagged release that makes it into production is
required.

> This is a good idea regardless. :)

Agreed.

Brad

> -----Original Message-----
> From: Wendy Smoak [mailto:[hidden email]]
> Sent: Thursday, November 13, 2008 6:44 PM
> To: Maven Users List
> Subject: Re: buildnumber value not making it to local repo
>
> On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad
> <[hidden email]> wrote:
>
> > I was hoping that build number would let us iteratively refine an
> > artifact in UAT without relying on version number alone.
>
> Do you require the full release process with a tag for every
> one of these versions, or would unique snapshots (with the
> revision number baked inside) work for you?
>
> Here's an example of the version numbers:
> http://people.apache.org/repo/m2-snapshot-repository/org/apach
> e/tiles/tiles-core/2.0.7-SNAPSHOT/
>
> > It sounds like the best that can be done is to inject the
> build number
> > into jar/war manifest files.
>
> This is a good idea regardless. :)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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: buildnumber value not making it to local repo

Brad Harper
In reply to this post by Nick_S
That's effectively what happens during the [internal] QA process. We
release 1.2.3-RC-1, ..., up to n, as needed. When its been qualified by
the QA folks, the artifact is re-released *without* the '-RC-x' suffix.

After some basic smoke tests, a request is made to deploy the artifact
into UAT where customers have access. Te UAT version lacks the '-RC-x'.

Often the issues that arise in UAT are very minor, and it's been a pain
to have to re-release to UAT [with a new version number]. These UAT-only
releases never make it into production.

I had hoped that the build number would replace our '-RC-x' versioning
convention and allow QA to differentiate submitted artifacts having the
same base version AND serve the same purpose within UAT.

When we get to the 'final' UAT-approved version, it is what it is. No
re-release would be required and the artifact can be deployed directly
to production. Since we deploy via the 'release' plugin, the tag
associated with that build is already on hand.

Brad

> -----Original Message-----
> From: Nick Stolwijk [mailto:[hidden email]]
> Sent: Friday, November 14, 2008 4:00 AM
> To: Maven Users List
> Subject: Re: buildnumber value not making it to local repo
>
> You could start a release branch with the release plugin and
> start releasing release candidates, like 1.2.3-RC1,
> 1.2.3-RC2, etc, until you have a final release and release
> that as 1.2.3.
>
> Hth,
>
> Nick Stolwijk
> ~Java Developer~
>
> Iprofs BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> www.iprofs.nl
>
>
>
> On Fri, Nov 14, 2008 at 1:44 AM, Wendy Smoak <[hidden email]> wrote:
> > On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad
> <[hidden email]> wrote:
> >
> >> I was hoping that build number would let us iteratively refine an
> >> artifact in UAT without relying on version number alone.
> >
> > Do you require the full release process with a tag for every one of
> > these versions, or would unique snapshots (with the revision number
> > baked inside) work for you?
> >
> > Here's an example of the version numbers:
> >
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/tiles/
> > tiles-core/2.0.7-SNAPSHOT/
> >
> >> It sounds like the best that can be done is to inject the build
> >> number into jar/war manifest files.
> >
> > This is a good idea regardless. :)
> >
> > --
> > Wendy
> >
> >
> ---------------------------------------------------------------------
> > 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]