Re: Gump has hanged...

[Stefano Mazzocchi]

Niclas Hedhman wrote:
http://brutus.apache.org/gump/public/buildLog.html
Stopped on the 120th project...
the log file doesn't say anything but it did crash somehow. weird.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Created: (GUMP-84) Packages defined in built modules are shown as "green" but they should be "blue"

[general]

Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://issues.apache.org/jira/browse/GUMP-84

Here is an overview of the issue:
-
Key: GUMP-84
Summary: Packages defined in built modules are shown as "green" but they should be 
"blue"
   Type: Bug

 Status: Unassigned
   Priority: Major

Project: Gump

   Assignee: 
   Reporter: Stefano Mazzocchi

Created: Tue, 12 Oct 2004 9:08 PM
Updated: Tue, 12 Oct 2004 9:08 PM

Description:
packages are colored "blue" when they are not built by gump. Modules are allowed to 
have their own internal packages, wrapping some of the jars they contain in their 
repository. Gump should treat those the same as packages, but currently it does not 
and it misleads the statistics.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

Gump has hanged...

[Niclas Hedhman]

http://brutus.apache.org/gump/public/buildLog.html

Stopped on the 120th project...


Cheers
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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

Betwixt Test Failures

[Stefano Mazzocchi]

Hello there,
the gump project is trying to reach for the 100% build of the ASF java 
tree. On the way up (we are now at 76% and growing steadily!) we found 
that betwixt stands in the way.

As you can see from
 http://brutus.apache.org/gump/public/project_todos.html
betwixt is now the second most critical project in the tree, preventing 
24 projects to compile.

From the build logs
http://brutus.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html
we understood that it's not a dependency problem (or something that gump 
could route around) but the project is failing because tests are failing.

The nags are set to be forwarded to [EMAIL PROTECTED] but I do 
understand that gump has been kinda "noisy" so far and for this reason 
people might simply not pay attention, this is the reason for this reply.

Why you? well, again, we have no idea on who is working on what, so I 
just picked the person that most recently committed something important 
to the tree.

If you think that you are not the right person for the task, please 
forword it to the appropriate person/mail list.

Thank you in advance for your cooperation.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

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]

jtidy

[Adam Jack]

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]

BATCH: All dressed up, with nowhere to go...

[brutus]

Dear Gumpmeisters,

The following 5 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Project icu4j (in module icu4j) success
[EMAIL PROTECTED]: Project jaxen (in module jaxen) success
[EMAIL PROTECTED]: Project jaxen-test (in module jaxen) success
[EMAIL PROTECTED]: Project rhino (in module rhino) success
[EMAIL PROTECTED]: Project xml-batik-rasterizer (in module xml-batik) success
*** G U M P
[EMAIL PROTECTED]: Project icu4j (in module icu4j) success
To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project icu4j *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:
http://brutus.apache.org/gump/public/icu4j/icu4j/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [icu4j.jar] identifier set to project name



The following work was performed:
http://brutus.apache.org/gump/public/icu4j/icu4j/gump_work/build_icu4j_icu4j.html
Work Name: build_icu4j_icu4j (Type: Build)
Work ended in a state of : Success
Elapsed: 28 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only all 
[Working Directory: /usr/local/gump/public/workspace/icu4j]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/icu4j/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar
-
[javac] Note: Recompile with -deprecation for details.

tools:
[javac] Compiling 63 source files to /usr/local/gump/public/workspace/icu4j/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.

richedit:
[javac] Compiling 143 source files to 
/usr/local/gump/public/workspace/icu4j/classes
[javac] Note: 
/usr/local/gump/public/workspace/icu4j/src/com/ibm/richtext/textpanel/StyledTextClipboard.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -deprecation for details.
 [copy] Copying 2 files to 
/usr/local/gump/public/workspace/icu4j/classes/com/ibm/richtext/textapps/resources

demos:
[javac] Compiling 28 source files to /usr/local/gump/public/workspace/icu4j/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.

jar:
  [jar] Building jar: /usr/local/gump/public/workspace/icu4j/icu4j.jar

docs:
 [echo] doc params: -breakiterator -use -tagletpath ./classes -taglet 
com.ibm.icu.dev.tool.docs.ICUTaglet -group 'ICU Core' 
'com.ibm.icu.lang*:com.ibm.icu.math*:com.ibm.icu.text*:com.ibm.icu.util*:com.ibm.icu.stringprep*'
 -group 'ICU Tests' 'com.ibm.icu.dev.test*' -group 'Demos' 'com.ibm.icu.dev.demo*' 
-group 'ICU Tools' 'com.ibm.icu.dev*'
[mkdir] Created dir: /usr/local/gump/public/workspace/icu4j/doc
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package com.ibm.icu.lang...
  [javadoc] Loading source files for package com.ibm.icu.math...
  [javadoc] Loading source files for package com.ibm.icu.text...
  [javadoc] Loading source files for package com.ibm.icu.util...
  [javadoc] Constructing Javadoc information...
  [javadoc] Registered Taglet com.ibm.icu.dev.tool.docs.ICUTaglet ...
  [javadoc] Standard Doclet version 1.4.2_05
  [javadoc] Building tree for all the packages and classes...
  [javadoc] 
/usr/local/gump/public/workspace/icu4j/src/com/ibm/icu/text/UnicodeSet.java:2847: 
warning - @return tag has no arguments.
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Warning: bad deprecated tag ''
  [javadoc] Warning: bad deprecated tag ''
  [javadoc] 
/usr/local/gump/public/workspace/icu4j/src/com/ibm/icu/util/ByteArrayWrapper.java:61: 
warning - @param argument "byteBuffer" is not a parameter name.
  [javadoc] 
/usr/local/gump/public/workspace/icu4j/src/com/ibm/icu/util/ByteArrayWrapper.java:71:

Re: Cocoon build attempt.

[Stefano Mazzocchi]

Adam R. B. Jack wrote:
We have a problem.
Gump tried to build cocoon but it should *NOT* have!

Yeah, I had a sneaking suspicion something was wrong there, but I was being
hopeful. Ok, I need to go back to the drawing board on 'build from
repository'.
Basically, the logic was to override the 'prerequisite failed' logic (that
would suppress a build) and in such case still go looking for artifacts &
try the build. I thought that if it failed to find artifacts it'd not build,
but apparently not. I'll look at this ASAP.
Thanks much, Adam!
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Fw: backward incompatible change in org.apache.axis.wsdl.toJava.JavaWriter.writeComment? [ Re: Fw: ws-wsif on Gump

[Adam R. B. Jack]

I love seeing such collaboration, especially when Gump initiates it by
finding an inconsistency. This took a mere matter of hours start to finish.
:-)

regards

Adam
- Original Message - 
From: "Davanum Srinivas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 12, 2004 3:51 PM
Subject: Re: backward incompatible change in
org.apache.axis.wsdl.toJava.JavaWriter.writeComment? [ Re: Fw: ws-wsif on
Gump


> done.
>
>
> On Tue, 12 Oct 2004 16:45:09 -0500, Aleksander Slominski
> <[EMAIL PROTECTED]> wrote:
> > hi,
> >
> > as it seems org.apache.axis.wsdl.toJava.JavaWriter was modified since
> > 1.1 so i wonder how stable toJava API (it seems old method is was in
> > 1.1RC2) ?
> >
> > so now in CVS i can see:
> > protected void writeComment(PrintWriter pw, Element element, boolean
> > addTab)
> > which breaks compatibility with old:
> > protected void writeComment(PrintWriter pw, Element element)
> >
> > so maybe somebody could add to AXIS CVS:
> > protected void writeComment(PrintWriter pw, Element element, boolean
> > addTab) {
> > writeComment(pw, element, true);
> > }
> > to keep compatibility?
> >
> > BTW: this and lack of setScopedProperty is only breaking change i
> > noticed when porting WSIF to use AXIS 1.2RC1 form 1.1RC2.
> >
> > thanks,
> >
> > alek
> >
> > Adam R. B. Jack wrote:
> >
> > >Resend from a better account...
> > >
> > >
> > >>Hi folks,
> > >>
> > >>Does this appear to represent an interface change within AXIS?
> > >>
> > >>
> > >>
> > >>
> >
>http://brutus.apache.org/gump/public/ws-wsif/ws-wsif/gump_work/build_ws-wsi
f_ws-wsif.html
> > >
> > >
> > >>dynamic:
> > >>[mkdir] Created dir:
> > >>/usr/local/gump/public/workspace/ws-wsif/java/build/classes
> > >>[javac] Compiling 168 source files to
> > >>/usr/local/gump/public/workspace/ws-wsif/java/build/classes
> > >>[javac] This version of java does not support the classic
compiler;
> > >>upgrading to modern
> > >>[javac]
> > >>
> > >>
> > >>
> >
>/usr/local/gump/public/workspace/ws-wsif/java/src/org/apache/wsif/tools/toj
a
> > >
> > >
> > >>va/WSIFJavaTestCaseWriter.java:134:
> > >>writeComment(java.io.PrintWriter,org.w3c.dom.Element,boolean) in
> > >>org.apache.axis.wsdl.toJava.JavaWriter cannot be applied to
> > >>(java.io.PrintWriter,org.w3c.dom.Element)
> > >>[javac] writeComment(pw,
p.getDocumentationElement());
> > >>[javac] ^
> > >>[javac]
> > >>
> > >>
> > >>
> >
>/usr/local/gump/public/workspace/ws-wsif/java/src/org/apache/wsif/tools/toj
a
> > >
> > >
> > >>va/WSIFJavaTestCaseWriter.java:145:
> > >>writeComment(java.io.PrintWriter,org.w3c.dom.Element,boolean) in
> > >>org.apache.axis.wsdl.toJava.JavaWriter cannot be applied to
> > >>(java.io.PrintWriter,org.w3c.dom.Element)
> > >>[javac] writeComment(pw,
p.getDocumentationElement());
> > >>[javac] ^
> > >>[javac] Note: Some input files use or override a deprecated API.
> > >>[javac] Note: Recompile with -deprecation for details.
> > >>[javac] 2 errors
> > >>
> > >>regards,
> > >>
> > >>Adam
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
>
>
> -- 
> Davanum Srinivas - http://webservices.apache.org/~dims/
>


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

Re: Cocoon build attempt.

[Adam R. B. Jack]

> We have a problem.
>
> Gump tried to build cocoon but it should *NOT* have!

Yeah, I had a sneaking suspicion something was wrong there, but I was being
hopeful. Ok, I need to go back to the drawing board on 'build from
repository'.

Basically, the logic was to override the 'prerequisite failed' logic (that
would suppress a build) and in such case still go looking for artifacts &
try the build. I thought that if it failed to find artifacts it'd not build,
but apparently not. I'll look at this ASAP.

regards,

Adam


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

Re: Cocoon build attempt.

[Stefano Mazzocchi]

Adam Jack wrote:
Build from repository is a beautiful thing. Even though Beaver "broke" with
a technicality (the LICENSE file was missing) Gump was able (and willing) to
take the latest successful build of it from the repository. As such, even
though we state Beaver is the "root cause" (despite not being a direct
dependency), Cocoon still got a shot at a build.
http://brutus.apache.org/gump/public/cocoon/cocoon/index.html
So, now we have some Cocoon issues to fix, it seems:
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
We have a problem.
Gump tried to build cocoon but it should *NOT* have! because a 
dependency was not satisfied and it was not "beaver".

http://brutus.apache.org/gump/public/excalibur/excalibur-xmlutil/gump_work/build_excalibur_excalibur-xmlutil.html
The reason why cocoon fails is exactly that excalibur-xmlutil is not 
present and gump should have figured that out.

I think that trying to build when the dependencies are not set it's more 
harmful than useful.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Cocoon build attempt.

[Adam Jack]

Build from repository is a beautiful thing. Even though Beaver "broke" with
a technicality (the LICENSE file was missing) Gump was able (and willing) to
take the latest successful build of it from the repository. As such, even
though we state Beaver is the "root cause" (despite not being a direct
dependency), Cocoon still got a shot at a build.

http://brutus.apache.org/gump/public/cocoon/cocoon/index.html

So, now we have some Cocoon issues to fix, it seems:


http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html

regards

Adam


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

BATCH: All dressed up, with nowhere to go...

[brutus]

Dear Gumpmeisters,

The following 1 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Project excalibur-event (in module excalibur) success
*** G U M P
[EMAIL PROTECTED]: Project excalibur-event (in module excalibur) success
To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project excalibur-event *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:
http://brutus.apache.org/gump/public/excalibur/excalibur-event/index.html
To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/excalibur/excalibur-event/rss.xml
- Atom: http://brutus.apache.org/gump/public/excalibur/excalibur-event/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 17000612102004, brutus:brutus-public:17000612102004
Gump E-mail Identifier (unique within run) #2.


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

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

JGen on Gump

[Adam R. B. Jack]

Dear Sir,

In an attempt to see JGen work on Gump, I've added 'notification' e-mails to
this project:

http://brutus.apache.org/gump/public/jgen/jgen/index.html
http://brutus.apache.org/gump/public/jgen/jgen/gump_work/build_jgen_jgen.html

Since Gump notifies "from" somebody, I selected your SF.net e-mail address
as the sender. I hope this is ok with you.

My first impressions are that FOP have changed an interface underneath you,
but I am no expert in this area. If this is the case, hopefully we can
communicate this back to the FOP team, and see if we can resolve it.

regards,

Adam


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

Java package sealed?

[Adam Jack]

This is interesting, seems either the package or the whole jar is 'sealed'
and so restricts class loading. Not sure why it affects this build, but it
does.


http://brutus.apache.org/gump/test/jakarta-cactus/jakarta-cactus-framework-12/gump_work/build_jakarta-cactus_jakarta-cactus-framework-12.html
BUILD FAILED
/usr/local/gump/test/workspace/jakarta-cactus/build-common.xml:123:
java.lang.SecurityException: sealing violation: package javax.servlet is
sealed
Not exactly sure how long this has been out there, it start into a bad start
on the 9th (and Stefano updated the JDK on the 7th, so maybe unrelated,
maybe related -- not sure).Some information:
http://java.sun.com/developer/JDCTechTips/2001/tt0130.htmlAnybody Java-savvy
enough to figure out what is occurring & what ought be fixed??regards,Adam


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

Re: [RT] Standardizing on Maven names

[Adam R. B. Jack]

We are, pretty much, we already agreed upon that -- at least for artifact
ids. It is just a slow migration, changing them as we detect differences.

The "xerces" != "xerces2" is a project name. Since it is so well used it
might be quite disruptive to change. I'm open to other's input on if and
when/how we'd make such a change.

regards,

Adam
- Original Message - 
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: "Apache Gump" <[EMAIL PROTECTED]>
Sent: Tuesday, October 12, 2004 10:11 AM
Subject: [RT] Standardizing on Maven names


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


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

[RT] Standardizing on Maven names

[Stefano Mazzocchi]

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?

--
Stefano.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Gump descriptors for Fulcrum components.

[Adam R. B. Jack]

> On Tue, 12 Oct 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
>
> > a. The Xerces stuff I don't understand either... Adam?
>
> xml-xerces is Xerces-J 2 in Gump.  xml-xerces2 doesn't exist.  There
> is xml-xerces1, if you really want that.

Yeah, this is annoying. A fundamental difference in naming in Gump (which I
see is 'nice' for convenience) and in Maven. I guess we (1) set the jar id
to be Maven's artifactId (so use the '2' if needed) but (2) leave the Gump
descriptor using xerces w/o the 2. This means hand editing the Gump
descriptor after Maven has created it, but (reading Niclas' mails) it seems
that is needed anyway.

regards,

Adam


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

Re: Gump descriptors for Fulcrum components.

[Adam R. B. Jack]

> How long do I have to wait till the
> next run?  I see details on when it ran, but not when it will run again.

It is an inexact science. The more things build, the longer it takes. It
takes about 3-4 hours right now w/ so much building.

Basically if we are all working on a certain project/set I typically kick
off a test run to do just that stack. [One day (soon I hope) we hope to have
this available to the community, where you use a webapp to select 'focus
projects', and Gump does simple/quick builds on those only.]

regards

Adam


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

Re: Gump descriptors for Fulcrum components.

[Adam R. B. Jack]

> On Tuesday 12 October 2004 18:40, Stefan Bodewig wrote:
>
> > I have no idea what you'd have to do to make it work with Maven.  I
> > don't believe there's been a release of beanutils that would reflect
> > this change, yet.
>
> The general rule is;
> The "project name" in the  element of the Gump descriptor must
have
> the same literal characters as the  or  (recommended to
> change to artifactId element) in the project.xml.

Almost right. Gump takes the id attribute on the  When that is NOT possible, i.e. not possible to change the Gump descriptor
to
> match the Maven artifactId,

It ought always be possible, IMHO.

regards,

Adam


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

Re: TEST-xxx files available?

[sebb]

Or you might be able to use something like JMeter uses in its build.xml:


  


Some of the output of the test run is logged to this file, which is
otherwise not available in a remote Gump.

HTH

On Tue, 12 Oct 2004 07:56:39 -0600, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> > Is there any way we can have a look at the TEST output for
> >
> http://brutus.apache.org/gump/public/excalibur/excalibur-event-impl/gump_work/build_excalibur_excalibur-event-impl.html
> >
> 
> If you add this,  http://gump.apache.org/metadata/project.html#junitreport,
> Gump ought show you the files/contents.
> 
> 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]

[jira] Created: (GUMP-83) The

[general]

Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://issues.apache.org/jira/browse/GUMP-83

Here is an overview of the issue:
-
Key: GUMP-83
Summary: The http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

Re: [proposal] remove of

[Adam R. B. Jack]

> AFAIK, 
> Is it?
>
> IIRC I added  to ensure that two different builds inside the
> same directory tree didn't affect each other.  mockobjects?  Yes, I
> think so.  Basically I was building the same project twice against two
> different sets of dependencies.
>
> Not using  but using to different build directories (or even
> separate modules) would have been cleaner.  No problem with cleaning
> this up - delete can go.

It was turned off, until I figured out (i.e. re-read the documentation) that
it could be done relative to the project, so not a danger of deleting /. If
there were any '..' entries in the path it was rejected. Crude, but
hopefully "good enough". So, right now it is enabled.

> > and  > (basically, gump can try to read all the directories that are
> > references in the descriptors and, if not there, they can be built.
>
> If Gump does that, fine.

Yup, I agree. We ought add it to JIRA. We'd be removing an issue for folks
that is quiet obscure, and no new user ought need to know such things.

regards,

Adam


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

Re: TEST-xxx files available?

[Adam R. B. Jack]

> Is there any way we can have a look at the TEST output for
>
http://brutus.apache.org/gump/public/excalibur/excalibur-event-impl/gump_work/build_excalibur_excalibur-event-impl.html
>

If you add this,  http://gump.apache.org/metadata/project.html#junitreport,
Gump ought show you the files/contents.

regards

Adam


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

Re: Process for removing Gumped projects?

[Stefan Bodewig]

On Tue, 12 Oct 2004, Eric Pugh <[EMAIL PROTECTED]>
wrote:

> Since we seem to be doing the "spring cleaning" process for Turbine
> and Fulcrum, I wanted to find out the process for removing gumped
> projects.  I assume just delete the file from /gump/project/.

Almost, also remove them from the files inside the profile directory.
And you should ensure that no other projects depend on them (grep will
be fine, I guess).

> jakarta-turbine-jyve
> jakarta-turbine-origami
> jakarta-turbine-flux

I just checked, no other project seems to depend on them.

Stefan

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

RE: Gump descriptors for Fulcrum components.

[Eric Pugh]

well, it looks like it was removed, so the next gump run shouldn't fail on
the xml-xerces2 dependency.  I am off to lunch, hopefully it'll be done when
we get back!

Eric

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 12, 2004 2:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Gump descriptors for Fulcrum components.
>
>
> On Tue, 12 Oct 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
>
> > a. The Xerces stuff I don't understand either... Adam?
>
> xml-xerces is Xerces-J 2 in Gump.  xml-xerces2 doesn't exist.  There
> is xml-xerces1, if you really want 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]

Process for removing Gumped projects?

[Eric Pugh]

Hi all,

Since we seem to be doing the "spring cleaning" process for Turbine and
Fulcrum, I wanted to find out the process for removing gumped projects.  I
assume just delete the file from /gump/project/.

I am thinking of removing
jakarta-turbine-jyve
jakarta-turbine-origami
jakarta-turbine-flux


These are old projects no longer maintained.  While I haven't yet called for
a vote, I wanted to make sure the process.

Eric


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

Re: Gump descriptors for Fulcrum components.

[Stefan Bodewig]

On Tue, 12 Oct 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:

> a. The Xerces stuff I don't understand either... Adam?

xml-xerces is Xerces-J 2 in Gump.  xml-xerces2 doesn't exist.  There
is xml-xerces1, if you really want that.

Stefan

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

Re: Gump descriptors for Fulcrum components.

[Niclas Hedhman]

On Tuesday 12 October 2004 19:16, Eric Pugh wrote:
> Okay..  Starting to get it!  So, I noticed that I got another batch of
> errors.  However, they still are freaking out about the xml-xerces2
> dependency.  However, I just checked the jakarta-turbine-fulcrum.xml and
> those entities where recently removed.  How long do I have to wait till the
> next run?  I see details on when it ran, but not when it will run again.

a. The Xerces stuff I don't understand either... Adam?

b. Next run is something like, the next full hour, one hour after the 
completion of previous run. I.e. we have 1-2 hours of Gump not running 
between runs.

> Also, fulcrum-security-nt requires on a jar called tagishauth.jar.  Should
> I create in /gump/project/tagishauth.xml file simiilar to the javamail.xml
> file?  However, I don't quite see where the jar would download from..  One
> of the standard repositories?

Nope, not artifacts. Either (preferred) we build them from its source CVS, or 
if that is not feasible, they get installed on the Gump machine as a package.

Cheers
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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

BATCH: Unable to send...

[brutus]

Dear Gumpmeisters,

The following 2 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Project depot-version-test (in module depot) failed
[EMAIL PROTECTED]: Project jakarta-hivemind (in module jakarta-hivemind) failed
*** G U M P
[EMAIL PROTECTED]: Project depot-version-test (in module depot) failed
Failed with to: [EMAIL PROTECTED] from: [Adam Jack <[EMAIL PROTECTED]>]
Failed to send notify e-mail: (113, 'No route to host')
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project depot-version-test has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed'.
For reference only, the following projects are affected by this:
- depot-version-test :  Depot -- repository tools and more...


Full details are available at:
http://brutus.apache.org/gump/public/depot/depot-version-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/depot/version/build/depot-version/junit/results



The following work was performed:
http://brutus.apache.org/gump/public/depot/depot-version-test/gump_work/build_depot_depot-version-test.html
Work Name: build_depot_depot-version-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 46 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/workspace/ant/dist -f 
build.xml test 
[Working Directory: /usr/local/gump/public/workspace/depot/version]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/depot/version/build/depot-version/junit/classes:/usr/local/gump/public/workspace/depot/version/dist/depot-version-gump-12102004.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/depot/common/dist/depot-common-gump-12102004.jar:/usr/local/gump/public/workspace/antworks-importer/dist/antworks-importer-0.2-gump-12102004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-testutil.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[junit] Testcase: testReliabilityTree took 0.012 sec
[junit] Running 
org.apache.depot.version.discovery.loading.VersionRuntimeLoadingTests
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.187 sec
[junit] Testsuite: 
org.apache.depot.version.discovery.loading.VersionRuntimeLoadingTests
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.187 sec

[junit] Testcase: testNoOp took 0.008 sec
[junit] Running 
org.apache.depot.version.extension.VirtualMachineExtensionInformationTests
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.397 sec
[junit] Testsuite: 
org.apache.depot.version.extension.VirtualMachineExtensionInformationTests
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.397 sec

[junit] Testcase: testReliabilityCompare took 0.099 sec
[junit] Testcase: testInfoMergeIgnoringVersion1 took 0.001 sec
[junit] Testcase: testInfoMergeIgnoringVersion2 took 0 sec
[junit] Testcase: testInfoMergeByLoadType1 took 0 sec
[junit] Testcase: testInfoMergeByLoadType2 took 0.001 sec
[junit] Testcase: testMismatchInfoMerge took 0.002 sec
[junit] Running org.apache.depot.version.formatting.ApacheVersionFormatTest
[junit] Tests run: 13, Failures: 1, Errors: 0, Time elapsed: 0.296 sec
[junit] Testsuite: org.apache.depot.version.formatting.ApacheVersionFormatTest
[junit] Tests run: 13, Failures: 1, Errors: 0, Time elapsed: 0.296 sec

[junit] Testcase: testParseMajorMinor took 0.063 sec
[junit] Testcase: testParseMajorMinorRelease took 0.007 sec
[junit] Testcase: testParseMajorMinorReleaseNoDash took 0.002 sec
[junit] Testcase: testParseMajorMinorPointReleaseNoDash took 0 sec

BATCH: All dressed up, with nowhere to go...

[brutus]

Dear Gumpmeisters,

The following 13 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Module jrefactory failed
[EMAIL PROTECTED]: Project jai (in module jrefactory) failed
[EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but 
with warnings.
[EMAIL PROTECTED]: Module xdoclet success, but with warnings.
[EMAIL PROTECTED]: Project jrefactory-pretty (in module jrefactory) failed
[EMAIL PROTECTED]: Module werkz success, but with warnings.
[EMAIL PROTECTED]: Project eyebrowse (in module eyebrowse) failed
[EMAIL PROTECTED]: Project jrefactory (in module jrefactory) failed
[EMAIL PROTECTED]: Project jgen (in module jgen) failed
[EMAIL PROTECTED]: Project struts-sslext (in module struts-sslext) failed
[EMAIL PROTECTED]: Project jetty-plus (in module jetty) failed
[EMAIL PROTECTED]: Project maven (in module maven) failed
[EMAIL PROTECTED]: Project maven-bootstrap (in module maven) failed
*** G U M P
[EMAIL PROTECTED]: Module jrefactory failed
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Module jrefactory has an issue affecting its community integration,
 and has been outstanding for 8 runs.
The current state of this module is 'Failed'.

Full details are available at:
http://brutus.apache.org/gump/public/jrefactory/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -INFO- Failed with reason synchronize failed
 -ERROR- Synchronize Failed: [Errno 21] Is a directory: 
'/usr/local/gump/public/workspace/jrefactory/ant.build'



The following work was performed:
http://brutus.apache.org/gump/public/jrefactory/gump_work/update_jrefactory.html
Work Name: update_jrefactory (Type: Update)
Work ended in a state of : Success
Elapsed: 2 mins 2 secs
Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvsroot/jrefactory update 
-P -d -A 
[Working Directory: /usr/local/gump/public/workspace/cvs/jrefactory]
-
No output
-

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

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 00010012102004, brutus:brutus-public:00010012102004
Gump E-mail Identifier (unique within run) #1.

*** G U M P
[EMAIL PROTECTED]: Project jai (in module jrefactory) failed
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jai has an issue affecting its community integration,
 and has been outstanding for 8 runs.
The current state of this project is 'Failed'.

Full details are available at:
http://brutus.apache.org/gump/public/jrefactory/jai/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [jai_codec.jar] identifier set to output basename: [jai_codec]
 -DEBUG- Output [jai_core.jar] identifier set to output basename: [jai_core]
 -INFO- Failed with reason synchronize failed
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/jrefactory/jai/rss.xml
- Atom: http://brutus.apache.org/gump/public/jrefactory/jai/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 00010012102004, brutus:brutus-public:00010012102004
Gump E-mail Identifier (unique within run) #2.

*** G U M P
[EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but 
with warnings.
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project txt2html-task contains errors.
The current state of this project is 'Success', with reason ''.

Full details are available at:
http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [ant] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/

RE: Gump descriptors for Fulcrum components.

[Eric Pugh]

One more thing...   Scarab (scarab.tigris.org) uses an older branched
version of jakarta-turbine-fulcrum.  This produced a single large jar called
fulcrum.jar.  However, Fulcrum head, and the current item to integrate is a
series of seperate components.  So, I believe this means that we need to
create some sort of project dependency, similar to how projects depend on
mail.jar.

I don't think there is any real need to build this branched version of
Fulcrum as only jakarta-turbine-3 and scarab rely on it.  and turbine 3 is a
dead end development "spike" and Scarab is moving away from the branched to
the CVS HEAD version of fulcrum.

Eric

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 12, 2004 12:40 PM
> To: [EMAIL PROTECTED]; Turbine Developers List
> Subject: Re: Gump descriptors for Fulcrum components.
>
>
> On Tue, 12 Oct 2004, Eric Pugh <[EMAIL PROTECTED]> wrote:
>
> > And what does this error mean?  I notice in the gump config file
> > that there is a dependency on commons-beanutils-core.
>
> I changed it after the build failure.
>
> commons-beanutils has been split into *-core and
> *-beanutils-collections.  For most projects replacing
> commons-beanutils with commons-beanutils-core just worked.
>
> I have no idea what you'd have to do to make it work with Maven.  I
> don't believe there's been a release of beanutils that would reflect
> this change, yet.
>
> > Does that mean I should be depending on that somehow in my
> > project.xml?
>
> Probably.
>
> > Or, should I update the dependency in the gump file to
> > commons-beanutils from commons-beanutils-core.
>
> There is no commons-beanutils in Gump anymore.
>
> 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: TEST-xxx files available?

[Stefan Bodewig]

On Tue, 12 Oct 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Is there any way we can have a look at the TEST output for
> http://brutus.apache.org/gump/public/excalibur/excalibur-event-impl/gump_work/build_excalibur_excalibur-event-impl.html



Stefan

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

RE: Gump descriptors for Fulcrum components.

[Eric Pugh]

Okay..  Starting to get it!  So, I noticed that I got another batch of
errors.  However, they still are freaking out about the xml-xerces2
dependency.  However, I just checked the jakarta-turbine-fulcrum.xml and
those entities where recently removed.  How long do I have to wait till the
next run?  I see details on when it ran, but not when it will run again.

Also, fulcrum-security-nt requires on a jar called tagishauth.jar.  Should I
create in /gump/project/tagishauth.xml file simiilar to the javamail.xml
file?  However, I don't quite see where the jar would download from..  One
of the standard repositories?

Eric

> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 12, 2004 12:46 PM
> To: Gump code and data; Turbine Developers List
> Subject: Re: Gump descriptors for Fulcrum components.
>
>
> On Tuesday 12 October 2004 18:40, Stefan Bodewig wrote:
>
> > I have no idea what you'd have to do to make it work with Maven.  I
> > don't believe there's been a release of beanutils that would reflect
> > this change, yet.
>
> The general rule is;
> The "project name" in the  element of the Gump descriptor
> must have
> the same literal characters as the  or  (recommended to
> change to artifactId element) in the project.xml.
>
> When that is NOT possible, i.e. not possible to change the Gump
> descriptor to
> match the Maven artifactId, then one have to resort to manual Jar
> overrides
> in Maven, using 
> constructs. See
> Maven manual about Jar Overrides.
>
>
> 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]

TEST-xxx files available?

[Niclas Hedhman]

Hi,

Is there any way we can have a look at the TEST output for
http://brutus.apache.org/gump/public/excalibur/excalibur-event-impl/gump_work/build_excalibur_excalibur-event-impl.html

Since this testcase doesn't fail on my local system (and I have been running 
it many times).


Cheers
Niclas
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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

RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stephen McConnell]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 12 October 2004 12:47
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-
> turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml
> logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
> 
> On Tue, 12 Oct 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> 
> > True - I'm just saying that there is a Jakarta Turbine Fulcrum
> > project within Apache.
> 
> Sure. 8-)
> 
> When I said "project", I was talking about the Gump .  No
> offence intended in any way.

How can one be possibly offended when one is only here for the
entertainment?

/Steve.




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

Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stefan Bodewig]

On Tue, 12 Oct 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

> True - I'm just saying that there is a Jakarta Turbine Fulcrum
> project within Apache.

Sure. 8-)

When I said "project", I was talking about the Gump .  No
offence intended in any way.

Stefan

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

Re: Gump descriptors for Fulcrum components.

[Niclas Hedhman]

On Tuesday 12 October 2004 18:40, Stefan Bodewig wrote:

> I have no idea what you'd have to do to make it work with Maven.  I
> don't believe there's been a release of beanutils that would reflect
> this change, yet.

The general rule is;
The "project name" in the  element of the Gump descriptor must have 
the same literal characters as the  or  (recommended to 
change to artifactId element) in the project.xml.

When that is NOT possible, i.e. not possible to change the Gump descriptor to 
match the Maven artifactId, then one have to resort to manual Jar overrides 
in Maven, using  constructs. See 
Maven manual about Jar Overrides.


Cheers
Niclas

-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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

RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stephen McConnell]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 12 October 2004 12:35
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-
> turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml
> logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
> 
> On Tue, 12 Oct 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >> -Original Message- From: Stefan Bodewig
> >>
> >> There is no jakarta-turbine-fulcrum project (anymore?),
> >
> > There sure is.  They have a bunch of projects producing a swag of
> > components.
> 
> There is a jakarta-turbine-fulcrum /module/, no /project/.  Nothing
> you could use in a single .

True - I'm just saying that there is a Jakarta Turbine Fulcrum project
within Apache.

/Steve.

 
> 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: Gump descriptors for Fulcrum components.

[Niclas Hedhman]

On Tuesday 12 October 2004 18:30, Eric Pugh wrote:
> Can you supply some information on what we should change them to?  To be
> honest, I've kinda quit watching the Avalon related mailing lists for the
> past while.  But I guess, if we are going to participate in Gump builds
> (which is a *good* thing) then we need to start pacing the latest and
> greatest changes.

Great that you are interested in getting involved with Gump. :o)

Basically, your POM needs to correspond to  elements in the Gump 
descriptor file (gump/project/jakarta-turbine-fulcrum.xml in Gump CVS(!) ).

First I generated all the Gump descriptors using Maven's Gump goal, but that 
gave me a lot of garbage. Then I took all of them out and added them 
manually, from the POMs, but I agree that there are probably a lot of 
inaccuracies.

I also need to make change among the dependencies in your POMs;

Most importantly;
avalon-framework*
  --> avalon-framework-api
  --> avalon-framework-impl
and that is probably 4.1.5 you want to use.


There are also plenty of others, but I can't recall them off hand.


Cheers
Niclas

P.S  BTW, I think Fulcrum needs to contact [EMAIL PROTECTED] and clarify 
the Hibernate dependency. IANAL, but it has been up elsewhere, and we are not 
allowed to do "import " on any LGPL code. I don't know the licensing on other 
external dependencies, but Hibernate has been up elsewhere before.
-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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

Re: Gump descriptors for Fulcrum components.

[Stefan Bodewig]

On Tue, 12 Oct 2004, Eric Pugh <[EMAIL PROTECTED]> wrote:

> And what does this error mean?  I notice in the gump config file
> that there is a dependency on commons-beanutils-core.

I changed it after the build failure.

commons-beanutils has been split into *-core and
*-beanutils-collections.  For most projects replacing
commons-beanutils with commons-beanutils-core just worked.

I have no idea what you'd have to do to make it work with Maven.  I
don't believe there's been a release of beanutils that would reflect
this change, yet.

> Does that mean I should be depending on that somehow in my
> project.xml?

Probably.

> Or, should I update the dependency in the gump file to
> commons-beanutils from commons-beanutils-core.

There is no commons-beanutils in Gump anymore.

Stefan

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

RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Eric Pugh]

Hi,

I think my last email came late into the process.  Let me know what I can do
to help.  I noticed that for the fulcrum-naming component, I was able to
remove the xerces implementation and xmlparserapi's from the project.xml and
have everything work.   When making these types of changes, do I need to
then update the jakarta-turbine-fulcrum.xml file?  I know that maven
automatically adds them if they are missing.

ERic

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 12, 2004 12:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml
> jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml
> jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml
> xml-crimson.xml
>
>
> On Tue, 12 Oct 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >> -Original Message- From: Stefan Bodewig
> >>
> >> There is no jakarta-turbine-fulcrum project (anymore?),
> >
> > There sure is.  They have a bunch of projects producing a swag of
> > components.
>
> There is a jakarta-turbine-fulcrum /module/, no /project/.  Nothing
> you could use in a single .
>
> 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: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stefan Bodewig]

On Tue, 12 Oct 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:
>> -Original Message- From: Stefan Bodewig
>> 
>> There is no jakarta-turbine-fulcrum project (anymore?), 
> 
> There sure is.  They have a bunch of projects producing a swag of
> components.

There is a jakarta-turbine-fulcrum /module/, no /project/.  Nothing
you could use in a single .

Stefan

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

RE: Gump descriptors for Fulcrum components.

[Eric Pugh]

Can you supply some information on what we should change them to?  To be
honest, I've kinda quit watching the Avalon related mailing lists for the
past while.  But I guess, if we are going to participate in Gump builds
(which is a *good* thing) then we need to start pacing the latest and
greatest changes.

I am working through the issues, and a couple have come up!
Fulcrum-Configuration-Impl[1] seems to be dying because of a
commons-beanutils dependency error.  I just updated the project.xml
formatting, and some references.  Do I need to do anything to get Gump to
pick up these changes?  And what does this error mean?  I notice in the gump
config file that there is a dependency on commons-beanutils-core.  Does that
mean I should be depending on that somehow in my project.xml?  Or, should I
update the dependency in the gump file to commons-beanutils from
commons-beanutils-core.

Also, looking for example at crypto-api [2] it looks like some dependencies
are missing.  Is this because they need to be built by the plugin?

Eric


[1]
http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-configu
ration-impl/index.html
[2]
http://brutus.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-crypto-
api/gump_work/build_jakarta-turbine-fulcrum_fulcrum-crypto-api.html



> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 11, 2004 8:35 PM
> To: [EMAIL PROTECTED]
> Cc: Gump code and data
> Subject: Gump descriptors for Fulcrum components.
>
>
>
> Hi,
>
> I am working on pulling more projects in under the Gump umbrella,
> and just
> asked Maven to generate all the Gump descriptors for the Fulcrum
> components.
>
> These are now being added to the gump/project/jakarta-turbine-fulcrum.xml
> module in Gump, which you all committers can modify.
>
> Any help to get this in order is greatly appreciated.
>
> Looking at it, I can see that there are cause for you to upgrade your POM
> artifactIds, for instance for Avalon, Merlin and Logkit, which
> are no longer
> accurate.
>
> Anyway, this will take a while to get right, so don't fall off
> the chair when
> Gump will hammer you with Nags.
>
>
> 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 jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stephen McConnell]

> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
> Sent: 12 October 2004 11:54
> To: Gump code and data
> Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-
> turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml
> logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
> 
> On Tuesday 12 October 2004 17:26, Stephen McConnell wrote:
> > > There is no jakarta-turbine-fulcrum project (anymore?),
> >
> > There sure is.  They have a bunch of projects producing a swag of
> > components.
> 
> Well, there is no "jakarta-turbine-fulcrum" project with that name.
Each
> component is its own project now.

Well, yes, but all under "jakarta-turbine-fulcrum" CVS.

/Steve.

> 
> 
> 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 jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Niclas Hedhman]

On Tuesday 12 October 2004 17:26, Stephen McConnell wrote:
> > There is no jakarta-turbine-fulcrum project (anymore?),
>
> There sure is.  They have a bunch of projects producing a swag of
> components.

Well, there is no "jakarta-turbine-fulcrum" project with that name. Each 
component is its own project now.


Niclas

-- 
   +--//---+
  / http://www.bali.ac/
 / http://niclas.hedhman.org / 
+--//---+


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

RE: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stephen McConnell]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 12 October 2004 10:02
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-
> turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml
> logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml
> 
> On 12 Oct 2004, <[EMAIL PROTECTED]> wrote:
> 
> >   Fix a bunch of broken project names,
> 
> AFAIU most of them have been autogenerated so we have a mismatch
> between the Gump plugin in Maven and Gump's view of the world, I'm
> afraid.
> 
> There is no jakarta-turbine-fulcrum project (anymore?), 

There sure is.  They have a bunch of projects producing a swag of
components.

Steve.




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

Re: cvs commit: gump/project beaver.xml

[Stefan Bodewig]

On Tue, 12 Oct 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> Should have said that I'm currently looking into it.

works now.

Stefan

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

Re: cvs commit: gump/project jakarta-turbine-3.xml jakarta-turbine-flux.xml jakarta-turbine-fulcrum.xml jakarta-turbine-site.xml logging-log4j-12.xml maven.xml scarab.xml xml-crimson.xml

[Stefan Bodewig]

On 12 Oct 2004, <[EMAIL PROTECTED]> wrote:

>   Fix a bunch of broken project names,

AFAIU most of them have been autogenerated so we have a mismatch
between the Gump plugin in Maven and Gump's view of the world, I'm
afraid.

There is no jakarta-turbine-fulcrum project (anymore?), Torque has
become db-torque many months ago and Gump calls Xerces-J 2.x
xml-xerces while Xerces-J 1.x has more or less been removed (and
would be xml-xerces1).

There still are some unsatisified references to

opensymphony
plexus
tagishauth

Stefan

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

Re: cvs commit: gump/project beaver.xml

[Stefan Bodewig]

On Tue, 12 Oct 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On 11 Oct 2004, <[EMAIL PROTECTED]> wrote:
> 
>>   +
> 
> this won't help too much unless you add the dependencies as well, in
> particular Ant ;-)

Should have said that I'm currently looking into it.

Stefan

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

Re: cvs commit: gump/project beaver.xml

[Stefan Bodewig]

On 11 Oct 2004, <[EMAIL PROTECTED]> wrote:

>   +

this won't help too much unless you add the dependencies as well, in
particular Ant ;-)

Stefan

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

Re: [proposal] remove of

[Stefan Bodewig]

On Sun, 10 Oct 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:

> AFAIK,  to ensure that two different builds inside the
same directory tree didn't affect each other.  mockobjects?  Yes, I
think so.  Basically I was building the same project twice against two
different sets of dependencies.

Not using  but using to different build directories (or even
separate modules) would have been cleaner.  No problem with cleaning
this up - delete can go.

> and  (basically, gump can try to read all the directories that are
> references in the descriptors and, if not there, they can be built.

If Gump does that, fine.

Stefan

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

Re: [proposal] remove of

[Stefan Bodewig]

On Sun, 10 Oct 2004, sebb <[EMAIL PROTECTED]> wrote:

> Seems to me that the build files run by Gump should automatically
> create any directories they need anyway? Or am I missing something?

Yes, the directory have to exists before Ant/Maven is started,
creating the during the build is too late.  This is the "JVM drops
CLASSPATH entries that don't exist on startup" problem.

Stefan

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

Re: a few questions on our descriptors

[Stefan Bodewig]

On Sun, 10 Oct 2004, Leo Simons <[EMAIL PROTECTED]> wrote:

> I believe the old gump actually had an XSLT snippet which performed
> this "macro expansion".

No, it has been done in Java.   inside of Ant can only specify
a single jar while  on the outside can depend on more than one
- so the code had to keep track of the jar ids involved.

Stefan

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

Re: a few questions on our descriptors

[Stefan Bodewig]

On Sun, 10 Oct 2004, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Sunday 10 October 2004 01:38, Stefano Mazzocchi wrote:
> 
>> gosh, this is all very confusing, people.
> 
> No shit.  AFAIUI, it is something about feeding the ant script with
> additional information need to properly build those projects.

Uhm, yes.  But the information is needed by the build file, not Ant.
Most of the time the builds want to copy files referenced by
properties and we need to override those properties, that's all.

> Personally, I think Gump has the wrong approach. It tries to adopt
> to whatever way the project is structured, but still ends up
> requiring explicit support in the build system of most projects,

I don't think this is true.  Most projects build from their build
files without doing anything specific in order to make Gump happy.

There are a few projects that need to do something special for Gump,
most of the time it is in order to break circular dependencies - like
the dom4j <-> jaxen problem - or because they require passing JUnit
tests before creating a jar but the tests fail in Gump.

Stefan

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