Hi Brett,
I want to take opportunity to talk with you and discuss more than this case.
Firstly, from my point of view flag optional is named unhappily.
Better name would be transitive/nontransitive with the default value
true/false .
BTW look at : http://jira.codehaus.org/browse/MNG-1205 (bug is more
general, for example compile scope is affected too)
I would prefer the way of properties, it could be implemented quickly
and without impact to the current implementation.
Currently we have got 2 use cases: AOP plugin and APT plugin.
BTW look at: http://jira.codehaus.org/browse/MNG-1197 (APT plugin
prototype).
1) APT plugin
APT has factorypath classpatth ( -factorypath switch), where we have
mentioned all annotation factories (jars). Of course usage of this
classpath is not mandatory, but can increase significantly performance
and many developers prefer to use it. If we introduce a new property to
the Artifact (for example properties), we will able to divide the
compile-classpath to the parts, and use them in the apropriate manner.
Example:
let f-1.0.jar - contains factories (we don't need transitive
propagation, so dependency scope is "provided"), and s1-1.0.jar ....
sn-1.0.jar contains other classes (we need transitive prapagation).
<dependencies>
<dependency>
<groupId>x</groupId>
<artifactId>f</artifactId>
<version>1.0</version>
<scope>provided</scope>
<properties><property>factory</property></properties>
</dependency>
<dependency>
<groupId>x</groupId>
<artifactId>s1</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
...
</dependencies>
dependency " f-1.0.jar" - will be interpreted as part of -factorypath ....
Remark:
The propagation of properties to the poms in repositories is not necessary.
2) AOP plugin (AspectJ or JBoss AOP)
Situation here is fairly similar to previous use case.
When weaving classes with AspectJ we need two different classpaths - one
where aspects are contained and the one where classes that should be
weaved are. Defining classes that should be weaved is easy, these are
simple the ones contained in the project we are building. But we need to
specify where to look for aspects (otherwise it would be necessary to
search among all classes in all dependencies, this brings performance
issue).
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
AspectJ can be use instead of standard javac compiler. Main problem we
see is that current compiler API is too rigid.
See plexus implementation of aspectJ compiler. There is lot of
properties that can't be set from the standard compiler plugin from
maven, is it not?.
Do you know any solution, how to incorporate new compilers effectively,
or is it necessary to do something similar as csharp compiler in sandbox?
best regards
JuBu
Brett Porter wrote:
We hadn't planned to overload scope like this, and for similar reasons
to not adding properties - they don't hold up under transitivity because
it requires that the dependency knows something about the final project,
which is impossible.
The scope provides a sensible default for most operations (by separating
into the 3 groups), and from there we apply filters to modify that as
necessary which can be part of the plugin configuration.
Do you have a use case for selection of particular dependencies that
doesn't match any of the scopes?
Cheers,
Brett
Juraj Burian wrote:
Rafal Krzewski wrote:
Juraj Burian wrote:
We are working on jboss-aop & APT plugins implementation.
We encountered the folowing problem (in general):
We need to split classpath into several parts. In other words, we
need to group dependencies.
For example, when running JBoss AOP it is necessary to supply
classpath where aspects are found and a different classpath where
classes that should be weaved are (ie. 2 different classpath).
It occured to me that M2 has already a notion of dependency grouping
and separate classpaths, determined by "dependency scope" there is
"compile" scope and "test" scope. Maybe you need to define additional
scopes, like compile-aspectpath, compile-inpath (or -weavepath),
test-aspectpath and so on? And how would these relate to dependency
inheritance (transitiveness)?
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Right, it's possible solution, but every new plugin will need a new
scope definition => lot of related changes in maven "core".
Dependency "transitivity" (bug is there) is managed via <optional>
flag (only scope:provided is by default not transitive), but in
general it depends on purpose of the given classpath.
JuBu
---------------------------------------------------------------------
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]
