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.
>

Reply via email to