The root of the issue, it seems, is in MavenMetadataSource.java -
there is a method that is called there when it is resolving
dependencies to get the effective dependency scope.
private static String getEffectiveScope( String originalScope,
String inheritedScope )
{
String effectiveScope = Artifact.SCOPE_RUNTIME;
if ( originalScope == null )
{
originalScope = Artifact.SCOPE_COMPILE;
}
if ( inheritedScope == null )
{
// direct dependency retains its scope
effectiveScope = originalScope;
}
else if ( Artifact.SCOPE_TEST.equals( originalScope ) ||
Artifact.SCOPE_PROVIDED.equals( originalScope ) )
{
// test and provided are not transitive, so exclude them
effectiveScope = null;
}
.... (a bunch of maven specific ommitted) ...
return effectiveScope;
}
The first pass through - an RSL-scoped object has a null inheritance
scope so it just keeps its original scope. On the second pass through,
the inherited scope is "rsl" but original scope is something like
"compile" (or whatever was set in the thing you are included as an
RSL... could be test scope, etc) - so when it comes in to this method
it forces it to be in scope runtime.
The MavenMetadataSource is annotated as @Component( role =
ArtifactMetadataSource.class, hint = "maven" ) - is there a way to
specify that you want to create your own custom one?
We can submit a patch to maven to make it pass on the inherited scope
if the inherited scope doesn't match any of the originals at the end
of the chain. This will allow for users to create some really screwed
up scenarios - for instance if you have a <scope>theme</scope>
artifact that defines a bunch of <scope>compile</scope> artifacts (who
knows why?) those would then be transitively included as theme scoped
artifacts - which would probably confuse the compiler and have strange
results.
The best solution I can think of would be if MavenMetadataSource was
open for extension in this one area - if the method was protected
instead of private and we could make a subclass of
MavenProtectedMetadataSource that only overrode that one method, and
then had maven use our replacement MavenMetadataSource - we'd be
golden.
I'm not familiar with plexus. If we get Maven to agree to change that
private method to protected and we do make our own subclass - is there
a way to get plexus to use our MavenMetadataResolver when flexmojos is
running?
The other benefit (if we can get this kind of approach working) is
that we can decide on a better behavior for how transitive
dependencies of the custom scopes are handled. For instance, if we
decide that an RSL's compile-time dependencies should be inherited as
compile-time dependencies and not as RSL's - it's quite simple to
implement that in a user-configurable way and then have our
getEffectiveScope method be in charge of deciding that.
So I guess the first question is about plexus - can we force plexus to
use our MavenMetadataSource in place of the default one that is
annotated as:
@Component( role = ArtifactMetadataSource.class, hint = "maven" )
If we can, I can test my theory about how well a replacement one would
work and solve our transitive dependency issues by doing a
quick-and-dirty copy-and-paste job and making a clone of the existing
class but with a "getEffectiveScope" method that is specifically
tailored to handling the flexmojos scopes.
I'm very confident that this should work, and in my opinion this would
not be "hacking maven" at all (assuming we can get them to agree to
make that method open for extension). It seems very logical that if we
want to use custom scopes we should also expect to tell maven how
these custom scopes should come into play for dependency resolution...
and writing a 40-line method that does it seems like a really simple
solution.
(of coures, if plexus doesn't let us swap out maven's implementation
for our own, we'll have to figure something else out which will likely
require maven to make that one method replaceable by plugins like
flexmojos that want to use custom scopes)
--
You received this message because you are subscribed to the Google
Groups "Flex Mojos" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/flex-mojos
http://flexmojos.sonatype.org/
