I wrote an answer then deleted it. I got lost a little. Seperating concerns:
-- support for maven2 in gump2
-- I'm not going to work on it
-- support for maven2 in gump3
-- pretty much like we did for maven1 + bootstrap
-- doing it quickly
-- not me
-- doing it properly
-- been thinking about that too
So...
-- how to properly support maven2 in gump3
Basically in the gump descriptors all we want to do is
project name=pluto type=mvn href=http://svn.a.o/r/a/p/x/pom.xml/
and then gump fetches that xml file and merges it into the rest of
the XML. We end up with lots of xml. Now we need
-- a python function or two to work with that xml (while in DOM form)
and help transform it into the python object model gump uses
Then the gump engine at some point figures out it needs to boostrap
mvn. The goal here is to use the actual bootstrap process used for
mvn, I believe that involves an svn checkout followed by running a
shell script followed by running a minimal mvn on itself.
project name=mvn-bootstrap
module name=mvn/
script name=bootstrap/ !-- .sh or .bat --
jar name=build/maven2-bootstrap.jar runtime=true/
/project
project name=mvn
module name=mvn/
depend name=maven2-bootstrap inherit=all/
mvn/
jar name=target/mvn.jar runtime=true/
/project
eg, pretty much as we do for Ant. Next bit is
-- a python plugin which can call Maven2
Ideally we can run mvn without using its shell scripts and just digest
a command which starts with java, since that makes it easier to get
things like the CLASSPATH right. In this case we don't have a local
installation but one running straight from trunk (just like ant). Now,
if we need some special bits like some java code to replace the repository
management, we would have something like
project name=mvn-gump-java-helper
module name=gump3/
depend name=ant inherit=all/
depend name=mvn-bootstrap inherit=all/
ant/
jar name=target/mvn-gump-java-helper.jar/
/project
project name=mvn
!-- ... --
depend project=mvn-gump-java-helper runtime=true/
/project
Now, as far as repository management, downloading, dependency resolution,
any of that is concerned, what we want to do in this mvn-gump-java-helper
is simply disable as much of those bits of maven2 as possible. Basically
what we want to end up with is a gump-generated CLASSPATH (in some form)
which maven just accepts as containing all the required dependencies. All
those pom.xml files are still available and we can write bits of glue (in
python) to expose info from them or for them up as much as needed. Eg Gump3
ends up doing something like
for element in parsed.pom.xml.DOM:
for (origname, replacement) in artifactmap:
element.replaceall(origname, replacement)
(...)
CLASSPATH=$JAVA_HOME/tools.jar:$MVN_HOME/target/mvn.jar:$GUMP_HOME/target/mvn-gump-java-helper.jar:
cd pluton/
java -cp $CLASSPATH org.apache.maven.Maven2.Main jar
I hope all that made sense. Now, moving on to the first implementation
details
-- how to bootstrap maven2
On Wed, Nov 16, 2005 at 04:45:56PM +1100, Brett Porter wrote:
Next, to build Maven. We have a bootstrap that runs without any
dependencies except Java that would produce the installation above -
but it downloads the Maven dependencies on the way. We could have it
resolve packaged versions of those by reusing the gump resolver.
Alternatively, something we are doing so it can be packaged on unix is
checking out the sources rather than relying on packaging, then
building them, then building m2 (and those packages would later be
rebuilt again using the new m2). Is that a better alternative to the
above?
Downloading things from elsewhere is not a problem. The key bit is getting
to a classpath when using maven to build stuff that contains only fresh
built sources and none of the prepackaged bits (just like when you're
bootstrapping GCC -- you download a binary GCC to build GCC, then you throw
the binary away). If there is a procedure to get absolutely everything from
source including all of mavens dependencies and build all of it properly (I
really hope there is one now for maven 2) and dependably, lets use it.
Key bit here is that what gump does for bootstrapping is the same as what
the maven 2 people do for bootstrapping. It sounds like the one you use
yourselves is the first option so lets roll with that.
- LSD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
