So I'm seeing two different solutions here that seem to address things a bit differently.
1) hashing to double check whether something has changed This has actually been suggested in the context of the JAR - so perhaps the hash to use is that of the dependency artifact and it's pom combined. It can be written in as an element at release time, and used to either warn or fail a build if it is no longer consistent. 2) revision the POMs to allow them to change. It hasn't been nailed down but the last time I thought about this, it would be along the lines of a new element in the <dependency> declaration (<revision/>). If absent, you'd get the latest revision (so you would pick up changes along the way if they occurred). At release the release plugin (or yourself) could lock in the <revision> element to ensure that reproducibility occurs. While this would facilitate making changes, they should still be heavily discouraged. While I'd like to just lock it down, the fact that very popular POMs (spring, hibernate) have needed significant and sometimes frequent fixes has made this impossible. However, other improvements should come hand in hand to make it less of an issue: - repository manager improvements to better validate incoming POMs - dependency management improvements to cover the use cases why they are changed - changes to static vs dynamic metadata (this is another use case for the revisions above - eg, when you move your SVN but want to build an old release where the POM points to the old location - if that metadata is migrated then the revisions might not be necessary) What do others think of this? Cheers, Brett On 19/05/06, Daniel Kulp <[EMAIL PROTECTED]> wrote:
The hash thing ONLY works for a limited set of changes to a pom.xml. For example, in the past there have been changes that affect dependencies like changing scopes from runtime to provided or similar. I've also seen changes to poms that change groupIds of dependencies (that were also moved in the repository). Many of those changes would (and did) cause build breakages even if the md5 hash thing was done. Until they REALLY do limit the changes to those that are COMPLETELY safe, we're all at risk. Then the question DOES arise: how WOULD they make changes like dependency changes, etc..? Dan On Friday 19 May 2006 18:56, Wayne Fay wrote: > -Or- like I said in my previous email (and unless I'm mistaken, what I > believe the Maven team is planning on implementing), they should add > hashing of the pom itself and check that file in addition to the > binary jar when looking for and downloading updates. > > This is also a reasonable fix to the solution, imo. Especially > considering the "difficulty" related to matching poms with a certain > version tag to binaries with another version tag (ie 1.4.2-rc1 and > -rc2 vs 1.4.2, etc). > > Wayne > > On 5/19/06, Orjan Austvold <[EMAIL PROTECTED]> wrote: > > Daniel Kulp wrote: > > > Right. But if an error is detected in a pom, why does the pom have > > > to be updated. For example, if there is a: > > > > > > foo/1.0/foo-1.0.pom > > > > > > why can't we do something like Gentoo Linux and leave that alone > > > and then add a: > > > foo/1.0-R2/foo-1.0-R2.pom > > > > > > It's stilll "foo 1.0 as release by the foo developers", but its the > > > R2 "update" as far as the maven repository is concerned. If the > > > foo developers produce a 1.0.1, fine. We create a: > > > foo/1.0.1/foo-1.0.1.pom > > > > > > Thus, existing apps and such that depend on the broken behavior are > > > OK and others can migrate to the "correct" poms as needed. > > > > > > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a > > > release, correct or broken, should stay that way. > > > > Right on, Daniel! Introduction of non-maven artifacts could adopt the > > scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released > > in which versions numbers could document a change made by "Maven" > > number X. Every change in a fixed release of the artifact (POM or > > whatever) would increase the X. > > > > A release to the repository has to be write-once. If this is not > > true, then Maven has to come with a footnote telling everybody to > > delete their local repository if a build goes astray. > > > > > > Ørjan > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Apache Maven - http://maven.apache.org "Better Builds with Maven" book - http://library.mergere.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
