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: > >> remember that Maven is a core engine to run plugins. >> Maven core does not depend on plexus-velocity [1], but >> maven-remote-resources- >> plugin does [2] >> Maven distribution does not contain every library needed by every plugin, >> but >> the logic to download them (hence the "Maven downloads the internet" effect >> some complain about). >> Each plugin is isolated to have access to its dependencies independently >> from >> others, and even independently from Maven core dependencies as much as >> possible. >> >> So I understand that you rebuilt Maven core from sources to match Gentoo >> spirit. >> What about core dependencies [1]? Did you download them (as done by >> build.xml) >> or modified the build to use you own compiled from source version? >> And what about dependencies needed by plugins? >> > > To give a introduction read this. Skip if this's too long. > What we've done is that we grabbed all the maven core dependencies, > converted those to ant projects (via maven-ant-plugin), tarballed it, and > uploaded to a separate server. Then, when user emerge (install) maven, it > downloads all these core dependencies, compiles them and installs to an > appropriate location in /usr/share. for example: /usr/share/maven-artifact > and the jar will be at lib/maven-artifact.jar. > > Then, maven collect these deps to a one place by creating symlinks to those > dependency jars in /usr/share/maven-2/lib/. This effectively drops the need > to create the uberjar in lib/. when the classworlds is launched, it'll > identify the dependency jars. > See this post as well. > http://maven.40175.n5.nabble.com/maven-core-tests-fail-when-invoked-via-ant-td4502850.html > > > Now, back to the issue in question. > Maven's core dependency is handled via maven-2.2.1-uber.jar. We use almost > same mechanism. That part is done. > Maven plugins handling was left ENTIRELY to the built maven. Therefore, I > expected that our maven build will take care of plugin dependencies by > downloading and resolving those. Maven did download the dependency jars of > the plugins as I've seen; in this case, plexus-velocity. But, it doesn't > correctly resolve the dependencies to make it available at plugin runtime. > So, I'm asking the question back from you. How does the plugin dependencies > are handled by maven? What are the points I should consider? > > In fact, we expect to bundle the maven-plugins to be compiled and installed > via Gentoo package management system (portage) too. So, your inputs about > how maven handles plugin _dependencies_ will be much useful. (The comping > and installing happens via portage, i.e. we do not worry maven about it.) > > >> >> What's your strategy about built-from-source vs binary-downloaded-from- >> central-repository? Where do you put the limit? Do you intent to build your >> own repository containing only artifacts built by Gentoo people? >> > > There are two aspects. The maven user's aspect, and gentoo packager's > aspect. User's aspect is the concern now. In user's case, maven will > download the dependency binary jars of the package they are building from > maven-central. I _assumed_ plugins also behave like any other jar. > > Packager's aspect is a little different, and doesn't need to be worried, > right now! > > Thanks, > --Kasun > > >> Regards, >> >> Hervé >> >> [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html >> >> [2] http://maven.apache.org/plugins/maven-remote-resources- >> plugin/dependencies.html >> >> Le samedi 2 juillet 2011, Kasun Gajasinghe a écrit : >>> Hi, >>> >>> First of all, the good news. We were able to integrate maven successfully >>> to Gentoo. Now, it was able to do most of the general compiling and >>> building stuff. We build maven-from-source which involve considerable >> work >>> to integrate. >>> >>> But, there's few glitches. There's an error in some builds which use >>> maven-remote-resources-plugin. This happened to me when testing the build >>> wagon-1.0-beta-7 tag, and few other builds. It fails with >>> ClassNotFoundException for the class >>> org.codehaus.plexus.velocity.DefaultVelocityComponent which is in the >>> package plexus-velocity. The stack trace is at >>> http://pastebin.com/p8YUsGw7. Does maven-2.2.1 need plexus-velocity as a >>> dependency? I haven't noticed. In fact, plexus-velocity is in the m2 >> repo, >>> though, apparently it's not used by the mvn. >>> >>> I tried adding plexus-velocity as a dependency (to uber jar if you may). >> We >>> don't actually use the uber jar, but we put the needs jars to maven lib/ >>> directory, which gets identified by classworlds. It solved the said >> issue. >>> But, then it asked for the artifact velocity. See: >>> http://pastebin.com/r9vsM85k >>> Oh well, what option I have now. I've included velocity as well to be >>> picked by classworlds when launching mvn. It brought me here where I got >>> stuck: http://pastebin.com/WvLSsupa >>> >>> Any help please? We are much close to the finish-line. >>> >>> Thanks, >>> --Kasun >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > ~~~*******'''''''''''''*******~~~ > Kasun Gajasinghe, > University of Moratuwa, > Sri Lanka. > Blog: http://blog.kasunbg.org > Twitter: http://twitter.com/kasunbg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
