How burnt-in to maven (and repo managers) is the snapshot resolution
metadata ? Specifically, when I pull metadata like
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>org.company</groupId>
<artifactId>artifact</artifactId>
<version>2.3-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20081030.213329</timestamp>
<buildNumber>5</buildNumber>
</snapshot>
<lastUpdated>20081030213342</lastUpdated>
</versioning>
</metadata>
Does the resultant resolved snapshot *have* to be called
artifact-${timestamp}-${buildnumber}.jar ?
It would be useful if it could be configured to be artifact-${git
sha1}.jar instead. Or even for it to be artifact-${uuid}, which is
resolved in the <snapshot> section
Even if it couldn't, an extensible tags element would be good; something like
...
<snapshot>
<timestamp>20081030.213329</timestamp>
<buildNumber>5</buildNumber>
<properties>
<revision>df360a1e8df170892de84df8876aaf28e3815598</revision>
<buildId>B2A7A1E7-FE24-4A81-B87C-88298C1D4CE5</buildId>
<branch>master</branch>
<hudson.project>Main-Build</hudson.project>
<hudson.build.number>123</hudson.build.number>
<flags>passed-integration, passed-regression</flags>
....
<properties>
</snapshot>
Would that be difficult to add without breaking many things?
On Wed, Dec 23, 2009 at 11:55 PM, Brian Fox <bri...@infinity.nu> wrote:
>
> On Wed, Dec 23, 2009 at 11:28 AM, Dan Tran <dant...@gmail.com> wrote:
> > It is interesting that 3.0 apha x already drops this feature even thou
> > the discussion ( a while back ) asserted it would be deprecated in 3.0
> > and remove in 3.1
> >
>
> I would characterize it as this feature hasn't yet been re-implemented
> in 3.x. Since this area was rewritten from the ground up to simplify
> it, this was left out. AFAIK, it's just waiting for someone to scratch
> the itch and implement it.
>
> > However, as I have complained before ;-), this feature is crucially
> > needed for multi platforms ( native, c/c++) build of the same project.
> > I hope maven team could come up
> > with an alternative in 3.x
>
> Yes, this is a recognized problem. Enhancing the snapshot metadata is
> likely the best solution to this problem.
>
> >
> > -D
> >
> > On Wed, Dec 23, 2009 at 8:21 AM, fabrice.mercier1 <beufm...@yahoo.fr> wrote:
> >>
> >> Hi
> >>
> >> Why do you think it is a bad practice ? I am currently trouble with the
> >> choice of setting it to true or false.
> >>
> >> Fabrice
> >>
> >>
> >> Jason van Zyl-5 wrote:
> >>>
> >>> I think it can be in the same vein as the no versions for plugins. Not
> >>> a very good idea and potentially harmful.
> >>>
> >>> We put it in, deprecate it over 3.0 and it becomes taboo in 3.1. If
> >>> it's a bad practice in the majority of cases then we eliminate it.
> >>> Over the life of 3.0 to 3.1 should be long enough. We can also start
> >>> deprecating things like this in the 2.x line.
> >>>
> >>> On 2009-09-04, at 4:49 PM, Brian Fox wrote:
> >>>
> >>>> I saw this on Benjamin's compat page yesterday and thought I'd throw
> >>>> it up for discussion:
> >>>> Non-unique Snapshot Deployments
> >>>>
> >>>> The setting <uniqueVersion>false</uniqueVersion> for a distribution
> >>>> repository has no effect in version 3.x, snapshot artifacts will
> >>>> always be deployed using a timestamped version.
> >>>>
> >>>> I personally am not a fan of this feature as I've seen it cause more
> >>>> problems than it solves. It also harkens back to a time when
> >>>> Repository Managers didn't exist and seems like a work around to
> >>>> cleaning up old snapshots. So my life would be easier if this didn't
> >>>> exist.
> >>>>
> >>>> That said, I know of at least one instance where this is required
> >>>> (will send a separate thread about that because it's a flaw in Maven
> >>>> that should be addressed separately).
> >>>>
> >>>> With the focus on 3.0 being a drop in for M2, this clearly would cause
> >>>> some heartache for users. Does anyone feel strongly enough that this
> >>>> should go back? (and is willing to write the new code for it?)
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder, Apache Maven
> >>> http://twitter.com/jvanzyl
> >>> http://twitter.com/SonatypeNexus
> >>> http://twitter.com/SonatypeM2E
> >>> ----------------------------------------------------------
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >> -----
> >> http://old.nabble.com/file/u1297858/ft.gif
> >> Architect
> >> Almerys, activité santé d'Orange Business Services, TOULOUSE
> >> http://www.orange-business.com http://www.orange-business.com
> >> --
> >> View this message in context:
> >> http://old.nabble.com/dropping-non-unique-snapshots-in-Maven-3-tp25295809p26904205.html
> >> Sent from the Maven Developers mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
