I guess if you manage to lose your repo, there could be either a special switch to disable it, or maybe better, being able to fix selectively those exceptions in *your* pom like you currently do for versions of a transitively retrieved artifact.
> Why I'd say because you'd like to prevent some kind or AIDM attack (Artifact In The Middle ;-)), which you're currently unable to detect if the upstream repo has been hacked? Not saying this is something that *must* be there in M4 or so, but I guess this would be cool for Maven to be able to support that kind of use-case. I'm not paranoid myself, but I guess there's a lot of companies that would like this feature (when you see how much Sonatype invested in security/blabla detection for nexus, I guess that's because it's somehow been asked by some customers. Note I don't count myself in them.). But maybe this isn't something that should go in the <dependency> block, but in a dedicated plugin. The thing is, you then fall back again on the problem of DRY having to somehow repeat GAV coordinates somewhere to describe that additional metadata. Anyway, I find it at least interesting to have that debate. 2014-03-24 12:23 GMT+01:00 Stephen Connolly <[email protected] >: > Why? Sounds like just one more thing that could go wrong, plus if you lost > your repo and are rebuilding all from source because the timestamps will > differ, so the .zip checksums will differ too > > On Monday, 24 March 2014, Baptiste Mathus <[email protected]> wrote: > > > 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 <[email protected] > <javascript:;> > > >: > > > > > 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 < > > > [email protected] <javascript:;>>: > > > > > > > > > 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 <[email protected] > <javascript:;> > > > > > >> 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 > > >>>> <[email protected] <javascript:;>> 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: [email protected]<javascript:;> > > > For additional commands, e-mail: [email protected] > <javascript:;> > > > > > > > > > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > > > -- > Sent from my phone > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! nbsp;! >
