gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Maven 2 (was Re: Maven 1.1)
Date Wed, 16 Nov 2005 10:51:43 GMT
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message