maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
Date Sat, 02 Jul 2011 14:13:13 GMT
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.boutemy@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message