RE: [Gump Wiki] Updated: GumpPython

[Brett Porter]

These emails also have no sent time attached. Can this be fixed?

Cheers,
Brett

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: None
> To: [EMAIL PROTECTED]
> Subject: [Gump Wiki] Updated: GumpPython
> 
> 
>Date: 2004-03-04T12:23:49
>Editor: 80.128.237.57 <>
>Wiki: Gump Wiki
>Page: GumpPython
>URL: http://wiki.apache.org/gump/GumpPython
> 
>fixed some URLs jakarta-gump -> gump
> 
> Change Log:
> 

RE: [GUMP@lsd]: ant-1.5/ant-1.5 failed

[Brett Porter]

Hi Stefan,

This would be contributing to Maven's failure with Ant 1.6 then, too. We had
to roll that back. Additionally, the classloader changes caused a few
problems.

I'd be interested to hear what you find out regarding 1.6 and Jelly.

Cheers,
Brett

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, 8 April 2004 3:51 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [EMAIL PROTECTED]: ant-1.5/ant-1.5 failed
> 
> 
> The build fails because Gumpy passes quite a few command line 
> arguments to bootstrap.sh that are not expected.
> 
> In particular the -Xbootclasspath option kills Ant.
> 
> System properties as well as the -verbose switch shouldn't 
> apply to 

RE: Ant 1.6 and Jelly/Maven (was Re: [GUMP@lsd]: ant-1.5/ant-1.5 failed)

[Brett Porter]

Ok, I've gotten myself on [EMAIL PROTECTED] because I'm interested in that anyway, so
I won't cross-post to gump again :)

> > This would be contributing to Maven's failure with Ant 1.6 
> then, too.
> 
> Quite possible.
> 
> I didn't know that Maven had a problem with Ant 1.6, even 
> though I am subscribed to the Maven dev list.  We really 
> should collaborate on issues like this - if you Maven guys 
> have trouble with Ant, please tell us Ant guys.

We did discuss it on dev for a while. dIon made the changes and we rolled it
back when we saw some incompatibilities.

There's nothing insurmountable there, but its going to require some
incompatible changes to be made, and'll have to wait until after 1.0. This
is the only reason it hasn't been taken any further just yet.

The future versions of Maven will probably use Maven differently and Jelly
sparingly, so it may be a non-issue.

> The on-topic part for Gump: If Maven could 
> be built by Gump, we might have seen this issue long before 
> Ant 1.6.0 was released.

:)

I'm actually working on this right now. I'm going to make a custom build
somewhat like the bootstrap but simpler. I was worried about the ant issue -
but if there is an ant-1.5 build then that is perfect for now. I'll post
separately to gump.

> Back to the issue at hand.  I'm sort of stuck here.  I don't 
> know anything about Jelly and Jelly development has stopped 
> AFAICT.  There doesn't seem to be anybody left I could ask 
> questions or who'd apply patches should that become 
> necessary.  It may very well be an issue like 

> where we can't fix Ant, but can provide a work-around so that code works
with Ant 1.5.x and 1.6.x afterwards.

Yes, James' public apology for Jelly probably doesn't bode well for its
future :)

This looks like the right track for the issue, although to be honest I think
I know about as much as you do at this point. I haven't looked in much depth
at the bindings of Maven to Ant in the past as I joined Maven after it was
in its current state.

> If Maven has the same problems, at least you could help me track it down.
I'm more than willing to get this resolved and we should try to do so (after

> Easter since I'll be offline during the holidays) in any way that works
for you.

My focus is elsewhere presently, but I'm happy to work with you on this
wherever I can help out.

> Yes, I understand that.  We know pretty well that the change broke some
things, but we did so consciously to solve a whole slew of other issues and
won't > revert it.

I think it's great. It should be a lot better to Maven, but the fact that it
will change will flow on to users currently, so we've bumped the upgrade to
1.1 or whatever comes next.

> How does Maven integrate with Ant?  The classloading changes shouldn't
affect Maven unless it runs Ant via the command line interface or the new
Launcher > class.  Do you have any details here?

commons-grant. It defines a derived AntClassLoader, AntProject and
propshandler to integrate a jelly context.

Cheers,
Brett

Maven and Gump again

[Brett Porter]

Just quickly before I leave for the day... But Stefan reminded me.

I'm planning to take a look at this in the coming week - but I was wondering
what the best approach is.

There is already a goal that will produce a maven installation using Maven -
is this enough for gump, or does Maven need to be able to build from ant (I
imagine it does)?

If so, I will adjust the bootstrap and make a build-gump.xml file that makes
a minimal maven installation, then runs "maven maven:installer" to make a
full one.

I will also update the gump plugin to generate either a maven or ant
descriptor: anyone have a link to where the final  tag format is?

Sorry for the hurriedness of the email...

Cheers,
Brett
 
--
Brett Porter ~ [EMAIL PROTECTED]
blog: http://blogs.codehaus.org/people/brett
Maven: http://maven.apache.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven/Gump & Artefact/Jar Identifiers

[Brett Porter]

Seems to be a bit of confusion here. I'll write a full email on how I see
maven and gump interacting.

- Brett

> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, 12 May 2004 4:32 AM
> To: Gump code and data
> Subject: Re: Maven/Gump & Artefact/Jar Identifiers
> 
> 
> On Wednesday 12 May 2004 01:19, Adam R. B. Jack wrote:
> > But each is a separate artefact to Maven, right?
> 
> No, not a requirement, only a recommendation.
> 
> > Gump is (as Leo would say) not a participant with an opinion, but a 
> > developer emulator. Gump needs to do what developers do, so 
> how Maven 
> > is used depends upon the existing projects. Right now it seems that 
> > calling the 'jar' goal is about right (although it is configurable).
> 
> Yes, the goal to be called must be 'settable' in the Gump 
> descriptor, just 
> like you can set the target in the  element.
> 
> 
> > Verses leaving things where they are, and using the jar override 
> > properties in the build.properties (again in offline mode) as we do?
> 
> Yes, the reason would be that according to Brett, all plugins 
> doesn't support 
> the build.properties you are refer to. It may not be a 
> problem to do what you 
> are doing, but it may not reflect the reality (incl, that one 
> can access the 
> pom.dependencies directly in one's maven.xml and do all kind 
> of funky stuff).
> 
> Niclas
> -- 
> +-//---+
> |   http://www.bali.ac |
> |  http://niclas.hedhman.org   |
> +--//--+
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Gump integration with Maven

[Brett Porter]

Hi,

I was finding myself a bit confused by the gump talk in context of Maven,
especially with all the different spellings of artifact :) I thought I
should recount how I think they can work together in a way that meets gumps
goals - let me know if I've got it wrong. I apologise for length.

Firstly, Maven's repository structure is setup to uniquely identify a
particular dependency by a combination of group ID, artifact ID, type (JAR
in all cases for gump I think, maybe extending to encompass plugin) and
version.

Formerly, groupID = artifactId and was called "id", and there is still a lot
of evidence of that legacy in Maven projects. For now, I think that gump
should concern itself with artifactId and not groupId. If there comes an
occasion that two maven projects with two group Ids produce the same
artifact Id, then we might need to look at alternatives to resolve the
conflict.

So, to sum up this point: I think gump should have just one id for a
project, that being the artifact Id for now, and using the full Maven ID
(groupId:artifactId:type) later when support and project usage is better.

If this needes to be done alongside ant projects, I'll leave it up to the
gump folk to decide how this is best treated. I imagine there shouldn't be
clashes as projects will be either maven or ant, not both (while it might be
possible, I imagine they only get gumped with one).

Next, to building projects with maven inside gump, which is happening now. I
think a build.properties file is being generated per project, and wanted to
suggest the generation of an all encompassing jar override build.properties
file in the user home directory. This will allow specifying the location of
all JARs coming from gump, and will automatically apply to all maven built
projects, including the maven plugins themselves. This should be much easier
to maintain.

The downside to this, is I imagine a bunch of Maven plugins will freak out
at more recent versions of Jelly or other things, and this could hold up
this part for a while to fix it. I think a fallback needs to be in place,
and I'm not sure the best way to do this (copy the build.properties to all
the projects being built, and remove it from the user home directory so that
Maven itself is the only thing unaffected?)
This is worth trying, as we might get further than expected, and certainly
it appears gumps goal is to go down this path.

The final item is gumping Maven itself. I've taken a look at building a new
ant based bootstrap for this, and think it isn't necessary. Let me know if
you agree. Based on the following.

The current ant based bootstrap uses an ant task to do the first build of a
maven core, using a set of known dependencies. It then uses this
installation to build all the plugins, and finally it rebuilds maven
completely using maven. At this last step, the jar overrides would kick in
and maven would be completely built using a latest JAR maven. So while the
whole process is not under gumps ideals, the end result is. 

Is this enough? I'd prefer not to have to modify this bootstrap for now.

An alternative of course is to use a "known good" maven to build maven which
we have goals for too.

There is one stumbling block here: even if all the right JARs are put into
$MAVEN_HOME/lib, forehead.conf hardcodes some filenames. Wildcards can be
used, so this can easily be worked around if it becomes a problem.

Let me know where to go next! 

Also, I seem to have lost the format for the http://blogs.codehaus.org/people/brett
Maven: http://maven.apache.org/

RE: Gump integration with Maven

[Brett Porter]

> > So, to sum up this point: I think gump should have just one 
> id for a 
> > project,
> 
> What about projects that produce multiple jars?

Sorry... I didn't realise that gump had a notion of a project that produces
multiple artifacts. In maven, project to artifact Id is 1:1, however a
project can produce multiple different 'types' of the same artifact (eg,
documentation, jar, or maybe different types of dist: src, bin, etc)

So if gump has a project id and a jar id under that which is usually the
same, this sounds something like groupId:artifactId. But to keep it simple -
one gump id per jar produced sounds ok.

> 
> > If this needes to be done alongside ant projects, I'll 
> leave it up to 
> > the gump folk to decide how this is best treated.
> 
> I'm not sure whether I parse this correctly.  There will 
> always be projects that want to be built by Maven but depend 
> on things that have not been built by Maven.  So we'll have 
> to make up some ids - or use those that have been made up by others.

Ok, I see your point. Maven projects will have been built against these
assuming the structure in ibiblio, so it seems that gump will have to match
up the artifactId in there regardless.

> > The downside to this, is I imagine a bunch of Maven plugins 
> will freak 
> > out at more recent versions of Jelly or other things, and 
> this could 
> > hold up this part for a while to fix it.
> 
> Aren't you going to release Maven and the 
> plugins rather soon?  Wouldn't you want your plugins to work 
> with latest Jelly?

We'd love for it all to work with the latest Jelly and Ant, but the current
structure has prohibited upgrading without a high risk. Post-1.0 this will
be revisited.

> Seriously, since we are trying to get things working in the 
> first place, we may be better of with using a more 
> conservative approach and switch to the mode you propose here 
> later - once we have a working setup.

ok

Thanks!

Cheers,
Brett 

RE: Maven on Gump

[Brett Porter]

Someone has deleted the local repository that you were using. Until all the
maven plugins you have use project.properties overrides, you'll have to
maintain a local repository with the JARs they need.

Running gump once without offline ought to correct this?

BTW, we are getting really close to releasing Maven 1.0, so I'll have some
time to set up the gump bootstrap of Maven via ant so you can do this all
nicely. I'll send through more info when I get there...

- Brett

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, 11 May 2004 2:22 PM
> To: Apache Gump
> Subject: Maven on Gump
> 
> 
> The Maven hasn't been updated, nor should have the project. 
> The Maven is being called using --offline, so oughtn't be 
> network savvy. Still something has changed, 'cos this started failing.
> 
> Any guesses how & why this would start failing (about 4 runs ago)?
> 
http://brutus.apache.org/gump/public/jakarta-gump-test/gump-test-maven1/gump
_work/build_jakarta-gump-test_gump-test-maven1.html

regards

Adam
--
Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven on Gump

[Brett Porter]

> > Running gump once without offline ought to correct this?
> 
> I can try that. Is this just once after install?

Yes, unless you keep the resultant repository, tar it up, and install it as
well.

- Brett

RE: Maven/Gump & Artefact/Jar Identifiers

[Brett Porter]

Adam,

I think artifact ID = jar ID, as the resultant filename in a repository is
always artifactId-version.jar

Whether the artifact ID or jar ID gets changed is probably on a project by
project basis.

I'm not entirely convinced myself though, and it would be worth getting an
opinion on maven-dev.

Cheers,
Brett

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, 6 May 2004 3:29 AM
> To: Gump code and data
> Subject: Maven/Gump & Artefact/Jar Identifiers
> 
> 
> I tinkered with using Maven to build commons-id. Some 
> success, but the problems come down to artefact identifiers. 
> I.e. commons logging is passed as a dependency (in the 
> build.properties file), but the 'Maven jar override' fails to 
> kick in 'cos the jar id (all) is different from the artefact 
> id (commons-logging).
> 
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/inde
x.html

[please forgive the wrap bug] The salient lines are below:

http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump
_file/commons-id+build.properties.html

# Note 'all' not 'commons-logging':
maven.jar.all=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/
commons-logging.jar
maven.jar.api=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/
commons-logging-api.jar

This page shows the problem quite well:

http://brutus.apache.org/gump/public/gump_xref/output_id_project.html

So, question. Do we try to rename all jar identifiers to match Maven
artefact identifiers (semi-appealing, if there isn't some gotcha) or do we
add a new attribute 'artefactId' to fullfill this role? Any other
thoughts/ideas?

Please let me know if I've not explain the problem well enough.

regards,

Adam
--
Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Gump integration with Maven

[Brett Porter]

The commons-logging ant build has been customised from one generated by
Maven. The Maven build does not produce the api JAR, although it could
easily be modified to do so in one of two ways:
- a custom postGoal on jar:jar in maven.xml to produce the second JAR with
the same ant code as is in build.xml
- a new goal that gump calls differently (eg
commons-logging:generate-api-jar prereqs="jar:jar")
- a sub project with artifact id commons-logging-api that takes the original
source directory with the relevant exclusions

I don't see a problem with either as long as gump can handle it. The third
is probably the preferred Maven solution and would fit with what we've been
discussing and is a much shorter solution (a cut down project.xml that
extends the original and overrides the source directory).

Either way, the groupId remains commons-logging, with the artifactIds being
commons-logging and commons-logging-api.

Cheers,
Brett

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, 15 May 2004 1:00 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Gump integration with Maven
> 
> 
> On Fri, 14 May 2004, Brett Porter <[EMAIL PROTECTED]> wrote:
> 
> > Sorry... I didn't realise that gump had a notion of a project that 
> > produces multiple artifacts.
> 
> Hmm, commons-logging is built by Maven.  Its Ant build file 
> produces two jars, commons-logging.jar and 
> commons-logging-api.jar - how does Maven deal with this?  Are 
> these two separate projects?  Or a group of two artifacts?  
> This is the case we need to get mapped when running Gump.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

RE: Gump integration with Maven

[Brett Porter]

> Yup, I think we need ASF-wide artefact ids (within group 
> ids). I'd like to think the community and/or communities can 
> come to agreement on what the values are, and if that means 
> defaulting to what Maven/Ibiblio already have, then so be it. 
> Consistency is the key more than anything else.

Sounds like a sensible approach.

> Hopefully we can have Maven bootstrap and plug-in testing in 
> Gump, to help identify such risk early on.

We knew about the problem early on, but weren't prepared to make the core
changes required to do this at the stage Maven was at. Sometimes to keep a
project moving forward, you don't want the "bleeding edge".

> I have concerns that I can't (easily) code what you asked for 
> (Gump plods through projects, and builds build.properties for 
> dependencies, it doesn't look ahead to be able to build a 
> workspace-wide list.) I'll keep an open mind on what you said 
> though, and see if I can figure out how.

What I was thinking was that you would generate the build.properties from
the list of gumped projects, rather than dependencies. If a project is not
gumped, the dependency will have to come from a repository anyway, right?
How do you intend to handle this case as projects come on board that use
non-ASF libraries?

> Please keep with us, and work with us to bootstrap Maven & 
> we'll work through these issues. [Again, changing the maven 
> 'gump' goal to produce  prove out what we are doing. Artefact's first...]

No problem. Just say when.

Cheers,
Brett

RE: Gump integration with Maven

[Brett Porter]

> > What I was thinking was that you would generate the 
> build.properties 
> > from the list of gumped projects, rather than dependencies.
> 
> Not quite following the distinction, but maybe I am too close 
> to the currently implementation. Gump has a list of projects 
> it is working on and/or knows about, and a project has 
> dependencies within that list.

I assumed projects was a subset of dependencies as some dependencies are not
gumped projects. You should need JAR overrides for all gumped projects, but
not dependencies that are not gumped for some reason. I'd consider packages
to be "gumped", but I think you are right - you should probably use a Maven
repository for Maven projects when they use a non-gumped non-packaged JAR
instead of creating a new package. (Is this making sense? I'm confusing
myself a little with all the jargon :)

> What I'm saying it is I can build a build.properties based on 
> the list of Gumped projects & intersected with the 
> dependencies. For me to understand what is 'not right' about 
> this, are you sayign this is fine, but any Maven plug-ins 
> that the build uses has dependencies that are not listed?

No, I think this is exactly what I meant. Gumped projects + packages produce
a big list of available JAR files, which go into ~/build.properties which
can be used globally assuming that the dependency tree gets traversed
correctly and the JARs actually exist by the time they are used. 

This produces the same end result as a build.properties file for every
project, but keeps it in a master copy, and will also affect Maven itself to
the extent of the plugins.

Anyway, it seems this is academic at this point, as we need to stick to the
per project one to avoid breaking Maven for now.

> If so, in Gump  dependencies into dependencies of the current project. Would 
> that work here? [Point me back at the archive if I've finally 
> caught on to what you explain a few mails back.]

I'm not sure I get this, sorry.

Anyway, I think the current approach is the right one for now and we can
look at alternatives down the track when we actually want to gump Maven.

Cheers,
Brett

RE: Gump integration with Maven

[Brett Porter]

Agreed.

> I think the real challenge is at the project level, projects need to 
> establish naming consistent with their Umbrella group, this is a real 
> growing pain at this point, I suspect eventually the entire Jakarta 
> Commons will need to migrate to 
> jakarta-commons/jakarta-commons-foo-x.x.ext from 
> commons-foo/foo-x.x.ext 
> sometime in the near future. But it would probably be good to 
> have the 
> system consistent before that point and keep such transitions 
> separate.

RE: [GUMP@brutus]: maven/maven-bootstrap failed

[Brett Porter]

Hi,

Can someone explain how this came about? I haven't seen any updates on the
gump list to indicate that Maven was going to be bootstrapped there yet.

A few issues:
- can we change it not to go to [EMAIL PROTECTED] until the gump end is working, as
it is probably just confusing
- commons-grant is in the commons sandbox. You won't be able to use CVS HEAD
for this as it has been messed around with to try and use Ant 1.6 and breaks
Maven as it currently is.
- Not sure why dIon's old email address is the sender?

Thanks,
Brett

> -Original Message-
> From: dIon Gillard [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, 22 May 2004 9:25 PM
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: maven/maven-bootstrap failed
> 
> 
> To whom it may engage...
> 
> This is an automated request, but not an unsolicited one. For help 
> understanding the request please visit 
> http://gump.apache.org/nagged.html, 
> and/or contact [EMAIL PROTECTED]
> 
> Project maven-bootstrap has an issue affecting its community 
> integration. The current state is 'Failed', for reason 
> 'Configuration Failed'
> 
> Full details are available at:
> 
> http://brutus.apache.org:8080/gump/maven/maven-bootstrap/index
.html
That said, some snippets follow:


Gump provided these annotations:
 - Info - Dependency on ant exists, no need to add for property
maven.jar.ant.
 - Info - Failed with reason configuration failed
 - Error - Bad Dependency. Project: commons-grant unknown to *this*
workspace


To subscribe to this information via syndicated feeds:
RSS: http://brutus.apache.org:8080/gump/maven/maven-bootstrap/rss.xml
Atom: http://brutus.apache.org:8080/gump/maven/maven-bootstrap/atom.xml

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Gump w/ Maven (was Re: Sending mails and reports)

[Brett Porter]

>
http://brutus.apache.org:8080/gump/apache-gump-test/gump-test-maven1/gump_wo
rk/build_apache-gump-test_gump-test-maven1.html#Output
> 
> [Hmm, for some reason the Maven log isn't showing up, not sure why.]

It appears there for me... Or are you referring to some output from the now
non-existent maven.log file?

Also, RC3 is out... Might want to upgrade :)

Cheers,
Brett

RE: Gump w/ Maven (was Re: Sending mails and reports)

[Brett Porter]

> It appears there for me... Or are you referring to some output from 
> the
now
> non-existent maven.log file?
> 
> Ah, the latter I believe. So no longer exists? Ok, I'll remove code that
looks for it.

No - everything was in maven -X already anyway.

If you want to customise the logging in anyway you can pass in a
log4j.properties via the system property as per log4j's documentation, but
maven -X should do just fine.

> > Also, RC3 is out... Might want to upgrade :)
> 
> Sure. That said, anything changed relevent to anything we do here? Just
curious.

I thought when anything changed it was relevant to what you do :)

Just bugfixes. Nothing gump-wise.

Maven 1.0 is scheduled for around June 1 so if you aren't doing anything
other than test with Maven until then, maybe it's worth waiting.

Now on a whole new topic...

I believe that some projects run javadoc so that gump can link to the latest
API documents. I noticed Ant have pulled it from there website and link to
gump (although the link is broken! I'll ping [EMAIL PROTECTED])

I was wondering whether it would be considered to do the same for Maven
projects, except that the whole release site could be generated to get the
latest reports like CVS changelogs, etc. I do this at work with our
continuous integration.

Thoughts?

Cheers,
Brett

RE: Gump w/ Maven (was Re: Sending mails and reports)

[Brett Porter]

Hi Adam,

You got it right.

Basically, Maven became API-stable at RC2. Several plugins were released
between RC2 and RC3 using this for the API as the releases are independent.

You'll usually have to run everything through online to pick up all the new
plugin dependencies after upgrading a plugin or a new Maven release.

Cheers,
Brett

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 28 May 2004 6:09 AM
> To: Gump code and data
> Subject: Re: Gump w/ Maven (was Re: Sending mails and reports)
> 
> 
> 
> > > RC3 doesn't seem so happy -- *as I installed it*. Do I 
> need to run 
> > > it
> once
> > > (online) or something? Any particular goal?
> >
> > Ok, assuming the answer is yes, I tried. Why does it want 
> rc2 for rc3?
> Some
> > plugins need clearing out or something?
> 
> Gosh I hate it when I have public conversations w/ myself. 
> Makes me think I ought wait a while longer (and think a while 
> more) before pressing send. Hmm ... I ought.
> 
> I deleted ~/.maven (or moved to ~/.maven-rc2) and ran maven 
> online. Let's see...
> 
> BTW: Nice to see commons-id and geronimo both trying to build...
> 
> regards,
> 
> Adam
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

RE: cvs commit: gump/project maven.xml

[Brett Porter]

I think we had this taken out on purpose because it is known to be broken.

Regardless, why would dIon be the sender? I don't think he's subscribed with
that address any more.

- Brett

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Monday, 7 June 2004 2:23 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: gump/project maven.xml
> 
> 
> niclas  2004/06/06 21:22:50
> 
>   Modified:project  maven.xml
>   Log:
>   No reason why Maven shouldn't declare a  to its mailing list...
>   
>   Revision  ChangesPath
>   1.9   +4 -4  gump/project/maven.xml
>   
>   Index: maven.xml
>   ===
>   RCS file: /home/cvs/gump/project/maven.xml,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- maven.xml   24 May 2004 20:28:47 -  1.8
>   +++ maven.xml   7 Jun 2004 04:22:50 -   1.9
>   @@ -58,8 +58,8 @@
>
>
>
>   -
>   +   + to="[EMAIL PROTECTED]"/>
>  
>
>  
>   @@ -112,8 +112,8 @@
>
>
>
>   -
>   +   + to="[EMAIL PROTECTED]" />
>  
>  
>
>   
>   
>   
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

RE: Maven 'gump' Re: [vfs][all]maven generated build file and con ditional compilation

[Brett Porter]

I'll implement it some time this week and send it round to test.

Adam, would you mind raising a JIRA issue against maven-gump-plugin?

Thanks,
Brett

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, 8 June 2004 8:48 AM
> To: Apache Gump
> Subject: Maven 'gump' Re: [vfs][all]maven generated build 
> file and conditional compilation
> 
> 
> 
> > > gump.xml is the descriptor generated by "maven gump" IIRC.  Since 
> > > Gump's support for Maven as a build tool is rather new, there 
> > > probably is no automated way to generate a Gump descriptor from 
> > > project.xml yet.
> 
> Hmm, ought we ask for the change prior to a Maven 1.0 
> release? I can't see what we'd want to change for  the foreseeable, and think it'd be nice to get in before 
> their release, if possible.
> 
 http://gump.apache.org/metadata/maven.html

regards

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Ought we consider a Gump on Brutus running JDK1.5?

[Brett Porter]

My 2c: I would have it ready to go when 1.5 goes into first release (so get
it ready now), but not nag anyone until then. While there might be helpful
stuff, you'd want to avoid nagging people for bugs in the betas too - and it
might be hard to differentiate.

I think it's a good idea though.

- Brett

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 11 June 2004 1:48 AM
> To: [EMAIL PROTECTED]
> Subject: Ought we consider a Gump on Brutus running JDK1.5?
> 
> 
> As more and more people go there, it'll get more and more 
> painful for us not to be.
> 
> Berin's post made me think of this:
> 
http://jroller.com/page/bloritsch/20040610#re_eintering_the_cocoon

regards,

Adam
--
Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven 'gump' Re: [vfs][all]maven generated build file and con ditional compilation

[Brett Porter]

Hi Adam,

Have you had a chance to look at the changes I made to do this?

Thanks,
Brett

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, 8 June 2004 11:09 PM
> To: Gump code and data
> Subject: Re: Maven 'gump' Re: [vfs][all]maven generated build 
> file and conditional compilation
> 
> 
> 
> > I'll implement it some time this week and send it round to test.
> >
> > Adam, would you mind raising a JIRA issue against maven-gump-plugin?
> 
> I've entered this:
> 
http://jira.codehaus.org/browse/MPGUMP-1

I've kept it simple, no requests for automatically adding 

Re: Maven 'gump' Re: [vfs][all]maven generated build file and conditional compilation

[Brett Porter]

That's cool.

Whatever's easier - I can provide a snapshot JAR to download, although
cvs co maven-plugins/gump and then maven plugin:install works too.

- Brett

On Wed, 16 Jun 2004 16:42:03 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> 
> Brett wrote:
> 
> > Have you had a chance to look at the changes I made to do this?
> 
> Sorry Brett, either Jira failed to notify, or I missed it. I'll try to get
> to it soon. I assume I checkout Maven from CVS and build (or something,
> right?) Or, is there a way to download/preview plug-ins? Sorry for being
> dense w.r.t Maven.
> 
> regards
> 
> Adam
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Gump Plugin 1.4 Released

[Brett Porter]

The maven team is pleased to announce the Maven Gump Plug-in 1.4 release! 

http://maven.apache.org/reference/plugins/gump/



Changes in this version include:

  New Features:

o Allow creation of http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-gump-plugin-1.4.jar
 

Have fun!
-The maven team
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fw: [ANN] Maven Gump Plugin 1.4 Released

[Brett Porter]

No problem. Let me know if it needs any changes.

Cheers,
Brett

On Sat, 10 Jul 2004 20:43:39 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> Brett,
> 
> Thanks very much! Sorry I didn't find time to look at the plug-in, I was
> pre-occupied w/ work & EMT classes. Thanks for helping out with it.
> 
> regards
> 
> Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Unit tests in Maven builds on Gump

[Brett Porter]

I remember fixing a bug (although I think it was in unrelated goals)
in the test plugin that didn't put junit on the classpath when the
tests are forked.

You can try upgrading to the latest test plugin (or Maven 1.0) to see
if the bug was fixed. If not, try not forking the tests (this might
cause other classloader issues though). Or, you can add junit to the
dependencies (no harm in this).

Sorry, won't have time to look any closer for about 3 weeks as I'm on holidays.

Cheers,
Brett

On Thu, 29 Jul 2004 12:21:09 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> Brett (et al)
> 
> Dims had set up the  builds a jar and does some unit tests. These tests have been failing (see
> below) due to the abscense of junit framework in the CLASSPATH. Now Gump is
> told to add junit, and (again, see below) it thinks it does. Can anybody
> explain what might be occuring?
> 
> Note: Until the next run comes along (and maybe changes things, 'cos I set
> the goal to be 'jar' for now) there is information at:
> 
> http://brutus.apache.org/gump/public/incubator-geronimo/incubator-geronimo/index.html
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: excalibur-thread-impl failure in Gump

[Brett Porter]

I caught a discussion of this on commons-dev... I'm going to bed soon,
but I'll take a look in the morning. I'm not sure if I can help out,
but it sounds familiar.

- Brett

On Tue, 21 Sep 2004 15:14:29 +0200, Stephen McConnell
<[EMAIL PROTECTED]> wrote:
> 
> 
> > -Original Message-
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: 21 September 2004 11:20
> > To: [EMAIL PROTECTED]
> > Subject: Re: excalibur-thread-impl failure in Gump
> >
> > On Tue, 21 Sep 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >
> > > I took a look at excalibur-pool-impl which is almost identical (and
> > > has testcases) and it's working ok.  I've just updated the
> > > project.xml to follow it as closely as possible.
> >
> > db-grafolia[1] works as well.  But it doesn't even list a dependency
> > on JUnit in the Gump descriptor.
> 
> The listing in the gump descriptor is only going to effect the Gump
> ordering - not the execution in Maven.  The junit target in maven fires
> off a junit plugin which has the junit stuff in its classpath - or at
> least is should.
> 
> The excalibur-thread-impl has just failed again. I'm kind of at the end
> of ideas for possible solutions.
> 
> Steve.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: excalibur-thread-impl failure in Gump

[Brett Porter]

Short answer:
It has a problem in build.properties. There are two maven.jar.junit
properties, and the second points at ant-junit.jar, which I assume
does not declare junit.framework.TestCase.

More:
The generated file has some strange entries:
http://brutus.apache.org/gump/public/excalibur/excalibur-thread-impl/gump_file/build.properties.html:
eg 
maven.jar.=/usr/local/gump/public/workspace/excalibur/components/thread/impl/target/classes
and all the ant, magic, etc dependencies which aren't declared in project.xml.

I assume these are coming from the gump descriptor. This should be
changed in one of the following ways:
- gump generates build.properties only for project.xml dependency
entries (including anything in extended POMs), rather than everything
in the gump descriptor
- gump descriptor has a flag on dependencies for ones that should be
controlled in build.properties

Not understanding the need for the extra libs and not being familiar
with Avalon, I'm not sure what the best solution is here. I always
thought that the gump deps to Maven deps would be 1:1.

gump descriptor generated from maven project should be ok, as it only
lists project.xml dependencies.

Any additions to the Maven Gump plugin are welcome - just file them in
JIRA and I'll take a look.

(BTW, You don't need a junit dependency, as Maven adds it).

Cheers,
Brett

On Tue, 21 Sep 2004 15:27:29 +0200, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Sep 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> 
> >> db-grafolia[1] works as well.  But it doesn't even list a
> >> dependency on JUnit in the Gump descriptor.
> >
> > The listing in the gump descriptor is only going to effect the Gump
> > ordering - not the execution in Maven.
> 
> I understood that much 8-)
> 
> > The junit target in maven fires off a junit plugin which has the
> > junit stuff in its classpath - or at least is should.
> 
> Since we want this to be our version of JUnit and not some arbitrary
> other one, we should hope the plugin recognizes jar overrides and make
> Gump add junit to the project.properties.
> 
> I'll just throw in a dependency on JUnit and we'll see what's going to
> happen.
> 
> Stefan
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: excalibur-thread-impl failure in Gump

[Brett Porter]

Ok, this time I got the reply-to right :)

> Unfortunately it has "junit", the reason being was that Gump 'jar ids' were
> within the scope of the project, so the 'ant' was implied. Since Gump only
> has 'jar id' that is the only thing that Gump can pass to Maven. Hence we
> need to make Gump 'jar ids' globally unique, and (for want of a better)
> match Maven 'artifact ids'.

Ok, I should explain Maven id's to clear this up a bit. They are
composed of a group and an artifact ID. The group must be unique (this
is easier to control than the whole id being unique), and the
artifactId must be unique within the group (also easy for those
maintaining the group to control). This guarantees the whole ID is
unique.

At the moment, groups are things like commons-collections, ant, and
maven (see the root directory of http://www.ibiblio.org/maven/ for a
list), but eventually we intend to move to a package structure, so the
group would be org.apache.ant and such.

The notation for an id is groupId:artifactId.

Usually, artifactId is the same as the filename (files are built as
artifactId-version.jar by default). This makes it much easier to
remember and look up.

For the above example, the ids should be junit:junit and ant:ant-junit
respectively.

> > JAR overrides do have a limitation in that they currently don't really
> > support the Maven id structure of group:artifact, which is planned to
> > be fixed for 1.1.

So what I was saying here is that we never used to have a groupId -
and the overrides you are using are a hangover of that. The property
must match either the  or  part of a dependency in
project.xml.

But if we have a project with ant:junit and junit:junit as
dependencies - there'll be a problem as in both cases the old id is
just junit.

> If you have time to explain in more detail I'd appreciate that, I'm not
> quite following.

Hope this helped.

> I agree. I was saying "correct" because I thought it used "junit", so I feel
> it ought ask for it (not have Maven transparently add it).

In this way, Maven attempts to separate the build from the actual
produced JAR (it isn't always successful, but we're working on that :)

excaliber doesn't depend on junit in any way to use it AFAIK, so its
not a dependency. It is a dependency of the excalbier unit tests
though. Maven will specify that for you to avoid having to do it
yourself only if you use the test plugin. In the same way, checkstyle
is not a dependency of excaliber - but it is used if you run the maven
checkstyle plugin report.
Tests admittedly are a bit more fuzzy because you code and compile
portions of your source against junit, but it should be treated the
same.

> Or we build Maven from scratch using Gump'ed artifacts?

I think this can happen now if you are game to try. Start by building
from MAVEN-1_0-BRANCH and then later move to HEAD. If you want to
build a Maven distribution using Maven 1.0, that's doable now. If you
want to use ant 1.5, I'd need to modify the bootstrap to accept JAR
overrides. Which do you prefer? Maybe start with Maven and work back
to Ant?

Thanks for your feedback Adam. Let me know what I can do for you.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: excalibur-thread-impl failure in Gump

[Brett Porter]

>   
> 
>   ant
>   ant-junit
>   1.6.2
>   jar
> 
> 
>   
>   ant
>   junit
> 
>   
> 
> This works quite well and we don't have any naming conflicts.

Yep, well this is identical to Maven for the first part. This is good,
because that means there shouldn't be any conflict in having gump
adopt the same identification mechanism.

I don't quite get the contents of the gump section - at first glance,
I think the relationship is back to front: a project shouldn't need to
declare gump information like this.

> p.s. Just another thought - the build.properties file generated by Gump
> seems to be including all inherited project references irrespective of
> the definition in gump.  For example, I recently removed all of the
> inherit attributes from the gump descriptor for the threads project
> (bringing it in line with the maven generated gump task output, but the
> properties file still contains a much larger set of dependency mappings.

Yep, this seems to be the core of the current problem (the id conflict
is more of a potential problem that gump faces regardless of what
build system a project is using).

> Would it be possible to simply restrict gump to generating only those
> properties that are explicitly declared (i.e. no inherited properties)?

Yeah, we've gotten a bit sidetracked, but this was one thing I
proposed earlier: just what is in project.xml + any parent projects
(which is what you get if you generate the gump descriptor with Maven
- this might be an even better idea, with enhancements such that it
updates instead of overwrites and adds more metadata as needed).

If the id issue is resolved, it would make this unnecessary, but that
is probably more of a long term goal.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: excalibur-thread-impl failure in Gump

[Brett Porter]

> It is the fact that Gump project names doesn't necessarily correspond to the
> names Maven have given them. So, Magic is capable of declaring the
> discrepancy.

That's what I thought (though didn't get the classpath bit or the
difference between id and alias - I'm not very gump literate at this
point). Like I said, I think the role belongs the other way around
which I think is what you are getting at next.

> Mind you, Magic has the ambition of no hand editing of generated gump
> descriptor, in fact we are now looking at how to tell Gump to generate the
> descriptors from the Magic model prior to Gump starting.

Likewise - running "maven gump" would be ideal if it always generated
exactly what was needed. I don't know how much extra gump stuff is
really needed in there.

> Q; Are you suggesting that we just run some Maven goals on the Excalibur
> codebase, and edit the output?

"maven gump" from each project will generate a standard descriptor. I
haven't done much with this output, but happy to take on any requests
:)

> My concern is that too many of the Excalibur projects are named differently
> internally in the POM than they are in Gump, and that a series of downstream
> changes are required.

This could be true - so probably a long term goal to unify all the
types of build types. I think we probably need to get a bit more
experience building these different projects as they are before
venturing into unchartered territory.

This is all just my opinion from a distance of course as a Maven
user/developer. As I said, I'm not familiar enough with gump internals
to comment on a lot of things.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jtidy

[Brett Porter]

Only one of those comes from Maven. Until we are building Maven from
scratch (as always, ready to talk about this when you are, btw),
you'll need to package this one.

The other 4 come from 3 different distributions. They could either be
added and built (you'll find the statcvs link from maven's plugins
page) or packaged.

Cheers,
Brett

On Tue, 12 Oct 2004 20:30:59 -0600, Adam  Jack <[EMAIL PROTECTED]> wrote:
> The jtidy build.xml vanished, so it is Maven or nada. Anybody else tempted
> to package jtidy -- it is the last step before Cocoon, it seems. That, or
> somehow we need to tackle this list below.
> 
> regards
> 
> Adam
> 
> The build cannot continue because of the following unsatisfied dependencies:
> 
> maven-sourceforge-plugin-1.0.jar (try downloading from
> http://maven-plugins.sourceforge.net)
> maven-statcvs-plugin-2.4.jar
> maven-findbugs-plugin-0.8.4.jar
> maven-xhtml-plugin-1.2.jar (try downloading from
> http://maven-validator.sourceforge.net)
> maven-checkstyle-plugin-2.4.1.jar (try downloading from
> http://maven.apache.org/reference/plugins/checkstyle)
> 
> Total time: 1 seconds
> Finished at: Tue Oct 12 18:56:25 PDT 2004
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jtidy

[Brett Porter]

> > -- it is the last step before Cocoon, it seems. That, or somehow we
> > need to tackle this list below.
> 
> Brett, if we built all those plugins from source, would we be able to
> use the freshly compiled versions of them in Maven using jar overrides
> or something?  Or would this involve changing the Maven installation?

I'll give a more explanatory answer, but the short answer is that it
doesn't require changing the Maven installation, so this should be
easy enough.

plugins are a bit "interesting" in Maven 1.x.

There are installation-wide plugins in $MAVEN_HOME/plugins
There are user plugins in $MAVEN_HOME_LOCAL/plugins (usually
$HOME/.maven/plugins)

to gump, I imagine we never go near the second one, and only change
the first one when we start building Maven from source.

Then there are runtime only plugins - specified as dependencies (as in
the case above), or built as part of a maven build using the reactor
(see geronimo, I think).

Since these ones are dependencies, they can be built using gump and
handled as regular dependencies with jar overrides. They will not
affect other projects, as they are not installed into either of the
two locations above - just loaded into memory for the current maven
run and forgotten once it stops.

> I'm very reluctant to make more parts of our build systems "installed".

Not exactly what you mean by installed here. I agree that they
shouldn't be installed in Maven for all builders to use.

I think that they have to be treated as with other dependencies: use
jar overrides. But whether you build them from source, or package them
is up to you. I'd say building them is unlikely to be problematic
(unless they have some obscure dependencies): plugin:plugin is a very
simple goal.

HTH,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jtidy

[Brett Porter]

> "installed package" in the Gump sense.  I want to build the build
> system from source, whereever possible.

Right. Once we get the current set of Maven projects all building
happily, I'll work with someone to make sure Maven itself bootstraps.
I don't think there is anything hard there - just need to sort out
policies behind it, whether we are building 1.1 (HEAD), 1.0.x (branch)
or both, where to install, etc.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jtidy

[Brett Porter]

You mean a maven plugin built by magic?

No problem - plugins are just JARs, just as long as the id remains
unique as we've already discussed.

Cheers,
Brett

> Any ideas what will happen when a project declares a dependency on a
> artifact in both the project.xml and the gump project definition, and
> the plugin itself is not built by maven?
> 
> This is the case with a plugin in the avalon repository that is build by
> Magic and used in Maven under the Fulcrum project.
> 
> Steve.
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RT] Standardizing on Maven names

[Brett Porter]

The maven repository uses "ant" and I guess "cocoon" would be used for these.

Let me clarify some terminology, just so I understand:

In gump there are projects, where a project id is unique globally, and
there are jar ids, where jar ids are unique within project, right?

So this parallels quite nicely to Maven's groupId (globally unique)
and artifactId (unique within group).

Now the twists :)

However, I'm worried there still might be a disconnect because Maven
talks about projects within a group, where Gump talks about projects
being a group.
eg: groupId geronimo, artifactId geronimo-clustering
but the project is geronimo-clustering, and that's where the gump
descriptor will be generated. Each subproject will have a descriptor.

Is this what gump expects? From what I can see, it is, so that's ok.

Next twist: the Apache Repository group has come up with a standard
repo format, and we are working towards that in future Maven versions.
groupIds are likely to be fully-qualified.
ie maven -> org.apache.maven (maybe even deeper)
  commons-collections -> org.apache.commons.collections

If we start migrating to different group IDs like this, will that
cause any issues? I'm guessing the only thing is that it might make an
ugly project name (as Stefan pointed out), so maybe gump needs to
explicitly declare a groupId, different from the project id.

Thoughts? This is a bit of a way off, and I don't think it really
changes anything - but best to make sure.

Cheers,
Brett

On Wed, 13 Oct 2004 09:54:16 +0200, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 
> 
> On Tue, 12 Oct 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> > We are having all sort of issues because maven and gump use
> > different naming schemes.
> >
> > Now, why don't we just adopt their naming conventions and live
> > peacefully together from that point on?
> 
> Wholeheartedly yes when it comes to jar ids.
> 
> Talking about project names, I really wouldn't want to call ant
> jakarta-ant or cocoon xml-cocoon.  But I guess I could live with this
> for pragmatic reasons.
> 
> Stefan
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jtidy

[Brett Porter]

> I really haven't followed Maven development, but when we tried to list
> the dependencies last time, some things (werkz is something I
> remember) simply were unbuildable if not un-findable.
> 
> We'll sort that out, I'm sure.

I thought the issue was dom4j - since resolved.

There are things like werkz, forehead, comons-grant which are pretty
much dead outside of Maven. The plan is to fold them in for Maven 1.1,
as they are quite small.  But we'll still build them for now.

We'll sort something out.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RT] Standardizing on Maven names

[Brett Porter]

> Maybe the Gump plugin needs an update, or Niclas used an old version,
> dunno.

There's only been one version with the maven tag.

I've just discovered
http://cvs.apache.org/viewcvs.cgi/maven-plugins/gump/src/plugin-resources/maven2gump.properties
 which apparently maps ids to gump ids.

Among other things, things like:
ant=jakarta-ant

Hmm... I had no idea that was there. Not exactly an elegant way to
maintain a list.

I'll get rid of it and cut a new version of the plugin.
Are there any still needing mapping that need be kept?

> I currently feel that we may be forced to declare artifact and group
> id individually on the jars we create, at least optionally.

I think this is a better way to do any compatibility mapping, if
possible. For example, it would help in doing what you mentioned next:

> Really difficult situations arise when projects get split
> (jakarta-slide used to contain slide-webdavclient which has now become
> a separate project in Gump) or artifacts get split.  This will be a
> problem to deal with since Gump living on the edge will have to follow
> such moves immediately while Maven project files can't be adapted
> without SNAPSHOTs being available IIUC.

the options for this seem to be:
- maintain the old one as a link to the new one in some way
- fork the gump descriptor - old points to old code, new to new (not a
migration really)
- keep project same, but map projects to group/artifact Ids that can change

I'm sure you guys already handle this and know the best option to take.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some progress on Fulcrum Component Builds!

[Brett Porter]

> Yesterday on IRC "stefanom" (who I guess is Stefan Bodewig) helped me get

That's probably Stefano Mazzocchi.

> I need someone to install into the "gump" users plugin directory the
> avalon-meta plugin by typing:
> 
> maven
> plugin:download -DgroupId=avalon-meta -DartifactId=avalon-meta-plugin -Dvers
> ion=1.4.0

Gumps all about building them from scratch. So what we really need is
an avalon-meta-plugin project. Once built, the plugin dependency will
take care of it.

This should have been what happened with the other 3, right?

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some progress on Fulcrum Component Builds!

[Brett Porter]

> 
> avalon/avalon-meta
> avalon-meta-plugin
> 
> avalon/merlin
> merlin-unit

why isn't this just avalon-meta and merlin for the group? If it is so
you can leverage dist/, that's not correct (see below).

> 
> respectively, AND requires
> http://www.apache.org/dist/ as a Maven repository.
> 
> I am not sure why it doesn't synchronize to ibiblio.org/maven. I thought that
> was automatic.

/dist/java-repository/ syncs to ibiblio, which contains:
http://www.apache.org/dist/java-repository/avalon-meta/plugins/avalon-meta-plugin-1.4.0.jar
http://www.apache.org/dist/java-repository/merlin/jars/merlin-unit-3.3.0.jar

However, I assume this is just for building with Maven regularly, as
under gump it is all offline.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven gump goal (was Re: [RT] Standardizing on Maven names)

[Brett Porter]

will do

Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> > I'll get rid of it and cut a new version of the plugin.
> > Are there any still needing mapping that need be kept?
> 
> BTW: If you are making tweaks, would you mind moving the   would be notified. If this isn't right (although I think a POM only has one
> project) then perhaps add something to the  duplicate) on the  
> Hmm ... I know what I ought be doing, a JIRA entry. Ok, done. This is minor,
> no pressure.
> 
> regards,
> 
> Adam
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some progress on Fulcrum Component Builds!

[Brett Porter]

> >  to 
> 
> :o)
> No, the project here refers to the name within Gump, but I think that the
> following is needed;
> 
> 
> 
> Brett, do you have any insight in this??  Steve?

AFAIK property is not needed. The gump plugin just generates:


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven, gump, developer effort (was: Re: [status] main issues)

[Brett Porter]

> I will assert that maven is the root problem (no offense intended to the
> maven people, I'm rather happy with maven recently otherwise). Maven is

No offense taken :) However, I don't think Maven itself is the problem
- as Adam has said, building works fine until we get to conflicting
dependency IDs. I'll discuss this against Adam's mail.

> not built to have other stuff control it, ie it is not very embeddable
> (unlike ant). 

This is true - but this is not how gump uses it?

> It is also not properly bootstrappable. 

I'm not entirely sure this is correct. Some small work would need to
be done to get it to play with gump, but this is on the Maven build,
not on Maven itself. I haven't pursued this because I don't want it to
be "one more thing to break the build chain" until everyone is
comfortable with it as it stands.

> It also has too
> many complex dependencies itself.

I've started cutting these down for Maven 1.1. I think dom4j and jelly
will always be problematic in the Maven 1.0 lifecycle though.

> I will assert as well that this problem goes away with maven2
> (http://cvs.apache.org/viewcvs.cgi/maven-components/ and
>   http://nagoya.apache.org/eyebrowse/SummarizeList?listId=254), being
> built using an IoC container and all as it is.

I think it will still build in the same way (jar overrides), but it
should be a whole lot easier to play with. You're right - you could
completely replace the artifact location mechanism if you wanted.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven and excalibur

[Brett Porter]

Hi,

Been meaning to reply to that other thread for some time... 

On Thu, 7 Oct 2004 17:15:34 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> 
> Basically, the first one I looked at either needed more Gump  descriptor (or changes to 'jar ids', see next) that lead to Maven jar
> overrides. BTW: The 'gump' goal for a Maven project takes this information
> from the POM and creates the correct Gump descriptor. Have you tried that?

My main worry is that there may be more information in the gump
descriptor than the maven plugin will create. Is anyone prepared to
try "maven gump" on excalibur and tell me what is missing?

I don't really have a desire to learn any more about gump to be
honest, but am happy to help out.

Niclas showed that Magic's descriptor lets you put gump id's against
every dependency. We can do that in Maven without changing the schema
if we need an interim solution while gump moves to a more robust ID
namespace. But its only going to be helpful if the maven gump goal is
being used to generate the descriptor, so that needs to be attempted
first.

> did mention groupId and artifactId -- whereas Gump has 'jar id' (which we
> map only to artifact id). As I understand it Maven 1.0 is still ok w/
> artifact id, it isn't yet requiring groupId, that is coming soon. When it

We won't "require" groupId in jar overrides for backwards
compatibility, but it needs to be an option to give it, because there
are already conflicts in the artifactId namespace as is shown in
excalibur.

> The main problem we have is that Gump jar ids are not sufficiently unique,
> so we've decided to (bit by bit) change ours to match theirs.
> 
> When I get time I'll look at these closer.

Thanks Adam.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The magically disappearing ant-contrib (Gump Project)

[Brett Porter]

shouldn't you need to use:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/ant-contrib/ant-contrib/src/etc/gump-descriptor.xml?rev=HEAD
instead?

That gives XML.

Cheers,
Brett

On Thu, 7 Oct 2004 19:56:35 -0600, Adam  Jack <[EMAIL PROTECTED]> wrote:
> I think there is a new reason for ant-contrib disappearing, and I suspect it
> is related to the spam that SF.net seem to be putting at the top of their
> viewcvs. When I curl this URL from brutus I get HTML not XML
> 
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/ant-contrib/ant-contrib/src/etc/gump-descriptor.xml
> 
> We've changed SF.net viewcvs URLs in the past to work past issues, and we've
> had numerous transient outages here also. I think it is time to move these
> descriptors into Gump CVS (perhaps as step one as part of Stefano's
> centralization.) If anybody can't access them there, I'm sure Gumpers/ASFers
> will help out with changes.
> 
> Any objections?
> 
> regards
> 
> Adam
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon artifactIds (was Re: Excalibur & Gump/Maven)

[Brett Porter]

Adam,

Just a stab, but it appears to be the latter. The projects using
Avalon may need to switch to the new id's.

I'm guessing that the projects in question are using an older version
of avalon-framework that has since been refactored, hence the disjoint
in dependencies?

- Brett

On Sat, 9 Oct 2004 07:07:15 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> > avalon-framework-api
> >
> >   this project defines the client API (interfaces, exceptions,
> >   immutable datatypes, etc. dealing with component lifecycle concerns).
> >
> > avalon-framework-legacy
> >
> >   contains some deprecated classes that have structural dependencies
> >   on the avalon-logkit project. Is dependent on the framework api.
> >
> > avalon-framework-impl
> >
> >   an implementation of the framework api.  Is dependent on the
> >   framework api and framework-legacy.
> >
> > As to what's needed by Excalibur Logging - you would need to ask someone
> > from the Excalibur project.
> 
> The problem we have is matching these to their Maven artifactIds. For Maven
> to be able to build things on top of Avalon (via Gump) we need Avalon's Gump
> descriptor  project descriptor. Can Magic (or whatever creates descriptors) do this?
> Does having 3 jars here mean things in Maven land need to change, do they
> need to start using three artifact Ids?
> 
> 
> 
> regards
> 
> Adam
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Removal of xerces1

[Brett Porter]

eh?

xerces:xerces is the maven name (there is also xerces:xmlParserAPIs
and xerces:xercesImpl in older ones I think).

And xalan:xalan.

I think the "2" was in the gump name?

- Brett


On Mon, 18 Oct 2004 16:26:24 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> > Only xerces-dist1 (which nothing depends on) depends on xerces1.
> >
> > Xerces-1, doesn't build in JDK1.5.
> >
> > Is it time to remove it from the descriptors?
> 
> Works for me.
> 
> BTW: What was the outcome xerces (Gump name) != xerces2 (Maven name). Would
> we chose this time to make a change there?
> 
> regards
> 
> Adam
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project ant.xml checkstyle.xml excalibur.xml incubator-altrmi.xml jakarta-bcel.xml jakarta-velocity.xml mx4j.xml xdoclet.xml xml-xalan.xml

[Brett Porter]

we've only ever synced in Apache releases 5.0 and 5.1 AFAICT.

Cheers,
Brett


On Tue, 19 Oct 2004 08:23:32 +0200, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On 16 Oct 2004, <[EMAIL PROTECTED]> wrote:
> 
> >   Must change the jakarta-bcel project to 'bcel' to get the Maven
> >   working.
> 
> Note that bcel had a long life at sourceforge before it came to
> Jakarta.  I'm not sure that bcel at Maven means the same thing as
> Apache's bcel.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml

[Brett Porter]

I had to get some background from Eric on IRC about this, as I
couldn't find the original message. I hope I'm on the right track.
I'll first discuss the general problem I see here and solutions, but
there is a fix for this specific issue at the end I think.

As I understand it, the general problem here is that the project.xml
changes, and the gump descriptor is not updated. The version is just a
reflection of this, and it probably changes the most. Is this correct?

I'd really like to go down the track of having gump effectively run
"maven gump" for a project, then use the generated descriptor instead.
What is involved in that from the gump end? I assume since it happened
for magic, it must be possible.

I realise there are customisations people make, and there are two
possible solutions - preferably to come up with a way to describe them
elsewhere so the descriptor can continue to be generated, or for the
descriptor generation to intelligently update one that already exists
without removing the customisations.

There may also be some builds doing funny things such that generation
won't work - and they should be allowed to generate a descriptor in
this case. They just need to take responsibility to keep it up to
date. This shouldn't happen if they are following the Maven guidelines
for a project set up.

As much as I'd like to get the correct solution, you can probably
overcome this now by specifying
maven.final.name=expected_jar_name
in gump's generated build.properties, which will result in
target/expected_jar_name.jar
This takes the version out of the equation. It may not work for all
situations, but should be a good start. Anyone doing funny things in
generating artifacts are going to have to take responsibility for the
gump descriptor.

Cheers,
Brett

On Mon, 25 Oct 2004 11:01:09 -0400, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> Niclas Hedhman wrote:
> 
> > On Monday 25 October 2004 15:04, [EMAIL PROTECTED] wrote:
> >
> >
> >>  Now, is there a way to 'inject' the version into maven? otherwise we'll
> >>have to continue updating these names as they projects change versions
> >
> >
> > One can access the POM as properties, such as ${pom.artifactId}, so there is a
> > small chance that setting "pom.currentVersion" would work, but I suspect that
> > the last-takes-precendence principle often used in Maven will prevail.
> 
> Hmmm, that is a very serious problem.
> 
> Brett (or any other maven knowledgeable person around here), is there
> any way to take precedence over the maven POM from the outside?
> 
> --
> Stefano.
> 
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What do we do with "beanutils"?

[Brett Porter]

Ok, we need a solution for when a project changes names. There have
been suggestions in the past, let's round them up:

- gump has a dummy project "beanutils" that depends just on
beanutils-core. I don't think this works with Maven though.

- projects declare any aliases in their gump descriptor (and Maven
allows that in the POM so it can generate the descriptor for them). So
beanutils-core has an alias of beanutils

- we don't do any gump solutions, and we maintain the big mapping file
in the maven gump plugin, so it can change the dependencies when
converting the gump descriptor. We look to store that mapping file in
gump, instead.

- we don't do anything. When a project changes name, they accept they
are going to break projects and they have to catch up. Possibly, the
previous version keeps the name so that projects keep building?
(others have more passionate feelings about how gump should behave in
this way I think, so I'll leave that to them).

Thoughts? (2) seems the best if possible on the gump end. Both (2) and
(3) are easy from the maven end.

Cheers,
Brett

On Mon, 01 Nov 2004 20:29:32 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> we call it "beanutils-core" and maven calls it "beanutils". Should I go
> ahead and unify the two or anybody has a better idea?
> 
> --
> Stefano.
> 
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What do we do with "beanutils"?

[Brett Porter]

> > - projects declare any aliases in their gump descriptor (and Maven
> > allows that in the POM so it can generate the descriptor for
> > them). So beanutils-core has an alias of beanutils
> 
> I understand the part about projects declaring aliases (we may even
> need to do that on the artifact level IMHO).  I don't understand why
> Maven needs to know about those at all - other than the Gump plugin,
> maybe.  

I'm thinking of the case where a project name changes, and the aliases
are project metadata. I'm not talking about gump names changing - I'm
talking about the artifactID changing over time (as was the case with
beanutils).

> I'm absolutely willing to maintain these aliases on an
> as-needed basis.

That sounds like the 3rd solution, however it seems the 1st worked anyway :)

> > - we don't do anything. When a project changes name, they accept
> > they are going to break projects and they have to catch
> > up.
> 
> But have the projects chosen the name?  I mean, is it the project's
> fault if the name we (Gump) assign to it and the one Maven uses for it
> are different?  Has the project itself any say in either of both?

Sorry for mixing up words,  Iwas talking about artifactId that the
project chooses.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What do we do with "beanutils"?

[Brett Porter]

I've been meaning to reply to this in kind.

If a project splits itself into three, should gump really try and map
projects depending on an older version to these? I know you are
experimenting with the latest and greatest, but this might be the
point where you start maintaining beanutils-1.6.x and
beanutils-*-1.7.x in gump and projects can migrate on their own (gump
could encourage those left on the old one to do so, but not require it
to keep running).

- Brett

On Mon, 8 Nov 2004 20:10:14 +, robert burrell donkin
<[EMAIL PROTECTED]> wrote:
> (sorry for being a little late to the party)
> 
> 
> 
> On 2 Nov 2004, at 20:18, Brett Porter wrote:
> 
> >>> - projects declare any aliases in their gump descriptor (and Maven
> >>> allows that in the POM so it can generate the descriptor for
> >>> them). So beanutils-core has an alias of beanutils
> >>
> >> I understand the part about projects declaring aliases (we may even
> >> need to do that on the artifact level IMHO).  I don't understand why
> >> Maven needs to know about those at all - other than the Gump plugin,
> >> maybe.
> >
> > I'm thinking of the case where a project name changes, and the aliases
> > are project metadata. I'm not talking about gump names changing - I'm
> > talking about the artifactID changing over time (as was the case with
> > beanutils).
> 
> sadly, beanutils is not so simple.
> 
> the artifact id had to be changed in any case to fit in with the new
> artifact naming conventions (or so it appeared at the time that the
> release was cut) but three artifact ids were always going to be needed:
> two new ones for the modular jar's with simple dependencies and the old
> one for the combined jar. the gump descriptors were tested then
> migrated to commons-beanutils-core (it seemed that no other projects
> used the classes moved into commons-beanutils-collections).
> 
> however, the route of least resistance seems to be for gump to forget
> that the combined distribution exists and use a alias. in any case,
> projects should really be migrating to the new modular jar's (they have
> much simpler dependencies) when they upgrade their dependencies...
> 
> - robert
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Missing Class for Fulcrum DVSL

[Brett Porter]

Just to confirm some things here:
- test honours jar overrides as it uses maven.dependency.classpath
- Maven does not introduce any jaxen dependencies normally. However,
if you are using any plugin:* latka:* pmd:* release:* goals it will be
introduced. This is an unfortunate side-effect of not having plugin
classloaders separate - something we desparately want to implement,
but would break a significant number of builds that have come to
depend (no pun intended!) on it.

If you run maven with -X you will see what maven.dependency.classpath
is and whether jaxen has found its way onto there.

I think Maven 1.1 is going to have to take the backwards compat hit
and separate the classloaders. I've already done the work but not
committed it.

- Brett

On Tue, 9 Nov 2004 18:55:24 +0100, Eric Pugh
<[EMAIL PROTECTED]> wrote:
> Not quite sure where this dependency is coming from.  I don't believe Maven
> is introducing for me the Jaxen dependency.  As the test runs perfectly
> without it.  Could it be the version of dom4j being used?  My component is
> just a wrapper around velocity-dvsl, so it may be somewhere in there...
> 
> I'll try and spill out the classpath in the test..
> 
> Eric
> 
> 
> 
> 
> > -Original Message-
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, November 09, 2004 5:39 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Missing Class for Fulcrum DVSL
> >
> >
> > On Tue, 09 Nov 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > > On Tue, 9 Nov 2004, Eric Pugh <[EMAIL PROTECTED]>
> > > wrote:
> >
> > >> I have inlined the text of the error.  The issue is something
> > >> missing on Jaxen.  However, I have in my Gump descriptor (but not
> > >> in Maven) a dependency on Jaxen.
> > >
> > > So how do you compile your code with Maven if you don't specify the
> > > dependency at all?  Is the version of Jaxen used Maven "helping
> > > out"?
> >
> > should read
> >
> > Is the version of Jaxen used by Maven "helping out"?
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Gump RSS link

[Brett Porter]

Hi,

I noticed a link to gump's RSS on http://www.planetapache.org/ (right
hand column under the blogroll), but it was to the lsd instance that
isn't running.

Is the appropriate place to change it to
http://brutus.apache.org/gump/public/rss.xml?

I think any committer can modify the planet stuff to get that changed
- I'll check it out later when I have access (or if anyone else cares
to do so).

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project excalibur.xml

[Brett Porter]

Is this a Maven generated descriptor adding them in, or hand-rolled
and added because Maven needs it?

Velocity should only be required by Maven if you are running site, xdoc, etc.

Getting this sorted out is getting really close to the top of my list
(it was going to be after the 1.0.1 release, but some small issues
have cropped up that are forcing a 1.0.2 release), so I'll get to it
after that.

Building Maven in gump and having the plugins look after their own
dependencies will stop this happening.

Cheers,
Brett


On Sun, 21 Nov 2004 21:44:02 +0800, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Sunday 21 November 2004 21:29, Leo Simons wrote:
> 
> > >   +
> >
> > I don't get it. What's going on? Why are things failing? AFAIK excalibur
> > doesn't use velocity...
> 
> I know, and asked the same question some time ago.
> 
> I can only conclude that Maven needs it somehow and doesn't have it.
> 
> 
> 
> Cheers
> Niclas
> --
>+--//---+
>   / http://www.bali.ac/
>  / http://niclas.hedhman.org /
> +--//---+
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project excalibur.xml

[Brett Porter]

On Mon, 22 Nov 2004 05:19:29 +0800, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Monday 22 November 2004 03:43, Brett Porter wrote:
> > Is this a Maven generated descriptor adding them in, or hand-rolled
> > and added because Maven needs it?
> 
> Not sure what you mean.

I'm not sure what you mean either :)

Let me get clear on what I think was what happened:
1. Project had no jakarta-velocity dependency
2. Maven build started failing on velocity missing
3. jakarta-velocity was added to gump descriptor to correct, though
excalibur doesn't need it.

What probably happened was the local repository was flushed - it was
originally set up to have a series of dependencies for plugins. In
Maven, plugin dependencies are fetched alongside a project's, so if
velocity it being fetched and not in project.xml, it is because one of
the plugins being used by the goals being called needs it.

The solution is to have the plugins built in gump, using the proper
dependencies in gump. The workaround is to have the missing jar placed
in the local repository.

Maven could be clearer on why it is downloading a certain dependency,
so I'll raise a feature request on that.

> This brings up the issue; Gump seems to be using 1.0. Is that sufficient or is
> an upgrade recommended?

I was holding off asking this because I wanted to be building Maven
itself. Since 1.0.2 should only be a couple of weeks off, it might be
worth waiting for that, though I don't think any of these bugs will be
affecting current gump users.

Who has access to brutus enough to help me start planning where to
install Maven as it gets built so that other projects can use it? Adam
was the main person I spoke to initially and has been very busy/quiet
lately.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project excalibur.xml

[Brett Porter]

> So IIUIC, one of the plugins that is used to build Excalibur needs Velocity?
> And that you don't need to declare that in a POM normally, and this shows up,
> since Maven is running -offline, and the plugin in question can't operate and
> can't download...
> 
> So, i.e. there shouldn't be a velocity dependency in the Excalibur Gump
> descriptor, but we should ensure that the Maven installation is proper.

That's what I was thinking. Velcoity is typically needed by any run of
the site/xdoc, but other plugins may use it also.

maven -X will reveal where it gets added after the dependency exists -
I've raised an issue to improve the reporting at the download stage
for Maven 1.1.

> AFAIK, most people around here; Stefano, Adam, Stefan, me, Leo and probably
> others.

Ok, well I'll get back to the list in a couple of weeks, and hopefully
I'll have a working solution (finally) that we can start to put
together when someone has time.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: getting new Apollo and Muse projects integrated into Gump

[Brett Porter]

> > Both projects have Maven-based builds.  I've generated Gump project
> > descriptors using the Maven gump plugin
> 
> This shouldn't be necessary 

The Maven gump plugin generates a  element now. It is the best
and recommended way to do it. If for any reason it is not doing a good
enough job, I'm happy to accept JIRA issues for the next release.

> and you probably better don't do so since
> the plugin as well as the Ant plugin (at least commonly used versions)
> are rather broken in my experience.

The ant plugin does as good a job as it can do without reimplementing
the entirety of Maven in ant. It's not broken, just not complete.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: getting new Apollo and Muse projects integrated into Gump

[Brett Porter]

> Taking
>  as
> an example (I didn't notice it had a  tag before you said so) I
> see two problems to start with
> 
> *  is broken.  Should be
>   .

Ok, we haven't done a full set of svn testing. Thanks for pointing this out.

> * Project name mappings are bogus (jakarta-ant, jakarta-log4j,
>   xml-axis).

Yep, this is a known issue, though I thought all these still resolved
to the correct one eventually.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed

[Brett Porter]

> > For example, one of our Maven deps has artifactId "axis-wsdl4j", but
> > the wsdl4j Gump project's jar name is "wsdl4j".
> 
> Then I really think your Maven dep is wrong since wsdl4j is not
> produced by Axis and shouldn't be considered part of Axis IMHO.

It appears the correct ID is axis:axis-wsdl4j, ie the artifact ID is
axis-wsdl4j, the group axis. This seems right.

So is the problem that wsdl4j has declared itself to be something
different in gump than it did in Maven?

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed

[Brett Porter]

> | It appears the correct ID is axis:axis-wsdl4j, ie the artifact ID is
> | axis-wsdl4j, the group axis. This seems right.
> |
> | So is the problem that wsdl4j has declared itself to be something
> | different in gump than it did in Maven?
> 
> The axis:axis-wsdl4j is a result of how Axis publishes the wsdl4j jar in
> the Maven repo (http://www.apache.org/dist/java-repository/axis/jars/).
> If it it makes things easier, I could publish the jar in the snapshot
> repo (http://cvs.apache.org/repository/) under wsdl4j:wsdl4j and then
> reference that in our Maven descriptors..
> 

That'll hurt your standalone build in the long run, so I'd say not.

This is just another case of Maven and Gump in parallel allocating IDs
to projects in the past - differently :)

There are probably 3 solutions:
1) change the gump IDs to match (project axis, id axis-wsdl4j?)
2) map the gump ID with an additional file as Stefan mentioned earlier
3) add the ability to map to a different gump ID in the project.xml
dependencies element and have it come out in the gump descriptor.

I'm going to do (3) eventually, with (1) an additional long term
solution and (2) the workaround we've been using.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Project apollo (in module apollo) failed

[Brett Porter]

Understanding that, I agree. I don't know how the wsdl4j jar got into
the repository originally, but if it is wrong then it should be fixed.

Sorry for the confusion.

Cheers,
Brett


On Tue, 07 Dec 2004 08:59:15 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Dec 2004, Brett Porter <[EMAIL PROTECTED]> wrote:
> 
> > There are probably 3 solutions:
> > 1) change the gump IDs to match (project axis, id axis-wsdl4j?)
> > 2) map the gump ID with an additional file as Stefan mentioned earlier
> > 3) add the ability to map to a different gump ID in the project.xml
> > dependencies element and have it come out in the gump descriptor.
> >
> > I'm going to do (3) eventually, with (1) an additional long term
> > solution and (2) the workaround we've been using.
> 
> I'd agree with you that (1) should be the best approach, if wsdl4j
> actually was an artifact of Axis.  Since it gets created by a
> totally different project and merely gets redistributed by Axis, I
> think it is simply wrong to depend on axis:axis-wsdl4j in any Maven
> build at all.
> 
> Like I said, I'll start a new thread.
> 
> 
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

gump descriptor questions

[Brett Porter]

Hi,

I'm updating the Maven gump generator to help Niclas out in getting
directory into gump. I have a few questions. I apologise in advance if
these are answered in the documentation, but I figured someone here
will be able to quickly give me the correct answer, rather than what I
infer the correct answer to be :)

The things I believe to be true:
- gump descriptors have one module and 1-to-many projects. In maven,
module maps to group (a multiproject), project to artifact (one
project.xml), is this correct?

questions:
- depend specifies a project name. Can you also specify a module name?
Or does gump assume all project id's to be globally unique at this
point?
- in javadoc, how is the module tag used? Should I be setting it to
the package, or the same module given to cvs/svn?
- for the 

Re: [RT] Gump 3.0 - Database Model

[Brett Porter]

must be stripping attachemnts - maybe it can be put on the wiki or something?


On Wed, 08 Dec 2004 19:35:18 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> Stefano Mazzocchi wrote:
> 
> 
> > Since I received no pushback on my proposal, let's move on discussing
> > the database model.
> >
> > I think the first step is to identify the entities that we want to
> > model, their relationships and their respective cardinality.
> >
> > Here is what Leo and I came up with so far (attached as PDF).
> >
> > Comments/criticism/questions appreciated.
> 
> Hmmm, trying again.
> 
> --
> Stefano.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

directory and gump

[Brett Porter]

Hi,

I've regenerated the eve gump descriptor using a development version
of the Maven Gump plugin. I'll do the others now.

I reread the documentation and did the following:
- stopped mapping ids (the ability is there for the project to do that
in its descriptor)
- removed work and mkdir (these seem irrelevant for Maven)
- added junitreport
- fixed svn
- added multiproject support

Hopefully that's it...

The only thing I am now unsure about: I set module name to the
artifactId, not the groupId. The reason for this is I believe (though
don't see anything supporting or contradicting it in the doco) that
gump may expect that name to be unique in the workspace, and groupId
will not be.

There is still the risk that there will be namespace issues later, but
we can cross that bridge when we come to it.

So, when/how will I know if this is correct?

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: directory projects

[Brett Porter]

Ok, so has directory been disabled because of this?

I'm about to regenerate the descriptors, and after that will comment
out all those above until we can sort out what to do with them...

- Brett


On Fri, 10 Dec 2004 12:10:59 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 9 Dec 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> 
> > If you find them annoying, just ignore :o)
> 
> They caused Gump to not run at all - which is a bit more than simply
> annoying.
> 
> Cheers
> 
> Stefan
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: directory projects

[Brett Porter]

> The EMPTY is annoying, but strictly speaking, they should be, whilest they
> actually contain linefeed + spaces. Need to be fixed, and shouldn't be too
> hard.

Ok, I'll have to look at this more. The templating I'm using always
does this - I'll need to track down the option not to. In the mean
time, I'll do it by hand.

> 
> Also, the  tag doesn't have module attribute, it should be a dir
> attribute.
> 

Fixed.

- Brett

> 
> 
> Cheers
> Niclas
> --
>+--//---+
>   / http://www.dpml.net   /
>  / http://niclas.hedhman.org /
> +--//---+
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: directory projects

[Brett Porter]

Ok, I still have to do the EMPTYs, but can you take another look? (or
is there a way I can do this?)

Are you sure the svn tag is right? The doco says it just takes an URL
(though this is fine if it works!)

- Brett


On Fri, 10 Dec 2004 23:07:52 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > The EMPTY is annoying, but strictly speaking, they should be, whilest they
> > actually contain linefeed + spaces. Need to be fixed, and shouldn't be too
> > hard.
> 
> Ok, I'll have to look at this more. The templating I'm using always
> does this - I'll need to track down the option not to. In the mean
> time, I'll do it by hand.
> 
> >
> > Also, the  tag doesn't have module attribute, it should be a dir
> > attribute.
> >
> 
> Fixed.
> 
> - Brett
> 
> 
> 
> >
> >
> > Cheers
> > Niclas
> > --
> >+--//---+
> >   / http://www.dpml.net   /
> >  / http://niclas.hedhman.org /
> > +--//---+
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

more questions - on depends

[Brett Porter]

Hi,

Niclas has been a bit unsure, so can someone please explain two things
about :

- is property valid for the Maven builder, and is it used to set the
name of the property to use in the build.properties file? Is the
default the project name, ie maven.jar.project?

- is id valid for the Maven builder to depend on particular jars of a
project? does it default to just the jar names the same as the
project?

I'm having trouble finding the actual code... I'll dig around more later.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: more questions - on depends

[Brett Porter]

> I hadn't thought of this before, but I don't think property is (today) valid
> for Maven, 'cos I think we use the id irrespective of any property name
> setting there. Maybe that is something to fix, if there is utility in it.
> That said, I wonder what would happen, I suspect it'd be set and passed
> using build.properties just like any other property, so it might work.

I don't think this is necessary as long as the IDs are mapped
correctly, so I'll remove it again.

> > - is id valid for the Maven builder to depend on particular jars of a
> > project? does it default to just the jar names the same as the
> > project?
> 
> I beleive so.
> 
> Do you mean does ID default? Sorta -- we trim dates/.jar and such.
> 

Yeah, so id = project if id is left off?

In that case, I'll add an optional ... property.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: more questions - on depends

[Brett Porter]

Got a bit lost on this thread :)

I agree, Gump should parse Maven POMs (sorry Niclas, if that leaves
you on your own :)
However, I added the mapping to allow projects to fix themselves until
that time arrives. It seems we've gotten to the point where the
generated descriptor is correct (I just have to remove property as it
is a duplicate of what is already generated, and add an optional id
element). I'll release a new version of the gump plugin to use.

Anywhere were we have mismatched projects (so several maven projects
declaring a dependency differently), that's something that probably
needs to be fixed from the Maven end. We manage the central
repository, so we can push to doing that.

If we are able to do this, do the combination of these two solutions
solve our problems now, and going forward?

Let's start a list of JAR names that have conflicts. Please add them here:
http://jira.codehaus.org/browse/MAVEN-1534
or if they are those pesky sun ones we can't distribute:
http://jira.codehaus.org/browse/MAVEN-1472

I'll do what I can to resolve them.

- Brett

On Mon, 13 Dec 2004 10:48:58 -0500, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
> Niclas Hedhman wrote:
> > On Monday 13 December 2004 16:24, Stefan Bodewig wrote:
> >
> >
> >>I think at least Stefan(o) prefer Gump an approach where Gump can
> >>parse Maven POMs directly.
> >
> >
> > :o) Cool. But you are back to some of the problems listed for approach "1.",
> > e.g.  there are artifacts that are not inter-project consistent.
> > So, POM *alone* is not enough, but can remove the need for a "gump" goal in
> > Maven.
> 
> Yep. POM alone is not enough, we should start thinking about a "registry
> of project names" on where everybody can agree upon.
> 
> Brett, what's your opinion on this?
> 
> --
> Stefano.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Gump descriptors for Directory projects

[Brett Porter]

Hi,

Isn't it better to get all the dependencies straightened out under
normal gump first?

what sorts of changes are you looking to make? I want to ensure we can
go back to generating the descriptors from Maven for the moment.

- Brett

On Thu, 16 Dec 2004 08:51:26 -0500, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Niclas,
> 
> Can you please move the gump descriptors to the CVS gump module? Am
> having trouble with several of them. (For example,
> http://brutus.apache.org/gump/kaffe/directory-ldap/ldap-snacc-provider/index.html).
> Makes it easier for us to maintain it.
> 
> Thanks,
> dims
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Gump descriptors for Directory projects

[Brett Porter]

ok... I don't think I'll have much time this weekend because of family
Christmas gatherings, but I'll see if I can take a look over this
again.

- Brett


On Thu, 16 Dec 2004 17:09:35 -0500, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Brett,
> 
> Problem is the same in "normal" gump...see
> http://brutus.apache.org/gump/public/directory-ldap/ldap-snacc-provider/index.html
> for example.
> 
> -- dims
> 
> 
> On Fri, 17 Dec 2004 06:49:41 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Isn't it better to get all the dependencies straightened out under
> > normal gump first?
> >
> > what sorts of changes are you looking to make? I want to ensure we can
> > go back to generating the descriptors from Maven for the moment.
> >
> > - Brett
> >
> > On Thu, 16 Dec 2004 08:51:26 -0500, Davanum Srinivas <[EMAIL PROTECTED]> 
> > wrote:
> > > Niclas,
> > >
> > > Can you please move the gump descriptors to the CVS gump module? Am
> > > having trouble with several of them. (For example,
> > > http://brutus.apache.org/gump/kaffe/directory-ldap/ldap-snacc-provider/index.html).
> > > Makes it easier for us to maintain it.
> > >
> > > Thanks,
> > > dims
> > >
> > > --
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> 
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project directory-eve.xml directory-janus.xml directory-kerberos.xml directory-ldap.xml directory-snickers.xml

[Brett Porter]

>   +   id="aspectjrt" reference="jarpath"/>
...
>

Doesn't this mean that the depend should list the id too?

BTW, can someone check about getting the CVS reply to set correctly?
[EMAIL PROTECTED] doesn't exist.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project directory-eve.xml directory-janus.xml directory-kerberos.xml directory-ldap.xml directory-snickers.xml

[Brett Porter]

> It does - well, at least for Ant builds.
> 
... 
> It will also populate CLASSPATH with all jars and create jar overrides
> for all jars (but with artifactIds that Maven doesn't recognize).

That's what I thought. So - technically or according to the
definition, it should have id. Practically, as Niclas said, it makes
no difference.

I'm just trying to understand what it is all meant to mean :)

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

how to add a new packaged JAR?

[Brett Porter]

Hi,

We need to add maven-javaapp-plugin for directory-eve to build
correctly under gump.

Home: http://maven-plugins.sourceforge.net/maven-javaapp-plugin/index.html
JAR: 
http://www.ibiblio.org/maven/maven-plugins/plugins/maven-javaapp-plugin-1.3.jar

I figured as this is not an Apache project, adding it as a package was
desired, however I'm happy to build it from source if necessary.

Also, kerberos failed, unable to update out of SVN. I'm not sure if
this is a once off or not:

svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn: Cannot replace a directory from within

Is it possible someone could do a clean checkout of the kerberos
module to ensure this doesn't happen next go round?

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: how to add a new packaged JAR?

[Brett Porter]

> Done. Removed the kerberos checkout as well as the workspace (maybe shouldn't
> have done that part :o) ).

So it'll come back next time?

Thanks for that. I've fixed (hopefully) unit tests in some packages,
leaving just ldap-clients which is using excalibur-cli and logkit
which I think you wanted to get rid of?

- Brett

> 
> Cheers
> Niclas
> --
>+--//---+
>   / http://www.dpml.net   /
>  / http://niclas.hedhman.org /
> +--//---+
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: how to add a new packaged JAR?

[Brett Porter]

that's exactly what I thought when I looked at it :)

I'll be able to do it tomorrow and generate it from the descriptors
with multiproject.

- Brett


On Tue, 28 Dec 2004 17:43:35 +0800, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Tuesday 28 December 2004 07:43, Brett Porter wrote:
> > Also, kerberos failed, unable to update out of SVN. I'm not sure if
> > this is a once off or not:
> >
> > svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> > svn: Cannot replace a directory from within
> 
> Wrong directory checkout.
> 
> directory/kerberos/trunk/kerberos  should be directory/kerberos/trunk and then
> more projects should be added; main, core, protocol, and client I guess.
> 
> I am too tired to do this right now.
> 
> Cheers
> Niclas
> --
>+--//---+
>   / http://www.dpml.net   /
>  / http://niclas.hedhman.org /
> +--//---+
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

directory descriptors and gump

[Brett Porter]

Hi,

All the directory descriptors are now Maven generated again. I think
this is it now (we'll see with tomorrow's update). Kerberos' path
should be fixed and the rest should be consistent with the previous
version.

If updates are needed, its preferred to do it via Maven (with the gump
2.0 plugin I will release after a vote), or let the directory
developers know so they can update the project.xml files accordingly.

If anyone is interested in restarting the discussion on using Maven
metadata directly, or at least generating the gump descriptors from
the project descriptors, let me know.

More importantly, getting the IDs sorted out would be a big bonus. I
think I have a better knowledge to discuss this now - I'll look to put
together a proposal.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

status of xalan breakage?

[Brett Porter]

Hi,

I notice xalan has been broken for two weeks. I've seen a couple of
enquiries here, but am not sure of the status.

Is anyone working on fixing this? It's knocked out half of the projects :)

I'd like to get directory finalised (which depends on this), and would
also like to move commons-jelly to a 

Re: status of xalan breakage?

[Brett Porter]

any objections to me doing this?

1) create a xalan-failing project that uses xalan HEAD to build
2) make the xalan descriptor either package the last release, or build
from a known-good tag
3) when xalan-failing starts building again, switch back


On Wed, 29 Dec 2004 23:03:40 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I notice xalan has been broken for two weeks. I've seen a couple of
> enquiries here, but am not sure of the status.
> 
> Is anyone working on fixing this? It's knocked out half of the projects :)
> 
> I'd like to get directory finalised (which depends on this), and would
> also like to move commons-jelly to a  generated ant descriptors, but it won't build until xalan does either.
> 
> Is it possible to do this:
> 1) create a xalan-failing project that uses xalan HEAD to build
> 2) make the xalan descriptor either package the last release, or build
> from a known-good tag
> 3) when xalan-failing starts building again, switch back
> 
> This is a highly manual but cheap way of doing "last good" :)
> 
> WDYT?
> 
> Cheers,
> Brett
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

gump and Maven IDs

[Brett Porter]

Hi,

http://wiki.apache.org/gump/MavenId

I've started a list of known incompatibilities (by no means
incomplete), listed my understanding of the problem, and potential
solutions.

Essentially, the core of the problem is that gump descriptors use the
definition of a project inconsistently. eg. asm is one project with
multiple jars; commons-jelly is multiple projects with one jar each.
These otherwise are the same, so the gump descriptors should be
defined the same way - and either way is possible with Maven and Ant
(though both may require changes to some projects to do it).

I think the latter is better, and have listed the reasons in the wiki
entry (in particular, the ability to isolate breakages). I think the
best solution is actually to change the way gump does the descriptors
(also explained on the page).

Any thoughts on what the best path is?

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Gump Maven Plugin 2.0 Released

[Brett Porter]

We are pleased to announce the Maven Gump Plug-in 2.0 release! 

http://maven.apache.org/reference/plugins/gump/



Changes in this version include:

  New Features:

o Add maven.gump.module.name property for overriding the module name 
o Add junitreport element to the descriptor 
o Add multiproject module for generating a single module with several 
  projects within the one descriptor. 
o Add nag element at module level Issue: MPGUMP-3. 
o Handle subversion as an SCM type 

  Fixed bugs:

o Set maven.final.name as a property for the <maven element, instead of 
  final.name 
o Set http://www.ibiblio.org/maven
  -DgroupId=maven
  -DartifactId=maven-gump-plugin
  -Dversion=2.0

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-gump-plugin-2.0.jar
 

Have fun!
-The Maven Gump Plug-in development team
  
---
Sent using Email 2.3.0
http://email.cleancode.org

Sent on: Sat, 08 Jan 2005 14:20:40 AUSEST
On System: CYGWIN_NT-5.1 1.5.12(0.116/4/2) i686


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: gump and Maven IDs

[Brett Porter]

> I think you're spot on that gump basically needs to change to support the
> maven model of one-jar-per-project-definition. 

great!

> In fact making it
> one-output-per-project-definition seems to make even more sense, where a
> "maven dist" is a different project from a "maven jar".

I'm not so sure about this. Which parts of the definition actually
change other than the outputs part?

> It will take a while for us to get there. One thing I wouldn't like to see
> happening is that you need 20 project definitions for a single ant command
> that results in 20 jars. I.e. Gump needs to support maven's
> one-jar-per-project model, but also others, and they all need to be
> convenient to set up.

Right - my solution proposed in there covers that. The JAR ID concept
would continue to work by modifying the artifact ID of the several
outputs:
eg:



This is very close to what is already there, and in several cases the
same. However, these are effectively being promoted to the level of
projects now. Therefore, id/ids would be removed from .

> Thinking about just doing (module = groupid, project = artifactid), that
> might get us into problems as the module name is also used for other things
> at the moment. But IIRC you can override that behaviour, so let's make that
> happen!

Yes, everything I saw module being used for was as a path and was
configurable elsewhere.

As far as I can tell, this gives a few simple steps forward to the
correct solution. For the long term goal, I agree with Stefano and
yourself - to be able to read the Maven project descriptor directly
and have gump understand it. As is shown by the Maven gump plugin,
everything in the gump descriptor can be derived from that presently.

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project jakarta-commons-jelly-core.xml

[Brett Porter]

yup, since done that.


On Wed, 12 Jan 2005 12:32:14 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On 12 Jan 2005, <[EMAIL PROTECTED]> wrote:
> 
> >   regenerate descriptor
> 
> >   -  Copyright 2004-2005 The Apache Software Foundation
> >   + * Copyright 2001-2004 The Apache Software Foundation.
> 
> you may want to fix the end-year the plugin generates.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

packaged JAR required

[Brett Porter]

Hi,

Can we please package the following for commons-jelly? I don't
recommend building it from source, they are not likely to change
without being absorbed into the other project anyway.

forehead (http://www.ibiblio.org/maven/forehead/jars/forehead-1.0-beta-5.jar)

Thanks,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project jakarta-velocity.xml

[Brett Porter]

Thanks!

- Brett


On Thu, 13 Jan 2005 11:47:26 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Jan 2005, Brett Porter <[EMAIL PROTECTED]> wrote:
> 
> > Can someone confirm that this is safe for existing projects?
> 
> No, there are a few projects that will need id attributes on depend
> tags now, I'll fix them.
> 
> Cheers
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven generated descriptors and runtime="true"

[Brett Porter]

sorry, the docs aren't very clear on runtime.

so none of the deps are transitive, unless they are given at run time?

I guess I'm just trying to figure the reason to pass it around before
adding more to the jelly metadata.

I guess another alternative is to switch latka to its maven build?

Anyway, feel free to restore them to the descriptor (just look at the
last commons.xml cvs history that had jelly), and after we've resolved
if they are needed, I can make sure they persist through the generated
descriptor.

- Brett


On Tue, 18 Jan 2005 10:34:03 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> when Jelly switched to a Maven generated descriptor, it lost all the
> runtime="true" attributes on the dependencies.  As a result Latka,
> which uses Jelly during its tests, no longer picks up
> commons-collections (and probably others).
> 
> Before I start adding the Jelly runtime dependencies left and right,
> is there any way to recover the runtime attributes in the descriptor?
> 
> Cheers
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven generated descriptors and runtime="true"

[Brett Porter]

I didn't quite understand why something would be needed at build time,
but not runtime?

> If that helps.  I'm not sure.  We still have a few cases of jelly-tags
> builds that passed in the Ant incarnation but fail now that we use
> Maven.  

which ones? There haven't been any mails, and
http://brutus.apache.org/gump/public/project_todos.html
doesn't show them. I'm guessing its because other dependent projects
are failing?

> I guess - but that's not backed by any facts yet - that the
> problem is that CVS dom4j needs Jaxen at runtime, but Maven's junit
> plugin ignores Jaxen even if it is on the classpath.

"ignores Jaxen" - this shouldn't be the case, though it won't be used
as the default XML parser I don't think. Anyway, no point stabbing in
the dark - if I see a failer, I can look at addressing it.

> quite a bit of work since it also happened to the tags.  I'll restore
> the ones for jelly and add more to the tags as the need arises.

Probably best as it was probably cut and pasted anyway, so this should
be more accurate.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven generated descriptors and runtime="true"

[Brett Porter]

> > I didn't quite understand why something would be needed at build
> > time, but not runtime?
> 
> Ant or JavaCC, for example.

Right, build != compile - sorry I wasn't thinking straight. These
don't often affect Maven if the plugin is assumed to be installed.

However, doesn't it really make more sense to be the other way around?
These are surely less common?

> I don't understand that either.  They probably sit in the moderation
> queue since [EMAIL PROTECTED] isn't subscribed to itself.

They've gotten through in the past. We should probably change the from
address to general@gump.apache.org and make sure it gets moderated
through, I guess.

> No, the tests [ERROR] out, and I think it is because ouf a
> ClaasNotFoundException for org.jaxen.JaxenException.  It was the last
> time when I checked.

Ok, will take a look when they appear on the main list. I don't have
time tonight anyway.

> OK, swing fails since the tests don't pick up the java.awt.headless
> sysproperty.[1]

Some of these were not actually being built under gump previously I
don't think, hence the reason they fail now and not before :)

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven generated descriptors and runtime="true"

[Brett Porter]

> They should (Maven should use CVS Ant and CVS Jelly) - at some point.

Sure, but one step at a time.

> > They've gotten through in the past. We should probably change the
> > from address to general@gump.apache.org and make sure it gets
> > moderated through, I guess.
> 
> IMHO we should use real email addresses or [EMAIL PROTECTED], yes.

[EMAIL PROTECTED] is a real email :) Using "people" is a bit deceptive I found.

> If we allow [EMAIL PROTECTED] to post to [EMAIL PROTECTED], then
> suddenly a lot of viruses will get through.  How many viruses have you
> received that have been "sent" from yourself?

Doesn't the mailer drop it because it wasn't sent from the apache.org domain?

> For the Ant builds, setting ant.build.clonevm did the trick (passing
> system properties to forked VMs).  Maven would have to use CVS Ant in
> order to make this work.  Hmm, I don't even know whether we currently
> support system properties for  at all.

I don't think it is Ant that needs to get the property though - its
junit, isn't it? If so, maven.junit.sysproperties should be being used
anyway. I'll look into it.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven generated descriptors and runtime="true"

[Brett Porter]

On Tue, 18 Jan 2005 12:09:11 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Jan 2005, Brett Porter <[EMAIL PROTECTED]> wrote:
> 
> >> If we allow [EMAIL PROTECTED] to post to [EMAIL PROTECTED],
> >> then suddenly a lot of viruses will get through.  How many viruses
> >> have you received that have been "sent" from yourself?
> >
> > Doesn't the mailer drop it because it wasn't sent from the
> > apache.org domain?
> 
> I don't think so.  I can use my apache.org address while posting from
> a different machine without problems.
> 

SPF is running - it will drop it, and I've seen it happen. However, it
is on *.apache.org, not on just apache.org mail domains (which is why
you can do it for your own).

mail sent from brutus won't get through though, so that explains why
its not working now either.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon failure

[Brett Porter]

Given that the codebase being built is locked, I propose:

> 3. Close the building of these projects, and package them if necessary.

- Brett


On Thu, 20 Jan 2005 03:20:57 +, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> 
> I just want to let everyone know that DPML switched its DNS service to our own
> management, and now pointing to our own servers, instead of the ibiblio.org
> one, and in the process, we didn't feel we needed to maintain the artifact
> repository that the Merlin testcases are using.
> 
> In fact, we knew that someone (now apparent) was still using the old location,
> and wanted to redirect them over to the new one. But in this case, the source
> files to do that are in a locked Subversion repository.
> 
> The change comprises
>   http://www.dpml.net
> in a couple of places to be changed to
>   http://repository.dpml.net
> 
> If someone can provide me with a template on the directory by directory
> redirect/rewrite/"external fetch" or whatever it is called, so that;
> 
> GET http://www.dpml.net/avalon
> 
> does a
> 
> GET http://repository.dpml.net/avalon
> 
> but ONLY for '/avalon' and subdirs.
> 
> and some rudimentary instructions, I can put that into the new server.
> 
> Otherwise, Gump folks have to figure out how to deal with the situation;
> 1. Disable the testcases for the affected projects.
> 2. Get the access into the source and change it.
> 3. Close the building of these projects, and package them if necessary.
> 4. Other?
> 
> Cheers
> Niclas
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven and Gump

[Brett Porter]

Hi,

A few questions (not clear from the docs, so if someone can save me
trawling the code that'd be great :)

- can I pass  to  and it will be passed in as
-Dname=value? This appears to be true
- can I pass  to ? I'd like to pass in -X for one
project to help debug a failure.
- can someone upgrade the Maven instance running to 1.0.2? I'm not
prepared to add Maven to the build cycle of Gump until I'm confident
with the Jelly/Directory experiments.

This is the one I need -X for - its unclear why velocity-dep does not
contain the collections class required:
http://brutus.apache.org/gump/public/apacheds/maven-directory-plugin/gump_work/build_apacheds_maven-directory-plugin.html

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven and Gump

[Brett Porter]

On Mon, 24 Jan 2005 09:43:49 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Jan 2005, Brett Porter <[EMAIL PROTECTED]> wrote:
> 
> > - can I pass  to  and it will be passed in
> > as -Dname=value?
> 
> You can and it will be passed as part of the generated properties file
> (not using the -D command line args).

I think that'll work. Will try.

> > - can I pass  to ? I'd like to pass in -X for
> > one project to help debug a failure.
> 
> Are you talking about arguments for the Java runtime or for Maven.  In
> the former case we use  for this in Ant, but I think we
> disabled that for Maven since we run Maven via the wrapper script (Ant
> is run via "java org.apache.tools.ant.Main", bypassing the script).

Actually, it's an argument to Maven. So there isn't a technique for
this presently?

> What would be the proper way to get them through the wrapper script?

For future reference, MAVEN_OPTS is passed to the JVM.

> > - can someone upgrade the Maven instance running to 1.0.2?
> 
> I'd appreciate if anybody else - with at least a little bit experience
> with Maven - could do so.  Otherwise I'll give it a try tomorrow.

I don't have access, but otherwise could help. Really, its just an untar though.

Thanks,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Heads Up] Brutus should be using Maven 1.0.2 now

[Brett Porter]

> "At least in theory" since we probably won't see any Gump runs until
> we get the "certificate is expired" problem resolved.  I think I only
> need to do a manual svn update and accept the certificate permanently,
> which I'll try next.

Yep - that worked for me.

Is there any reason to be using https though? Surely you only need
anonymous, http checkout?

- Brett

> 
> Cheers
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Heads Up] Brutus should be using Maven 1.0.2 now

[Brett Porter]

That doesn't look very healthy. The build failed too.

But that's kaffe to, so I don't know if that ever worked?

The jelly warnings are usually hidden by the default log4j settings -
are they being overridden?

- Brett


On Tue, 25 Jan 2005 09:44:54 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hmm,
> 
> we seem to be using Maven 1.0.2 now,
> 
> 
> Are those Jelly warnings something to worry about?
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Heads Up] Brutus should be using Maven 1.0.2 now

[Brett Porter]

> Maybe I should have done something more than just pointing MAVEN_HOME
> to a different location (actually I twisted a symlink)?  Something
> like removing the Maven cache and re-populate it with newer plugin
> versions (I'd need to know how to do that, though).

Unless Adam did something funny when setting it up, that should be enough.

> Doesn't look that way.  We'll have to wait for the JDK 1.5 run
> starting in about an hour to be sure.

Sounds good to me.

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Heads Up] Brutus should be using Maven 1.0.2 now

[Brett Porter]

That's to populate the repository, but the new install has picked that
up just fine.

I think it's likely to be kaffe - let's hold for the JDK 1.5 run.

- Brett


On Tue, 25 Jan 2005 11:08:35 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Jan 2005, Brett Porter <[EMAIL PROTECTED]> wrote:
> >> Maybe I should have done something more than just pointing
> >> MAVEN_HOME to a different location (actually I twisted a symlink)?
> >> Something like removing the Maven cache and re-populate it with
> >> newer plugin versions (I'd need to know how to do that, though).
> >
> > Unless Adam did something funny when setting it up, that should be
> > enough.
> 
> I vaguely recall he ran Maven without --offline once, or something
> like that.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Heads Up] Brutus should be using Maven 1.0.2 now

[Brett Porter]

the bit about offline? If this were a problem, it would exhibit as
dependencies not being found.

the bit about bootstrapping?
when jelly and directory (my foray into gump) are stable, sure.

plugins? It should be fine. ~/.maven/cache is just a cache, only the
plugin JARs that exist in ~/.maven/plugins and $MAVEN_HOME/plugins are
actually loaded.

but if you are concerned, delete it... no harm done.

You should be able to test it by setting your JDK to 1.4, going to the
jelly checkout, and running "maven jar".

- Brett

On Tue, 25 Jan 2005 11:14:19 +0100, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Jan 2005, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 25 Jan 2005, Brett Porter <[EMAIL PROTECTED]> wrote:
> >>> Maybe I should have done something more than just pointing
> >>> MAVEN_HOME to a different location (actually I twisted a symlink)?
> >>> Something like removing the Maven cache and re-populate it with
> >>> newer plugin versions (I'd need to know how to do that, though).
> >>
> >> Unless Adam did something funny when setting it up, that should be
> >> enough.
> >
> > I vaguely recall he ran Maven without --offline once, or something
> > like that.
> 
> Does
> 
> <http://marc.theaimsgroup.com/?l=gump&m=108424955701760&w=2>
> 
> ring a bell?
> 
> We do have quite a few plugins in ~gump/.maven.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]