Is there any value in letting the 5.0.0 be like HTML in that new elements may continuously introduced but older clients must allow "graceful degradation"?
Cheers, Paul On Thu, Jun 12, 2014 at 9:51 PM, Simon Wang <[email protected]> wrote: > 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 > > >
