Hello, it is not yet finished, and I am not sure if it actually would work for most scenarios. But I was starting a plugin which allows to maintain and create a "checksum lock file" for dependencies.
The basic idea is, that when I distribute a released maven project (source) via for example Git, I want to enable the builders to check if they are actually using the same dependencies than I was locking. https://github.com/ecki/lockdep-maven-plugin This is somewhat inspired by this: https://github.com/nicoulaj/checksum-maven-plugin The idea is especially to catch overwritten repository releases and rough proxies. With the extra lock file it should be easier to adopt to new versions. Greetings Bernd Am Mon, 24 Mar 2014 11:19:30 +0100 schrieb Baptiste Mathus <bmat...@batmat.net>: > Hi, > > Sorry if it's the wrong thread, just let me know. > > I thought I'd dump that thought I've had for some time here: was > enriching a bit the <dependency> block already discussed? > > So that one can somehow express a <checksum> tag. I'm posting this > here since this would also require a pom upgrade. > I've re-read the recent threads but didn't find anything about it. > Also crawled JIRA without luck (though I guess this has already been > reported somewhere). > > Something like > > *<dependency>* > * <groupId>...* > * <artifactId>...* > * <version>...* > * <checksum>sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62</checksum>* > *</dependency>* > > WDYT? > > Cheers > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte <rfscho...@apache.org>: > > > Hi, > > > > I think this is good start and I would expect that the planned > > consumer pom.xml would still validate against the model 4.0.0 xsd, > > since now it is the standard file being uploaded and used by a lot > > of build management tools. > > If there are some flaws in the current XML, this could be the right > > moment to design a new consumer specific XML, maybe together with > > the Aether team for example. > > > > Robert > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > stephen.alan.conno...@gmail.com>: > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. > > What we/I > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > >> inheritance interpolated and properties resolved > >> > >> On Tuesday, 25 February 2014, Jörg Hohwiller <jo...@j-hohwiller.de> > >> wrote: > >> > >> Hi there, > >>> > >>> just for the record to this thread: > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > >>> The plugin allows to generate a consumer POM and apply it to the > >>> current MavenProject (via setFile). > >>> So we can already test various impacts of what can, will and > >>> should happen > >>> when a "consumer POM" is installed, signed, deployed instead of > >>> the original pom.xml file that can later on be in future model > >>> formats. > >>> > >>> See thread on dev mojo with subject "consumer-maven-plugin added > >>> to sandbox". > >>> Hope to hear from you. > >>> > >>> Kind regards > >>> Jörg > >>> > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > >>> > >>> On 25 November 2013 03:28, Stephen Connolly > >>>> <stephen.alan.conno...@gmail.com> wrote: > >>>> [del] > >>>> > >>>> Given that we have decided that the reporting stuff possibly > >>>> was a > >>>>> mistake... Well let's drop that > >>>>> > >>>>> Given that profiles do not make sense in deployed poms... Drop > >>>>> them too > >>>>> > >>>>> We think <repositories> is evil... Let's drop that... We've > >>>>> dropped build > >>>>> and reporting=> no need for pluginRepositories at all so. > >>>>> > >>>>> I'm in favour of cleaning out elements that cause problems > >>>>> when they > >>>> are tweaked in a the non-Maven Way. > >>>> The emails to the users list would be reduce and there is less > >>>> chance of causing confusion. > >>>> > >>>> Applying the "current" best practises and baking them into the > >>>> poms is a good thing. > >>>> > >>>> > >>>> > >>> > >>> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
