Jukka Zitting wrote: > Hi, > > On Sun, Sep 20, 2009 at 10:19 PM, Marshall Schor <m...@schor.com> wrote: > >> After thinking about this for a while, and considering both methods, I >> think the most reliable way to handle 3rd party Jars is to manually put >> them into the lib/ directory, once, and then check the lib/ directory >> into SVN. This avoids build issues in the future which could occur if >> the Jar obtained from the maven dependency plugin is somehow corrupted, >> or changes level, etc. Also, having the Jars in SVN insures that >> whatever work we do to update the LICENSE/NOTICE files for those Jars >> remains valid (because the Jar doesn't (potentially) change). >> > > By policy non-SNAPSHOT artifact in the Maven repository never change, > and each artifact is accompanied by checksums that guard against > corruption. It's possible for a user to mess up the files in their > local Maven repository, but it's probably just as likely that they'd > mess up any files in ./lib. > > To me the proposed solution sounds like extra effort with little or no > benefit. > Interesting. Is there any *enforcement* of the policy of not updating non-SNAPSHOT artifacts (with their checksums)? For instance, if someone (say, a non-apache project, by accident) runs a maven script to deploy a changed artifact (and its checksum) to maven central, would that be blocked somehow?
It also seems that if there is this policy, that the default for the maven repository control for *releases* would have an <updatePolicy>never</updatePolicy> in the maven SuperPom (relying on the policy that the repository artifact is never updated), but it isn't there. There is an <updatePolicy>never</updatePolicy> in the SuperPom for its own plugin-repository, though. -Marshall > BR, > > Jukka Zitting > > >
