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: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 > >>> 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-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
