exactly. by that way, not only simplify pom. Also for one maven build, could identify project dependency hierarchy easier.
base on that, could do further things: 1. to ensure whether could parallel build for module projects. 2. provide analysis report for developers to show their dependency hierarchy to help them improve their structure. ... Regards Simon 2014-06-12 21:02 GMT+08:00 Arnaud Héritier <[email protected]>: > > 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 <[email protected]> > 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 <[email protected]>: > > > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <[email protected] > > > > > > > > > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier >
