First ping maven-dev.... check if they wanna or accept patch that, file a jira http://jira.codehaus.org/browse/MNG
I think they will accept, so far maven allows custom scopes.... that said, it is invalid to assume a custom scope is equal to runtime.... but again, maven team decision, AFIK, they don't wanna custom scopes any longer. Plexus does allow to completely replace @Component( role = ArtifactMetadataSource.class, hint = "maven" ) I believe guice would allow that also, but not sure if that is wise, I would really prefer to see a maven fix for this. Maven is producing unreliable results.... custom scopes are bad, ok, I know that.... but flexmojos has no choice and that is no reason to maven dependency just twist my wrong scope into something else less wrong =D Imagine a folk wrote compiile (double i) by mistake.... I can accept maven breaking the build and not allowing you to proceed, but assuming compiile is the same as runtime, this is really bad. I have another idea to fix that, but man, I'm not really on the mood to implement it.... it would allow flexmojos do describe custom scopes.... how deep do you wanna go? =D VELO On Thu, Dec 2, 2010 at 4:52 PM, Ryan Gardner <[email protected]> wrote: > 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]<flex-mojos%[email protected]> > For more options, visit this group at > http://groups.google.com/group/flex-mojos > > http://flexmojos.sonatype.org/ > -- 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/
