You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Simon Wang <wa...@gmail.com> on 2014/06/11 11:18:05 UTC
Re: Model Version 5.0.0
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 <ni...@gmail.com>:
> On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@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.
>
Re: Model Version 5.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 13 juin 2014 10:51:35 Simon Wang a écrit :
> 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.
> ...
we already have that without such feature: plugins can easily know what is in
the reactor
from what I understand, it will just simplify poms a little bit: ok, why not
and since old maven version cannot understand a pom without missing info, this
will require the 5.0.0 POM, even if no new element was added
Regards,
Hervé
>
> Regards
> Simon
>
> 2014-06-12 21:02 GMT+08:00 Arnaud Héritier <ah...@gmail.com>:
> > http://www.gradle.org/docs/current/userguide/dependency_management.html#su
> > b: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 <he...@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 <ni...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Model Version 5.0.0
Posted by Paul Benedict <pb...@apache.org>.
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 <wa...@gmail.com> 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 <ah...@gmail.com>:
>
> >
> >
> 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 <he...@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 <ni...@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
> >
>
Re: Model Version 5.0.0
Posted by Simon Wang <wa...@gmail.com>.
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 <ah...@gmail.com>:
>
> 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 <he...@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 <ni...@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
>
Re: Model Version 5.0.0
Posted by Arnaud Héritier <ah...@gmail.com>.
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 <he...@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 <ni...@gmail.com>:
> > > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@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
Re: Model Version 5.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <ni...@gmail.com>:
> > On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus <bm...@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