a link to where the final maven / 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
.
Cheers,
Brett
--
Brett Porter ~ [EMAIL PROTECTED]
blog: http://blogs.codehaus.org/people/brett
Maven: http://maven.apache.org/
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
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
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
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
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
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
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
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
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
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
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.
-
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.
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:
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'
resource
info
groupant/group
nameant-junit/name
version1.6.2/version
typejar/type
/info
gump
classpath/
aliasant/alias
idjunit/id
/gump
/resource
This works quite well and we don't have any naming conflicts.
Yep, well
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
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
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
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
groupIdavalon/avalon-meta/groupId
artifactIdavalon-meta-plugin/artifactId
groupIdavalon/merlin/groupId
artifactIdmerlin-unit/artifactId
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
depend project=avalon-merlin-unit/ to depend project=merlin-unit/
:o)
No, the project here refers to the name within Gump, but I think that the
following is needed;
depend property=maven.jar.merlin-unit project=avalon-merlin-unit/
Brett, do you have any insight in this?? Steve?
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
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
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
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
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
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
- 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
)
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
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
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
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,
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
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 maven/ element now. It is the best
and recommended way to do it. If for any reason it is not doing a good
enough job,
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,
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
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
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
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
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
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
Hi,
Niclas has been a bit unsure, so can someone please explain two things
about depend/:
- 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
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
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
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
://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
+ property name=maven.jar.aspectjrt project=aspectj
id=aspectjrt reference=jarpath/
...
depend project=aspectj/
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.
-
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
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,
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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 property ... / to maven / and it will be passed in as
-Dname=value? This appears to be true
- can I pass arg ... / to maven /? I'd like to pass in -X for one
project to help
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
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
:
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
Hi,
I added jline for jelly-tags-interaction, but there is a problem.
The JLine CVS repository's module name need to be . because of the way
it has been checked in (unfortunately), but the command gump is using is:
cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvsroot/jline checkout
-P -d
Thanks!
On Mon, 31 Jan 2005 09:15:17 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Sat, 29 Jan 2005, Brett Porter [EMAIL PROTECTED] wrote:
I figured the dir on cvs/ is being used for both the CVSROOT and
module name?
No. dir is for CVSROOT only, module is the name of the module
+0800, Niclas Hedhman [EMAIL PROTECTED] wrote:
On Saturday 12 February 2005 18:47, Brett Porter wrote:
Hi,
Can someone please install packages for nanocontainer beta-3 and
nanocontainer-nanowar (beta-3) as listed here:
http://nanocontainer.codehaus.org/Downloads
Not build from source
http://brutus.apache.org/gump/public/apseda/apseda/gump_file/TEST-org.apache.apseda.examples.DiscardProtocolProviderTest.txt.html
Is it possible that I can get access to brutus to investigate this
further? It seems to be some sort of firewall related issue - I'd like
to tweak the test case until
Hi,
Can we turn off --quiet on svn update?
This failed:
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/gump_work/update_jakarta-commons-sandbox.html
with output:
svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn:
Cannot replace a directory from within
It was not at
Hi,
I've corrected the svn url, but mina still says this:
http://brutus.apache.org/gump/public/mina/index.html
It looks like it needs a clean checkout. Can someone explain to me how
to do this?
- Brett
-
To unsubscribe,
Feb 2005, Brett Porter [EMAIL PROTECTED] wrote:
It looks like it needs a clean checkout. Can someone explain to me
how to do this?
Right now the only way I know is: log in to brutus and remove the
working copies. I'll do so in a few minutes.
Stefan
On Mon, 14 Feb 2005 10:01:40 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Sun, 13 Feb 2005, Brett Porter [EMAIL PROTECTED] wrote:
Can we turn off --quiet on svn update?
Not that easily.
Is it in code?
I've run a manual update without problems, maybe it
was a transient error
Hi,
ApacheDS-core does not need attention, I think I have fixed it.
Currently, Maven under gump assumes that all Maven plugins already
have access to downloaded JARs as we're working off an installation.
This was not the case for the aspectj plugin, so I had Maven download
aspectjtools-1.2 to
Correct.
- Brett
On Mon, 21 Feb 2005 12:22:59 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Mon, 21 Feb 2005, Brett Porter [EMAIL PROTECTED] wrote:
Yes, but the project does not declare a dependency on it, it
utilises Maven's plugin which is pre-installed.
I see.
This means
forrest - cocoon - jakarta-turbine-jcs - struts
good luck :)
On Fri, 25 Feb 2005 11:36:49 +1100, David Crossley [EMAIL PROTECTED] wrote:
Gump is telling us that it cannot build forrest due to a failed
dependency on Struts. However we do not depend on on struts.
Can anyone explain why this is
You need to edit the descriptor in CVS
(gump/repositories/gleamynode.xml I believe).
- Brett
On Wed, 2 Mar 2005 21:49:50 +0900, Trustin Lee [EMAIL PROTECTED] wrote:
Hi,
On Wed, 02 Mar 2005 00:30:03 PST, tl-netty2 development
[EMAIL PROTECTED] wrote:
To whom it may engage...
This is
Hi,
I didn't realise that just changing the descriptor wasn't enough after
directory moved to the top level of SVN, so I have deleted the
checkouts. I assume they will be checked out again automatically next
build. If that's not the case, please let me know.
- Brett
Hi,
I was reminded of Gump and Maven metadata this morning, and with all
the gump3 activity thought I would check in.
I haven't been completely across the gump3 plans, but was wondering
what plans there are for a couple of things:
- using Maven IDs. Last Leo and I said on this was...
It looks like it is declared as a dependency though - it should be in
the local repository instead, or made a gump package, or built from
sources. Check out the javaapp plugin for an example.
- Brett
On 4/14/05, Dion Gillard [EMAIL PROTECTED] wrote:
User-specific plugins go in ~/.maven/plugins.
Hi Leo,
On 4/17/05, Leo Simons [EMAIL PROTECTED] wrote:
The more and more I look at this, the more I'm disliking how all this is set
up, esp. as its not very consistent across different projects, and we don't
have very clear guidelines on how people should be doing this (other than
copy
Hmm. One problem I see is that the rest of the world (ie make users, python
developers) don't follow that model at all, and would have to make a
significant adjustment to start thinking about groups and what are the
groupings in their software.
group = product, project = thing that I build,
What about exporting an NFS/Samba mount from the gump zone on helios?
- Brett
On 5/4/05, Leo Simons [EMAIL PROTECTED] wrote:
Hi gang,
With setting up gump on multiple machines, we really need to start getting
our installed packages into shape. For now some manual rsyncing with
brutus as
Yes, these were preinstalled in the local repository on brutus as the
1.0.2 release required them. Running maven site once online will
pick up most that will ever be needed.
- Brett
On 6/3/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
Hi all,
looking at the current Gump run I see all Maven
On 6/3/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Fri, 3 Jun 2005, Brett Porter [EMAIL PROTECTED] wrote:
Yes, these were preinstalled in the local repository on brutus as
the 1.0.2 release required them.
The gump user local one, yes?
Correct. It might be time to try again
I will update it. Half of those aren't needed any more.
I'll need a packaged dom4j-1.4 - can someone sort that out? We can't
upgrade to 1.5+.
- Brett
On 6/3/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Fri, 3 Jun 2005, Brett Porter [EMAIL PROTECTED] wrote:
Correct. It might be time
on this right now.
- Brett
On 6/4/05, Brett Porter [EMAIL PROTECTED] wrote:
I will update it. Half of those aren't needed any more.
I'll need a packaged dom4j-1.4 - can someone sort that out? We can't
upgrade to 1.5+.
- Brett
Some comments on this:
- the project descriptor link is way out of date :)
- any scope to parse maven2 metadata? Some Ant projects may also be
using this in the near future via the dependencies task
- I previously pointed Leo at maven-model, where the Java code that
parses the file is
In subversion (under metadata I think).
- Brett
On 8/12/05, Trustin Lee [EMAIL PROTECTED] wrote:
Hi,
I've been keep receiving build failure messages from GUMP. Now I'm taking a
breath and fix the GUMP descriptors for some of my projects.
But I was not able to locate GUMP descriptor
Hi,
Having looked at the recent problems with Apache Directory, I can't
immediately fix them. The checkout is locked and I don't have access
to vmgump. I hadn't been tracking these since it moved from brutus.
While you might want to look into automating svn cleanup on locked
checkouts, I'm
On 8/15/05, Leo Simons [EMAIL PROTECTED] wrote:
Would you like access?
If you trust me to poke around without damaging anything when a
project goes down, I'm happy to go in and fix it again - sure.
Heck, would you like to be on the Gump PMC?
I have to admit my interests lay with getting
No, it should be fine (assuming maven 1?). The only issues with Maven
is syncing up id's.
All you need to know should be here:
http://maven.apache.org/reference/plugins/gump/
- Brett
On 8/21/05, robert burrell donkin [EMAIL PROTECTED] wrote:
jaxme is moving to use maven. since there are a lot
the dependencies must either be in gump (preferred), or packaged.
asm and groovy are in gump already, so its just a matter of matching the id's.
http://maven.apache.org/reference/plugins/gump/
On 8/21/05, Joerg Heinicke [EMAIL PROTECTED] wrote:
Hello,
few projects fail to unavailable
applied. The cobetura plugin will need to be packaged, and AFAIK I
don't have access to vmgump yet. Is that right folks?
- Brett
On 8/23/05, Joerg Heinicke [EMAIL PROTECTED] wrote:
the dependencies must either be in gump (preferred), or packaged.
asm and groovy are in gump already, so its
On 9/4/05, Henri Yandell [EMAIL PROTECTED] wrote:
This getting dealt with at all?
I got access, but I haven't had the time to go in and find where things are
again :)
The process is:
- create the metadata file in SVN (any committer can do)
- place the JAR in the expected location.
I'll
1 - 100 of 129 matches
Mail list logo
