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 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-ant > -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
