maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Héritier <aherit...@gmail.com>
Subject Re: Model Version 5.0.0
Date Thu, 12 Jun 2014 13:02:48 GMT
http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:project_dependencies
???
The idea behind it may be that by default we can declare in a
multi-projects build some dependencies without groupId and version. In that
case they are using automatically the module groupId and and version asking
for the dep (2 lines less in your pom for each dep like this).



On Thu, Jun 12, 2014 at 8:21 AM, Hervé BOUTEMY <herve.boutemy@free.fr>
wrote:

> any reference to what you call "project dependency"?
> how is it different from a classic dependency? a dependency in a reactor?
>
> Regards,
>
> Hervé
>
> Le mercredi 11 juin 2014 17:18:05 Simon Wang a écrit :
> > Since we're thinking about model-5.0.
> >
> > Is it possible to support project dependency in 5.0?
> > Project dependency could benefit users a lot.
> > They needn't care about whether others dependent projects(might changed)
> > are installed or not.
> > And users needn't always run maven build with parent pom.
> >
> > Regards
> > Simon
> >
> > 2014-03-25 18:41 GMT+08:00 Nigel Magnay <nigel.magnay@gmail.com>:
> > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bmathus@batmat.net>
> > >
> > > wrote:
> > > > FWIW, I'm aware it's easily feasible to add that checksum validation
> in
> > > > a
> > > > plugin, but you'll still have to repeat the coordinates.
> > > > And that very thing was my point: I don't think having to repeat
> those
> > > > coordinates to add metadata is great.
> > > >
> > > > Not even saying this *must* go in modelVersion 5, I just wanted that
> > >
> > > debate
> > >
> > > > to happen at least for future reference if people wonder why maven
> pom
> > > > can't store that dependency metadata (DRY'ly alongside its data, I
> > > > mean).
> > >
> > > There's all sorts of other per-dependency information that would be
> > > useful, for example - flex applications needing to store RSL deployment
> > > paths and policy file urls.
> > >
> > > The 'maven way' seems to be sentenced to perennially repeat yourself,
> and
> > > live with the fact your plugin config and your dependency list can
> drift
> > > out of sync. Or to suffer some kind of excuse of 'just specify the
> > > dependencies you want to apply this metadata to with some kind of
> regular
> > > expression (!)'.
> > >
> > > XML even has a well-understood extension mechanism for this kind of
> thing.
> > >
> > >
> > > ...
> > > <dependency security:sha1="1234567890abcdef" >
> > >
> > >   <groupId>com.woo</groupId>
> > >   <artifactId>yay</artifactId>
> > >   <version>1.0</version>
> > >   <flex:rslInfo>
> > >
> > >       <flex:deployment-path>/blah/blah</flex:deployment-path>
> > >       <flex:policy-file>/woo/policy.xml</flex:policy-file>
> > >
> > >   </flex:rslInfo>
> > >
> > > </dependency>
> > >
> > > ....
> > > <plugins>
> > >
> > >   <plugin>
> > >
> > >      /// some plugin that enforces security:sha1
> > >
> > > .... etc etc etc
> > >
> > >
> > >
> > > If your tooling doesn't understand namespaced nodes, it's trivial to
> strip
> > > them.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message