I don't see anything obvious Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : > On Sat, Jul 2, 2011 at 7:43 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > yes, plugin depdendencies are downloaded like any other artifacts via > > DefaultArtifactResolver in maven-artifact-manager for Maven 2 [1]. > > > > Plugin resolution and classloader preparation is done in > > DefaultPluginManager > > in maven-core [2] > > > > Velocity and plexus-velocity are nothing different than any library. > > > > I don't see any obvious reason why it fails: mvn -X debugging seems to be > > necessary, comparing output from official Maven build and Gentoo's one > > I see. Well, I did look at the debug output with my limited understanding, > but couldn't find the error. It's much appreciated if you can have a quick > look at it and let me know what you see. > > As I see, the error comes at the following line. Maven has reloaded all the > core maven dependencies since the gentoo maven build shows loading them > urls[x]. official maven build shows this. > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > > [0] Official maven build http://paste.pocoo.org/show/426913/ > [1] Gentoo maven build http://paste.pocoo.org/show/426899/ > [2] The diff from [0] to [1] http://paste.pocoo.org/show/426901/ > > Thanks, > --Kasun > > > Regards, > > > > Hervé > > > > [1] http://maven.apache.org/ref/2.2.1/maven-artifact-manager > > > > [2] http://maven.apache.org/ref/2.2.1/maven-core > > > > Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : > > > On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY <herve.bout...@free.fr> > > > > wrote: > > > > remember that Maven is a core engine to run plugins. > > > > Maven core does not depend on plexus-velocity [1], but > > > > maven-remote-resources- > > > > plugin does [2] > > > > Maven distribution does not contain every library needed by every > > > > plugin, > > > > > > but > > > > the logic to download them (hence the "Maven downloads the internet" > > > > effect some complain about). > > > > Each plugin is isolated to have access to its dependencies > > > > independently > > > > > > from > > > > others, and even independently from Maven core dependencies as much > > > > as possible. > > > > > > > > So I understand that you rebuilt Maven core from sources to match > > > > Gentoo > > > > > > spirit. > > > > What about core dependencies [1]? Did you download them (as done by > > > > build.xml) > > > > or modified the build to use you own compiled from source version? > > > > And what about dependencies needed by plugins? > > > > > > To give a introduction read this. Skip if this's too long. > > > What we've done is that we grabbed all the maven core dependencies, > > > converted those to ant projects (via maven-ant-plugin), tarballed it, > > > and uploaded to a separate server. Then, when user emerge (install) > > > maven, it downloads all these core dependencies, compiles them and > > > installs to an > > > > > appropriate location in /usr/share. for example: > > /usr/share/maven-artifact > > > > > and the jar will be at lib/maven-artifact.jar. > > > > > > Then, maven collect these deps to a one place by creating symlinks to > > > > those > > > > > dependency jars in /usr/share/maven-2/lib/. This effectively drops the > > > > need > > > > > to create the uberjar in lib/. when the classworlds is launched, it'll > > > identify the dependency jars. > > > See this post as well. > > > > http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-a > > nt > > > > > -td4502850.html > > > > > > > > > Now, back to the issue in question. > > > Maven's core dependency is handled via maven-2.2.1-uber.jar. We use > > > > almost > > > > > same mechanism. That part is done. > > > Maven plugins handling was left ENTIRELY to the built maven. Therefore, > > > I expected that our maven build will take care of plugin dependencies > > > by downloading and resolving those. Maven did download the dependency > > > jars > > > > of > > > > > the plugins as I've seen; in this case, plexus-velocity. But, it > > > doesn't correctly resolve the dependencies to make it available at > > > plugin > > > > runtime. > > > > > So, I'm asking the question back from you. How does the plugin > > > > dependencies > > > > > are handled by maven? What are the points I should consider? > > > > > > In fact, we expect to bundle the maven-plugins to be compiled and > > > > installed > > > > > via Gentoo package management system (portage) too. So, your inputs > > > about how maven handles plugin _dependencies_ will be much useful. > > > (The comping and installing happens via portage, i.e. we do not worry > > > maven about it.) > > > > > > > What's your strategy about built-from-source vs > > > > binary-downloaded-from- central-repository? Where do you put the > > > > limit? Do you intent to build your own repository containing only > > > > artifacts built by Gentoo people? > > > > > > There are two aspects. The maven user's aspect, and gentoo packager's > > > aspect. User's aspect is the concern now. In user's case, maven will > > > download the dependency binary jars of the package they are building > > > from maven-central. I _assumed_ plugins also behave like any other > > > jar. > > > > > > Packager's aspect is a little different, and doesn't need to be > > > worried, right now! > > > > > > Thanks, > > > --Kasun > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html > > > > > > > > [2] http://maven.apache.org/plugins/maven-remote-resources- > > > > plugin/dependencies.html > > > > > > > > Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : > > > > > Hi, > > > > > > > > > > First of all, the good news. We were able to integrate maven > > > > > successfully to Gentoo. Now, it was able to do most of the general > > > > > compiling and building stuff. We build maven-from-source which > > > > involve > > > > > > > considerable > > > > > > > > work > > > > > > > > > to integrate. > > > > > > > > > > But, there's few glitches. There's an error in some builds which > > > > > use maven-remote-resources-plugin. This happened to me when > > > > > testing the build wagon-1.0-beta-7 tag, and few other builds. It > > > > > fails with ClassNotFoundException for the class > > > > > org.codehaus.plexus.velocity.DefaultVelocityComponent which is in > > > > > the package plexus-velocity. The stack trace is at > > > > > http://pastebin.com/p8YUsGw7. Does maven-2.2.1 need plexus-velocity > > > > as > > > > > > > a dependency? I haven't noticed. In fact, plexus-velocity is in the > > > > m2 > > > > > > repo, > > > > > > > > > though, apparently it's not used by the mvn. > > > > > > > > > > I tried adding plexus-velocity as a dependency (to uber jar if you > > > > > may). > > > > > > > > We > > > > > > > > > don't actually use the uber jar, but we put the needs jars to maven > > > > > lib/ directory, which gets identified by classworlds. It solved the > > > > > said > > > > > > > > issue. > > > > > > > > > But, then it asked for the artifact velocity. See: > > > > > http://pastebin.com/r9vsM85k > > > > > Oh well, what option I have now. I've included velocity as well to > > > > > be picked by classworlds when launching mvn. It brought me here > > > > > where I got stuck: http://pastebin.com/WvLSsupa > > > > > > > > > > Any help please? We are much close to the finish-line. > > > > > > > > > > Thanks, > > > > > --Kasun > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
