Brett Porter wrote:
On 5/15/05, Gilles Dodinet <[EMAIL PROTECTED]> wrote:
previous plugin version only used the following dependency property
(similar to the war.bundle property), as well as a couple of properties
defined in project.properties (but those will go under the plugin config
section)
Yuo hit the nail on the head earlier, that transitive dependencies made the properties problematic.
<properties>
<eclipse.plugin.bundle>true</eclipse.plugin.bundle>
</properties>
I think the default bundling is ok, and then something like: <configuration> <excludedDependencies> <excludedDependency>groupId:artifactId</excludedDependency> ... </excludedDependencies> </configuration>
We could add some tools to help filter an artifact list by a list of "groupId:artifactId" strings.
however im rewriting it (targeting both m1 and m2) and there's now are several
other dependency properties like <maven.pde.export/> which indicates if a
dependency should be marked as exported in the plugin descriptor; or
<maven.pde.targetPath/> which is used to override the default library output folder
on a per-dependency basis.
Some of this is getting quite complicated to define in the above way, and if you look at the Geronimo Maven1 POM's you'll see that listing it on the dependencies starts to get quite confusing also. It's hard to get a single view of what sets these properties define.
The alternative I took with the assembly plugin was to build a separate descriptor. It may be worth doing this for some plugins.
I'd keep pushing that the defaults for a plugin should cover as many
use cases as possible so the amount of configuration needed is
minimal.
indeed, and if using the defaults, no configuration should be needed at all here. also in this case, using another descriptor doesn't seem to be the way to go as it would be pretty odd : one of the primary goal is indeed to generate/update a pde plugin descriptor.
last, while the dependency filtering may be a nice addition, i think there's still a visibility issue here and in some way, doesn't it invalidate the transitivity feature since it would require the user to have an almost complete view on the underlying dependencies ?
regards,
-- gd
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
