date:20110702

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

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: builds.apache.org seg faulting...

AFAIK, nothing was done on the job configuration recently [1]

Olivier, the #217 run you launched went well: did you do something?

Regards,

Hervé


[1] https://builds.apache.org/job/maven-plugins-ITs-2.x/jobConfigHistory/

Le vendredi 1 juillet 2011, Barrie Treloar a écrit :
 https://builds.apache.org/view/M-R/view/Maven/job/maven-plugins-ITs-2.x/216
 /console #
 # An unexpected error has been detected by HotSpot Virtual Machine:
 #
 #  SIGBUS (0x7) at pc=0xf770a7a4, pid=13024, tid=4150232768
 #
 # Java VM: Java HotSpot(TM) Server VM (1.5.0_22-b03 mixed mode)
 # Problematic frame:
 Segmentation fault
 #
 
 Is this something we have done or infra be contacted?
 
 -
 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

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

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:

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

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,

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

2011-07-02 Thread Ralph Goers

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 herve.bout...@free.fr wrote:

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,

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

On Sat, Jul 2, 2011 at 7:43 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 yes, plugin depdendencies are downloaded like any other artifacts via
 DefaultArtifactResolver in maven-artifact-manager for Maven 2 [1].

 Plugin resolution and classloader preparation is done in
 DefaultPluginManager
 in maven-core [2]

 Velocity and plexus-velocity are nothing different than any library.

 I don't see any obvious reason why it fails: mvn -X debugging seems to be
 necessary, comparing output from official Maven build and Gentoo's one


I see. Well, I did look at the debug output with my limited understanding,
but couldn't find the error. It's much appreciated if you can have a quick
look at it and let me know what you see.

As I see, the error comes at the following line. Maven has reloaded all the
core maven dependencies since the gentoo maven build shows loading them
urls[x]. official maven build shows this.
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.

[0] Official maven build http://paste.pocoo.org/show/426913/
[1] Gentoo maven build http://paste.pocoo.org/show/426899/
[2] The diff from [0] to [1] http://paste.pocoo.org/show/426901/

Thanks,
--Kasun


 Regards,

 Hervé

 [1] http://maven.apache.org/ref/2.2.1/maven-artifact-manager

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

 Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
  On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY herve.bout...@free.fr
 wrote:
   remember that Maven is a core engine to run plugins.
   Maven core does not depend on plexus-velocity [1], but
   maven-remote-resources-
   plugin does [2]
   Maven distribution does not contain every library needed by every
 plugin,
   but
   the logic to download them (hence the Maven downloads the internet
   effect some complain about).
   Each plugin is isolated to have access to its dependencies
 independently
   from
   others, and even independently from Maven core dependencies as much as
   possible.
  
   So I understand that you rebuilt Maven core from sources to match
 Gentoo
   spirit.
   What about core dependencies [1]? Did you download them (as done by
   build.xml)
   or modified the build to use you own compiled from source version?
   And what about dependencies  needed by plugins?
 
  To give a introduction read this. Skip if this's too long.
  What we've done is that we grabbed all the maven core dependencies,
  converted those to ant projects (via maven-ant-plugin), tarballed it, and
  uploaded to a separate server. Then, when user emerge (install) maven, it
  downloads all these core dependencies, compiles them and installs to an
  appropriate location in /usr/share. for example:
 /usr/share/maven-artifact
  and the jar will be at lib/maven-artifact.jar.
 
  Then, maven collect these deps to a one place by creating symlinks to
 those
  dependency jars in /usr/share/maven-2/lib/. This effectively drops the
 need
  to create the uberjar in lib/. when the classworlds is launched, it'll
  identify the dependency jars.
  See this post as well.
 
 http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-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]

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

On Sat, Jul 2, 2011 at 7:45 PM, Ralph Goers ralph.go...@dslextreme.comwrote:

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

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

problem in maven-shade-plugin svn

/Users/benson/asf/mvn/plugins svn cleanup
svn: In directory 'maven-shade-plugin/src/it/mini-jar-package-info'
svn: Error processing command 'committed' in
'maven-shade-plugin/src/it/mini-jar-package-info'
svn: Working copy 'maven-shade-plugin/src/it' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

there may be problems for everyone else until I cure this.

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

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

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

I don't see anything obvious

Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
 On Sat, Jul 2, 2011 at 7:43 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
  yes, plugin depdendencies are downloaded like any other artifacts via
  DefaultArtifactResolver in maven-artifact-manager for Maven 2 [1].
  
  Plugin resolution and classloader preparation is done in
  DefaultPluginManager
  in maven-core [2]
  
  Velocity and plexus-velocity are nothing different than any library.
  
  I don't see any obvious reason why it fails: mvn -X debugging seems to be
  necessary, comparing output from official Maven build and Gentoo's one
 
 I see. Well, I did look at the debug output with my limited understanding,
 but couldn't find the error. It's much appreciated if you can have a quick
 look at it and let me know what you see.
 
 As I see, the error comes at the following line. Maven has reloaded all the
 core maven dependencies since the gentoo maven build shows loading them
 urls[x]. official maven build shows this.
 [INFO] Setting property: classpath.resource.loader.class =
 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
 [INFO] Setting property: velocimacro.messages.on = 'false'.
 [INFO] Setting property: resource.loader = 'classpath'.
 
 [0] Official maven build http://paste.pocoo.org/show/426913/
 [1] Gentoo maven build http://paste.pocoo.org/show/426899/
 [2] The diff from [0] to [1] http://paste.pocoo.org/show/426901/
 
 Thanks,
 --Kasun
 
  Regards,
  
  Hervé
  
  [1] http://maven.apache.org/ref/2.2.1/maven-artifact-manager
  
  [2] http://maven.apache.org/ref/2.2.1/maven-core
  
  Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit :
   On Sat, Jul 2, 2011 at 2:03 PM, Hervé BOUTEMY herve.bout...@free.fr
  
  wrote:
remember that Maven is a core engine to run plugins.
Maven core does not depend on plexus-velocity [1], but
maven-remote-resources-
plugin does [2]
Maven distribution does not contain every library needed by every
  
  plugin,
  
but
the logic to download them (hence the Maven downloads the internet
effect some complain about).
Each plugin is isolated to have access to its dependencies
  
  independently
  
from
others, and even independently from Maven core dependencies as much
as possible.

So I understand that you rebuilt Maven core from sources to match
  
  Gentoo
  
spirit.
What about core dependencies [1]? Did you download them (as done by
build.xml)
or modified the build to use you own compiled from source version?
And what about dependencies  needed by plugins?
   
   To give a introduction read this. Skip if this's too long.
   What we've done is that we grabbed all the maven core dependencies,
   converted those to ant projects (via maven-ant-plugin), tarballed it,
   and uploaded to a separate server. Then, when user emerge (install)
   maven, it downloads all these core dependencies, compiles them and
   installs to an
  
   appropriate location in /usr/share. for example:
  /usr/share/maven-artifact
  
   and the jar will be at lib/maven-artifact.jar.
   
   Then, maven collect these deps to a one place by creating symlinks to
  
  those
  
   dependency jars in /usr/share/maven-2/lib/. This effectively drops the
  
  need
  
   to create the uberjar in lib/. when the classworlds is launched, it'll
   identify the dependency jars.
   See this post as well.
  
  http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-a
  nt
  
   -td4502850.html
   
   
   Now, back to the issue in question.
   Maven's core dependency is handled via maven-2.2.1-uber.jar. We use
  
  almost
  
   same mechanism. That part is done.
   Maven plugins handling was left ENTIRELY to the built maven. Therefore,
   I expected that our maven build will take care of plugin dependencies
   by downloading and resolving those.  Maven did download the dependency
   jars
  
  of
  
   the plugins as I've seen; in this case, plexus-velocity.  But, it
   doesn't correctly resolve the dependencies to make it available at
   plugin
  
  runtime.
  
   So, I'm asking the question back from you. How does the plugin
  
  dependencies
  
   are handled by maven? What are the points I should consider?
   
   In fact, we expect to bundle the maven-plugins to be compiled and
  
  installed
  
   via Gentoo package management system (portage) too. So, your inputs
   about how maven handles plugin _dependencies_ will be much useful.
   (The comping and installing happens via portage, i.e. we do not worry
   maven about it.)
   
What's your strategy about built-from-source vs
binary-downloaded-from- central-repository? Where do you put the
limit? Do you intent to build your own repository containing only
artifacts built by Gentoo people?
   
   There are two aspects. The maven user's aspect, and gentoo packager's
   aspect. User's aspect is the concern now. In user's case, maven will
   download the

coast clear, + status report on shade

The problem I reported with svn was local to my checkout; my checkin
had succeeded.

I've applied all the patches with tests, and even written tests for
two without tests. I've invited two others to provide tests, and
there's one interesting patch that poses a legal issue: the submitted
just posted a github pull request, so since the JIRA is at codehaus, I
have legal qualms. I've asked legal-discuss. In a week, with or
without these, I propose to release.

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

Re: builds.apache.org seg faulting...

2011-07-02 Thread Olivier Lamy

Hello

2011/7/2 Hervé BOUTEMY herve.bout...@free.fr:
 AFAIK, nothing was done on the job configuration recently [1]

 Olivier, the #217 run you launched went well: did you do something?
Nope.
So probably a temporary overload on the machine.
I remember a build took all resources on b.a.o so due to this it has
been disabled.

 Regards,

 Hervé


 [1] https://builds.apache.org/job/maven-plugins-ITs-2.x/jobConfigHistory/

 Le vendredi 1 juillet 2011, Barrie Treloar a écrit :
 https://builds.apache.org/view/M-R/view/Maven/job/maven-plugins-ITs-2.x/216
 /console #
 # An unexpected error has been detected by HotSpot Virtual Machine:
 #
 #  SIGBUS (0x7) at pc=0xf770a7a4, pid=13024, tid=4150232768
 #
 # Java VM: Java HotSpot(TM) Server VM (1.5.0_22-b03 mixed mode)
 # Problematic frame:
 Segmentation fault
 #

 Is this something we have done or infra be contacted?

 -
 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





-- 
Olivier Lamy
http://twitter.com/olamy | http://www.linkedin.com/in/olamy

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

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

2011-07-02 Thread 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.


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

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 ralph.go...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Is Maven Site Plugin 3.0-beta-4 ready for release?

2011-07-02 Thread Dennis Lundberg

Hi

What's the status on this? I know Hervé worked on extracting a shared
component (maven-reporting-exec) for the Maven 3 specific parts of the
plugin. Did you finish with that?

I would like to push for a release of Site Plugin 3 shortly. The only
issue left according to JIRA is this one:

http://jira.codehaus.org/browse/MSITE-560

There are a lot stuff fixed already, and we need to get this out so that
Maven 3 users can benefit from them. Do we want/need to add anything
more before the release?

-- 
Dennis Lundberg

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

Re: Is Maven Site Plugin 3.0-beta-4 ready for release?

AFAIK, code is ok: I'm closing MSITE-560
the only thing to confirm is the documentation: there is a TODO in 
maven-3.apt.vm that we should check carefully: I'm personnally lost on this 
one.

Regards,

Hervé

Le samedi 2 juillet 2011, Dennis Lundberg a écrit :
 Hi
 
 What's the status on this? I know Hervé worked on extracting a shared
 component (maven-reporting-exec) for the Maven 3 specific parts of the
 plugin. Did you finish with that?
 
 I would like to push for a release of Site Plugin 3 shortly. The only
 issue left according to JIRA is this one:
 
 http://jira.codehaus.org/browse/MSITE-560
 
 There are a lot stuff fixed already, and we need to get this out so that
 Maven 3 users can benefit from them. Do we want/need to add anything
 more before the release?


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

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

2011-07-02 Thread Kristian Rosenvold

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1142276 - /maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt

2011-07-02 Thread Stephen Connolly

On 2 July 2011 20:23,  hbout...@apache.org wrote:
 Author: hboutemy
 Date: Sat Jul  2 19:23:41 2011
 New Revision: 1142276

 URL: http://svn.apache.org/viewvc?rev=1142276view=rev
 Log:
 added phase to sample run-its command

 Modified:
    maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt

 Modified: maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt?rev=1142276r1=1142275r2=1142276view=diff
 ==
 --- maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt (original)
 +++ maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt Sat Jul  2 
 19:23:41 2011
 @@ -36,7 +36,7 @@ Maven Plugins Parent POM
     to run its ITs, but by convention, these ITs are defined by every plugin 
 in a run-its profile:

  +---
 -mvn -Prun-its
 +mvn -Prun-its integration-test

should be verify not integration-test to allow the post-integration test tidy-up

  +---

     As of version 21, this POM sets the Java source and target versions to 
 1.5. Thus any plugin




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

compiler plugin config in plugins -- recent parent change seems ineffectual

OK, well, I'm stumped.

In maven-shade-plugin, I modified my local copy to point to
maven-plugins version 20 as parent. This in turn points to maven
parent 20. Which configures the compiler plugin for source level 1.5.

Yet, help:effective-pom shows me source level 1.4, and adding in a
generic gets an error.

Now, I can add the compiler plugin to the shade pom, but I'd like to
understand what I'm missing here.

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

Re: compiler plugin config in plugins -- recent parent change seems ineffectual

correction: I made shade point to maven-plugins:21, which in turn
points to maven-parent 20, which is the one with the 1.5's in it.

On Sat, Jul 2, 2011 at 8:04 PM, Benson Margulies bimargul...@gmail.com wrote:
 OK, well, I'm stumped.

 In maven-shade-plugin, I modified my local copy to point to
 maven-plugins version 20 as parent. This in turn points to maven
 parent 20. Which configures the compiler plugin for source level 1.5.

 Yet, help:effective-pom shows me source level 1.4, and adding in a
 generic gets an error.

 Now, I can add the compiler plugin to the shade pom, but I'd like to
 understand what I'm missing here.


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

Re: compiler plugin config in plugins -- recent parent change seems ineffectual

Oh, Duh, I see. It's only in a profile in the plugin parent. oops.

On Sat, Jul 2, 2011 at 8:04 PM, Benson Margulies bimargul...@gmail.com wrote:
 OK, well, I'm stumped.

 In maven-shade-plugin, I modified my local copy to point to
 maven-plugins version 20 as parent. This in turn points to maven
 parent 20. Which configures the compiler plugin for source level 1.5.

 Yet, help:effective-pom shows me source level 1.4, and adding in a
 generic gets an error.

 Now, I can add the compiler plugin to the shade pom, but I'd like to
 understand what I'm missing here.


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

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

On Sun, Jul 3, 2011 at 12:30 AM, Hervé BOUTEMY herve.bout...@free.frwrote:

 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

On Sun, Jul 3, 2011 at 1:05 AM, Benson Margulies bimargul...@gmail.comwrote:

 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 ralph.go...@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-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@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

2011-07-02 Thread Martin Gainty


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: kasu...@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.bout...@free.frwrote:
 
  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

On Sun, Jul 3, 2011 at 3:46 AM, Kristian Rosenvold 
kristian.rosenv...@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-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@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

On Sun, Jul 3, 2011 at 6:06 AM, Martin Gainty mgai...@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: kasu...@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.bout...@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

Another maven pom release