What's your other idea on implementing the custom scopes? I'm not sure how to get maven to use a replacement component for the:
@Component( role = ArtifactMetadataSource.class, hint = "maven" ) I just tried making a copy of the MavenMetadataSource and putting it in the flexmojos-maven-plugin but changing the method we care about and then running the plugin to see if it would use that version. That didn't work. Next, I read up on the classloaders here http://maven.apache.org/guides/mini/guide-maven-classloading.html and figured I'd try to make an extension and load in the core classpath - so I made a new pom and put the custom version over there and then added it to my <build><extensions> settings but it still loads the default one and not the customized version that I made. I tried changing the hint = "maven" to hint="default" just in case that might help, but that didn't work either. Is there some other way to replace a maven-core component with a custom implementation? Ryan On Thu, Dec 2, 2010 at 12:22 PM, Marvin Froeder <[email protected]> wrote: > 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] >> 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/ > -- 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/
