Niclas Hedhman wrote:
David Crossley wrote:
It seems that Gump is still using the old descriptor in our SVN.
How do i get Gump to switch? The profile/gump.xml looks okay,
but the last time that it was built was two days ago using the
old descriptor.
It doesn't look Ok in my checked out
On Wed, 13 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Stefan Bodewig wrote:
Hi, the Gump project that used to be called saxon now is saxon7,
so wherever you maintain the mapping, please adjust it and
regenerate the descriptor.
no, it's called saxon6 now. saxon7 already existed.
-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Sent: 14 October 2004 05:44
To: Gump code and data
Subject: Re: dependence on mysql jdbc driver bogus?
On Thursday 14 October 2004 11:37, Stefano Mazzocchi wrote:
excalibur-datasource fails to build because it
On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
Instead, I suggest that we take the prettyprinter.jar from the
xdoclet CVS and make it into an installed package in Gump.
Just create a project for it inside xdoclet's descriptor. Name it
xdoclet-pretty or something. No need to
-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
Sent: 14 October 2004 06:59
To: Gump code and data
Subject: Re: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 12:33, Niclas Hedhman wrote:
I would suggest we mavenize xdoclet and
On Thursday 14 October 2004 14:38, Stefan Bodewig wrote:
On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
Instead, I suggest that we take the prettyprinter.jar from the
xdoclet CVS and make it into an installed package in Gump.
Just create a project for it inside xdoclet's
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
On Thursday 14 October 2004 17:37, Eric Pugh wrote:
merlin-unit-3.3.0.jar
avalon-meta-plugin-1.4.0.jar
For Maven builds;
groupIdavalon/avalon-meta/groupId
artifactIdavalon-meta-plugin/artifactId
groupIdavalon/merlin/groupId
artifactIdmerlin-unit/artifactId
respectively, AND requires
On Thursday 14 October 2004 17:37, Eric Pugh wrote:
As far as the error on merlin-unit, I think that in the
jakarta-turbine-fulcrum.xml file we depend on avalon-merlin-unit however,
in the avalon.xml file it is defined as merlin-unit, so I think I should
change that to merlin-unit:
depend
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
On Thu, 14 Oct 2004, Eric Pugh [EMAIL PROTECTED]
wrote:
Yesterday on IRC stefanom (who I guess is Stefan Bodewig
Must have been Stefano Mazzocchi
) helped me get some of the Maven plugins for building the Fulcrum
components installed. So, for the fulcrum-crypto-api component(
On Thursday 14 October 2004 18:14, Brett Porter wrote:
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/,
On Wed, 13 Oct 2004, Brett Porter [EMAIL PROTECTED] wrote:
I'll get rid of it and cut a new version of the plugin.
Thanks.
Are there any still needing mapping that need be kept?
I don't know. We usually have something like tpl-project for Apache
projects, so log4j went from jakarta-log4j to
On Wed, 13 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I think, personally, that Gump and Maven should start talking about
creating a more serious infrastructure and joining forces from the
POM point of view.
I think we are already doing that with Brett helping out a lot 8-)
In the
I think I sorted out my local build issues.. It was an aspect of bad
network connectivity causing the merlin-unit unit testing to not download
all the resources it needed.
At this point, I have been able to successfully build ALL the fulcrum
components.
Now, I believe for the gump builds, maven
Stefano Mazzocchi wrote:
excalibur-datasource fails to build because it depends on mm-mysql but
doing a grep -r mysql . in that directory doesn't yield anything.
I suspect it's a bogus dependency in their POM. Thoughts?
Niclas discovered the same thing. I think he committed the change, or
at
On Thursday 14 October 2004 22:00, Berin Loritsch wrote:
Stefano Mazzocchi wrote:
excalibur-datasource fails to build because it depends on mm-mysql but
doing a grep -r mysql . in that directory doesn't yield anything.
I suspect it's a bogus dependency in their POM. Thoughts?
Niclas
Niclas Hedhman wrote:
On Thursday 14 October 2004 12:33, Niclas Hedhman wrote:
I would suggest we mavenize xdoclet and remove jrefactory and friends
since they are clearly not enough friends of gump to live in the house
with him.
I will start on it straight away...
IIUIC, Xdoclet is not yet
David Crossley wrote:
David Crossley wrote:
Stefano Mazzocchi wrote:
first of all, I think forrest should really transfer control of their
descriptor to the gump project.
Well, i said that we would sometime soon. I also said
not now because we have an imminent release of Forrest.
Our attention is
Stefan Bodewig wrote:
On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
Instead, I suggest that we take the prettyprinter.jar from the
xdoclet CVS and make it into an installed package in Gump.
Just create a project for it inside xdoclet's descriptor. Name it
xdoclet-pretty or
Eric Pugh wrote:
Hi all,
Yesterday on IRC stefanom (who I guess is Stefan Bodewig) helped me get
some of the Maven plugins for building the Fulcrum components installed.
ehm, that was me ;-)
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Gump is currently stalled due to the fact that there is no disk space
left on the second disk of Brutus.
This is because every different gump run uses a different workspace,
this doesn't need to be.
I'll work on solving the issue right away.
Sorry for the inconvenience.
--
Stefano.
On Thursday 14 October 2004 23:28, Stefano Mazzocchi wrote:
Gump is currently stalled due to the fact that there is no disk space
left on the second disk of Brutus.
Good gracious!!!
This is because every different gump run uses a different workspace,
this doesn't need to be.
I'll work on
On Thu, 14 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
This is because every different gump run uses a different workspace,
this doesn't need to be.
Well, they can share installed packages (which they allready do IIUC)
and the checked out sources. This won't help in the long run, I'm
This is because every different gump run uses a different workspace,
this doesn't need to be.
Not sure this is accurate, unless they run at non-overlapping times or
something. What is your thinking?
regards
Adam
-
To
This is because every different gump run uses a different workspace,
this doesn't need to be.
Not sure this is accurate, unless they run at non-overlapping times or
something. What is your thinking?
A few thoughts that come to mind:
1) We can have the infrequent Gumps [JDK1.5/Kaffe], that
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 nag element out if
projects and up onto the module? That way if we get a CVS|SVN error folks
would be notified. If this isn't
Adam R. B. Jack wrote:
This is because every different gump run uses a different workspace,
this doesn't need to be.
Not sure this is accurate, unless they run at non-overlapping times or
something. What is your thinking?
I thought about it again and there is one way to do things better, but
I'm
Message:
A new issue has been created in JIRA.
-
View the issue:
http://issues.apache.org/jira/browse/GUMP-86
Here is an overview of the issue:
-
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?
On Friday 15 October 2004 07:45, Brett Porter wrote:
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
31 matches
Mail list logo
