I believe this is also a valid complaint/problem, and I know this is something the Maven dev team is working on for future Maven versions, perhaps even 2.1, by including md5 for the poms themselves and checking for changes to both the poms and the jars. So I think everyone agrees with you in principle.
In the meantime, this problem can easily be solved by "blowing away" your local m2 repo periodically and allowing artifacts to be re-downloaded from scratch. Not an ideal solution, but it is effective, and relatively simply to accomplish. The trouble with requiring a bump in the version number to reflect a change in the pom should be obvious -- for 99% of the artifacts in the Maven repo, the Maven team has no control over the project itself, they are merely publishing the pom and Maven bundles for our use. Thus, the Maven project cannot simply bump a project from 1.2.5 to 1.2.6 simply because a bad pom exists in the repo. Wayne On 5/19/06, Orjan Austvold <[EMAIL PROTECTED]> wrote:
During the last 8-10 months we have experienced several updates in already released artifacts in the maven repository at Ibiblio. Many of these has been caused by reports to Maven evangelism. For us this has been extremely problematic since the time of download of dependencies causes developers to have different POMs in their local repository. For us this has caused our projects to produce different builds dependent on which developer made the build and at which time the build was made. Personally I strongly believe in once an artifact has been released -- with or without errors in the artifacts POM -- it should be left in the state it's in. If a change is required due to a malformed POM, a missing groupId, non-existing parent, missing dependency, wrong scope of a dependency or the alike, it should be left in the state it is in. If an update is required a new version should be released. Due to the instability of released artifacts at Ibiblio we are now considering setting up our own repository (not a mirror and not a maven-proxy repository) to gain complete control over changes in released POMs. Of course this is not the intention of Maven 2. Please comment. Thanks, Ørjan Austvold --------------------------------------------------------------------- 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]
