>-----Original Message----- >From: Ron Wheeler [mailto:[email protected]] > > On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote: >>> -----Original Message----- >>> From: Ron Wheeler [mailto:[email protected]] >>> >>> 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: [email protected] For additional commands, e-mail: [email protected]
