In this case, the information should not go on every dependency, but
in the POM of the project so that it is only ever specified once, so
its not really a dependency properties issue.
As for that old chestnut, it's not a matter of "go jump in the lake",
but more "the solution's on the other side, here's a paddle".
Specifying the dependencies in the plugin configuration should be less
than or equal to the verbosity of putting it in properties. For
example:
<dependency>
group / artifact / version
<properties>
<rpm.bundle>...</rpm.bundle>
</properties>
</dependency>
vs
<dependency>
g /a /v
</dependency>
....
<configuration>
<bundledDependencies>
<bundledDependency>group:artifactId</bundledDependency>
</bundledDependencies>
</configuration>
...
The saving grows as you add dependencies, and the standard method is
to pick a standard set, and only include/exclude on top of that,
reducing the number necessary to give even further.
I'll more than happily add dependency properties the day someone can
show a case where
a) the above doesn't work
b) their alternate solution works for transitive dependencies brought in.
:)
I may well be missing something, but I don't remember any cases where
this has been shown yet.
Cheers,
Brett
On 4/14/06, Allison, Bob <[EMAIL PROTECTED]> wrote:
> It has been requested in several forms. I posted a JIRA (MNG-1732) that
> had a means to provide this kind of information. It was intended to
> solve two problems:
> -- Packaging of WAR dependencies in an EAR (putting the dependency in
> the EAR's package instead of the WAR) without requiring that the
> dependency be listed in the EAR
> -- Providing a means for extra information about a dependency for use
> inside plugins (in my case, it was the location to install the jar in
> the RPM)
>
> The answer I basically got was "go jump in a lake". Well, Brett was
> more polite than that. The gist of the argument, as I recall, was that
> the devs got rid of attaching properties to dependencies because they
> caused problems. The RPM plugin has been stalled because I have been
> trying to come up with a way to collect the packaging information for
> dependencies without the user needing to define the whole
> <dependency>...</dependency> information twice (once for Maven, once in
> the plugin configuration to define packaging).
>
> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 13, 2006 19:29
> To: Maven Users List
> Subject: Re: mvn2, dependincies, javadoc plugin and links...
>
>
> This feature has certainly been requested (should be in jira
> somewhere), but is not currently implemented.
>
> - Brett
>
> On 4/14/06, Jules Gosnell <[EMAIL PROTECTED]> wrote:
> > I was thinking...
> >
> > My pom.xml has a load of explicit <dependencies> which are used to
> form
> > the classpath.
> > My javadoc-plugin clause has a load of <links> which correspond to the
> > same dependencies.
> >
> > How about having e.g. a javadoc-url sub-elt in each dependency that
> the
> > javadoc-plugin could read and automatically (if e.g.
> > automagic-linking=true) . This would ensure that deps and links were
> > consistant with each other and would probably result in much better
> > javadoc linkage...
> >
> > Of course, this may have already been done - if so, what is the syntax
> ?
> >
> > Thanks for your time,
> >
> > Jules
> >
> > --
> > "Open Source is a self-assembling organism. You dangle a piece of
> > string into a super-saturated solution and a whole operating-system
> > crystallises out around it."
> >
> > /**********************************
> > * Jules Gosnell
> > * Partner
> > * Core Developers Network (Europe)
> > *
> > * www.coredevelopers.net
> > *
> > * Open Source Training & Support.
> > **********************************/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
