You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Arnaud Héritier <ah...@gmail.com> on 2010/08/02 09:48:06 UTC
Re: force maven to redownload/refresh "released" dependencies
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 05/08/2010 1:00 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>>
>> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>>> -----Original Message-----
>>>> From: Ron Wheeler [mailto:rwheeler@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Kathryn Huxtable <ka...@kathrynhuxtable.org>.
On Aug 6, 2010, at 12:57 PM, Kalle Korhonen wrote:
> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
> <EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Manfred Moser <ma...@mosabuam.com>.
> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
> <EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Ron Wheeler [mailto:rwheeler@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
> On
>> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
>> <EH...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
On
>On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
><EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Kathryn Huxtable <ka...@kathrynhuxtable.org>.
On Aug 6, 2010, at 2:58 PM, Paul Benedict wrote:
> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
> <EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Paul Benedict <pb...@apache.org>.
On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
<EH...@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
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:jason@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@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.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Jason van Zyl <ja...@sonatype.com>.
On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jason@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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.
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Jason van Zyl [mailto:jason@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Jason van Zyl <ja...@sonatype.com>.
On Aug 6, 2010, at 3:53 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Kathryn Huxtable [mailto:kathryn@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Kathryn Huxtable [mailto:kathryn@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Kathryn Huxtable <ka...@kathrynhuxtable.org>.
On Aug 6, 2010, at 1:00 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Kalle Korhonen [mailto:kalle.o.korhonen@gmail.com]
>>
>> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
>> <EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Kalle Korhonen <ka...@gmail.com>.
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
<EH...@transunion.com> wrote:
>>-----Original Message-----
>>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
> On
>>
>>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
>><EH...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by Martin Gainty <mg...@hotmail.com>.
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: kathryn@kathrynhuxtable.org
> Date: Fri, 6 Aug 2010 18:28:32 -0500
> To: users@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:rwheeler@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: force maven to redownload/refresh "released" dependencies
Posted by Kathryn Huxtable <ka...@kathrynhuxtable.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:rwheeler@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Ron Wheeler [mailto:rwheeler@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Ron Wheeler [mailto:rwheeler@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/08/2010 4:01 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
> On
>> On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
>> <EH...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Eduardo M KALINOWSKI [mailto:eduardo@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by Eduardo M KALINOWSKI <ed...@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.
--
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
eduardo@kalinowski.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
On
>
>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
><EH...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Paul Benedict <pb...@apache.org>.
On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
<EH...@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
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Kalle Korhonen [mailto:kalle.o.korhonen@gmail.com]
>
>On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
><EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric
<EH...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by Manfred Moser <ma...@mosabuam.com>.
>>-----Original Message-----
>>From: Manfred Moser [mailto:manfred@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Manfred Moser [mailto:manfred@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
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<wa...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Wayne Fay [mailto:waynefay@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Wayne Fay <wa...@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!
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Justin Edelson <ju...@gmail.com>.
On Aug 8, 2010, at 5:32 AM, Baptiste MATHUS <ml...@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 <wa...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Baptiste MATHUS <ml...@batmat.net>.
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 <wa...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: force maven to redownload/refresh "released" dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:rwheeler@artifact-software.com]
>>>
>>> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>>>> -----Original Message-----
>>>>> From: Ron Wheeler [mailto:rwheeler@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by Manfred Moser <ma...@mosabuam.com>.
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:rwheeler@artifact-software.com]
>>
>> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>>> -----Original Message-----
>>>> From: Ron Wheeler [mailto:rwheeler@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>
> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>>> -----Original Message-----
>>> From: Ron Wheeler [mailto:rwheeler@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: Ron Wheeler [mailto:rwheeler@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: Ron Wheeler [mailto:rwheeler@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by Ron Wheeler <rw...@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
1.
> manfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: force maven to redownload/refresh "released" dependencies
Posted by Manfred Moser <ma...@mosabuam.com>.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: a.geo [mailto:aquiles.geo@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Posted by "a.geo" <aq...@gmail.com>.
mvn package -U
maybe?
the -U parameter tell to maven to refresh all dependencies required by the
artifact
2010/8/2 Arnaud Héritier <ah...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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