You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Kasun Gajasinghe <ka...@gmail.com> on 2011/07/02 09:12:51 UTC

[Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

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

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

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 <he...@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 <he...@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-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


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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sat, Jul 2, 2011 at 7:43 PM, Hervé BOUTEMY <he...@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 <he...@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
>
>


-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

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 <he...@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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sun, Jul 3, 2011 at 6:06 AM, Martin Gainty <mg...@hotmail.com> wrote:

>
> there are 4 classpath properties you pass to the maven-ant runtime
> environment
>                <property name="compile_classpath"
> refid="maven.compile.classpath"/>
>                <property name="runtime_classpath"
> refid="maven.runtime.classpath"/>
>                <property name="test_classpath"
> refid="maven.test.classpath"/>
>                <property name="plugin_classpath"
> refid="maven.plugin.classpath"/if the missing jar is located on
> maven.runtime.classpath then the ant runtime should resolve the classpath
>
> http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html
>
> when you get a chance could you explain why you are repackaging maven in an
> ant environment
> seems like you're effort is to stuff a mercedes engine in a yugo
> ?
>

You are missing the point. We are not running ant inside maven. We use ant
only for packaging maven itself (bootstrapping). That's the solution for the
hen and egg problem in maven. There is no need of AntRun plugin.

Thanks for trying to help anyway.

--Kasun


> Martin Gainty
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
>
> > From: kasunbg@gmail.com
> > Date: Sun, 3 Jul 2011 05:44:37 +0530
> > Subject: Re: [Gentoo-Maven-Intg] plexus-velocity missing -
> maven-remote-resources-plugin fails with a ClassNotFoundException
> > To: dev@maven.apache.org
> >
> > On Sun, Jul 3, 2011 at 12:30 AM, Hervé BOUTEMY <herve.boutemy@free.fr
> >wrote:
> >
> > > Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
> > > > No, you are not discouraging me in anyway. This stage is just the
> first
> > > > step of a much wider task. The ultimate goal of this work is to
> provide
> > > > the ability to package maven-based builds to Gentoo system. Gentoo
> > > > encourages and the package-management installs packages by first
> > > compiling
> > > > them from source. So, as you can understand, if the package source
> uses
> > > > maven as the build management tool, it needs maven to do the building
> and
> > > > generate the jar.
> > > >
> > > > Further, there are other constraints involved. Mainly the packages
> should
> > > > be able to use the existing jars available in the system (under
> > > > /usr/share), and we've are not strict about having a specific version
> as
> > > a
> > > > dep as long the existing system jar is api-compatible.
> > > honestly, this is the part I really doubt about: it will be hard to do
> > > (will
> > > need to change the way Maven resolves dependencies), and I expect there
> > > will
> > > be a lot of failures since dependencies version modification in general
> > > causes
> > > failures.
> > >
> > > As a proof of concept, I find the task fun.
> > > As a user, I expect a lot of problems and wouldn't really be confident
> > > about
> > > this.
> > >
> > >
> > To re-iterate, as a 'user' this will have a 'normal' behavior of Maven.
> It's
> > the system part that will be different, and have the said constraints.
> >
> > And, maven is packaged with almost the same dependency versions of Maven.
> > There were few exceptions in some Plexus packages, but the versions are
> > close enough and api-compatible. Do you really think this leads to the
> said
> > error?
> >
> > But if you want to try, why not :)
> > >
> >
> > Well, we have packaged ant and is in a good working condition. Now,
> > unfortunately, maven-based projects don't have a simpler way to package
> > their projects, to be installed via portage (the package mgt system). We
> are
> > going to provide a direct way for this.
> >
> >
> > --Kasun
> >
> > --
> > ~~~*******'''''''''''''*******~~~
> > Kasun Gajasinghe,
> > University of Moratuwa,
> > Sri Lanka.
> > Blog: http://blog.kasunbg.org
> > Twitter: http://twitter.com/kasunbg
>
>



-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

RE: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Martin Gainty <mg...@hotmail.com>.

there are 4 classpath properties you pass to the maven-ant runtime environment
                <property name="compile_classpath" refid="maven.compile.classpath"/>
                <property name="runtime_classpath" refid="maven.runtime.classpath"/>
                <property name="test_classpath" refid="maven.test.classpath"/>
                <property name="plugin_classpath" refid="maven.plugin.classpath"/if the missing jar is located on maven.runtime.classpath then the ant runtime should resolve the classpath
http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html

when you get a chance could you explain why you are repackaging maven in an ant environment
seems like you're effort is to stuff a mercedes engine in a yugo 
?
Martin Gainty 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.


> From: kasunbg@gmail.com
> Date: Sun, 3 Jul 2011 05:44:37 +0530
> Subject: Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException
> To: dev@maven.apache.org
> 
> On Sun, Jul 3, 2011 at 12:30 AM, Hervé BOUTEMY <he...@free.fr>wrote:
> 
> > Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
> > > No, you are not discouraging me in anyway. This stage is just the first
> > > step of a much wider task. The ultimate goal of this work is to provide
> > > the ability to package maven-based builds to Gentoo system. Gentoo
> > > encourages and the package-management installs packages by first
> > compiling
> > > them from source. So, as you can understand, if the package source uses
> > > maven as the build management tool, it needs maven to do the building and
> > > generate the jar.
> > >
> > > Further, there are other constraints involved. Mainly the packages should
> > > be able to use the existing jars available in the system (under
> > > /usr/share), and we've are not strict about having a specific version as
> > a
> > > dep as long the existing system jar is api-compatible.
> > honestly, this is the part I really doubt about: it will be hard to do
> > (will
> > need to change the way Maven resolves dependencies), and I expect there
> > will
> > be a lot of failures since dependencies version modification in general
> > causes
> > failures.
> >
> > As a proof of concept, I find the task fun.
> > As a user, I expect a lot of problems and wouldn't really be confident
> > about
> > this.
> >
> >
> To re-iterate, as a 'user' this will have a 'normal' behavior of Maven. It's
> the system part that will be different, and have the said constraints.
> 
> And, maven is packaged with almost the same dependency versions of Maven.
> There were few exceptions in some Plexus packages, but the versions are
> close enough and api-compatible. Do you really think this leads to the said
> error?
> 
> But if you want to try, why not :)
> >
> 
> Well, we have packaged ant and is in a good working condition. Now,
> unfortunately, maven-based projects don't have a simpler way to package
> their projects, to be installed via portage (the package mgt system). We are
> going to provide a direct way for this.
> 
> 
> --Kasun
> 
> -- 
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://blog.kasunbg.org
> Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sun, Jul 3, 2011 at 12:30 AM, Hervé BOUTEMY <he...@free.fr>wrote:

> Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
> > No, you are not discouraging me in anyway. This stage is just the first
> > step of a much wider task. The ultimate goal of this work is to provide
> > the ability to package maven-based builds to Gentoo system. Gentoo
> > encourages and the package-management installs packages by first
> compiling
> > them from source. So, as you can understand, if the package source uses
> > maven as the build management tool, it needs maven to do the building and
> > generate the jar.
> >
> > Further, there are other constraints involved. Mainly the packages should
> > be able to use the existing jars available in the system (under
> > /usr/share), and we've are not strict about having a specific version as
> a
> > dep as long the existing system jar is api-compatible.
> honestly, this is the part I really doubt about: it will be hard to do
> (will
> need to change the way Maven resolves dependencies), and I expect there
> will
> be a lot of failures since dependencies version modification in general
> causes
> failures.
>
> As a proof of concept, I find the task fun.
> As a user, I expect a lot of problems and wouldn't really be confident
> about
> this.
>
>
To re-iterate, as a 'user' this will have a 'normal' behavior of Maven. It's
the system part that will be different, and have the said constraints.

And, maven is packaged with almost the same dependency versions of Maven.
There were few exceptions in some Plexus packages, but the versions are
close enough and api-compatible. Do you really think this leads to the said
error?

But if you want to try, why not :)
>

Well, we have packaged ant and is in a good working condition. Now,
unfortunately, maven-based projects don't have a simpler way to package
their projects, to be installed via portage (the package mgt system). We are
going to provide a direct way for this.


--Kasun

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
> No, you are not discouraging me in anyway. This stage is just the first
> step of a much wider task. The ultimate goal of this work is to provide
> the ability to package maven-based builds to Gentoo system. Gentoo
> encourages and the package-management installs packages by first compiling
> them from source. So, as you can understand, if the package source uses
> maven as the build management tool, it needs maven to do the building and
> generate the jar.
> 
> Further, there are other constraints involved. Mainly the packages should
> be able to use the existing jars available in the system (under
> /usr/share), and we've are not strict about having a specific version as a
> dep as long the existing system jar is api-compatible.
honestly, this is the part I really doubt about: it will be hard to do (will 
need to change the way Maven resolves dependencies), and I expect there will 
be a lot of failures since dependencies version modification in general causes 
failures.

As a proof of concept, I find the task fun.
As a user, I expect a lot of problems and wouldn't really be confident about 
this.

But if you want to try, why not :)

> 
> So, this is the step we take to have a custom maven build tailored to
> Gentoo system satisfying all the constraints.
> 
> --Kasun

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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sun, Jul 3, 2011 at 1:05 AM, Benson Margulies <bi...@gmail.com>wrote:

> This strikes me as forking maven, making a fundamental changing in the
> behavior, and then passing off the results as still 'maven'. I'm not
> sure if 'trademark' is the right stepping-off point here, but
> something about it seems very wrong.
>

Oh, I won't go that far. :)
We haven't forked, and didn't change a single bit of code in Maven. There
were few changes in the dependencies (for example having wagon-* 1.0_beta7
versions instead of 1.0_beta6.), but I don't think that's a fork per se.
And, for the _system_, there will be a maven eclass, which handles the
versioning. Gentoo has the concept of SLOTs, the which you can think of as
baskets, each containing a set of compatible versions.
I may not be the right person to answer this type of issue anyway!

--Kasun


>
> On Sat, Jul 2, 2011 at 3:22 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote:
> >>>
> >>
> >> Ralph,
> >> No, you are not discouraging me in anyway. This stage is just the first
> step
> >> of a much wider task. The ultimate goal of this work is to provide the
> >> ability to package maven-based builds to Gentoo system. Gentoo
> encourages
> >> and the package-management installs packages by first compiling them
> from
> >> source. So, as you can understand, if the package source uses maven as
> the
> >> build management tool, it needs maven to do the building and generate
> the
> >> jar.
> >>
> >> Further, there are other constraints involved. Mainly the packages
> should be
> >> able to use the existing jars available in the system (under
> /usr/share),
> >> and we've are not strict about having a specific version as a dep as
> long
> >> the existing system jar is api-compatible.
> >
> >
> > This makes me wonder if anyone you are working with has experience
> working with Java applications. What you are doing sounds like it is ripe
> for problems. API dependencies aren't the only things that change between
> versions. You might have new configuration attributes added, additional
> dependencies, etc. Trying to get a whole pile of Java-based applications to
> use the same versions of jars is a problem in an application server, let
> alone across a whole operating system.
> >
> > Ralph
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Benson Margulies <bi...@gmail.com>.

This strikes me as forking maven, making a fundamental changing in the
behavior, and then passing off the results as still 'maven'. I'm not
sure if 'trademark' is the right stepping-off point here, but
something about it seems very wrong.

On Sat, Jul 2, 2011 at 3:22 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote:
>>>
>>
>> Ralph,
>> No, you are not discouraging me in anyway. This stage is just the first step
>> of a much wider task. The ultimate goal of this work is to provide the
>> ability to package maven-based builds to Gentoo system. Gentoo encourages
>> and the package-management installs packages by first compiling them from
>> source. So, as you can understand, if the package source uses maven as the
>> build management tool, it needs maven to do the building and generate the
>> jar.
>>
>> Further, there are other constraints involved. Mainly the packages should be
>> able to use the existing jars available in the system (under /usr/share),
>> and we've are not strict about having a specific version as a dep as long
>> the existing system jar is api-compatible.
>
>
> This makes me wonder if anyone you are working with has experience working with Java applications. What you are doing sounds like it is ripe for problems. API dependencies aren't the only things that change between versions. You might have new configuration attributes added, additional dependencies, etc. Trying to get a whole pile of Java-based applications to use the same versions of jars is a problem in an application server, let alone across a whole operating system.
>
> Ralph
>
>

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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sun, Jul 3, 2011 at 2:28 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> uh, you've got doxia-module-*.jar in your /usr/share/maven-2/lib/
> directory?
> but these are not in Maven core: only doxia-api and doxia-logging-api are
> part
> of Maven core [2]
> Other Doxia artifacts are used in site plugin only, and should not be
> shared
> in core.
> Your problem seems to be related: this "doxia-default" role has been added
> in
> doxia-sitetools component, which should not be in the classpath.
> see DOXIA-147 [3]
>
> IMHO, with full Doxia in Maven core classloader, you'll have failures with
> reporting plugins (if not strange issues like the one you had here)
>

Yes, I've removed the doxia modules and added the needed doxia-sink-api and
doxia-logging-api. I think you meant to doxia-sink-api not doxia-api. The
issue is resolved!

Thanks,
--Kasun


>
> Regards,
>
> Hervé
>
> [2] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html
>
> [3] http://jira.codehaus.org/browse/DOXIA-147
>
> Le dimanche 3 juillet 2011, Kasun Gajasinghe a écrit :
> > On Sun, Jul 3, 2011 at 1:28 PM, Hervé BOUTEMY <he...@free.fr>
> wrote:
> > > > Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing
> > > > 2.2.1. We surely need to support 3.0.3 too, the future of maven.
> > > > Is it possible Doxia plays a part here too? We haven't really
> bothered
> > > > about these site stuff, and therefore, doxia version we have is a
> > > > little older.
> > >
> > > no, Doxia shouldn't be involved in your actual problems: it's used only
> > > for reporting, and there is only a simple doxia API that is included in
> > > Maven core
> >
> > Yes, but the said issue is more related to the remote-resources-plugin.
> It
> > too only use doxia-sink-api though. Anyway, there's some bond between
> that
> > plugin and doxia. In [1] line 1348, the failed component's role-hint is
> > "doxia-default".
> >
> > And, the nightmare I referred is not doxia, but the whole process. There
> > were around 50 ebuilds that I've bumped in the process, and there were
> lot
> > of understanding to do in Maven as well. And, we just started the testing
> > phase, so it's not suitable to put in to main tree in Gentoo.
> >
> > [1] http://paste.pocoo.org/show/426899/
> >
> > There's another little issue with hidden classes in the uber jar. It
> suits
> > for a new thread i guess.
> >
> > --Kasun
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

uh, you've got doxia-module-*.jar in your /usr/share/maven-2/lib/ directory?
but these are not in Maven core: only doxia-api and doxia-logging-api are part 
of Maven core [2]
Other Doxia artifacts are used in site plugin only, and should not be shared 
in core.
Your problem seems to be related: this "doxia-default" role has been added in 
doxia-sitetools component, which should not be in the classpath.
see DOXIA-147 [3]

IMHO, with full Doxia in Maven core classloader, you'll have failures with 
reporting plugins (if not strange issues like the one you had here)

Regards,

Hervé

[2] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html

[3] http://jira.codehaus.org/browse/DOXIA-147

Le dimanche 3 juillet 2011, Kasun Gajasinghe a écrit :
> On Sun, Jul 3, 2011 at 1:28 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> > > Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing
> > > 2.2.1. We surely need to support 3.0.3 too, the future of maven.
> > > Is it possible Doxia plays a part here too? We haven't really bothered
> > > about these site stuff, and therefore, doxia version we have is a
> > > little older.
> > 
> > no, Doxia shouldn't be involved in your actual problems: it's used only
> > for reporting, and there is only a simple doxia API that is included in
> > Maven core
> 
> Yes, but the said issue is more related to the remote-resources-plugin. It
> too only use doxia-sink-api though. Anyway, there's some bond between that
> plugin and doxia. In [1] line 1348, the failed component's role-hint is
> "doxia-default".
> 
> And, the nightmare I referred is not doxia, but the whole process. There
> were around 50 ebuilds that I've bumped in the process, and there were lot
> of understanding to do in Maven as well. And, we just started the testing
> phase, so it's not suitable to put in to main tree in Gentoo.
> 
> [1] http://paste.pocoo.org/show/426899/
> 
> There's another little issue with hidden classes in the uber jar. It suits
> for a new thread i guess.
> 
> --Kasun


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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sun, Jul 3, 2011 at 1:28 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> > Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1.
> > We surely need to support 3.0.3 too, the future of maven.
> > Is it possible Doxia plays a part here too? We haven't really bothered
> > about these site stuff, and therefore, doxia version we have is a little
> > older.
> no, Doxia shouldn't be involved in your actual problems: it's used only for
> reporting, and there is only a simple doxia API that is included in Maven
> core
>

Yes, but the said issue is more related to the remote-resources-plugin. It
too only use doxia-sink-api though. Anyway, there's some bond between that
plugin and doxia. In [1] line 1348, the failed component's role-hint is
"doxia-default".

And, the nightmare I referred is not doxia, but the whole process. There
were around 50 ebuilds that I've bumped in the process, and there were lot
of understanding to do in Maven as well. And, we just started the testing
phase, so it's not suitable to put in to main tree in Gentoo.

[1] http://paste.pocoo.org/show/426899/

There's another little issue with hidden classes in the uber jar. It suits
for a new thread i guess.

--Kasun

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

> Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1.
> We surely need to support 3.0.3 too, the future of maven.
> Is it possible Doxia plays a part here too? We haven't really bothered
> about these site stuff, and therefore, doxia version we have is a little
> older.
no, Doxia shouldn't be involved in your actual problems: it's used only for 
reporting, and there is only a simple doxia API that is included in Maven core
Just for the record, with Maven 3, this has totally been removed from core

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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sun, Jul 3, 2011 at 3:46 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:

> lø., 02.07.2011 kl. 12.22 -0700, skrev Ralph Goers:
> > On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote:
> > >>
> > >
> > > Ralph,
> > > No, you are not discouraging me in anyway. This stage is just the first
> step
> > > of a much wider task. The ultimate goal of this work is to provide the
> > > ability to package maven-based builds to Gentoo system. Gentoo
> encourages
> > > and the package-management installs packages by first compiling them
> from
> > > source. So, as you can understand, if the package source uses maven as
> the
> > > build management tool, it needs maven to do the building and generate
> the
> > > jar.
> > >
> > > Further, there are other constraints involved. Mainly the packages
> should be
> > > able to use the existing jars available in the system (under
> /usr/share),
> > > and we've are not strict about having a specific version as a dep as
> long
> > > the existing system jar is api-compatible.
> >
> >
>
> I think what you're trying to do is tremendously gutsy, but I would
> expect no less from gentoo :)
>
> Would you basically be trying to build the whole stack more or less from
> trunk, or would you be going off the latest released versions ?
>

We are building the stack with Maven 2.2.1 tag. For the deps plexus and
wagon, we tried to go with the latest released version available where we
can.


> I can't directly help you with the problem you're facing, but it would
> sound like it might be coming in somewhere related to the site stuff,
> which is integrated in 2.2.1 core. This was totally removed from 3.x
> core, which is another reason why starting the whole lot with 3.x might
> be easier; it has a simpler dependency profile. But I'm not going to
> re-iterate that.
>

Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1. We
surely need to support 3.0.3 too, the future of maven.
Is it possible Doxia plays a part here too? We haven't really bothered about
these site stuff, and therefore, doxia version we have is a little older.

--Kasun


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


-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kristian Rosenvold <kr...@gmail.com>.

lø., 02.07.2011 kl. 12.22 -0700, skrev Ralph Goers:
> On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote:
> >> 
> > 
> > Ralph,
> > No, you are not discouraging me in anyway. This stage is just the first step
> > of a much wider task. The ultimate goal of this work is to provide the
> > ability to package maven-based builds to Gentoo system. Gentoo encourages
> > and the package-management installs packages by first compiling them from
> > source. So, as you can understand, if the package source uses maven as the
> > build management tool, it needs maven to do the building and generate the
> > jar.
> > 
> > Further, there are other constraints involved. Mainly the packages should be
> > able to use the existing jars available in the system (under /usr/share),
> > and we've are not strict about having a specific version as a dep as long
> > the existing system jar is api-compatible.
> 
> 

I think what you're trying to do is tremendously gutsy, but I would
expect no less from gentoo :)

Would you basically be trying to build the whole stack more or less from
trunk, or would you be going off the latest released versions ? 

I can't directly help you with the problem you're facing, but it would
sound like it might be coming in somewhere related to the site stuff,
which is integrated in 2.2.1 core. This was totally removed from 3.x
core, which is another reason why starting the whole lot with 3.x might
be easier; it has a simpler dependency profile. But I'm not going to
re-iterate that. 


Kristian



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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Ralph Goers <ra...@dslextreme.com>.

On Jul 2, 2011, at 8:38 AM, Kasun Gajasinghe wrote:
>> 
> 
> Ralph,
> No, you are not discouraging me in anyway. This stage is just the first step
> of a much wider task. The ultimate goal of this work is to provide the
> ability to package maven-based builds to Gentoo system. Gentoo encourages
> and the package-management installs packages by first compiling them from
> source. So, as you can understand, if the package source uses maven as the
> build management tool, it needs maven to do the building and generate the
> jar.
> 
> Further, there are other constraints involved. Mainly the packages should be
> able to use the existing jars available in the system (under /usr/share),
> and we've are not strict about having a specific version as a dep as long
> the existing system jar is api-compatible.

This makes me wonder if anyone you are working with has experience working with Java applications. What you are doing sounds like it is ripe for problems. API dependencies aren't the only things that change between versions. You might have new configuration attributes added, additional dependencies, etc. Trying to get a whole pile of Java-based applications to use the same versions of jars is a problem in an application server, let alone across a whole operating system.

Ralph

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

I just read this mail after reploying to previous, saying that I didn't see 
how Doxia could be involved
a nightmare, that's it: I don't understand how something about Doxia could fix 
something in Maven core

But it's working: let's celebrate

(I still think I wouldn't be confident when using this rebuilt Maven 
version...)

Le dimanche 3 juillet 2011, Kasun Gajasinghe a écrit :
> After this brainstorming with all of you, finally figured out the error.
> The issue was with doxia, that is in the site-tools. The build failed in a
> compile section, so I didn't thought that caused the issue. I have
> incorporated an older incompatible doxia version, thinking I can fix the
> site-related stuff later. With the new version, it worked. It's not
> related to bootstrapping anyway.
> 
> Thanks to Hervé, Kristian, Martin and all the others for helping!
> 
> On Sun, Jul 3, 2011 at 8:19 AM, Mark Derricutt <ma...@talios.com> wrote:
> > I think I died a little reading this.  Maven itself already has subtle
> > strange issues and problems working with dependency ranges, having a
> > gentoo specific version of maven that does even more different things
> > with artifact
> > resolution would be a nightmare to deal with.  Esp. if you have
> > developers working on different distributions or OS's.
> 
> Oh well, 'nightmare' is probably the word that suits in here as well! But
> this is a long-time blocker in Gentoo. maven-bin is already available for
> users, this effort is for the packagers. There was an effort several years
> ago, which got stalled due to developer got hit by bus factor. Now is the
> time to get this right!
> 
> --Kasun


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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

After this brainstorming with all of you, finally figured out the error. The
issue was with doxia, that is in the site-tools. The build failed in a
compile section, so I didn't thought that caused the issue. I have
incorporated an older incompatible doxia version, thinking I can fix the
site-related stuff later. With the new version, it worked. It's not related
to bootstrapping anyway.

Thanks to Hervé, Kristian, Martin and all the others for helping!

On Sun, Jul 3, 2011 at 8:19 AM, Mark Derricutt <ma...@talios.com> wrote:

> I think I died a little reading this.  Maven itself already has subtle
> strange issues and problems working with dependency ranges, having a gentoo
> specific version of maven that does even more different things with
> artifact
> resolution would be a nightmare to deal with.  Esp. if you have developers
> working on different distributions or OS's.
>

Oh well, 'nightmare' is probably the word that suits in here as well! But
this is a long-time blocker in Gentoo. maven-bin is already available for
users, this effort is for the packagers. There was an effort several years
ago, which got stalled due to developer got hit by bus factor. Now is the
time to get this right!

--Kasun

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Mark Derricutt <ma...@talios.com>.

I think I died a little reading this.  Maven itself already has subtle
strange issues and problems working with dependency ranges, having a gentoo
specific version of maven that does even more different things with artifact
resolution would be a nightmare to deal with.  Esp. if you have developers
working on different distributions or OS's.

I remember going thru the same pains with Redhat/JPackage when they tried
the same with.

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Sun, Jul 3, 2011 at 3:38 AM, Kasun Gajasinghe <ka...@gmail.com> wrote:

> Further, there are other constraints involved. Mainly the packages should
> be
> able to use the existing jars available in the system (under /usr/share),
> and we've are not strict about having a specific version as a dep as long
> the existing system jar is api-compatible.
>
> So, this is the step we take to have a custom maven build tailored to
> Gentoo
> system satisfying all the constraints.
>

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sat, Jul 2, 2011 at 7:45 PM, Ralph Goers <ra...@dslextreme.com>wrote:

> Not to belittle what you are doing, but on every system I use I
> 1) Download the maven gziip.
> 2) unzip it in /opt
> 3) create a symlink of /opt/maven to the maven I downloaded
> 4) add /opt/maven/bin to the path in /etc/profile
> 5) add an export for M2_HOME to /opt/maven in /etc/profile.
>
> Then I start using maven.  Even if Maven is installed on the system I do
> this. If I want to use Ant I do the same thing. I got burned enough times by
> the crappy way RedHat installed Java and Ant on their systems that I just
> will not use them and I now assume that whatever things the system builder
> did to install those components probably broke it.
>
> I know that won't discourage you from doing what you are doing, but from a
> user's perspective I'd rather have a system that did the above for me than
> what you describe below. Obviously, installing into /usr/share instead of
> /opt wouldn't make much of a difference to the process.
>

Ralph,
No, you are not discouraging me in anyway. This stage is just the first step
of a much wider task. The ultimate goal of this work is to provide the
ability to package maven-based builds to Gentoo system. Gentoo encourages
and the package-management installs packages by first compiling them from
source. So, as you can understand, if the package source uses maven as the
build management tool, it needs maven to do the building and generate the
jar.

Further, there are other constraints involved. Mainly the packages should be
able to use the existing jars available in the system (under /usr/share),
and we've are not strict about having a specific version as a dep as long
the existing system jar is api-compatible.

So, this is the step we take to have a custom maven build tailored to Gentoo
system satisfying all the constraints.

--Kasun


> Ralph
>
> On Jul 2, 2011, at 3:59 AM, Kasun Gajasinghe wrote:
>
> > On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY <he...@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
> >>
> >>
> >
> >
> > --
> > ~~~*******'''''''''''''*******~~~
> > Kasun Gajasinghe,
> > University of Moratuwa,
> > Sri Lanka.
> > Blog: http://blog.kasunbg.org
> > Twitter: http://twitter.com/kasunbg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Ralph Goers <ra...@dslextreme.com>.

Not to belittle what you are doing, but on every system I use I
1) Download the maven gziip.
2) unzip it in /opt
3) create a symlink of /opt/maven to the maven I downloaded
4) add /opt/maven/bin to the path in /etc/profile
5) add an export for M2_HOME to /opt/maven in /etc/profile.

Then I start using maven.  Even if Maven is installed on the system I do this. If I want to use Ant I do the same thing. I got burned enough times by the crappy way RedHat installed Java and Ant on their systems that I just will not use them and I now assume that whatever things the system builder did to install those components probably broke it.

I know that won't discourage you from doing what you are doing, but from a user's perspective I'd rather have a system that did the above for me than what you describe below. Obviously, installing into /usr/share instead of /opt wouldn't make much of a difference to the process.

Ralph
 
On Jul 2, 2011, at 3:59 AM, Kasun Gajasinghe wrote:

> On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY <he...@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
>> 
>> 
> 
> 
> -- 
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe,
> University of Moratuwa,
> Sri Lanka.
> Blog: http://blog.kasunbg.org
> Twitter: http://twitter.com/kasunbg


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

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Kasun Gajasinghe <ka...@gmail.com>.

On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY <he...@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
>
>

-- 
~~~*******'''''''''''''*******~~~
Kasun Gajasinghe,
University of Moratuwa,
Sri Lanka.
Blog: http://blog.kasunbg.org
Twitter: http://twitter.com/kasunbg

Re: [Gentoo-Maven-Intg] plexus-velocity missing - maven-remote-resources-plugin fails with a ClassNotFoundException

Posted by Hervé BOUTEMY <he...@free.fr>.

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?

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?

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