On 05/08/2010 1:00 PM, Haszlakiewicz, Eric wrote:
-----Original Message-----
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]

  On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote:
-----Original Message-----
From: Ron Wheeler [mailto:rwhee...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to