force maven to redownload/refresh "released" dependencies

[Shan Syed]

is there a way to force a project to refresh certain dependencies every
build? i.e. replicate SNAPSHOT behaviour with "released" artifacts

S

[Wayne Fay]

> is there a way to force a project to refresh certain dependencies every
> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts

Absolutely not. Released artifacts MUST NOT CHANGE.

Wayne

[Manos Batsis]

On 07/30/2010 07:16 PM, Wayne Fay wrote:
>> is there a way to force a project to refresh certain dependencies every
>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>
> Absolutely not. Released artifacts MUST NOT CHANGE.

+1, never ever ;-)

Released artifact versioning is supposed to guarantee consistency.

Manos

[Shan Syed]

ok, thanks
basically for liability reasons for a certain project, we have to provide
specific times of when a project was built and when/where all its
dependencies were retrieved at/from
we have to ensure a sanitary build for all these JARs and a complete log of
going from 0 to 100 for the build; so we are faced with either clearing out
the .m2 each time
I was wondering if there was a way to force this through maven

On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
<***@geekologue.com>wrote:

> On 07/30/2010 07:16 PM, Wayne Fay wrote:
>
>> is there a way to force a project to refresh certain dependencies every
>>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>>
>>
>> Absolutely not. Released artifacts MUST NOT CHANGE.
>>
>
> +1, never ever ;-)
>
> Released artifact versioning is supposed to guarantee consistency.
>
> Manos
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Paul Benedict]

Replacing a SNAPSHOT with a non-SNAPSHOT version is equivalent to upgrading.
Jason is right in that this should never be automatically done by Maven.
Maven cannot guess or determine when you are ready to give up SNAPSHOT
versions.

However, perhaps you need an external batch process that discovers new
versions and automatically upgrades POMs.

Paul

On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed <***@gmail.com> wrote:

> ok, thanks
> basically for liability reasons for a certain project, we have to provide
> specific times of when a project was built and when/where all its
> dependencies were retrieved at/from
> we have to ensure a sanitary build for all these JARs and a complete log of
> going from 0 to 100 for the build; so we are faced with either clearing out
> the .m2 each time
> I was wondering if there was a way to force this through maven
>
> On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
> <***@geekologue.com>wrote:
>
> > On 07/30/2010 07:16 PM, Wayne Fay wrote:
> >
> >> is there a way to force a project to refresh certain dependencies every
> >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
> >>>
> >>
> >> Absolutely not. Released artifacts MUST NOT CHANGE.
> >>
> >
> > +1, never ever ;-)
> >
> > Released artifact versioning is supposed to guarantee consistency.
> >
> > Manos
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-***@maven.apache.org
> > For additional commands, e-mail: users-***@maven.apache.org
> >
> >
>

[D D]

Wouldn't you be better off implementing such mechanism in an SCM package?
Audit can be done with scripts either sitting on top of SCM or Unix/Linux
machine.

Added logging layer from hosting it on Linux/Unix would benefit you far more
and provide better flexibility.

Hope it helps,
Dave

On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed <***@gmail.com> wrote:

> ok, thanks
> basically for liability reasons for a certain project, we have to provide
> specific times of when a project was built and when/where all its
> dependencies were retrieved at/from
> we have to ensure a sanitary build for all these JARs and a complete log of
> going from 0 to 100 for the build; so we are faced with either clearing out
> the .m2 each time
> I was wondering if there was a way to force this through maven
>
> On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
> <***@geekologue.com>wrote:
>
> > On 07/30/2010 07:16 PM, Wayne Fay wrote:
> >
> >> is there a way to force a project to refresh certain dependencies every
> >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
> >>>
> >>
> >> Absolutely not. Released artifacts MUST NOT CHANGE.
> >>
> >
> > +1, never ever ;-)
> >
> > Released artifact versioning is supposed to guarantee consistency.
> >
> > Manos
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-***@maven.apache.org
> > For additional commands, e-mail: users-***@maven.apache.org
> >
> >
>

[Jason van Zyl]

On Jul 30, 2010, at 2:21 PM, Shan Syed wrote:

> ok, thanks
> basically for liability reasons for a certain project, we have to provide
> specific times of when a project was built and when/where all its
> dependencies were retrieved at/from
> we have to ensure a sanitary build for all these JARs and a complete log of
> going from 0 to 100 for the build; so we are faced with either clearing out
> the .m2 each time
> I was wondering if there was a way to force this through maven
>

Put the artifacts in a repository manager where you download the released artifact once and then manage it from your infrastructure. Once the artifact is within your infrastructure the released artifact is not going to change unless someone from within your organization changes it. They shouldn't, and can't if your permissions are setup correctly, and so the requirement of using the same artifacts and their origin becomes moot. If your organization cares that much about liability concerns then you absolutely should not be connecting to the outside world every time you build.

> On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
> <***@geekologue.com>wrote:
>
>> On 07/30/2010 07:16 PM, Wayne Fay wrote:
>>
>>> is there a way to force a project to refresh certain dependencies every
>>>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>>>
>>>
>>> Absolutely not. Released artifacts MUST NOT CHANGE.
>>>
>>
>> +1, never ever ;-)
>>
>> Released artifact versioning is supposed to guarantee consistency.
>>
>> Manos
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-***@maven.apache.org
>> For additional commands, e-mail: users-***@maven.apache.org
>>
>>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

-- Buddha

[Shan Syed]

not my organization - our client wants a log of everything that came down
the pipe to create this build, that's all
it's not a matter of "worry" or "concern", so no need to be overly dramatic
some companies just want a complete audit trail of what they paid for, which
is fine by me
I'm looking for technical solutions because I'm in a technical role, not
policy advice; sometimes in this business you delivery what you're paid to
deliver regardless of whether it makes sense to you
we cannot respond to our clients saying "the guys on the maven list told us
that your request is stupid"

deleting the m2 works, I was just curious to see if there was a switch in
maven to force all downloads again

On Fri, Jul 30, 2010 at 2:47 PM, Jason van Zyl <***@sonatype.com> wrote:

>
> On Jul 30, 2010, at 2:21 PM, Shan Syed wrote:
>
> > ok, thanks
> > basically for liability reasons for a certain project, we have to provide
> > specific times of when a project was built and when/where all its
> > dependencies were retrieved at/from
> > we have to ensure a sanitary build for all these JARs and a complete log
> of
> > going from 0 to 100 for the build; so we are faced with either clearing
> out
> > the .m2 each time
> > I was wondering if there was a way to force this through maven
> >
>
> Put the artifacts in a repository manager where you download the released
> artifact once and then manage it from your infrastructure. Once the artifact
> is within your infrastructure the released artifact is not going to change
> unless someone from within your organization changes it. They shouldn't, and
> can't if your permissions are setup correctly, and so the requirement of
> using the same artifacts and their origin becomes moot. If your organization
> cares that much about liability concerns then you absolutely should not be
> connecting to the outside world every time you build.
>
> > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
> > <***@geekologue.com>wrote:
> >
> >> On 07/30/2010 07:16 PM, Wayne Fay wrote:
> >>
> >>> is there a way to force a project to refresh certain dependencies every
> >>>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
> >>>>
> >>>
> >>> Absolutely not. Released artifacts MUST NOT CHANGE.
> >>>
> >>
> >> +1, never ever ;-)
> >>
> >> Released artifact versioning is supposed to guarantee consistency.
> >>
> >> Manos
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-***@maven.apache.org
> >> For additional commands, e-mail: users-***@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
>
>

[Jason van Zyl]

On Jul 30, 2010, at 3:45 PM, Shan Syed wrote:

> not my organization - our client wants a log of everything that came down
> the pipe to create this build, that's all
> it's not a matter of "worry" or "concern", so no need to be overly dramatic
> some companies just want a complete audit trail of what they paid for, which
> is fine by me
> I'm looking for technical solutions because I'm in a technical role, not
> policy advice; sometimes in this business you delivery what you're paid to
> deliver regardless of whether it makes sense to you
> we cannot respond to our clients saying "the guys on the maven list told us
> that your request is stupid"

Sounds like you're being paid to deliver an accurate bill of materials (BOM) which is perfectly reasonable. Not download things over and over again which frankly isn't very sensible. In that the BOM, containing released artifacts, will not be different whether you download 1 or 100 times. You'll have "what came down the pipe." And that you might want to explain this to your client that the BOM is not any more accurate if they are, in fact, asking you to explicitly download the released artifacts on each build.

>
> deleting the m2 works, I was just curious to see if there was a switch in
> maven to force all downloads again

This makes absolutely no sense, doesn't change your BOM, and is just wasteful. Consumes bandwidth unnecessarily from a resource that is being used by the whole Maven community.

>
> On Fri, Jul 30, 2010 at 2:47 PM, Jason van Zyl <***@sonatype.com> wrote:
>
>>
>> On Jul 30, 2010, at 2:21 PM, Shan Syed wrote:
>>
>>> ok, thanks
>>> basically for liability reasons for a certain project, we have to provide
>>> specific times of when a project was built and when/where all its
>>> dependencies were retrieved at/from
>>> we have to ensure a sanitary build for all these JARs and a complete log
>> of
>>> going from 0 to 100 for the build; so we are faced with either clearing
>> out
>>> the .m2 each time
>>> I was wondering if there was a way to force this through maven
>>>
>>
>> Put the artifacts in a repository manager where you download the released
>> artifact once and then manage it from your infrastructure. Once the artifact
>> is within your infrastructure the released artifact is not going to change
>> unless someone from within your organization changes it. They shouldn't, and
>> can't if your permissions are setup correctly, and so the requirement of
>> using the same artifacts and their origin becomes moot. If your organization
>> cares that much about liability concerns then you absolutely should not be
>> connecting to the outside world every time you build.
>>
>>> On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
>>> <***@geekologue.com>wrote:
>>>
>>>> On 07/30/2010 07:16 PM, Wayne Fay wrote:
>>>>
>>>>> is there a way to force a project to refresh certain dependencies every
>>>>>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>>>>>
>>>>>
>>>>> Absolutely not. Released artifacts MUST NOT CHANGE.
>>>>>
>>>>
>>>> +1, never ever ;-)
>>>>
>>>> Released artifact versioning is supposed to guarantee consistency.
>>>>
>>>> Manos
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-***@maven.apache.org
>>>> For additional commands, e-mail: users-***@maven.apache.org
>>>>
>>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>>
>>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.

-- Paul Graham

[Wayne Fay]

>> deleting the m2 works, I was just curious to see if there was a switch in
>> maven to force all downloads again
>
> This makes absolutely no sense, doesn't change your BOM, and is just
> wasteful. Consumes bandwidth unnecessarily from a resource that is being
> used by the whole Maven community.

I'd think that if you had enough developers doing this on every
machine on a consistent basis (eg every build), it might add up to
enough traffic to get you on a blacklist somewhere... You really need
to install Nexus or another MRM, this is just plain dumb.

Wayne

[Shan Syed]

it only applies to our final release cuts, not our day-to-day
just once for this project really; I wanted to insert such this switch (if
existed) in our "delivery build" profile
we use archiva for everything else, and actually only make use of public
maven repositories when we up a version of our dependencies, which is rare
because of change control

it's all weird stuff, I know, but sometimes I just don't question it

On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay <***@gmail.com> wrote:

> >> deleting the m2 works, I was just curious to see if there was a switch
> in
> >> maven to force all downloads again
> >
> > This makes absolutely no sense, doesn't change your BOM, and is just
> > wasteful. Consumes bandwidth unnecessarily from a resource that is being
> > used by the whole Maven community.
>
> I'd think that if you had enough developers doing this on every
> machine on a consistent basis (eg every build), it might add up to
> enough traffic to get you on a blacklist somewhere... You really need
> to install Nexus or another MRM, this is just plain dumb.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Paul Benedict]

There is a maxim to follow when deploying: "do not redeploy a version more
than once". Once you deploy version X.Y.Z, it should never be updated, and
those who download it never need to download it again. So, back to the
original problem, are you guys doing that?

On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed <***@gmail.com> wrote:

> it only applies to our final release cuts, not our day-to-day
> just once for this project really; I wanted to insert such this switch (if
> existed) in our "delivery build" profile
> we use archiva for everything else, and actually only make use of public
> maven repositories when we up a version of our dependencies, which is rare
> because of change control
>
> it's all weird stuff, I know, but sometimes I just don't question it
>
> On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay <***@gmail.com> wrote:
>
> > >> deleting the m2 works, I was just curious to see if there was a switch
> > in
> > >> maven to force all downloads again
> > >
> > > This makes absolutely no sense, doesn't change your BOM, and is just
> > > wasteful. Consumes bandwidth unnecessarily from a resource that is
> being
> > > used by the whole Maven community.
> >
> > I'd think that if you had enough developers doing this on every
> > machine on a consistent basis (eg every build), it might add up to
> > enough traffic to get you on a blacklist somewhere... You really need
> > to install Nexus or another MRM, this is just plain dumb.
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-***@maven.apache.org
> > For additional commands, e-mail: users-***@maven.apache.org
> >
> >
>

[Shan Syed]

no, this isn't in regard to our own published artifacts

I regret starting this thread, I apologize
I didn't mean this question to be an affront to maven conventions - I just
need to figure out a better way to capture a full log
they even want a log of how the build environment was downloaded and
installed


On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict <***@apache.org> wrote:

> There is a maxim to follow when deploying: "do not redeploy a version more
> than once". Once you deploy version X.Y.Z, it should never be updated, and
> those who download it never need to download it again. So, back to the
> original problem, are you guys doing that?
>
> On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed <***@gmail.com> wrote:
>
> > it only applies to our final release cuts, not our day-to-day
> > just once for this project really; I wanted to insert such this switch
> (if
> > existed) in our "delivery build" profile
> > we use archiva for everything else, and actually only make use of public
> > maven repositories when we up a version of our dependencies, which is
> rare
> > because of change control
> >
> > it's all weird stuff, I know, but sometimes I just don't question it
> >
> > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay <***@gmail.com> wrote:
> >
> > > >> deleting the m2 works, I was just curious to see if there was a
> switch
> > > in
> > > >> maven to force all downloads again
> > > >
> > > > This makes absolutely no sense, doesn't change your BOM, and is just
> > > > wasteful. Consumes bandwidth unnecessarily from a resource that is
> > being
> > > > used by the whole Maven community.
> > >
> > > I'd think that if you had enough developers doing this on every
> > > machine on a consistent basis (eg every build), it might add up to
> > > enough traffic to get you on a blacklist somewhere... You really need
> > > to install Nexus or another MRM, this is just plain dumb.
> > >
> > > Wayne
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-***@maven.apache.org
> > > For additional commands, e-mail: users-***@maven.apache.org
> > >
> > >
> >
>

[Paul Benedict]

You can use -X for a debug log. Or you can funnel system out to a file. I
believe tools like Continuum or Hudson do such things.

Paul

On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed <***@gmail.com> wrote:

> no, this isn't in regard to our own published artifacts
>
> I regret starting this thread, I apologize
> I didn't mean this question to be an affront to maven conventions - I just
> need to figure out a better way to capture a full log
> they even want a log of how the build environment was downloaded and
> installed
>
>
> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict <***@apache.org>
> wrote:
>
> > There is a maxim to follow when deploying: "do not redeploy a version
> more
> > than once". Once you deploy version X.Y.Z, it should never be updated,
> and
> > those who download it never need to download it again. So, back to the
> > original problem, are you guys doing that?
> >
> > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed <***@gmail.com> wrote:
> >
> > > it only applies to our final release cuts, not our day-to-day
> > > just once for this project really; I wanted to insert such this switch
> > (if
> > > existed) in our "delivery build" profile
> > > we use archiva for everything else, and actually only make use of
> public
> > > maven repositories when we up a version of our dependencies, which is
> > rare
> > > because of change control
> > >
> > > it's all weird stuff, I know, but sometimes I just don't question it
> > >
> > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay <***@gmail.com> wrote:
> > >
> > > > >> deleting the m2 works, I was just curious to see if there was a
> > switch
> > > > in
> > > > >> maven to force all downloads again
> > > > >
> > > > > This makes absolutely no sense, doesn't change your BOM, and is
> just
> > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is
> > > being
> > > > > used by the whole Maven community.
> > > >
> > > > I'd think that if you had enough developers doing this on every
> > > > machine on a consistent basis (eg every build), it might add up to
> > > > enough traffic to get you on a blacklist somewhere... You really need
> > > > to install Nexus or another MRM, this is just plain dumb.
> > > >
> > > > Wayne
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-***@maven.apache.org
> > > > For additional commands, e-mail: users-***@maven.apache.org
> > > >
> > > >
> > >
> >
>

[Ron Wheeler]

On 30/07/2010 5:09 PM, Paul Benedict wrote:
> You can use -X for a debug log. Or you can funnel system out to a file. I
> believe tools like Continuum or Hudson do such things.
>
> Paul
>
> On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed<***@gmail.com> wrote:
>
>> no, this isn't in regard to our own published artifacts
>>
>> I regret starting this thread, I apologize
Don 't be sorry. You are getting really good advice from some very
knowledgeable people who just want to help you.
You are not doing things in a way that make it easy for you to satisfy
your client and your life is much harder than it needs to be.

No need to apologize. That is what the forum is for.
Take a close look at what is being proposed and ask the questions that
you need to have answered.

Everyone has clients to satisfy and sometimes they don't ask for what
they really need in the most direct way but you can give them what they
need to do their job in a better way than your current approach and you
will have a lot less work to do as well.


Ron

>> I didn't mean this question to be an affront to maven conventions - I just
>> need to figure out a better way to capture a full log
>> they even want a log of how the build environment was downloaded and
>> installed
>>
>>
>> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict<***@apache.org>
>> wrote:
>>
>>> There is a maxim to follow when deploying: "do not redeploy a version
>> more
>>> than once". Once you deploy version X.Y.Z, it should never be updated,
>> and
>>> those who download it never need to download it again. So, back to the
>>> original problem, are you guys doing that?
>>>
>>> On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed<***@gmail.com> wrote:
>>>
>>>> it only applies to our final release cuts, not our day-to-day
>>>> just once for this project really; I wanted to insert such this switch
>>> (if
>>>> existed) in our "delivery build" profile
>>>> we use archiva for everything else, and actually only make use of
>> public
>>>> maven repositories when we up a version of our dependencies, which is
>>> rare
>>>> because of change control
>>>>
>>>> it's all weird stuff, I know, but sometimes I just don't question it
>>>>
>>>> On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay<***@gmail.com> wrote:
>>>>
>>>>>>> deleting the m2 works, I was just curious to see if there was a
>>> switch
>>>>> in
>>>>>>> maven to force all downloads again
>>>>>> This makes absolutely no sense, doesn't change your BOM, and is
>> just
>>>>>> wasteful. Consumes bandwidth unnecessarily from a resource that is
>>>> being
>>>>>> used by the whole Maven community.
>>>>> I'd think that if you had enough developers doing this on every
>>>>> machine on a consistent basis (eg every build), it might add up to
>>>>> enough traffic to get you on a blacklist somewhere... You really need
>>>>> to install Nexus or another MRM, this is just plain dumb.
>>>>>
>>>>> Wayne
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-***@maven.apache.org
>>>>> For additional commands, e-mail: users-***@maven.apache.org
>>>>>
>>>>>

[Yoav Landman]

You may want to take a look at the CI integration in Artifactory -
http://wiki.jfrog.org/confluence/display/RTF/Build+Integration
You can get a json object with a report of all this information captured at
build time: detailed build environment information, published artifacts and
resolved dependencies of all scopes.
Like many have commented here, re-downloading cached release artifacts if
you run your build from scratch should be done from the caches of your repo
manager.

Yoav

On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed <***@gmail.com> wrote:

> no, this isn't in regard to our own published artifacts
>
> I regret starting this thread, I apologize
> I didn't mean this question to be an affront to maven conventions - I just
> need to figure out a better way to capture a full log
> they even want a log of how the build environment was downloaded and
> installed
>
>
> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict <***@apache.org>
> wrote:
>
> > There is a maxim to follow when deploying: "do not redeploy a version
> more
> > than once". Once you deploy version X.Y.Z, it should never be updated,
> and
> > those who download it never need to download it again. So, back to the
> > original problem, are you guys doing that?
> >
> > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed <***@gmail.com> wrote:
> >
> > > it only applies to our final release cuts, not our day-to-day
> > > just once for this project really; I wanted to insert such this switch
> > (if
> > > existed) in our "delivery build" profile
> > > we use archiva for everything else, and actually only make use of
> public
> > > maven repositories when we up a version of our dependencies, which is
> > rare
> > > because of change control
> > >
> > > it's all weird stuff, I know, but sometimes I just don't question it
> > >
> > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay <***@gmail.com> wrote:
> > >
> > > > >> deleting the m2 works, I was just curious to see if there was a
> > switch
> > > > in
> > > > >> maven to force all downloads again
> > > > >
> > > > > This makes absolutely no sense, doesn't change your BOM, and is
> just
> > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is
> > > being
> > > > > used by the whole Maven community.
> > > >
> > > > I'd think that if you had enough developers doing this on every
> > > > machine on a consistent basis (eg every build), it might add up to
> > > > enough traffic to get you on a blacklist somewhere... You really need
> > > > to install Nexus or another MRM, this is just plain dumb.
> > > >
> > > > Wayne
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-***@maven.apache.org
> > > > For additional commands, e-mail: users-***@maven.apache.org
> > > >
> > > >
> > >
> >
>

[Kathryn Huxtable]

I second this! I've used Artifactory and liked it. (I somewhat prefer Nexus, at least the last time I looked at Artifactory.)

-K

On Aug 6, 2010, at 1:47 PM, Yoav Landman wrote:

> You may want to take a look at the CI integration in Artifactory -
> http://wiki.jfrog.org/confluence/display/RTF/Build+Integration
> You can get a json object with a report of all this information captured at
> build time: detailed build environment information, published artifacts and
> resolved dependencies of all scopes.
> Like many have commented here, re-downloading cached release artifacts if
> you run your build from scratch should be done from the caches of your repo
> manager.
>
> Yoav
>
> On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed <***@gmail.com> wrote:
>
>> no, this isn't in regard to our own published artifacts
>>
>> I regret starting this thread, I apologize
>> I didn't mean this question to be an affront to maven conventions - I just
>> need to figure out a better way to capture a full log
>> they even want a log of how the build environment was downloaded and
>> installed
>>
>>
>> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict <***@apache.org>
>> wrote:
>>
>>> There is a maxim to follow when deploying: "do not redeploy a version
>> more
>>> than once". Once you deploy version X.Y.Z, it should never be updated,
>> and
>>> those who download it never need to download it again. So, back to the
>>> original problem, are you guys doing that?
>>>
>>> On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed <***@gmail.com> wrote:
>>>
>>>> it only applies to our final release cuts, not our day-to-day
>>>> just once for this project really; I wanted to insert such this switch
>>> (if
>>>> existed) in our "delivery build" profile
>>>> we use archiva for everything else, and actually only make use of
>> public
>>>> maven repositories when we up a version of our dependencies, which is
>>> rare
>>>> because of change control
>>>>
>>>> it's all weird stuff, I know, but sometimes I just don't question it
>>>>
>>>> On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay <***@gmail.com> wrote:
>>>>
>>>>>>> deleting the m2 works, I was just curious to see if there was a
>>> switch
>>>>> in
>>>>>>> maven to force all downloads again
>>>>>>
>>>>>> This makes absolutely no sense, doesn't change your BOM, and is
>> just
>>>>>> wasteful. Consumes bandwidth unnecessarily from a resource that is
>>>> being
>>>>>> used by the whole Maven community.
>>>>>
>>>>> I'd think that if you had enough developers doing this on every
>>>>> machine on a consistent basis (eg every build), it might add up to
>>>>> enough traffic to get you on a blacklist somewhere... You really need
>>>>> to install Nexus or another MRM, this is just plain dumb.
>>>>>
>>>>> Wayne
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-***@maven.apache.org
>>>>> For additional commands, e-mail: users-***@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>

[Nicola Musatti]

Shan Syed wrote:
> no, this isn't in regard to our own published artifacts
>
> I regret starting this thread, I apologize
> I didn't mean this question to be an affront to maven conventions - I just
> need to figure out a better way to capture a full log
> they even want a log of how the build environment was downloaded and
> installed
>
>
In my opinion you have nothing to apologize for. Your problem is just an
example of how Maven's artifact-centric view is at least partly in
contrast with the source centric view of "orthodox" configuration
management.

While in general I do appreciate Maven's strongly opinionated approach,
as it helps ensure that little time is wasted making the same decisions
over and over again, I believe that better support for a source centric
approach would be a good thing. A first step in this direction could be
to provide an explicit, official representation for artifact variants
obtained by building different tags/branches of a same project.

Cheers,
Nicola Musatti

[Gorham-Engard, Frank]

You could try changing the repository location property on the command line to a fresh empty directory. That will force the download and logging of all SNAPSHOT and release dependencies.
>mvn ... -Dmaven.repo.local=<new-temp-directory>

<!-- Frank Gorham-Engard →
"Be kinder than necessary.
  Everyone is fighting some kind of battle."

-----Original Message-----
From: Shan Syed [mailto:***@gmail.com]
Sent: Friday, July 30, 2010 2:21 PM
To: Maven Users List
Subject: Re: force maven to redownload/refresh "released" dependencies

ok, thanks
basically for liability reasons for a certain project, we have to provide
specific times of when a project was built and when/where all its
dependencies were retrieved at/from
we have to ensure a sanitary build for all these JARs and a complete log of
going from 0 to 100 for the build; so we are faced with either clearing out
the .m2 each time
I was wondering if there was a way to force this through maven

On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis
<***@geekologue.com>wrote:

> On 07/30/2010 07:16 PM, Wayne Fay wrote:
>
>> is there a way to force a project to refresh certain dependencies every
>>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>>
>>
>> Absolutely not. Released artifacts MUST NOT CHANGE.
>>
>
> +1, never ever ;-)
>
> Released artifact versioning is supposed to guarantee consistency.
>
> Manos
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org

[Ron Wheeler]

On 30/07/2010 12:57 PM, Manos Batsis wrote:
> On 07/30/2010 07:16 PM, Wayne Fay wrote:
>>> is there a way to force a project to refresh certain dependencies every
>>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>
>> Absolutely not. Released artifacts MUST NOT CHANGE.
>
> +1, never ever ;-)
>
> Released artifact versioning is supposed to guarantee consistency.
>
> Manos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>
+1

I have been the victim of an Apache project that rereleased its
artifacts. This led to great difficulty in controlling builds to ensure
that the correct version of the release was used.

[Nicola Musatti]

Shan Syed wrote:
> ok, thanks
> basically for liability reasons for a certain project, we have to provide
> specific times of when a project was built and when/where all its
> dependencies were retrieved at/from
> we have to ensure a sanitary build for all these JARs and a complete log of
> going from 0 to 100 for the build; so we are faced with either clearing out
> the .m2 each time
> I was wondering if there was a way to force this through maven
>
I'd say there are two sides to your problem: one is how to control when
third-party artifacts are downloaded from remote repositories and the
other is to control when and from which sources your own artifacts are
built.

One way to tackle the first problem is to use a repository manager like
nexus, but not its proxying capabilities. Instead third party artifacts
could be added to a specific repository by hand.

For the second problem you could use a specifically tailored aggregate
project that included all of the jars you need to build, so that none
would be retrieved from repositories. If you are using Subversion for
version control you could use svn:externals to automatically check out
of your projects.

Cheers,
Nicola Musatti

[Ron Wheeler]

On 02/08/2010 11:00 AM, Nicola Musatti wrote:
> Shan Syed wrote:
>> ok, thanks
>> basically for liability reasons for a certain project, we have to
>> provide
>> specific times of when a project was built and when/where all its
>> dependencies were retrieved at/from
>> we have to ensure a sanitary build for all these JARs and a complete
>> log of
>> going from 0 to 100 for the build; so we are faced with either
>> clearing out
>> the .m2 each time
>> I was wondering if there was a way to force this through maven
> I'd say there are two sides to your problem: one is how to control
> when third-party artifacts are downloaded from remote repositories and
> the other is to control when and from which sources your own artifacts
> are built.
>
> One way to tackle the first problem is to use a repository manager
> like nexus, but not its proxying capabilities. Instead third party
> artifacts could be added to a specific repository by hand.
>
Using a repository is always a good idea. In practical terms, I am not
sure if the source of the download is all that important in most cases
since the come from Maven Central most of the time and you can not
easily tell the client who actually put the jar file in Maven Central or
even what company the person worked for.
This may be a case where the client started out with a good idea
(control who is building components that the "prime" contractor is using
but as Maven gets more popular, Maven Central becomes an easy place to
get things even if it is not the home of the author.
The idea of setting up Nexus (or some other proxy) and only using the
manual upload to feed it, will go a long way to giving the client a
comfortable feeling that you do know where and when you got your components.

You would not have to worry about individual .m2 contents since the
downloads would all be distributed centrally from your repo.
This would speed up the builds tremendously.

> For the second problem you could use a specifically tailored aggregate
> project that included all of the jars you need to build, so that none
> would be retrieved from repositories. If you are using Subversion for
> version control you could use svn:externals to automatically check out
> of your projects.
>
We do this with our third party libraries and it ensures that developers
build with the "right" version which is more important than the client
knowing, in our case.
We do have a set of versioned POM files that can be provided to anyone
who wants to know what libraries (and their versions) were used to
build any particular version of our application.
We do not change the version of third-party software in the POMs within
a version of our software so builds within a release are all built with
the same set of dependencies.
If we did need to change the version of a third-party package, that
would trigger a new minor version of out application.

We do not track the actual download from Maven Central or our manual
uploads for artifacts not in Maven Central. That is only done once per
artifact version.
I am not sure if Nexus could report this activity if we did want to
track it. There might be logs available.
Once you stop individuals from accessing the dependencies directly
without controls, it gets much easier to track dependencies to the level
that your client wants.


It also makes the POM of our artifacts very small since they only depend
on a few aggregate projects.

> Cheers,
> Nicola Musatti
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Jason van Zyl]

Maven won't do that, and we would never make that possible. If you require this you have something seriously wrong with your project infrastructure. Seriously bad project infrastructure smell.

On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:

> is there a way to force a project to refresh certain dependencies every
> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>
> S

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

[Paul Benedict]

Shan,

Maven has a policy how often it checks for updated snapshots. Is that what
you are looking for?

Paul

On Fri, Jul 30, 2010 at 11:39 AM, Jason van Zyl <***@sonatype.com> wrote:

> Maven won't do that, and we would never make that possible. If you require
> this you have something seriously wrong with your project infrastructure.
> Seriously bad project infrastructure smell.
>
> On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:
>
> > is there a way to force a project to refresh certain dependencies every
> > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
> >
> > S
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>

[Justin Edelson]

I was actually under the impression you could do this like this:

<repository>
<releases>
<updatePolicy>always</updatePolicy>
</releases>
</repository>

Although I've never tried this because it's a terrible idea.

If this doesn't work, someone should probably remove the corresponding
section from http://maven.apache.org/settings.html#Repositories and
http://maven.apache.org/settings.html#Repositories (yes, those pages
show the repository being disabled, but it is still configured with an
updatePolicy).

Justin

On 7/30/10 12:39 PM, Jason van Zyl wrote:
> Maven won't do that, and we would never make that possible. If you require this you have something seriously wrong with your project infrastructure. Seriously bad project infrastructure smell.
>
> On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:
>
>> is there a way to force a project to refresh certain dependencies every
>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>
>> S
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>

[Arnaud Héritier]

I see only one case where it could be useful, it is when we use staging repositories and have to update our released binaries.
It is a shame to have to manually remove binaries previously downloaded (and it is error prone).
I agree that never updating released binaries is a maven fundamental and we'll never change that.
But we'll have to improve tooling around staging to easily allow to cleanup the local repository (or a part of it) for QA teams and others involved in staging process.
Cheers,

Arnaud


On Jul 30, 2010, at 6:39 PM, Jason van Zyl wrote:

> Maven won't do that, and we would never make that possible. If you require this you have something seriously wrong with your project infrastructure. Seriously bad project infrastructure smell.
>
> On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:
>
>> is there a way to force a project to refresh certain dependencies every
>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
>>
>> S
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>

[a.geo]

mvn package -U

maybe?

the -U parameter tell to maven to refresh all dependencies required by the
artifact

2010/8/2 Arnaud Héritier <***@gmail.com>

> I see only one case where it could be useful, it is when we use staging
> repositories and have to update our released binaries.
> It is a shame to have to manually remove binaries previously downloaded
> (and it is error prone).
> I agree that never updating released binaries is a maven fundamental and
> we'll never change that.
> But we'll have to improve tooling around staging to easily allow to cleanup
> the local repository (or a part of it) for QA teams and others involved in
> staging process.
> Cheers,
>
> Arnaud
>
>
> On Jul 30, 2010, at 6:39 PM, Jason van Zyl wrote:
>
> > Maven won't do that, and we would never make that possible. If you
> require this you have something seriously wrong with your project
> infrastructure. Seriously bad project infrastructure smell.
> >
> > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:
> >
> >> is there a way to force a project to refresh certain dependencies every
> >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts
> >>
> >> S
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>


--
Cesar De la Cruz Rojas
*
-----------------------------------------------------------------------------
*
Sennior Software Engineer
-----------------------------------------------------------------------------
Follow me in Facebook : http://www.facebook.com/aquiles.geo
Twitter http://twitter.com/ageo
Picture blog http://ageo.deviantart.com

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: a.geo [mailto:***@gmail.com]
>Sent: Monday, August 02, 2010 9:54 AM
>To: Maven Users List
>Subject: Re: force maven to redownload/refresh "released" dependencies
>
>mvn package -U
>
>maybe?
>
>the -U parameter tell to maven to refresh all dependencies required by
the
>artifact

I tried that, but it only works for snapshots. (as is implied by the
long version of that: --update-snapshots).

There really should be a way to get maven to force a check on all
dependencies.

For everyone that says "Released artifacts MUST NOT CHANGE", that great
if you live in an ideal world, but guess what: some of us actually have
to live in the *real* world where things don't always follow the
guidelines. It would be nice if maven didn't make it so hard to deal
with those situations.

eric

[Manfred Moser]

> For everyone that says "Released artifacts MUST NOT CHANGE", that great
> if you live in an ideal world, but guess what: some of us actually have
> to live in the *real* world where things don't always follow the
> guidelines. It would be nice if maven didn't make it so hard to deal
> with those situations.

Sorry.. but in this case I think the cost of accommodating for behaviours
against the known best practice would far outweigh the benefits. I would
not want to see such a feature available even for the pure cost people
then using it. Just adapt your practice.

manfred

[Ron Wheeler]

On 04/08/2010 6:34 PM, Manfred Moser wrote:
>> For everyone that says "Released artifacts MUST NOT CHANGE", that great
>> if you live in an ideal world, but guess what: some of us actually have
>> to live in the *real* world where things don't always follow the
>> guidelines. It would be nice if maven didn't make it so hard to deal
>> with those situations.
> Sorry.. but in this case I think the cost of accommodating for behaviours
> against the known best practice would far outweigh the benefits. I would
> not want to see such a feature available even for the pure cost people
> then using it. Just adapt your practice.
>
+1.
We are still suffering from a project that allowed released artifacts to
change without creating a new release.
Bad practices need to stopped not supported.

Ron

1.


> manfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Ron Wheeler [mailto:***@artifact-software.com]
>
> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
great
>>> if you live in an ideal world, but guess what: some of us actually
have
>>> to live in the *real* world where things don't always follow the
>>> guidelines. It would be nice if maven didn't make it so hard to
deal
>>> with those situations.
>> Sorry.. but in this case I think the cost of accommodating for
behaviours
>> against the known best practice would far outweigh the benefits. I
would
>> not want to see such a feature available even for the pure cost
people
>> then using it. Just adapt your practice.
>>
>+1.
>We are still suffering from a project that allowed released artifacts
to
>change without creating a new release.
>Bad practices need to stopped not supported.
>
>Ron

I'm sure I'm not the only person that is very disappointed at the lack
of desire to help people get things working. It's one thing to
encourage people to do things the right way, but I think it's stupid to
actively put obstacles in the path of people trying to deal with
environments that aren't perfect.
Do you really think it's better to not have any way to recover from the
case when a project changes release artifacts? As you say, you're still
suffering from it. Perhaps that's exactly because maven doesn't provide
you the tools to effectively deal with it!
IMO, maven should, at the very least, be able to indicate an error when
things are inconsistent, even for release artifacts. The current
behaviour, where you have absolutely NO CLUE what's going on if an
artifact changes, leads to huge amounts of confusion.

eric

[Ron Wheeler]

On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>
>> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
> great
>>>> if you live in an ideal world, but guess what: some of us actually
> have
>>>> to live in the *real* world where things don't always follow the
>>>> guidelines. It would be nice if maven didn't make it so hard to
> deal
>>>> with those situations.
>>> Sorry.. but in this case I think the cost of accommodating for
> behaviours
>>> against the known best practice would far outweigh the benefits. I
> would
>>> not want to see such a feature available even for the pure cost
> people
>>> then using it. Just adapt your practice.
>>>
>> +1.
>> We are still suffering from a project that allowed released artifacts
> to
>> change without creating a new release.
>> Bad practices need to stopped not supported.
>>
>> Ron
> I'm sure I'm not the only person that is very disappointed at the lack
> of desire to help people get things working. It's one thing to
> encourage people to do things the right way, but I think it's stupid to
> actively put obstacles in the path of people trying to deal with
> environments that aren't perfect.
If you see a blind man walking into traffic do you help him step off the
curb?
You can stop people from changing released artifacts.
Get them to use SNAPSHOTs until they really have tested the release and
got the OK to issue a release.
If people are not testing their SNAPSHOTs before releasing them, you
need to stop this.
> Do you really think it's better to not have any way to recover from the
> case when a project changes release artifacts?
The repository manager can delete a release which does allow you to
rerelease the save version.
When this is done, each programmer has to manually remove the bad
version from their local cache to ensure that Maven gets the rereleased
artifact.
This should only be done once in a blue moon not as part of regular
operation.
> As you say, you're still
> suffering from it. Perhaps that's exactly because maven doesn't provide
> you the tools to effectively deal with it!
I am suffering because it is hard to tell which release 2.1.3 is the
"good" version with the patches.
> IMO, maven should, at the very least, be able to indicate an error when
> things are inconsistent, even for release artifacts. The current
> behaviour, where you have absolutely NO CLUE what's going on if an
> artifact changes, leads to huge amounts of confusion.
That is not a Maven problem it is a people problem.
That is why you don't let artifacts change.
>
>
> eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Ron Wheeler [mailto:***@artifact-software.com]
>
> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>> -----Original Message-----
>>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>>
>>> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
>> great
>>>>> if you live in an ideal world, but guess what: some of us actually
>> have
>>>>> to live in the *real* world where things don't always follow the
>>>>> guidelines. It would be nice if maven didn't make it so hard to
>> deal
>>>>> with those situations.
>>>> Sorry.. but in this case I think the cost of accommodating for
>> behaviours
>>>> against the known best practice would far outweigh the benefits. I
>> would
>>>> not want to see such a feature available even for the pure cost
>> people
>>>> then using it. Just adapt your practice.
>>>>
>>> +1.
>>> We are still suffering from a project that allowed released
artifacts
>> to
>>> change without creating a new release.
>>> Bad practices need to stopped not supported.
>>>
>>> Ron
>> I'm sure I'm not the only person that is very disappointed at the
lack
>> of desire to help people get things working. It's one thing to
>> encourage people to do things the right way, but I think it's stupid
to
>> actively put obstacles in the path of people trying to deal with
>> environments that aren't perfect.
>If you see a blind man walking into traffic do you help him step off
the
>curb?

Yes, actually I would. At the same time I would mention that it might
be better for him to use the crosswalk. I certainly wouldn't take away
his cane so he can't even tell the curb is there until he trips over it.

>You can stop people from changing released artifacts.
>Get them to use SNAPSHOTs until they really have tested the release
and
>got the OK to issue a release.
>If people are not testing their SNAPSHOTs before releasing them, you
>need to stop this.

No, actually you can't. It is absolutely impossible to ensure that a
release artifact will never change.
You certainly can (and should) do a lot to discourage that from
happening, and you can do a lot to make it difficult to cause it to
happen, but once it does happen you shouldn't continue to make things
difficult for people to notice that something is wrong and to fix it.

>> Do you really think it's better to not have any way to recover from
the
>> case when a project changes release artifacts?
>The repository manager can delete a release which does allow you to
>rerelease the save version.
>When this is done, each programmer has to manually remove the bad
>version from their local cache to ensure that Maven gets the rereleased
>artifact.
>This should only be done once in a blue moon not as part of regular
>operation.

And if this happens, maven should tell you about it! I think it would
be nice it there was an easy way to tell maven to remove the bad version
from the local cache, but the bare minimum it should do is spit out an
error like:
[ERROR] release artifact com.example:foo in the local cache does not
match repository version (http://central/com/example/foo)
[ERROR] to use the repository version, remove the files at
~/.m2/repository/com/example/foo

>> As you say, you're still
>> suffering from it. Perhaps that's exactly because maven doesn't
provide
>> you the tools to effectively deal with it!
>I am suffering because it is hard to tell which release 2.1.3 is the
>"good" version with the patches.

So why wouldn't you want to know that there are two different copies of
that release? I don't understand why there is such resistance to
providing the tools to effectively deal with problematic situations.

>> IMO, maven should, at the very least, be able to indicate an error
when
>> things are inconsistent, even for release artifacts. The current
>> behaviour, where you have absolutely NO CLUE what's going on if an
>> artifact changes, leads to huge amounts of confusion.
>That is not a Maven problem it is a people problem.
>That is why you don't let artifacts change.

I don't know what world you live in, but in mine I don't have absolute
control over everything.

eric

[Manfred Moser]

Eric,

It seems like we will not agree here. The changes necessary and the
additional overhead to make your suggestions work have to much of a
negative impact imho. I cant see your feature getting implemented by
anybody. Your only option is to implement it yourself and see how you
fare. If you do it as a plugin that does the check you want you might get
traction with other users.

However I cant see anybody from the core team working on this. If the
problem is really so big for yourself then you can go and fix it. If
fixing it is too much hazzle you will have to change your procedure. Your
choice.

Apart from that I think we can agree to disagree.

manfred

>>-----Original Message-----
>>From: Ron Wheeler [mailto:***@artifact-software.com]
>>
>> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>>> -----Original Message-----
>>>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>>>
>>>> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>>>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
>>> great
>>>>>> if you live in an ideal world, but guess what: some of us actually
>>> have
>>>>>> to live in the *real* world where things don't always follow the
>>>>>> guidelines. It would be nice if maven didn't make it so hard to
>>> deal
>>>>>> with those situations.
>>>>> Sorry.. but in this case I think the cost of accommodating for
>>> behaviours
>>>>> against the known best practice would far outweigh the benefits. I
>>> would
>>>>> not want to see such a feature available even for the pure cost
>>> people
>>>>> then using it. Just adapt your practice.
>>>>>
>>>> +1.
>>>> We are still suffering from a project that allowed released
> artifacts
>>> to
>>>> change without creating a new release.
>>>> Bad practices need to stopped not supported.
>>>>
>>>> Ron
>>> I'm sure I'm not the only person that is very disappointed at the
> lack
>>> of desire to help people get things working. It's one thing to
>>> encourage people to do things the right way, but I think it's stupid
> to
>>> actively put obstacles in the path of people trying to deal with
>>> environments that aren't perfect.
>>If you see a blind man walking into traffic do you help him step off
> the
>>curb?
>
> Yes, actually I would. At the same time I would mention that it might
> be better for him to use the crosswalk. I certainly wouldn't take away
> his cane so he can't even tell the curb is there until he trips over it.
>
>>You can stop people from changing released artifacts.
>>Get them to use SNAPSHOTs until they really have tested the release
> and
>>got the OK to issue a release.
>>If people are not testing their SNAPSHOTs before releasing them, you
>>need to stop this.
>
> No, actually you can't. It is absolutely impossible to ensure that a
> release artifact will never change.
> You certainly can (and should) do a lot to discourage that from
> happening, and you can do a lot to make it difficult to cause it to
> happen, but once it does happen you shouldn't continue to make things
> difficult for people to notice that something is wrong and to fix it.
>
>>> Do you really think it's better to not have any way to recover from
> the
>>> case when a project changes release artifacts?
>>The repository manager can delete a release which does allow you to
>>rerelease the save version.
>>When this is done, each programmer has to manually remove the bad
>>version from their local cache to ensure that Maven gets the rereleased
>>artifact.
>>This should only be done once in a blue moon not as part of regular
>>operation.
>
> And if this happens, maven should tell you about it! I think it would
> be nice it there was an easy way to tell maven to remove the bad version
> from the local cache, but the bare minimum it should do is spit out an
> error like:
> [ERROR] release artifact com.example:foo in the local cache does not
> match repository version (http://central/com/example/foo)
> [ERROR] to use the repository version, remove the files at
> ~/.m2/repository/com/example/foo
>
>>> As you say, you're still
>>> suffering from it. Perhaps that's exactly because maven doesn't
> provide
>>> you the tools to effectively deal with it!
>>I am suffering because it is hard to tell which release 2.1.3 is the
>>"good" version with the patches.
>
> So why wouldn't you want to know that there are two different copies of
> that release? I don't understand why there is such resistance to
> providing the tools to effectively deal with problematic situations.
>
>>> IMO, maven should, at the very least, be able to indicate an error
> when
>>> things are inconsistent, even for release artifacts. The current
>>> behaviour, where you have absolutely NO CLUE what's going on if an
>>> artifact changes, leads to huge amounts of confusion.
>>That is not a Maven problem it is a people problem.
>>That is why you don't let artifacts change.
>
> I don't know what world you live in, but in mine I don't have absolute
> control over everything.
>
> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>

[Ron Wheeler]

On 05/08/2010 1:13 PM, Manfred Moser wrote:
> Eric,
>
> It seems like we will not agree here. The changes necessary and the
> additional overhead to make your suggestions work have to much of a
> negative impact imho. I cant see your feature getting implemented by
> anybody. Your only option is to implement it yourself and see how you
> fare. If you do it as a plugin that does the check you want you might get
> traction with other users.
>
> However I cant see anybody from the core team working on this. If the
> problem is really so big for yourself then you can go and fix it. If
> fixing it is too much hazzle you will have to change your procedure. Your
> choice.
The network traffic that that would cause in a modern project with
dozens of dependencies would create a real nuisance.

Ron
> Apart from that I think we can agree to disagree.
>
> manfred
>
>>> -----Original Message-----
>>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>>
>>> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>>>> -----Original Message-----
>>>>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>>>>
>>>>> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>>>>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
>>>> great
>>>>>>> if you live in an ideal world, but guess what: some of us actually
>>>> have
>>>>>>> to live in the *real* world where things don't always follow the
>>>>>>> guidelines. It would be nice if maven didn't make it so hard to
>>>> deal
>>>>>>> with those situations.
>>>>>> Sorry.. but in this case I think the cost of accommodating for
>>>> behaviours
>>>>>> against the known best practice would far outweigh the benefits. I
>>>> would
>>>>>> not want to see such a feature available even for the pure cost
>>>> people
>>>>>> then using it. Just adapt your practice.
>>>>>>
>>>>> +1.
>>>>> We are still suffering from a project that allowed released
>> artifacts
>>>> to
>>>>> change without creating a new release.
>>>>> Bad practices need to stopped not supported.
>>>>>
>>>>> Ron
>>>> I'm sure I'm not the only person that is very disappointed at the
>> lack
>>>> of desire to help people get things working. It's one thing to
>>>> encourage people to do things the right way, but I think it's stupid
>> to
>>>> actively put obstacles in the path of people trying to deal with
>>>> environments that aren't perfect.
>>> If you see a blind man walking into traffic do you help him step off
>> the
>>> curb?
>> Yes, actually I would. At the same time I would mention that it might
>> be better for him to use the crosswalk. I certainly wouldn't take away
>> his cane so he can't even tell the curb is there until he trips over it.
>>
>>> You can stop people from changing released artifacts.
>>> Get them to use SNAPSHOTs until they really have tested the release
>> and
>>> got the OK to issue a release.
>>> If people are not testing their SNAPSHOTs before releasing them, you
>>> need to stop this.
>> No, actually you can't. It is absolutely impossible to ensure that a
>> release artifact will never change.
>> You certainly can (and should) do a lot to discourage that from
>> happening, and you can do a lot to make it difficult to cause it to
>> happen, but once it does happen you shouldn't continue to make things
>> difficult for people to notice that something is wrong and to fix it.
>>
>>>> Do you really think it's better to not have any way to recover from
>> the
>>>> case when a project changes release artifacts?
>>> The repository manager can delete a release which does allow you to
>>> rerelease the save version.
>>> When this is done, each programmer has to manually remove the bad
>>> version from their local cache to ensure that Maven gets the rereleased
>>> artifact.
>>> This should only be done once in a blue moon not as part of regular
>>> operation.
>> And if this happens, maven should tell you about it! I think it would
>> be nice it there was an easy way to tell maven to remove the bad version
>> from the local cache, but the bare minimum it should do is spit out an
>> error like:
>> [ERROR] release artifact com.example:foo in the local cache does not
>> match repository version (http://central/com/example/foo)
>> [ERROR] to use the repository version, remove the files at
>> ~/.m2/repository/com/example/foo
>>
>>>> As you say, you're still
>>>> suffering from it. Perhaps that's exactly because maven doesn't
>> provide
>>>> you the tools to effectively deal with it!
>>> I am suffering because it is hard to tell which release 2.1.3 is the
>>> "good" version with the patches.
>> So why wouldn't you want to know that there are two different copies of
>> that release? I don't understand why there is such resistance to
>> providing the tools to effectively deal with problematic situations.
>>
>>>> IMO, maven should, at the very least, be able to indicate an error
>> when
>>>> things are inconsistent, even for release artifacts. The current
>>>> behaviour, where you have absolutely NO CLUE what's going on if an
>>>> artifact changes, leads to huge amounts of confusion.
>>> That is not a Maven problem it is a people problem.
>>> That is why you don't let artifacts change.
>> I don't know what world you live in, but in mine I don't have absolute
>> control over everything.
>>
>> eric
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-***@maven.apache.org
>> For additional commands, e-mail: users-***@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Wayne Fay]

> The network traffic that that would cause in a modern project with dozens of
> dependencies would create a real nuisance.

If every artifact had md5 and sha1 hashes etc, then the traffic would
merely be to check the hashes against the local artifact... which
Maven already does, and complains when things don't match.

Note: I'm not encouraging this approach. Releases must never change,
period, end of story. Push another release if you find a given release
is broken.

Wayne

[Baptiste MATHUS]

Hi,

I rapidly browsed the thread, please excuse me if I missed something.
Isn't mvn dependency:purge-local-repository the solution?

Please note that I'm 100% with people saying releases must never change. And
it's so important it's not something specific to maven world. Imagine you
release a 1.0 to some client, and try to find the corresponding sources when
encountering a blocking bug. You're either going not to be able to find the
right sources, or to have to do some ugly thing like storing svn-revision in
the MANIFEST while packaging the jar... That's just something that should
not be done in the software world, period.

Cheers

Le 5 août 2010 22:08:03 UTC+2, Wayne Fay <***@gmail.com> a écrit :

> > The network traffic that that would cause in a modern project with dozens
> of
> > dependencies would create a real nuisance.
>
> If every artifact had md5 and sha1 hashes etc, then the traffic would
> merely be to check the hashes against the local artifact... which
> Maven already does, and complains when things don't match.
>
> Note: I'm not encouraging this approach. Releases must never change,
> period, end of story. Push another release if you find a given release
> is broken.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>


--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Ron Wheeler]

On 08/08/2010 5:32 AM, Baptiste MATHUS wrote:
> Hi,
>
> I rapidly browsed the thread, please excuse me if I missed something.
> Isn't mvn dependency:purge-local-repository the solution?
>
> Please note that I'm 100% with people saying releases must never change. And
> it's so important it's not something specific to maven world. Imagine you
> release a 1.0 to some client, and try to find the corresponding sources when
> encountering a blocking bug. You're either going not to be able to find the
> right sources, or to have to do some ugly thing like storing svn-revision in
> the MANIFEST while packaging the jar... That's just something that should
> not be done in the software world, period.
>
That is exactly what happened to us using an open source project.
Caused grief for a long time. One is never really sure which artifact or
set of sources match up with what you are running.

Ron

> Cheers
>
> Le 5 août 2010 22:08:03 UTC+2, Wayne Fay<***@gmail.com> a écrit :
>
>>> The network traffic that that would cause in a modern project with dozens
>> of
>>> dependencies would create a real nuisance.
>> If every artifact had md5 and sha1 hashes etc, then the traffic would
>> merely be to check the hashes against the local artifact... which
>> Maven already does, and complains when things don't match.
>>
>> Note: I'm not encouraging this approach. Releases must never change,
>> period, end of story. Push another release if you find a given release
>> is broken.
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-***@maven.apache.org
>> For additional commands, e-mail: users-***@maven.apache.org
>>
>>
>

[Justin Edelson]

On Aug 8, 2010, at 5:32 AM, Baptiste MATHUS <***@batmat.net> wrote:

> Hi,
>
> I rapidly browsed the thread, please excuse me if I missed something.
> Isn't mvn dependency:purge-local-repository the solution?

The issue identified by the OP is that there's no way to (pro-actively) detect that a release has changed.
>
> Please note that I'm 100% with people saying releases must never change. And
> it's so important it's not something specific to maven world. Imagine you
> release a 1.0 to some client, and try to find the corresponding sources when
> encountering a blocking bug. You're either going not to be able to find the
> right sources, or to have to do some ugly thing like storing svn-revision in
> the MANIFEST while packaging the jar... That's just something that should
> not be done in the software world, period.
>
> Cheers
>
> Le 5 août 2010 22:08:03 UTC+2, Wayne Fay <***@gmail.com> a écrit :
>
>>> The network traffic that that would cause in a modern project with dozens
>> of
>>> dependencies would create a real nuisance.
>>
>> If every artifact had md5 and sha1 hashes etc, then the traffic would
>> merely be to check the hashes against the local artifact... which
>> Maven already does, and complains when things don't match.
>>
>> Note: I'm not encouraging this approach. Releases must never change,
>> period, end of story. Push another release if you find a given release
>> is broken.
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-***@maven.apache.org
>> For additional commands, e-mail: users-***@maven.apache.org
>>
>>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !

[Wayne Fay]

>> I rapidly browsed the thread, please excuse me if I missed something.
>> Isn't mvn dependency:purge-local-repository the solution?
>
> The issue identified by the OP is that there's no way to (pro-actively) detect that a release has changed.

I apologize in advance for a TERRIBLE suggestion... assuming you are
running a local MRM and thus merely consuming local bandwith... you
could bind purge-local-repo to init phase.

PS- Don't do this!

Wayne

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Wayne Fay [mailto:***@gmail.com]
>
>>> I rapidly browsed the thread, please excuse me if I missed
something.
>>> Isn't mvn dependency:purge-local-repository the solution?
>>
>> The issue identified by the OP is that there's no way to
(pro-actively)
>detect that a release has changed.
>
>I apologize in advance for a TERRIBLE suggestion... assuming you are
>running a local MRM and thus merely consuming local bandwith... you
>could bind purge-local-repo to init phase.
>
>PS- Don't do this!

Even with a local repository manager this isn't that great of a
suggestion: local might mean faster network, but not infinite bandwidth,
especially when you've got more than a few developers working on things.
(and the few extra minutes it would add to the build even for one
developer would be kind of annoying)

eric

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Manfred Moser [mailto:***@mosabuam.com]
>
>It seems like we will not agree here. The changes necessary and the
>additional overhead to make your suggestions work have to much of a
>negative impact imho. I cant see your feature getting implemented by
>anybody. Your only option is to implement it yourself and see how you
>fare. If you do it as a plugin that does the check you want you might
get
>traction with other users.

I don't (yet) know much about the internals of maven, but is it really
that much of an impact on the code? There's already support present for
checking for differences in snapshot versions, right? I'm imagining
that making it work for release artifacts would be a matter of not
distinguishing between release and snapshot artifacts and having the
check apply to both.
It sounds like you think it'll be harder to do than that; what I am
missing?

eric

[Kalle Korhonen]

On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
<***@transunion.com> wrote:
>>-----Original Message-----
> I don't (yet) know much about the internals of maven, but is it really
> that much of an impact on the code?  There's already support present for
> checking for differences in snapshot versions, right?  I'm imagining
> that making it work for release artifacts would be a matter of not
> distinguishing between release and snapshot artifacts and having the
> check apply to both.
> It sounds like you think it'll be harder to do than that; what I am
> missing?

What you are asking is absurd. That's the exact difference between
snapshots and releases; snapshots should be updated and releases
shouldn't. Why would you insist on removing this differentiation?
Wouldn't it be easier for you to just use snapshots if you need to
check for updates?

Kalle

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Kalle Korhonen [mailto:***@gmail.com]
>
>On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
><***@transunion.com> wrote:
>>>-----Original Message-----
>> I don't (yet) know much about the internals of maven, but is it really
>> that much of an impact on the code?  There's already support present for
>> checking for differences in snapshot versions, right?  I'm imagining
>> that making it work for release artifacts would be a matter of not
>> distinguishing between release and snapshot artifacts and having the
>> check apply to both.
>> It sounds like you think it'll be harder to do than that; what I am
>> missing?
>
>What you are asking is absurd. That's the exact difference between
>snapshots and releases; snapshots should be updated and releases
>shouldn't. Why would you insist on removing this differentiation?
>Wouldn't it be easier for you to just use snapshots if you need to
>check for updates?

Please read the rest of the email thread. The short summary is:
Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation.

eric

[Paul Benedict]

On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
<***@transunion.com>wrote:

> Please read the rest of the email thread. The short summary is:
> Yes, I know what *should* happen, but the world isn't perfect and release
> artifacts DO sometimes change. It is not absurd to be able to detect and
> recover from that kind of situation.
>
>
The solution is to wipe out your local artifact. No one should be updating
released artifacts. If they do, they abused what a release means -- hence
the problem to begin with. The solution given is the only (correct) one in
Maven.

Paul

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: ***@gmail.com [mailto:***@gmail.com]
On
>
>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
><***@transunion.com>wrote:
>
>> Please read the rest of the email thread. The short summary is:
>> Yes, I know what *should* happen, but the world isn't perfect and
>release
>> artifacts DO sometimes change. It is not absurd to be able to detect
and
>> recover from that kind of situation.
>>
>>
>The solution is to wipe out your local artifact. No one should be
updating
>released artifacts. If they do, they abused what a release means --
hence
>the problem to begin with. The solution given is the only (correct) one
in
>Maven.

I'm AGREEING with you that the solution is to wipe out the local
artifact! But you can only do that once you know there is something
wrong. How do you detect that the artifact has changed?
Maybe you'll get lucky and something is different enough in your
artifact that the build process fails. Or maybe you have some
regression testing that you'll do so you notice the problem. Having
maven compare the checksums seems like a much more reliable way to catch
these problems.

eric

[Kalle Korhonen]

So you just want to verify?

$ mvn --help

usage: mvn [options] [<goal(s)>] [<phase(s)>]

Options:
-am,--also-make If project list is specified, also
build projects required by the
list
-amd,--also-make-dependents If project list is specified, also
build projects that depend on
projects on the list
-B,--batch-mode Run in non-interactive (batch)
mode
-C,--strict-checksums Fail the build if checksums don't
match
-c,--lax-checksums Warn if checksums don't match

Kalle


On Fri, Aug 6, 2010 at 1:01 PM, Haszlakiewicz, Eric
<***@transunion.com> wrote:
>>-----Original Message-----
>>From: ***@gmail.com [mailto:***@gmail.com]
> On
>>
>>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
>><***@transunion.com>wrote:
>>
>>> Please read the rest of the email thread.  The short summary is:
>>>  Yes, I know what *should* happen, but the world isn't perfect and
>>release
>>> artifacts DO sometimes change.  It is not absurd to be able to detect
> and
>>> recover from that kind of situation.
>>>
>>>
>>The solution is to wipe out your local artifact. No one should be
> updating
>>released artifacts. If they do, they abused what a release means --
> hence
>>the problem to begin with. The solution given is the only (correct) one
> in
>>Maven.
>
> I'm AGREEING with you that the solution is to wipe out the local
> artifact!  But you can only do that once you know there is something
> wrong.  How do you detect that the artifact has changed?
> Maybe you'll get lucky and something is different enough in your
> artifact that the build process fails.  Or maybe you have some
> regression testing that you'll do so you notice the problem.  Having
> maven compare the checksums seems like a much more reliable way to catch
> these problems.
>
> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Eduardo M KALINOWSKI]

On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote:
> I'm AGREEING with you that the solution is to wipe out the local
> artifact! But you can only do that once you know there is something
> wrong. How do you detect that the artifact has changed?

You don't have to, because released artifacts do not change[0].

[0]Unless someone intentionally screws up. And it is no accidental
screw up, I think all artifact managers forbid redeploying a non
snapshot version. So in order to that happen, someone must circunvent
the normal deploying route. If someone really needs to do so, then
that person may simply warn everyone that might be affected. That is
feasible, because such situation should never happen in any of the
public repositories, being limited to the organization repository.


--
Be circumspect in your liaisons with women. It is better to be seen at
the opera with a man than at mass with a woman.
-- De Maintenon

Eduardo M KALINOWSKI
***@kalinowski.com.br

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Eduardo M KALINOWSKI [mailto:***@kalinowski.com.br]
>
>On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote:
>> I'm AGREEING with you that the solution is to wipe out the local
>> artifact! But you can only do that once you know there is something
>> wrong. How do you detect that the artifact has changed?
>
>You don't have to, because released artifacts do not change[0].
>
>[0]Unless someone intentionally screws up. And it is no accidental
>screw up, I think all artifact managers forbid redeploying a non
>snapshot version. So in order to that happen, someone must circunvent
>the normal deploying route. If someone really needs to do so, then
>that person may simply warn everyone that might be affected. That is
>feasible, because such situation should never happen in any of the
>public repositories, being limited to the organization repository.

It doesn't require much of a screwup to create a changed release
artifacts. For example, all it takes is a simple typo when uploading an
artifact to your nexus repository. I did exactly this when trying to
import a specific release of a package that isn't available on central
and isn't built through maven. I ended up with releases in the
repository with the wrong jar files attached, and by the time I noticed
it was wrong people had already tried to build things using it, and I
didn't realize that there was something I needed to warn about. Even if
I did warn people, the overhead of everyone needing to read an email,
figure out where they ran builds from, figure out what needs to be
removed and remove the files from every machine that they might have
worked on is huge.

i.e. I intended to upload
foox-1.2.jar as com.mycompany:foox:1.2
fooy-1.2.jar as com.mycompany:fooy:1.2
but I actually ended up with it switched
fooy-1.2.jar as com.mycompany:foox:1.2
foox-1.2.jar as com.mycompany:fooy:1.2

I don't have control over the release cycle of these packages so I
couldn't just declare a new release.

Even after I fixed our central repository people were having problems
building. Eventually we figured out what was going on, but it would
have been far easier if maven could have actually told us that there was
an inconsistency between the central repo and the .m2 directories.

In the real world artifacts DO change. I've seen other people ask about
this on the mailing list so I know I'm not the only one that has run
into situations like this.

eric

[Ron Wheeler]

On 06/08/2010 4:01 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: ***@gmail.com [mailto:***@gmail.com]
> On
>> On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
>> <***@transunion.com>wrote:
>>
>>> Please read the rest of the email thread. The short summary is:
>>> Yes, I know what *should* happen, but the world isn't perfect and
>> release
>>> artifacts DO sometimes change. It is not absurd to be able to detect
> and
>>> recover from that kind of situation.
>>>
>>>
>> The solution is to wipe out your local artifact. No one should be
> updating
>> released artifacts. If they do, they abused what a release means --
> hence
>> the problem to begin with. The solution given is the only (correct) one
> in
>> Maven.
> I'm AGREEING with you that the solution is to wipe out the local
> artifact! But you can only do that once you know there is something
> wrong. How do you detect that the artifact has changed?
If you can not deploy the release, that will tell you that you are
trying to rerelease an artifact.
> Maybe you'll get lucky and something is different enough in your
> artifact that the build process fails.
Your attempt to deploy will fail. That will tell you right away that you
are doing the wrong thing.

> Or maybe you have some
> regression testing that you'll do so you notice the problem. Having
> maven compare the checksums seems like a much more reliable way to catch
> these problems.
>
Yes use SNAPSHOTS.

> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Ron Wheeler [mailto:***@artifact-software.com]
>> I'm AGREEING with you that the solution is to wipe out the local
>> artifact! But you can only do that once you know there is something
>> wrong. How do you detect that the artifact has changed?
>If you can not deploy the release, that will tell you that you are
>trying to rerelease an artifact.
>> Maybe you'll get lucky and something is different enough in your
>> artifact that the build process fails.
>Your attempt to deploy will fail. That will tell you right away that
you
>are doing the wrong thing.

No, the deployment of a project that USES a changed artifact will NOT
fail.

eric

[Ron Wheeler]

On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>> I'm AGREEING with you that the solution is to wipe out the local
>>> artifact! But you can only do that once you know there is something
>>> wrong. How do you detect that the artifact has changed?
>> If you can not deploy the release, that will tell you that you are
>> trying to rerelease an artifact.
>>> Maybe you'll get lucky and something is different enough in your
>>> artifact that the build process fails.
>> Your attempt to deploy will fail. That will tell you right away that
> you
>> are doing the wrong thing.
> No, the deployment of a project that USES a changed artifact will NOT
> fail.

Yes.
That is why releases can not be replaced.
In your case, you should have deleted the wrong artifacts and loaded
them with new versions.
And informed the victims that they needed to update their dependencies.

You were completely in control of the versions and names.

Ron

> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Kathryn Huxtable]

On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote:

> On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote:
>>> -----Original Message-----
>>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>>> I'm AGREEING with you that the solution is to wipe out the local
>>>> artifact! But you can only do that once you know there is something
>>>> wrong. How do you detect that the artifact has changed?
>>> If you can not deploy the release, that will tell you that you are
>>> trying to rerelease an artifact.
>>>> Maybe you'll get lucky and something is different enough in your
>>>> artifact that the build process fails.
>>> Your attempt to deploy will fail. That will tell you right away that
>> you
>>> are doing the wrong thing.
>> No, the deployment of a project that USES a changed artifact will NOT
>> fail.
>
> Yes.
> That is why releases can not be replaced.
> In your case, you should have deleted the wrong artifacts and loaded them with new versions.
> And informed the victims that they needed to update their dependencies.
>
> You were completely in control of the versions and names.

And, frustrating though it is, that's what I've done when my bad QC has released bad stuff onto Central. You just put out another version and apologize on the web page. There's not a lot else to do, and it's not that bad.

-K

[Martin Gainty]

if the developer just completed the code but the artifact did'nt execute and pass all the test-suites tag as alpha so the user community know thats its dicey at best
artifact-version-alpha-1

if the artifact passes muster (no errors and no failures) with all the test suites (surefire) then tag it as beta
artifact-version-beta-2

if someone wants a build right now the artifact developer can release immediately as snapshot
artifact-version-snapshot

if the artifactId is blessed by more than the developer then you can tag as RC e.g.
artifact-version-RC1

the idea behind version controlled build environments (such as maven) is the developer can request a specific artifact for example:
e.g. user pings author to request artifact-A will incorporate function X
developer factors code to implement function X
author releases artifact-version-snapshot
all the other developers know that referencing an alpha or beta or snapshot is dicey and should not pollute their production builds
when the developer finally sees the artifact version has been promoted to RC (release candidate) they can reference the Release Candidate in their production builds

this is my understanding of how maven contributes to the SDLC process.

Take a look at configuring classifier for use in a qualified artifact for implementation details
http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-platform-classifier.html

Bedankt
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.





> Subject: Re: force maven to redownload/refresh "released" dependencies
> From: ***@kathrynhuxtable.org
> Date: Fri, 6 Aug 2010 18:28:32 -0500
> To: ***@maven.apache.org
>
> On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote:
>
> > On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote:
> >>> -----Original Message-----
> >>> From: Ron Wheeler [mailto:***@artifact-software.com]
> >>>> I'm AGREEING with you that the solution is to wipe out the local
> >>>> artifact! But you can only do that once you know there is something
> >>>> wrong. How do you detect that the artifact has changed?
> >>> If you can not deploy the release, that will tell you that you are
> >>> trying to rerelease an artifact.
> >>>> Maybe you'll get lucky and something is different enough in your
> >>>> artifact that the build process fails.
> >>> Your attempt to deploy will fail. That will tell you right away that
> >> you
> >>> are doing the wrong thing.
> >> No, the deployment of a project that USES a changed artifact will NOT
> >> fail.
> >
> > Yes.
> > That is why releases can not be replaced.
> > In your case, you should have deleted the wrong artifacts and loaded them with new versions.
> > And informed the victims that they needed to update their dependencies.
> >
> > You were completely in control of the versions and names.
>
> And, frustrating though it is, that's what I've done when my bad QC has released bad stuff onto Central. You just put out another version and apologize on the web page. There's not a lot else to do, and it's not that bad.
>
> -K
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>

[Kathryn Huxtable]

On Aug 6, 2010, at 12:57 PM, Kalle Korhonen wrote:

> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
> <***@transunion.com> wrote:
>>> -----Original Message-----
>> I don't (yet) know much about the internals of maven, but is it really
>> that much of an impact on the code? There's already support present for
>> checking for differences in snapshot versions, right? I'm imagining
>> that making it work for release artifacts would be a matter of not
>> distinguishing between release and snapshot artifacts and having the
>> check apply to both.
>> It sounds like you think it'll be harder to do than that; what I am
>> missing?
>
> What you are asking is absurd. That's the exact difference between
> snapshots and releases; snapshots should be updated and releases
> shouldn't. Why would you insist on removing this differentiation?
> Wouldn't it be easier for you to just use snapshots if you need to
> check for updates?

What Katie (and others) said!

I have my differences with the current Maven philosophy, but one thing that has been baked in from the beginning is that artifact coordinates imply a fixed thing. The artifact does not change. That's one of the *points* of Maven.

-K

[Kathryn Huxtable]

On Aug 6, 2010, at 1:00 PM, Haszlakiewicz, Eric wrote:

>> -----Original Message-----
>> From: Kalle Korhonen [mailto:***@gmail.com]
>>
>> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
>> <***@transunion.com> wrote:
>>>> -----Original Message-----
>>> I don't (yet) know much about the internals of maven, but is it really
>>> that much of an impact on the code? There's already support present for
>>> checking for differences in snapshot versions, right? I'm imagining
>>> that making it work for release artifacts would be a matter of not
>>> distinguishing between release and snapshot artifacts and having the
>>> check apply to both.
>>> It sounds like you think it'll be harder to do than that; what I am
>>> missing?
>>
>> What you are asking is absurd. That's the exact difference between
>> snapshots and releases; snapshots should be updated and releases
>> shouldn't. Why would you insist on removing this differentiation?
>> Wouldn't it be easier for you to just use snapshots if you need to
>> check for updates?
>
> Please read the rest of the email thread. The short summary is:
> Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation.

Eric, you're not going to win this one. It's part of the philosophy of Maven. It's also good practice.

Give it up.

I'm not going to fight the site generation being split out of Maven. I think I understand Jason's point on that, though I disagree. And that's a *much* less nasty violation of Maven's perceived function, if in fact, it is a violation.

What you're wanting is a violation.

-K

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Kathryn Huxtable [mailto:***@kathrynhuxtable.org]
>
>Eric, you're not going to win this one. It's part of the philosophy of
>Maven. It's also good practice.
>
>Give it up.
>
>I'm not going to fight the site generation being split out of Maven. I
>think I understand Jason's point on that, though I disagree. And that's
a
>*much* less nasty violation of Maven's perceived function, if in fact,
it
>is a violation.
>
>What you're wanting is a violation.

You're missing the point of what I'm asking. I'm not suggesting that
maven make it possible or easy to *create* the violation. I'm
suggesting that it should be able to *detect* the violation.

I'm baffled as to why the maven community is so against the idea of
having additional (optional) checks to detect problems.

eric

[Paul Benedict]

On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
<***@transunion.com>wrote:

> You're missing the point of what I'm asking. I'm not suggesting that
> maven make it possible or easy to *create* the violation. I'm
> suggesting that it should be able to *detect* the violation.
>
> I'm baffled as to why the maven community is so against the idea of
> having additional (optional) checks to detect problems.
>
>
Eric,

The point is releases don't change. To "detect" means wasting bandwidth
comparing your supposedly unchanging released local artifacts to supposedly
unchanging released remote artifacts. If anything, writing a Maven plug-in
for this would be more appropriate, but I don't see your suggestion as part
of Maven core.

Paul

[Manfred Moser]

> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
> <***@transunion.com>wrote:
>
>> You're missing the point of what I'm asking. I'm not suggesting that
>> maven make it possible or easy to *create* the violation. I'm
>> suggesting that it should be able to *detect* the violation.
>>
>> I'm baffled as to why the maven community is so against the idea of
>> having additional (optional) checks to detect problems.
>>
>>
> Eric,
>
> The point is releases don't change. To "detect" means wasting bandwidth
> comparing your supposedly unchanging released local artifacts to
> supposedly
> unchanging released remote artifacts. If anything, writing a Maven plug-in
> for this would be more appropriate, but I don't see your suggestion as
> part
> of Maven core.

Exactly what I suggested. If you really need this you will have to do it
yourself.

manfred

[Kathryn Huxtable]

On Aug 6, 2010, at 2:58 PM, Paul Benedict wrote:

> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
> <***@transunion.com>wrote:
>
>> You're missing the point of what I'm asking. I'm not suggesting that
>> maven make it possible or easy to *create* the violation. I'm
>> suggesting that it should be able to *detect* the violation.
>>
>> I'm baffled as to why the maven community is so against the idea of
>> having additional (optional) checks to detect problems.
>>
>>
> Eric,
>
> The point is releases don't change. To "detect" means wasting bandwidth
> comparing your supposedly unchanging released local artifacts to supposedly
> unchanging released remote artifacts. If anything, writing a Maven plug-in
> for this would be more appropriate, but I don't see your suggestion as part
> of Maven core.

And actually, it wouldn't be that hard to write such a plugin. But you have to want it...

-K

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: ***@gmail.com [mailto:***@gmail.com]
On
>On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
><***@transunion.com>wrote:
>
>> You're missing the point of what I'm asking. I'm not suggesting that
>> maven make it possible or easy to *create* the violation. I'm
>> suggesting that it should be able to *detect* the violation.
>>
>> I'm baffled as to why the maven community is so against the idea of
>> having additional (optional) checks to detect problems.
>>
>>
>Eric,
>
>The point is releases don't change. To "detect" means wasting bandwidth
>comparing your supposedly unchanging released local artifacts to
supposedly
>unchanging released remote artifacts. If anything, writing a Maven
plug-in
>for this would be more appropriate, but I don't see your suggestion as
part
>of Maven core.

Is it really going to be that much wasted bandwidth to download a few
checksums?

Can a plugin hook into the existing support for detecting changes in
snapshots?

eric

[Ron Wheeler]

On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: ***@gmail.com [mailto:***@gmail.com]
> On
>> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
>> <***@transunion.com>wrote:
>>
>>> You're missing the point of what I'm asking. I'm not suggesting that
>>> maven make it possible or easy to *create* the violation. I'm
>>> suggesting that it should be able to *detect* the violation.
>>>
>>> I'm baffled as to why the maven community is so against the idea of
>>> having additional (optional) checks to detect problems.
>>>
>>>
>> Eric,
>>
>> The point is releases don't change. To "detect" means wasting bandwidth
>> comparing your supposedly unchanging released local artifacts to
> supposedly
>> unchanging released remote artifacts. If anything, writing a Maven
> plug-in
>> for this would be more appropriate, but I don't see your suggestion as
> part
>> of Maven core.
> Is it really going to be that much wasted bandwidth to download a few
> checksums?
>
> Can a plugin hook into the existing support for detecting changes in
> snapshots?
You do not have to.
SNAPSHOTS are checked in exactly the way you want releases to be checked
because SNAPSHOTS are supposed to change and by default you get the
latest deployed SNAPSHOT.
To find out if you have the latest SNAPSHOT, Maven will check the
repository and download the new version for you automatically.

That is why we are so comfortable with the current system.
Only the stuff that you indicate is unstable, is checked and the stable
stuff (called Releases) can be used from your local cache without problem.

The clear distinction between a stable release and a SNAPSHOT is your
team's commitment to each other not to break things after you have said
that they are done.
With SNAPSHOTS you can decide to stick with a certain version of a
SNAPSHOT or take the latest depending on your informal contract with the
developer.
If I tell you that today I am deploying a SNAPSHOT that is tested to do
this function and that function while I am continuing to work on a third
function and fix a deficiency in the first function, at least you know
what you have to deal with. Youi can decide that you want to get my
fixes as soon as they are deployed or you want to stick with the buggy
one since your code deals with the bug and you want to go on testing
with a stable version of my SNAPSHOT. But it is your choice and you know
what you are getting.

If I deploy a Release of my artifact, you are assured that I am
promising you a production quality artifact ready to go in the final build.
If you, God forbid, find a bug in my release 2.1.4, I must issue a
patched version with a new version number 2.1.5 or 2.1.4.1 and let
people know that if they want the fixed version, they have to change
their dependencies or suffer the bug that you found.
I can not lie to you about what you are getting.

In a team, this is a big help.

Ron


> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Ron Wheeler [mailto:***@artifact-software.com]
> On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote:
>> Is it really going to be that much wasted bandwidth to download a few
>> checksums?
>>
>> Can a plugin hook into the existing support for detecting changes in
>> snapshots?
>You do not have to.
>SNAPSHOTS are checked in exactly the way you want releases to be
checked
>because SNAPSHOTS are supposed to change and by default you get the
>latest deployed SNAPSHOT.
>To find out if you have the latest SNAPSHOT, Maven will check the
>repository and download the new version for you automatically.

So you're saying that I should always upload a released package using a
SNAPSHOT version? Then it seems like I'm lying about what the package
actually is.

>That is why we are so comfortable with the current system.
>Only the stuff that you indicate is unstable, is checked and the stable
>stuff (called Releases) can be used from your local cache without
problem.
>
>The clear distinction between a stable release and a SNAPSHOT is your
>team's commitment to each other not to break things after you have said
>that they are done.
...snip...

I am not arguing against the idea of having snapshots that can be
updated, and releases that stay stable. I'm perfectly fine with that
being what *should* happen, but I know it's impossible that the correct
procedures will be followed at all times.

It seems that you're connecting the creation of a release with the
process of uploading it to a particular repository. If you're dealing
solely with projects that use maven, and perfect people that never
fiddle with the repository directly, then you can probably consider
those to be equivalent.
But not everything is a maven project, and not everyone follows the
perfect procedures, and not all disks are perfectly immune from
corruption. If there is ever a problem with uploading the artifact to
the repository, or with it after it's been uploaded, then I'd want to
know that there is something wrong.

eric

[Jason van Zyl]

On Aug 6, 2010, at 3:53 PM, Haszlakiewicz, Eric wrote:

>> -----Original Message-----
>> From: Kathryn Huxtable [mailto:***@kathrynhuxtable.org]
>>
>> Eric, you're not going to win this one. It's part of the philosophy of
>> Maven. It's also good practice.
>>
>> Give it up.
>>
>> I'm not going to fight the site generation being split out of Maven. I
>> think I understand Jason's point on that, though I disagree. And that's
> a
>> *much* less nasty violation of Maven's perceived function, if in fact,
> it
>> is a violation.
>>
>> What you're wanting is a violation.
>
> You're missing the point of what I'm asking. I'm not suggesting that
> maven make it possible or easy to *create* the violation. I'm
> suggesting that it should be able to *detect* the violation.
>
> I'm baffled as to why the maven community is so against the idea of
> having additional (optional) checks to detect problems.
>

The nut of the problem is that if we had to support every optional behavior for a particular subset of the community the code base would likely be unmaintainable. No one here is going to implement anything toward what you're specifically asking for because Maven was specifically designed not to work for what you want. It probably would not be hard to do what you ask for, but just because something is possible doesn't mean it's a good idea to do it.

Generally when people argue along the lines of "well my organization doesn't do that and we can't change" I retort that the community of Maven users is like an organization and it's far more powerful then yours. We don't do that and we're not going to change. So the onus would be on you to take the sources of Maven and alter it for your use and then the cost of maintaining that behavior becomes yours and it's not cheap. It's really not cheap. We can't make everyone happy and that's ok with us, well it's at least ok with me. I guess I can't speak for everyone. There are other build tool options, or you can maintain your own fork of Maven with the behavior your organization desires.

Now what you're asking for here sounds particularly disastrous. If across your organization a release does not actually mean a release in the Maven sense you are going to have so many problems with what plugins normally expect and how artifacts may be integrated across different groups. Trust me, you do not want to go hunting around trying to figure out if something actually changed because looking at an artifact that is supposed to be immutable in Maven but isn't just screams out N points of failure. None of the IDE integration would work properly, many of the CI tools also wouldn't work very well. You're just asking for a world of very expensive pain. Every organization can change. You may not be able to change tomorrow but you can change. I've seen it happen at the biggest of the big.

My suggestion if you are looking at Maven is to start with a smaller project and use Maven the way it's supposed to be used and evaluate if that's workable for your organization today. I can tell you with absolute certainty that what you're asking for is never going to implemented. But on the dev list we can point you in the right direction if you want to hack something up yourself.

> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

the course of true love never did run smooth ...

-- Shakespeare

[Ron Wheeler]

Eric
This is the kindest and gentlest explanation of the situation and the
best offer that you are going to get.

Ron


On 06/08/2010 8:38 PM, Jason van Zyl wrote:
> The nut of the problem is that if we had to support every optional behavior for a particular subset of the community the code base would likely be unmaintainable. No one here is going to implement anything toward what you're specifically asking for because Maven was specifically designed not to work for what you want. It probably would not be hard to do what you ask for, but just because something is possible doesn't mean it's a good idea to do it.
>
> Generally when people argue along the lines of "well my organization doesn't do that and we can't change" I retort that the community of Maven users is like an organization and it's far more powerful then yours. We don't do that and we're not going to change. So the onus would be on you to take the sources of Maven and alter it for your use and then the cost of maintaining that behavior becomes yours and it's not cheap. It's really not cheap. We can't make everyone happy and that's ok with us, well it's at least ok with me. I guess I can't speak for everyone. There are other build tool options, or you can maintain your own fork of Maven with the behavior your organization desires.
>
> Now what you're asking for here sounds particularly disastrous. If across your organization a release does not actually mean a release in the Maven sense you are going to have so many problems with what plugins normally expect and how artifacts may be integrated across different groups. Trust me, you do not want to go hunting around trying to figure out if something actually changed because looking at an artifact that is supposed to be immutable in Maven but isn't just screams out N points of failure. None of the IDE integration would work properly, many of the CI tools also wouldn't work very well. You're just asking for a world of very expensive pain. Every organization can change. You may not be able to change tomorrow but you can change. I've seen it happen at the biggest of the big.

>
> My suggestion if you are looking at Maven is to start with a smaller project and use Maven the way it's supposed to be used and evaluate if that's workable for your organization today. I can tell you with absolute certainty that what you're asking for is never going to implemented. But on the dev list we can point you in the right direction if you want to hack something up yourself.
>
>> eric
>>

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: Jason van Zyl [mailto:***@sonatype.com]
>
>The nut of the problem is that if we had to support every optional
behavior
>for a particular subset of the community the code base would likely be
>unmaintainable. No one here is going to implement anything toward what
>you're specifically asking for because Maven was specifically designed
not
>to work for what you want. It probably would not be hard to do what you
ask
>for, but just because something is possible doesn't mean it's a good
idea
>to do it.

I understand that including every potential optional feature is not
reasonable, and I'm not expecting that someone immediately go implement
this for me just because I'm asking. However, I was hoping that it
wouldn't get immediately dismissed without apparently considering the
usefulness of it (especially since it seems like sometime similar is
already done for snapshots), and I was hoping to perhaps even get a
pointer of the sort of "we don't have the time to do it, but if you
really want to work on this look at X".
But, oh well, I guess I'll try to figure it out on my own.

>Now what you're asking for here sounds particularly disastrous. If
across
>your organization a release does not actually mean a release in the
Maven

Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO
CHANGE! I just want a way to detect that something has become
inconsistent when someone makes a mistake, and fail the build. If you
think detecting problems is disastrous, well I don't really know what to
say to that.

eric

[Jason van Zyl]

On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote:

>> -----Original Message-----
>> From: Jason van Zyl [mailto:***@sonatype.com]
>>
>> The nut of the problem is that if we had to support every optional
> behavior
>> for a particular subset of the community the code base would likely be
>> unmaintainable. No one here is going to implement anything toward what
>> you're specifically asking for because Maven was specifically designed
> not
>> to work for what you want. It probably would not be hard to do what you
> ask
>> for, but just because something is possible doesn't mean it's a good
> idea
>> to do it.
>
> I understand that including every potential optional feature is not
> reasonable, and I'm not expecting that someone immediately go implement
> this for me just because I'm asking. However, I was hoping that it
> wouldn't get immediately dismissed without apparently considering the
> usefulness of it (especially since it seems like sometime similar is
> already done for snapshots), and I was hoping to perhaps even get a
> pointer of the sort of "we don't have the time to do it, but if you
> really want to work on this look at X".
> But, oh well, I guess I'll try to figure it out on my own.
>
>> Now what you're asking for here sounds particularly disastrous. If
> across
>> your organization a release does not actually mean a release in the
> Maven
>
> Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO
> CHANGE!

I think a few steps down the road, and what you are asking for makes that very possible. I'm just cognizant of the thin end of the wedge, and one small change opens up all sorts of unexpected results.

> I just want a way to detect that something has become
> inconsistent when someone makes a mistake, and fail the build. If you
> think detecting problems is disastrous, well I don't really know what to
> say to that.

That is an erroneous logical extension of what I described. Any movement toward and supporting mutable releases is disastrous. Detecting problems is far to general a category to assign us not caring about.

You could write your own metadata on deploy, and use the enforcer plugin to verify the state as you wish, react accordingly.

>
> eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

To do two things at once is to do neither.

-—Publilius Syrus, Roman slave, first century B.C.

[Ron Wheeler]

On 09/08/2010 1:25 PM, Jason van Zyl wrote:
> On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote:
>
>>> -----Original Message-----
>>> From: Jason van Zyl [mailto:***@sonatype.com]
>>>
>>> The nut of the problem is that if we had to support every optional
>> behavior
>>> for a particular subset of the community the code base would likely be
>>> unmaintainable. No one here is going to implement anything toward what
>>> you're specifically asking for because Maven was specifically designed
>> not
>>> to work for what you want. It probably would not be hard to do what you
>> ask
>>> for, but just because something is possible doesn't mean it's a good
>> idea
>>> to do it.
>> I understand that including every potential optional feature is not
>> reasonable, and I'm not expecting that someone immediately go implement
>> this for me just because I'm asking. However, I was hoping that it
>> wouldn't get immediately dismissed without apparently considering the
>> usefulness of it (especially since it seems like sometime similar is
>> already done for snapshots), and I was hoping to perhaps even get a
>> pointer of the sort of "we don't have the time to do it, but if you
>> really want to work on this look at X".
>> But, oh well, I guess I'll try to figure it out on my own.
>>
>>> Now what you're asking for here sounds particularly disastrous. If
>> across
>>> your organization a release does not actually mean a release in the
>> Maven
>>
>> Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO
>> CHANGE!
> I think a few steps down the road, and what you are asking for makes that very possible. I'm just cognizant of the thin end of the wedge, and one small change opens up all sorts of unexpected results.
>
>> I just want a way to detect that something has become
>> inconsistent when someone makes a mistake, and fail the build. If you
>> think detecting problems is disastrous, well I don't really know what to
>> say to that.
> That is an erroneous logical extension of what I described. Any movement toward and supporting mutable releases is disastrous. Detecting problems is far to general a category to assign us not caring about.
Preventing this problem by not allowing releases to change is better
than detecting them afterwards.

You might also want to consider the approach that we took.
We eliminated 90% of the dependency references in individual POMs by
using aggregating POMs that define the dependency on whole sets of
individual artifacts so that application POMs only refer to a few (5 or
so) aggregations to get 60-70 individual artifacts into the application
jars and wars.

This makes it easy to fix the kind of problem that you encountered since
I only have to fix and rerelease 1 SNAPSHOT to get everyone back on the
same page if we are in the SNAPSHOT phase of a release or fix and update
the minor release of the aggregation if it is released.

If we are actually preparing a release, people do have to be told to
update their dependencies but at least it is easy to find since you only
have 5 to look through and you know you have it because almost every
project POM has it.

I suspect that the kind of error that you hit, would always occur in a
SNAPSHOT phase and never in the release phase of an application since
the error would jump out at you as soon as you tried to use the badly
named artifacts.


> You could write your own metadata on deploy, and use the enforcer plugin to verify the state as you wish, react accordingly.
>
>> eric
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-***@maven.apache.org
>> For additional commands, e-mail: users-***@maven.apache.org
>>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -—Publilius Syrus, Roman slave, first century B.C.
>
>
>
>

[Manfred Moser]

>>-----Original Message-----
>>From: Manfred Moser [mailto:***@mosabuam.com]
>>
>>It seems like we will not agree here. The changes necessary and the
>>additional overhead to make your suggestions work have to much of a
>>negative impact imho. I cant see your feature getting implemented by
>>anybody. Your only option is to implement it yourself and see how you
>>fare. If you do it as a plugin that does the check you want you might
> get
>>traction with other users.
>
> I don't (yet) know much about the internals of maven, but is it really
> that much of an impact on the code? There's already support present for
> checking for differences in snapshot versions, right? I'm imagining
> that making it work for release artifacts would be a matter of not
> distinguishing between release and snapshot artifacts and having the
> check apply to both.
> It sounds like you think it'll be harder to do than that; what I am
> missing?

It might be easy to he do but I have a feeling you will not be liked by
the community. By doing this in your own plugin or forked codebase you
will by merely running it put a large additional strain and the public and
shared infrastructure like maven central and others. You will not get any
good will and might end up getting blocked by central.

I really suggest you drop this idea and adopt a proper process or move to
a different tool.

manfred

[Ron Wheeler]

On 05/08/2010 1:00 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>
>> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>>> -----Original Message-----
>>>> From: Ron Wheeler [mailto:***@artifact-software.com]
>>>>
>>>> On 04/08/2010 6:34 PM, Manfred Moser wrote:
>>>>>> For everyone that says "Released artifacts MUST NOT CHANGE", that
>>> great
>>>>>> if you live in an ideal world, but guess what: some of us actually
>>> have
>>>>>> to live in the *real* world where things don't always follow the
>>>>>> guidelines. It would be nice if maven didn't make it so hard to
>>> deal
>>>>>> with those situations.
>>>>> Sorry.. but in this case I think the cost of accommodating for
>>> behaviours
>>>>> against the known best practice would far outweigh the benefits. I
>>> would
>>>>> not want to see such a feature available even for the pure cost
>>> people
>>>>> then using it. Just adapt your practice.
>>>>>
>>>> +1.
>>>> We are still suffering from a project that allowed released
> artifacts
>>> to
>>>> change without creating a new release.
>>>> Bad practices need to stopped not supported.
>>>>
>>>> Ron
>>> I'm sure I'm not the only person that is very disappointed at the
> lack
>>> of desire to help people get things working. It's one thing to
>>> encourage people to do things the right way, but I think it's stupid
> to
>>> actively put obstacles in the path of people trying to deal with
>>> environments that aren't perfect.
>> If you see a blind man walking into traffic do you help him step off
> the
>> curb?
> Yes, actually I would. At the same time I would mention that it might
> be better for him to use the crosswalk. I certainly wouldn't take away
> his cane so he can't even tell the curb is there until he trips over it.
>
>> You can stop people from changing released artifacts.
>> Get them to use SNAPSHOTs until they really have tested the release
> and
>> got the OK to issue a release.
>> If people are not testing their SNAPSHOTs before releasing them, you
>> need to stop this.
> No, actually you can't. It is absolutely impossible to ensure that a
> release artifact will never change.
> You certainly can (and should) do a lot to discourage that from
> happening, and you can do a lot to make it difficult to cause it to
> happen, but once it does happen you shouldn't continue to make things
> difficult for people to notice that something is wrong and to fix it.
>
>>> Do you really think it's better to not have any way to recover from
> the
>>> case when a project changes release artifacts?
>> The repository manager can delete a release which does allow you to
>> rerelease the save version.
>> When this is done, each programmer has to manually remove the bad
>> version from their local cache to ensure that Maven gets the rereleased
>> artifact.
>> This should only be done once in a blue moon not as part of regular
>> operation.
> And if this happens, maven should tell you about it! I think it would
> be nice it there was an easy way to tell maven to remove the bad version
> from the local cache, but the bare minimum it should do is spit out an
> error like:
> [ERROR] release artifact com.example:foo in the local cache does not
> match repository version (http://central/com/example/foo)
> [ERROR] to use the repository version, remove the files at
> ~/.m2/repository/com/example/foo
>
No way! I do not want that kind of traffic going through my repo and
network.
Checking SNAPSHOTs is enough of a load. Checking almost 100 released
artifacts to do a build would bring things to a halt.
Is the user has release 2.1.2 in his local cache and his build calls for
release 2.1.2, that is it. Use it, don't be wandering over the internet
to my repo site "just checking" to see if someone screwed with 2.1.2.
If you have to fix 2.1.2 then issue a 2.1.2.1 if you can not stand 2.1.3.

>>> As you say, you're still
>>> suffering from it. Perhaps that's exactly because maven doesn't
> provide
>>> you the tools to effectively deal with it!
>> I am suffering because it is hard to tell which release 2.1.3 is the
>> "good" version with the patches.
> So why wouldn't you want to know that there are two different copies of
> that release? I don't understand why there is such resistance to
> providing the tools to effectively deal with problematic situations.
>
>>> IMO, maven should, at the very least, be able to indicate an error
> when
>>> things are inconsistent, even for release artifacts. The current
>>> behaviour, where you have absolutely NO CLUE what's going on if an
>>> artifact changes, leads to huge amounts of confusion.
>> That is not a Maven problem it is a people problem.
>> That is why you don't let artifacts change.
> I don't know what world you live in, but in mine I don't have absolute
> control over everything.
I do.
You need to bring this problem to the attention of someone who does have
control and make sure that they understand the problem caused by not
QCing releases and expecting to rerelease until they have it right.

You can tell him/her that it is a Maven "problem" but don't quote anyone
here as regarding that as a problem.
You can also describe in detail, by now, the difficulty and chaos that
rereleaseing causes in terms or repeatable builds, network traffic,
difficulty in knowing what you have built, customer confidence in your
QC procedures, etc.


> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@maven.apache.org
> For additional commands, e-mail: users-***@maven.apache.org
>
>