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

Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/11/04 20:44:29 UTC

Re: svn commit: r330729 - /gump/metadata/project/struts.xml

On Fri, 04 Nov 2005, <bi...@apache.org> wrote:

> Reverting the last few commits, since they don't help
> 
> Modified: gump/metadata/project/struts.xml URL:
> http://svn.apache.org/viewcvs/gump/metadata/project/struts.xml?rev=330729&r1=330728&r2=330729&view=diff
>
>      <depend project="commons-validator" />
> -    <depend project="commons-jelly-tags-ant" />
> -    <depend project="commons-jelly" />
> -    <depend project="commons-jexl" />
> -    <depend project="commons-collections" />
> -    <depend project="dom4j" />
> -    <depend project="packaged-jaxen" />
>      <depend project="httpunit" />
> -    <option project="jakarta-cactus-framework-12" />
> -    <option project="jakarta-cactus-integration-ant-12"/>
>      <depend project="jakarta-oro" />

Bill,

the problem is that even if the build needed those projects, Maven
will ignore them unless the project descriptor mentions those
dependencies as well.

I'm not sure, but I guess that some change in xdoclet now requires a
newer version of dom4j than the one shipping with Maven.

This implies the Maven build of struts-taglibs actually works at all,
I never tried it.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2

Posted by Leo Simons <ma...@leosimons.com>.

On Fri, Nov 18, 2005 at 12:20:39AM -0800, Bill Barker wrote:
> "Stefan Bodewig" <bo...@apache.org> wrote in message 
> news:87fypv7tjg.fsf@www.samaflost.de...
> > On Wed, 16 Nov 2005, Leo Simons <ma...@leosimons.com> wrote:
> >
> >>   --> support for maven2 in gump2
> >>       --> I'm not going to work on it
> >
> > I'd offer to do a monkey-see-monkey-do support if it is not too
> > different from maven 1 support.  In general I agree that gump3 is the
> > way to go and that we should do it properly.
> >
> > It depends on how quickly we are going to need it.  As soon as
> > projects in our tree switch to Maven2 exclusively, we will at least
> > need that quick-hack version.
> 
> I believe that both the Maven1 and Maven2 scripts use $MAVEN_HOME, which is 
> the biggest problem with just creating a <mvn/> tag for Gump2.  There are 
> also problems with separating the local Maven repository between Gump1 and 
> Gump2.  As much as I hate to admit it, having a <mvn/> tag in Gump2 looks 
> like it will be a lot of work :(.

Do I understand correctly that the problem you see is that

 -> you need different values of MAVEN_HOME

 -> you need different contents of ~/.maven

if so, that isn't something you can't hack in there I think. Just create

~/.maven1
~/.maven2

prior to invoking maven1:

  rm -f ~/.maven
  ln -s ~/.maven1 ~/.maven
  export MAVEN_HOME=foo

prior to invoking maven2:

  rm -f ~/.maven
  ln -s ~/.maven2 ~/.maven
  export MAVEN_HOME=bar

the equivalents in python involve something like

  os.unlink(fnmatch('~/.maven'))
  os.symlink('~/.maven', '~/maven2')
  os.environ["MAVE_HOME"] = 'foo'

relevant docs at

  http://docs.python.org/lib/module-os.html

LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Brett Porter <br...@gmail.com>.

On 11/19/05, Leo Simons <ma...@leosimons.com> wrote:
> Maven is in the center of the developers for a project (they type "mvn"
> and not "gump") so what these people want to author is a POM. Gump should
> read that POM and understand it.

Sorry, I probably didn't explain where I was coming from. Maven does
transitive dependencies. Even when you take the versioning out of it,
it still needs to traverse the projects to get the correct list. So
this is fine as long as it hits Maven projects, but when it finds a
dependency without a POM, then it needs to be able to parse whatever
is given to figure out the dependencies of that.

>
> Maybe we should just try it and see how far we get.

Yep, I think I can make an attempt at it. But for now, sleep.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Leo Simons <ma...@leosimons.com>.

On Fri, Nov 18, 2005 at 11:10:24PM +1100, Brett Porter wrote:
> > Why do you keep referring to a something.xml? Is it going to be a lot
> > easier to have the maven jar resolver read a something.xml rather than do
> > something else (like, I dunno, a database, or an XML/RPC interface, or
> > ...)? Just checking -- I think there's more assumptions in my head that
> > might need to get out.
> 
> No, we can read from any number of sources, nothing has to be XML.
> Like what you are saying - we just need to end up with a Maven POM in
> Java (where you need to end up with your Gump object model).
> 
> All I'm saying is that both Maven and Gump shouldn't have to implement
> the same mechanism to read all the formats gump digests (and as Maven
> pulls dependencies, it will need to get that information). If Gump
> intends to do this, all it needs to do is output a file from the gump
> object model and Maven can read just one format (and if it outputs a
> POM, even better :)
> 
> Of course, Maven *could* do all this, but either that's doubling up,
> or putting Maven at the centre of Gump, neither of which seem
> desirable :)

Maven is in the center of the developers for a project (they type "mvn"
and not "gump") so what these people want to author is a POM. Gump should
read that POM and understand it.

Question: can gump get away with writing things like settings.xml and
command line arguments and not touch any POM at all (eg maven just reads
the normal pom.xml that's already there) yet change enough of maven's
behaviour so that all the classworlds match up properly with the "gump
process"?

Maybe we should just try it and see how far we get.

- Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)

Posted by Brett Porter <br...@gmail.com>.

On 11/14/05, Leo Simons <ma...@leosimons.com> wrote:
> On Mon, Nov 14, 2005 at 09:53:01PM +1100, Brett Porter wrote:
> > We probably need a compatibility option, but it's listed on the known
> > incompatibility pages.
>
> Aw, that sucks as a concept! I thought maven1 was going to stay compatible
> and there'd be painfulness only once (maven1 -> maven2)?

Why is having to set a compat option painful?

It's about getting better metadata - a lot of people make typos and
don't realise it, and its hard to track down.

There's nothing in there we set out to break existing builds with, but
we did drop support for things that we said a long time ago were
unsupported.

> IMHO maven is broken and its behaviour should change. Validate XML if
> there is a reference to a DTD or a schema or a pomVersion bigger than X,
> otherwise preserve the old behavior. Or something.

There is a schema. It's optional to declare it.

> If maven is not going to change, then yes, that would make sense, but
> I think some people are not going to be very happy.

Most people have been happy to change their pom, not realising the
elements weren't being used before. If this is something you think is
an issue, then by all means complain to the relevant list.

On the gump side, I can't see why you wouldn't use the latest no
matter how broken you think it is. Isn't that the point?

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)

Posted by Leo Simons <ma...@leosimons.com>.

On Mon, Nov 14, 2005 at 09:53:01PM +1100, Brett Porter wrote:
> We probably need a compatibility option, but it's listed on the known
> incompatibility pages.

Aw, that sucks as a concept! I thought maven1 was going to stay compatible
and there'd be painfulness only once (maven1 -> maven2)?

> We actually started validating the project.xml files. Some people have
> a lot of random content in there that was previously silenty ignored.

Grr. Very useful, that was. I know I did stuff like

  <jsd>
    <custom-metadata-here/>
  </jsd>

:-)

> Maybe its worth considering them a failed build for the purposes of
> Gump so that they update it?

IMHO maven is broken and its behaviour should change. Validate XML if
there is a reference to a DTD or a schema or a pomVersion bigger than X,
otherwise preserve the old behavior. Or something.

If maven is not going to change, then yes, that would make sense, but
I think some people are not going to be very happy.

cheers!

LSD

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Leo Simons <ma...@leosimons.com>.

I missed a bit..

On Fri, Nov 18, 2005 at 10:27:53PM +1100, Brett Porter wrote:
> On 11/16/05, Leo Simons <ma...@leosimons.com> wrote:
> > 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
> 
> Fine by me. I assume gump3 is not far off then?

Heh, I wish :-). We don't have a working webapp nor do we have it sending
out email. But there's a lot of the hard problems solved in there and for
me its just a whole less painful to work with (I still get lost around the
gump2 codebase all the time).

I hope to find more time to hack on it. Its not far off in terms of man
hours, I hope :-)

LSD

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Brett Porter <br...@gmail.com>.

On 11/18/05, Leo Simons <ma...@leosimons.com> wrote:
> Bing! Light bulb went on in my head. Pull not push. I'm trying to think
> about an easy way to do the pull stuff, but that is probably all dependent
> on the mechanisms maven employs.

I'm pretty sure I can do this.

>
> Both gump and maven 2 are neatly "inversion of control". Both made the right
> decisions but this really makes things harder as there's a wrestle for
> control. I think I now also understand better why continuum is a real need
> in a maven 2 world -- its just natural to not try and to subvert the
> control that maven 2 implements.

Right - it builds on top of it that fit that pattern.

> Why do you keep referring to a something.xml? Is it going to be a lot
> easier to have the maven jar resolver read a something.xml rather than do
> something else (like, I dunno, a database, or an XML/RPC interface, or
> ...)? Just checking -- I think there's more assumptions in my head that
> might need to get out.

No, we can read from any number of sources, nothing has to be XML.
Like what you are saying - we just need to end up with a Maven POM in
Java (where you need to end up with your Gump object model).

All I'm saying is that both Maven and Gump shouldn't have to implement
the same mechanism to read all the formats gump digests (and as Maven
pulls dependencies, it will need to get that information). If Gump
intends to do this, all it needs to do is output a file from the gump
object model and Maven can read just one format (and if it outputs a
POM, even better :)

Of course, Maven *could* do all this, but either that's doubling up,
or putting Maven at the centre of Gump, neither of which seem
desirable :)

> Gump3 will ignore everything it doesn't understand as long as its valid
> XML. I think gump2 does the same but I'm less sure -- just try :-)

Will do.

>
> Hey Brett, are you going to be at ApacheCon and esp. the hackathon? I'd
> love to get some help digesting maven 2 internals! :-)

Yep. See you there!

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Leo Simons <ma...@leosimons.com>.

On Fri, Nov 18, 2005 at 10:27:53PM +1100, Brett Porter wrote:
> Yes, but you are going to have to go the other way around. It's a
> component that resolves artifacts and metadata. It doesn't get fed, it
> hunts.

Bing! Light bulb went on in my head. Pull not push. I'm trying to think
about an easy way to do the pull stuff, but that is probably all dependent
on the mechanisms maven employs.

Both gump and maven 2 are neatly "inversion of control". Both made the right
decisions but this really makes things harder as there's a wrestle for
control. I think I now also understand better why continuum is a real need
in a maven 2 world -- its just natural to not try and to subvert the
control that maven 2 implements.

> Unfortunately, the assumptions above won't work. Maven needs to
> resolve JARs, and resolve dependencies via metadata. This means it has
> to be able to find the JARs (Seems easy enough), and the metadata -
> which means reading gump.xml/pom.xml/something-else.xml.
> 
> In the part above where you create a gump object model, you will need
> to write that out in a form so that Maven (though the gump java
> helper) can digest it and get the proper ids and the dependencies.

Why do you keep referring to a something.xml? Is it going to be a lot
easier to have the maven jar resolver read a something.xml rather than do
something else (like, I dunno, a database, or an XML/RPC interface, or
...)? Just checking -- I think there's more assumptions in my head that
might need to get out.

> Is it possible for me to put ID mappings into the gump2/3 descriptor
> without breaking anything, or will we need to align them?

Gump3 will ignore everything it doesn't understand as long as its valid
XML. I think gump2 does the same but I'm less sure -- just try :-)

Hey Brett, are you going to be at ApacheCon and esp. the hackathon? I'd
love to get some help digesting maven 2 internals! :-)

cheers,

Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2

Posted by Brett Porter <br...@gmail.com>.

On 11/17/05, Stefan Bodewig <bo...@apache.org> wrote:
> One thing that bothers me with Maven 1 from a Gump point of view is
> that I don't have any way to override jars that come bundled with
> Maven unless projects declare a dependency on them.

That's the same in m2, but its what you want as things are truly
separated (maven's are maven's, each plugins are their owns, the
project gets exactly what it declares). In m1 everything was shoved in
together.

>
> A few projects run tests without declaring a dependency on junit at
> all, and even if they did, I'm not sure where our jar would be used -
> just to compile the tests or also when the test plugin executes them?
>

Tests are run in an isolated classloader, so you have to declare a
junit dependency on the project.

> From what I read above this is going to become worse with an installed
> version of Maven 2.  So yes, any plan that allows us to really use the
> HEAD/trunk versions of Maven and all stuff Maven uses is very much
> appreciated.

This should be possible now.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Brett Porter <br...@gmail.com>.

On 11/16/05, Leo Simons <ma...@leosimons.com> wrote:
> 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

Fine by me. I assume gump3 is not far off then?

>   --> how to properly support maven2 in gump3
>

...

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

I'll come back to this.

> <project name="mvn">
>   <module name="mvn"/>
>   <depend name="maven2-bootstrap" inherit="all"/>
>   <mvn/>
>   <jar name="target/mvn.jar" runtime="true"/>
> </project>

This is oversimplified as a working Maven contains more than one jar
and a few dependencies. But the bootstrap can be used to build that
install in the first step and then the above could rebuild a new maven
install after gump has built its dependencies. That was all discussed
in my email.

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

There is no classpath. Maven starts with just classworlds, which
constructs class loaders for different areas of the system. So its
fine to run without the shell scripts, they don't do much except make
it usable, but the behaviour won't change.

> In this case we don't have a local
> installation but one running straight from trunk (just like ant).

As built above, sure.

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

You've got Maven at this point, you can build with it :)

This will just be one class, and was something I discussed in my prior email.

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

Yes, but you are going to have to go the other way around. It's a
component that resolves artifacts and metadata. It doesn't get fed, it
hunts. You can't use CLASSPATH. The helper will be the implementation
that goes and finds things.

> I hope all that made sense. Now, moving on to the first implementation
> details....

LOL. Like there weren't any implementation details above :)

Unfortunately, the assumptions above won't work. Maven needs to
resolve JARs, and resolve dependencies via metadata. This means it has
to be able to find the JARs (Seems easy enough), and the metadata -
which means reading gump.xml/pom.xml/something-else.xml.

In the part above where you create a gump object model, you will need
to write that out in a form so that Maven (though the gump java
helper) can digest it and get the proper ids and the dependencies.

Is it possible for me to put ID mappings into the gump2/3 descriptor
without breaking anything, or will we need to align them?

>
>   --> how to bootstrap maven2
>
> 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.

Currently, it downloads the bits that it depends on outside the Maven
tree. I can change those to be checked out and built too.

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

Ok, this part is fine.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2

Posted by Bill Barker <wb...@wilshire.com>.

"Stefan Bodewig" <bo...@apache.org> wrote in message 
news:87fypv7tjg.fsf@www.samaflost.de...
> On Wed, 16 Nov 2005, Leo Simons <ma...@leosimons.com> wrote:
>
>>   --> support for maven2 in gump2
>>       --> I'm not going to work on it
>
> I'd offer to do a monkey-see-monkey-do support if it is not too
> different from maven 1 support.  In general I agree that gump3 is the
> way to go and that we should do it properly.
>
> It depends on how quickly we are going to need it.  As soon as
> projects in our tree switch to Maven2 exclusively, we will at least
> need that quick-hack version.
>

I believe that both the Maven1 and Maven2 scripts use $MAVEN_HOME, which is 
the biggest problem with just creating a <mvn/> tag for Gump2.  There are 
also problems with separating the local Maven repository between Gump1 and 
Gump2.  As much as I hate to admit it, having a <mvn/> tag in Gump2 looks 
like it will be a lot of work :(.

> Stefan 




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2

Posted by Stefan Bodewig <bo...@apache.org>.

On Wed, 16 Nov 2005, Leo Simons <ma...@leosimons.com> wrote:

>   --> support for maven2 in gump2
>       --> I'm not going to work on it

I'd offer to do a monkey-see-monkey-do support if it is not too
different from maven 1 support.  In general I agree that gump3 is the
way to go and that we should do it properly.

It depends on how quickly we are going to need it.  As soon as
projects in our tree switch to Maven2 exclusively, we will at least
need that quick-hack version.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Leo Simons <ma...@leosimons.com>.

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

Re: Maven 2

Posted by Stefan Bodewig <bo...@apache.org>.

On Wed, 16 Nov 2005, Brett Porter <br...@gmail.com> wrote:

> Because it has an even more online nature (plugins are not
> preinstalled), to use an installed version we'd again need to create
> a minimal local repository including those plugins, then use offline
> mode (-o), and ensure it can't get any internet access just to make
> sure.

One thing that bothers me with Maven 1 from a Gump point of view is
that I don't have any way to override jars that come bundled with
Maven unless projects declare a dependency on them.

A few projects run tests without declaring a dependency on junit at
all, and even if they did, I'm not sure where our jar would be used -
just to compile the tests or also when the test plugin executes them?

>From what I read above this is going to become worse with an installed
version of Maven 2.  So yes, any plan that allows us to really use the
HEAD/trunk versions of Maven and all stuff Maven uses is very much
appreciated.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 2 (was Re: Maven 1.1)

Posted by Brett Porter <br...@gmail.com>.

Ok, here's the opportunity for me to write the mail in my head.

Aside from the non-existance of a gump machine right now, what is
needed to use Maven 2,
a) minimally
b) ideally

Because it has an even more online nature (plugins are not
preinstalled), to use an installed version we'd again need to create a
minimal local repository including those plugins, then use offline
mode (-o), and ensure it can't get any internet access just to make
sure.

However, it should be pretty easy to step it up to the next level.
Instead of a pre-installed repository, we can add a "Gump artifact
resolver".

What I'd need to know is the best way to make that work. Can you
verify that to resolve a JAR file in gump (assuming gump has already
built it) I'd need to:
* know the base working directory
* know the location of the gump XML file
* parse out <project name> and within that <jar name>
* look in base/project_name/jar_name

The resolver can also parse these files for depends. This would
require knowing where everything is, so even better would be:
* a list of directories creating gump descriptors
* that all files in the descriptor are relative to that gump descriptor

Is that how it is currently?

We come back to the problem of aligning IDs. I think the best place to
solve this is in the gump descriptors. Here is how I'd parse them out
in order of preference:
* GroupId:
1) <project groupId="">
2) <module groupId="">
3) <module name="">
* Artifact ID:
1) <jar artifactId="">
2) <jar id="">
3) <project artifactId="">
4) <project name="">
* Type:
1) <jar type="" />
2) <jar /> means "jar"
3) <project type="" />
4) how do you specify non-jar outputs?
* Classifier:
1) <jar classifier="" />
2) <project classifier="" />
3) default is none

If I start adding them, will it break anything?

Now, the next issue comes when Gump3 parses multiple input formats. I
don't want to duplicate information in Maven - can we get gump to pick
a format and produce that as part of the build, regardless of its
input? A POM would simplify things :)

Ok, this would have a preinstalled Maven using some packaged plugins
working offline without a manual repository setup.

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?

- Brett

On 11/16/05, Stefan Bodewig <bo...@apache.org> wrote:
> On Tue, 15 Nov 2005, Leo Simons <ma...@leosimons.com> wrote:
>
> > Actually, someone's looking at changing the excalibur build to use
> > maven 2. That pretty much means tree detoriation anyway. We're going
> > to start seeing that all over apache as projects migrate to maven 2.
>
> Pluto's trunk has already jumped to Maven 2.  We will need a maven2
> builder, that's "all".
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1

Posted by Martin van den Bemt <ml...@mvdb.net>.


Brett Porter wrote:
> I don't know of them all, but I believe the following projects are on
> the way or considering it:
> 
> Cocoon, Pluto, JetSpeed 2, Struts, Excalibur, Geronimo, Directory, Felix

Add MyFaces (they are considering it) to the list (tobago is already maven2). Struts has an attempt 
somewhere in svn (just read that on the myfaces list).

Mvgr,
Martin


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1

Posted by Brett Porter <br...@gmail.com>.

I don't know of them all, but I believe the following projects are on
the way or considering it:

Cocoon, Pluto, JetSpeed 2, Struts, Excalibur, Geronimo, Directory, Felix

Those are the ones feeling pain points in their build that Maven
solves. For the ones where it already just works, there is probably
little reason to change.

I want to get a good multiproject site/reporting solution together
before proposing it as a parallel build in commons, but I think that
there could be a lot of benefits there too.

- Brett

On 11/16/05, Dion Gillard <di...@gmail.com> wrote:
> On 11/16/05, Leo Simons <ma...@leosimons.com> wrote:
> [snip]
> > Actually, someone's looking at changing the excalibur build to use maven
> > 2. That pretty much means tree detoriation anyway. We're going to start
> > seeing that all over apache as projects migrate to maven 2.
> >
> > cheers,
> >
> > LSD
>
> Just out of curiosity, what adoption of Maven 2 has there been @
> Apache. In Jakarta I've seen very little.
> --
> http://www.multitask.com.au/people/dion/
> "You are going to let the fear of poverty govern your life and your
> reward will be that you will eat, but you will not live." - George
> Bernard Shaw
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1

Posted by Brett Porter <br...@gmail.com>.

On 11/16/05, Leo Simons <ma...@leosimons.com> wrote:
> Actually, someone's looking at changing the excalibur build to use maven
> 2. That pretty much means tree detoriation anyway. We're going to start
> seeing that all over apache as projects migrate to maven 2.

In theory, Gump should be able to build and use Maven 2 very shortly.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1

Posted by Dion Gillard <di...@gmail.com>.

On 11/16/05, Leo Simons <ma...@leosimons.com> wrote:
[snip]
> Actually, someone's looking at changing the excalibur build to use maven
> 2. That pretty much means tree detoriation anyway. We're going to start
> seeing that all over apache as projects migrate to maven 2.
>
> cheers,
>
> LSD

Just out of curiosity, what adoption of Maven 2 has there been @
Apache. In Jakarta I've seen very little.
--
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Maven 2 (was Re: Maven 1.1)

Posted by Stefan Bodewig <bo...@apache.org>.

On Tue, 15 Nov 2005, Leo Simons <ma...@leosimons.com> wrote:

> Actually, someone's looking at changing the excalibur build to use
> maven 2. That pretty much means tree detoriation anyway. We're going
> to start seeing that all over apache as projects migrate to maven 2.

Pluto's trunk has already jumped to Maven 2.  We will need a maven2
builder, that's "all".

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1

Posted by Leo Simons <ma...@leosimons.com>.

On Tue, Nov 15, 2005 at 06:28:28AM +0100, Stefan Bodewig wrote:
> On Mon, 14 Nov 2005, Brett Porter <br...@gmail.com> wrote:
> 
> > We actually started validating the project.xml files. Some people
> > have a lot of random content in there that was previously silenty
> > ignored.
> > 
> > Maybe its worth considering them a failed build for the purposes of
> > Gump so that they update it?
> 
> If it wasn't the excalibur project, maybe.
> 
> You may not have noticed it, but before I destroyed vmgump the only
> project still depending on the old Avalon codebase was James - since I
> don't find a replacement for meta-tools in Excalibur.  All other
> dependencies, in particular commons-logging's dependency on framework
> and logkit have been migrated to the Excalibur maintained versions.

I'm sure the james people would love to hear about the stuff that's
keeping them depending on the old avalon codebase. Either we migrate
that to excalibur or into james or they stop using it :-)

> On the other hand - unless Leo jumps in - I'm afraid that the
> Excalibur community doesn't care about Gump that much and we'd be left
> with a build tree that is only building around 50% or even less "just"
> because Maven started to validate the descriptors.

Actually, someone's looking at changing the excalibur build to use maven
2. That pretty much means tree detoriation anyway. We're going to start
seeing that all over apache as projects migrate to maven 2.

cheers,

LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1

Posted by Stefan Bodewig <bo...@apache.org>.

On Mon, 14 Nov 2005, Brett Porter <br...@gmail.com> wrote:

> We actually started validating the project.xml files. Some people
> have a lot of random content in there that was previously silenty
> ignored.
> 
> Maybe its worth considering them a failed build for the purposes of
> Gump so that they update it?

If it wasn't the excalibur project, maybe.

You may not have noticed it, but before I destroyed vmgump the only
project still depending on the old Avalon codebase was James - since I
don't find a replacement for meta-tools in Excalibur.  All other
dependencies, in particular commons-logging's dependency on framework
and logkit have been migrated to the Excalibur maintained versions.

On the other hand - unless Leo jumps in - I'm afraid that the
Excalibur community doesn't care about Gump that much and we'd be left
with a build tree that is only building around 50% or even less "just"
because Maven started to validate the descriptors.

Breaking backwards compatibility, even with the best reasons, is very
difficult to do and to get accepted.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)

Posted by Brett Porter <br...@gmail.com>.

We probably need a compatibility option, but it's listed on the known
incompatibility pages.

We actually started validating the project.xml files. Some people have
a lot of random content in there that was previously silenty ignored.

Maybe its worth considering them a failed build for the purposes of
Gump so that they update it?

- Brett

On 11/14/05, Leo Simons <ma...@leosimons.com> wrote:
> On Mon, Nov 14, 2005 at 05:55:48AM +0100, Stefan Bodewig wrote:
> > On Sun, 13 Nov 2005, Bill Barker <wb...@wilshire.com> wrote:
> > > "Stefan Bodewig" <bo...@apache.org> wrote in message
> > > news:87y83y2710.fsf@www.samaflost.de...
> >
> > >> The version of dom4j that Maven 1.0.2 uses is quite old - some
> > >> prerelase of 1.4.  Maybe we could upgrade to Maven 1.1?
> > >
> > > I just tried with Maven 1.1b2, and Maven chokes on the Excalibur
> > > project.xml long before getting to Struts.  It looks like there
> > > isn't enough backwards compatibility in Maven to make it possible to
> > > upgrade the version that Gump is using.
> >
> > That's unfortunate.  Thanks for checking.
>
> Heh. I'm sure maven would appreciate a bug report, so they can fix it :-)
>
> -LSD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)

Posted by Leo Simons <ma...@leosimons.com>.

On Mon, Nov 14, 2005 at 05:55:48AM +0100, Stefan Bodewig wrote:
> On Sun, 13 Nov 2005, Bill Barker <wb...@wilshire.com> wrote:
> > "Stefan Bodewig" <bo...@apache.org> wrote in message 
> > news:87y83y2710.fsf@www.samaflost.de...
> 
> >> The version of dom4j that Maven 1.0.2 uses is quite old - some
> >> prerelase of 1.4.  Maybe we could upgrade to Maven 1.1?
> > 
> > I just tried with Maven 1.1b2, and Maven chokes on the Excalibur
> > project.xml long before getting to Struts.  It looks like there
> > isn't enough backwards compatibility in Maven to make it possible to
> > upgrade the version that Gump is using.
> 
> That's unfortunate.  Thanks for checking.

Heh. I'm sure maven would appreciate a bug report, so they can fix it :-)

-LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)

Posted by Stefan Bodewig <bo...@apache.org>.

On Sun, 13 Nov 2005, Bill Barker <wb...@wilshire.com> wrote:
> "Stefan Bodewig" <bo...@apache.org> wrote in message 
> news:87y83y2710.fsf@www.samaflost.de...

>> The version of dom4j that Maven 1.0.2 uses is quite old - some
>> prerelase of 1.4.  Maybe we could upgrade to Maven 1.1?
> 
> I just tried with Maven 1.1b2, and Maven chokes on the Excalibur
> project.xml long before getting to Struts.  It looks like there
> isn't enough backwards compatibility in Maven to make it possible to
> upgrade the version that Gump is using.

That's unfortunate.  Thanks for checking.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org