date:20041007

On Wed, 06 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
 Stefan Bodewig wrote:
 
 On 6 Oct 2004, [EMAIL PROTECTED] wrote:
 
   ant basedir=proposal/xdocs target=docs-from-scratch
  -  jvmarg value=-Xmx256m/
 
 This is the only occurence of this in the entire repository.
 
 Why doesn't anybody else has a problem with this?

Since nobody else needs more memory than the default invocation of
Java provides?  This particular project runs xdoclet on all Ant source
files and the memory impact is quite visible.

 should better be supported.

  -ant target=gump debug=true
  +ant target=gump
 Is supported by Gump (the Python incarnation) IIRC.
 
 This was used in 3/4 descriptors.

I know.

 I really don't understand why it should be a descriptor/based thing.

Sometimes you simply don't get enough information about a build
failure without that.  For the people who don't run Gump instances
themselves, this is the easiest way to get into the details.

Stefan

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

Re: ws-jaxme failure on Gump

On Wed, 6 Oct 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote:

 The reason the we-jaxme descriptor has mkdir entries and work
 entries is that (perhaps historically) the JVM would drop system
 classpath parts that did not exist at Ant's start-up.

Not historically, still does.  It doesn't affect all tasks, though.
javac passes a -classpath arg to the compiler so it is enough for
the directory to exist at compile time, while java and junit (with
fork=false) need the directories to exist when Ant starts.

 Given this is a source directory, I suspect you only need the work
 entry.

Yes, should work.

Stefan

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

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

Dear Gumpmeisters,

The following 7 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Project txt2html-task (in Module jakarta-servletapi-5) 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 invicta (in Module invicta) failed
[EMAIL PROTECTED]: Project jetty-plus (in Module jetty) failed
[EMAIL PROTECTED]: Project struts-sslext (in Module struts-sslext) failed
*** 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 folk at [EMAIL PROTECTED]

Project txt2html-task contains errors.
Project State : 'Success', Reason ''

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole output [ant] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant]
 -INFO- No license on redistributable project with outputs.
 -ERROR- Failed to publish 
[/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant] to repository 
: [Errno 21] Is a directory


The following work was performed:
http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/gump_work/build_jakarta-servletapi-5_txt2html-task.html
Work Name: build_jakarta-servletapi-5_txt2html-task (Type: Build)
State: Success
Elapsed: 3 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 ant 
[Working Directory: /usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant:/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-
Buildfile: build.xml

prepare:
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/classes
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/docs
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/docs/api
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/examples
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/docs
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/docs/api
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/src
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/examples

ant:
[javac] Compiling 1 source file to 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant
[javac] Note: 
/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/src/ant/task/Txt2Html.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -deprecation for details.

BUILD SUCCESSFUL
Total time: 2 seconds
-




To subscribe to this information via syndicated feeds:
 RSS: http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/rss.xml
 Atom: http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/atom.xml


--
Gump E-mail Identifier (within run) #1.
Produced by Gump 2.1.0-alpha-0003.
[Run (1007102004, brutus:brutus-public:1007102004)]
http://brutus.apache.org/gump/public/index.html
http://brutus.apache.org/gump/public/options.html

*** G U M P
[EMAIL PROTECTED]: Project jrefactory-pretty (in Module jrefactory) failed
To

Re: One step forward: ws-jaxme requires new jar file

On Thu, 07 Oct 2004, Jochen Wiedmann [EMAIL PROTECTED]
wrote:

 Beaver is a Java parser generator subject to the BSD license. In
 other words, it would most probably be possible to add a Beaver
 project to Gump. Is this the suggested way to go?

If possible, yes.

 If so, can anyone point me to an existing project descriptor file,
 which could serve as a start?

If it is an sourceforge project, httpunit may be a good starting
point.  Otherwise it may get a bit more complex when we need to add a
repository definition.

Where can I get more information about Beaver?

 Otherwise, how do I add the dependency to the existing project
 descriptor?

There are (at least) three more options - in decreasing order of
Stefan's personal preference:

* turn it into an installed dependency (like jaf.xml for example).
  Requires write access to Brutus to actually work.

* add a project to jaxme's module descriptor that points to the jar
  in your CVS module.

* add a work to the ws-jaxme project that points to the jar in your
  CVS module.

Stefan

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

Re: One step forward: ws-jaxme requires new jar file

2004-10-07 Thread Davanum Srinivas

http://beaver.sourceforge.net/?

-- dims


On Thu, 07 Oct 2004 13:31:27 +0200, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On Thu, 07 Oct 2004, Jochen Wiedmann [EMAIL PROTECTED]
 wrote:
 
  Beaver is a Java parser generator subject to the BSD license. In
  other words, it would most probably be possible to add a Beaver
  project to Gump. Is this the suggested way to go?
 
 If possible, yes.
 
  If so, can anyone point me to an existing project descriptor file,
  which could serve as a start?
 
 If it is an sourceforge project, httpunit may be a good starting
 point.  Otherwise it may get a bit more complex when we need to add a
 repository definition.
 
 Where can I get more information about Beaver?
 
  Otherwise, how do I add the dependency to the existing project
  descriptor?
 
 There are (at least) three more options - in decreasing order of
 Stefan's personal preference:
 
 * turn it into an installed dependency (like jaf.xml for example).
   Requires write access to Brutus to actually work.
 
 * add a project to jaxme's module descriptor that points to the jar
   in your CVS module.
 
 * add a work to the ws-jaxme project that points to the jar in your
   CVS module.
 
 Stefan
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

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

Re: One step forward: ws-jaxme requires new jar file

On Thu, 7 Oct 2004, Davanum Srinivas [EMAIL PROTECTED] wrote:

 http://beaver.sourceforge.net/?

OK, I'll give it a shot.

Stefan

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

Re: One step forward: ws-jaxme requires new jar file

On Thu, 07 Oct 2004, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On Thu, 7 Oct 2004, Davanum Srinivas [EMAIL PROTECTED] wrote:
 
 http://beaver.sourceforge.net/?
 
 OK, I'll give it a shot.

Hmm, no CVS repo hosting the sources?

Stefan

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

Re: [vote] move the descriptors in our hands

On Wed, 06 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

 So, two votes:

three ;-)

   1) move the metadata to SVN

I guess most of us Gumpers are comfortable with this, not sure about
the other occasional committers.  I also don't know whether write
access for everybody really works right now.  I'm leaning towards +1
but we really need to ensure that every Apache committer can change
descriptors.

   2) move the descriptors into that module
   3) give all committers write access to the /metadata folder (DTD
   will *NOT* reside there!)

If 1) then 2) and 3), yes.

Stefan

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

Re: One step forward: ws-jaxme requires new jar file

Stefan Bodewig wrote:
Hmm, no CVS repo hosting the sources?
I have filed a bug report, see
http://sourceforge.net/tracker/index.php?func=detailaid=1042208group_id=96950atid=616484
Regards,
Jochen
--
http://lilypie.com/baby1/050423/1/5/1/+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (GUMP-81) Gump (or it's tools, CVS, etc.) does not cope with Unicode filenames

2004-10-07 Thread general

Message:

  A new issue has been created in JIRA.

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

Here is an overview of the issue:
-
Key: GUMP-81
Summary: Gump (or it's tools, CVS, etc.) does not cope with Unicode filenames
   Type: Bug

 Status: Unassigned
   Priority: Major

Project: Gump

   Assignee: 
   Reporter: Adam Jack

Created: Thu, 7 Oct 2004 6:05 AM
Updated: Thu, 7 Oct 2004 6:05 AM

Description:
A circumstance was found whereby 'resume.xml' (with an e acute) in a module (XOM, 
FWIIW) was checked out of the repository, but the (Python code) 'sync' to a working 
directory failed. It failed because Python's os.listdir returned a string for it, not 
Unicode (although it returned unicode for al lthe plain file). This seems related to 
the fact that the default filesystem encoding on the platofrm was 'ascii', and this 
file was not ascii.

We need to create a test for such files, then work with Gump to resolve this issue.


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

Re: cvs commit: gump/project ant.xml barcode4j.xml depot.xml excalibur.xml gump.xml j2ee-connector.xml jaas.xml jakarta-cactus.xml jakarta-velocity.xml jstl-jsp-12.xml jts.xml jython.xml mx4j.xml scarab.xml ws-axis.xml ws-juddi.xml wss4j.xml xml-xalan.xml

Stefan Bodewig wrote:
On Thu, 07 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

so what are the changes?
 jvmargs can be an empty element inside ant

I don't know, but maven probably supports it as well.

and
 debug= can be an attribute inside ant

ditto.  Not sure about nant either.
Adam?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [vote] move the descriptors in our hands

David Crossley wrote:
Stefano Mazzocchi wrote:
There are 4 ASF descriptos that currently don't reside in our repository:
 1) avalon_trunk
 2) cocoon
 3) forrest
 4) lenya
and a few others (3) from outside.
I would strongly suggest that we start moving them.
The only problematic one is cocoon's since it's a central piece of the 
build system. But this can be easily solved with svn:external if we 
move the metadata in SVN.

At Forrest our module.xml is an integral part of our build.
I gather that we could use the svn:externals property too.
yes, if that's the need, yes. note however, how svn:external works only 
on a folder (or, at least, I couldn't make it work on a single file)

an alternative, which I'm considering for cocoon too, is to use a get 
operation in the build.xml that fetches the file directly from the CVS 
repository via viewCVS.

This would allow us to avoid moving the metadata to SVN entirely!
We could instead re-structure our build system at Forrest
to not depend on the module.xml file. At first glance it is
just to grab our version number. However, we are just about
to enter a release process, so not yet.
hmmm, if it's just the version number, it's a trivial change, as you can 
place that into the build.properties files and be as happy.

in any case, it is failing so I will start moving it over anyway. you 
guys can decide what to do on your own.

Anyway, +1 from me (still need to raise on forrest-dev)
please do
for moving our metadata to the Gump repository
and +1 for moving all Gump metadata to SVN.
with the above get trick it might not be necessary for now.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

[status] main issues

There are three main issues, IMO, that prevent gump from reaching a 
thermal equilibrium.

 1) the data pollution is too much (signal/noise ratio too low)
 2) the metadata is black magic, inconsistent and not properly documented
 3) the maven integration is poor and hacky
before we can tackle the real juicy challenges that gump faces (for 
example, serious blame back-tracking) we need to get to equilibrium.

Equilibrium is defined when there are no projects with FOG = 0.00
So, goal #1 of this group, IMO, should focus on reaching equilibrium 
before attempting to do anything more serious.

Of the above, I worked on 2) by creating a validation tool. Next phase 
is to write a cron job that validates each module descriptor and nags if 
 it's not valid.

As for 1), I plan to improve the HTML output first (remove some of the 
noise and use DHTML to make ti a little more dynamic), and second work 
on a dynamic webapp for data visualization.

But the *most* serious concern is that we seem to have no way to build 
with Maven and, due to excalibur, this is holding up basically 15 
percent of our projects (including, yes, you guessed right, cocoon).

The problem with maven is that I don't know how we can inject the 
gump-generated dependency jars into maven.

Does anybody have an idea? we can't expect excalibur to fix this on 
their own since this is obviously a gump issue, more than an excalibur 
issue.

--
Stefano.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: One step forward: ws-jaxme requires new jar file

Stefano Mazzocchi wrote:
I would suggest we just add the package, then. jaxme is holding up 134 
projects, let's not add anymore potentially shaky dependencies for now.
May I ask a silly question: How come the number 134? I can hardly 
imagine, that more than two or three of them are actually using JaxMe 
right now?

Regards,
Jochen
--
http://lilypie.com/baby1/050423/1/5/1/+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: One step forward: ws-jaxme requires new jar file

On Thu, 07 Oct 2004, Jochen Wiedmann [EMAIL PROTECTED]
wrote:

 May I ask a silly question: How come the number 134? I can hardly
 imagine, that more than two or three of them are actually using
 JaxMe right now?

dom4j does.  jaxen depends on dom4j and an insane amount of projects
depend on jaxen.

Stefan

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

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

Dear Gumpmeisters,

The following 1 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Module xom success
*** G U M P
[EMAIL PROTECTED]: Module xom 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 folk at [EMAIL PROTECTED]

Module xom *no longer* has an issue.
Module State : 'Success', Reason ''

Full details are available at:

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

That said, some snippets follow:



The following work was performed:
http://brutus.apache.org/gump/public/xom/gump_work/update_xom.html
Work Name: update_xom (Type: Update)
State: Success
Elapsed: 13 secs
Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvs update -P -d -A 
[Working Directory: /usr/local/gump/public/workspace/cvs/xom]
-
P src/nu/xom/URIUtil.java
-




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


--
Gump E-mail Identifier (within run) #1.
Produced by Gump 2.1.0-alpha-0003.
[Run (15000607102004, brutus:brutus-public:15000607102004)]
http://brutus.apache.org/gump/public/index.html
http://brutus.apache.org/gump/public/options.html


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

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

Re: One step forward: ws-jaxme requires new jar file

Stefan Bodewig wrote:
dom4j does.  jaxen depends on dom4j and an insane amount of projects
depend on jaxen.
I have just checked. Dom4j is dependent on jaxmeapi.jar. Most probably
it depends only on the Java 5 XML classes like XMLConstants, QName,
or NamespaceContext. We have long ago suggested, that these be moved to 
a separate jar file in xml-general or jakarta-general. :-(

Jochen
--
http://lilypie.com/baby1/050423/1/5/1/+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [status] main issues

2004-10-07 Thread Niclas Hedhman

On Thursday 07 October 2004 21:37, Stefano Mazzocchi wrote:

 The problem with maven is that I don't know how we can inject the
 gump-generated dependency jars into maven.

Brett Porter (Maven expert) is normally around to answer questions on how 
Maven operates.

 Does anybody have an idea? we can't expect excalibur to fix this on
 their own since this is obviously a gump issue, more than an excalibur
 issue.

I can propose a short term solution;
Revert the Excalibur packages in Gump back to the one sitting in the frozen 
avalon-excalibur CVS, which builds close to perfectly in Gump (I think 
there is the altrmi instrumentation packages that fails as a dep on altrmi, 
or something like that.) 

Then we take the Excalibur Maven projects and name them slightly different, so 
we can sort that out without holding up all the projects downstream.


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


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

Re: [vote] move the descriptors in our hands

2004-10-07 Thread David Crossley

Stefano Mazzocchi wrote:
 David Crossley wrote:
  At Forrest our module.xml is an integral part of our build.
  I gather that we could use the svn:externals property too.
 
 yes, if that's the need, yes. note however, how svn:external works only 
 on a folder (or, at least, I couldn't make it work on a single file)

Drat, no good then, because we only want the one file.

 an alternative, which I'm considering for cocoon too, is to use a get 
 operation in the build.xml that fetches the file directly from the CVS 
 repository via viewCVS.
 
 This would allow us to avoid moving the metadata to SVN entirely!

Sounds good.

  We could instead re-structure our build system at Forrest
  to not depend on the module.xml file. At first glance it is
  just to grab our version number. However, we are just about
  to enter a release process, so not yet.
 
 hmmm, if it's just the version number, it's a trivial change, as you can 
 place that into the build.properties files and be as happy.

Yes. We do not have build.properties, but can do something.

 in any case, it is failing so I will start moving it over anyway. you 
 guys can decide what to do on your own.

As far as i can tell, it is failing because ant-contrib
is failing and we get some previous build of that.
Not our failure, so i didn't do anything.
We have had this one before.

  Anyway, +1 from me (still need to raise on forrest-dev)
 
 please do
 
  for moving our metadata to the Gump repository
  and +1 for moving all Gump metadata to SVN.
 
 with the above get trick it might not be necessary for now.

Will investigate. As i said we are not doing any change
for now, due to imminent release.

-- 
David Crossley


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

Re: [vote] move the descriptors in our hands

David Crossley wrote:
As far as i can tell, it is failing because ant-contrib
is failing and we get some previous build of that.
Not our failure, so i didn't do anything.
We have had this one before.
no, it's not because ant-contrib is failing, but because it's no longer 
there!

where did ant-contrib go btw?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

RE: [status] main issues

2004-10-07 Thread Stephen McConnell



 -Original Message-
 From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]


 But the *most* serious concern is that we seem to have no way to build

 with Maven and, due to excalibur, this is holding up basically 15 
 percent of our projects (including, yes, you guessed right, cocoon).

Fast track solution could be to put the last released jar files into an
excalibur-releases module with project ids matching the current set of
ids, and disable the existing excalibur descriptors pending resolution
of gump/maven equation (see below).

 The problem with maven is that I don't know how we can inject the 
 gump-generated dependency jars into maven.

Maven is fine on the injection stuff - basically it used a jar
override property that tells maven to use the jar file named in a
property value as the actual jar to bind against.  The problem is the
generation of the property files (by gump's maven builder).

 Does anybody have an idea?

Gump uses a namespace made of a project id and an optional output key.
Maven uses a combination of group and artifact name combination.  If we
take for example - the jar file produced by ant containing the junit
optional task is referenced in gump as:

   project: ant
   id: junit

In Maven the same jar file is normally referenced as:

   groupId: ant
   artifactId: ant-junit

When Gump's maven builder generates the proprieties file used during the
maven build, it uses the gump project model to establish the set of
dependencies and for each dump declared dependency (with full
inheritance of dependencies) create a property with the following name
and value:

maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
jar

Problem here is that:

  1. this property definition does not correspond to anything 
 declared in the target project's project.xml (because the 
 property is derived from the gump based dependencies - not
 the project's declared dependencies)

  2. the strategy for mapping of gump artifact keys to maven 
 artifact keys is basically broken in that duplicate property
 names can be generated (e.g. the property name generated for 
 the main JUnit project jar file is maven.jar.junit)

The solution to this problem is to drive the property file generation
off the project.xml file and NOT the gump dependency graph. This will
solve most issues because it will result in a much smaller set of
properties - but an underlying problem needs to be solved - namely the
declaration within a maven project of any mappings between maven
artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit).
These mappings need to be used by the maven gump task when generating a
maven project descriptor.

Stephen.

 we can't expect excalibur to fix this on
 their own since this is obviously a gump issue, more than an excalibur

 issue.
 
 --
 Stefano.
 



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

Re: [status] main issues

Stephen,
thanks much for your input. Some comments below.
But the *most* serious concern is that we seem to have no way to build

with Maven and, due to excalibur, this is holding up basically 15 
percent of our projects (including, yes, you guessed right, cocoon).

Fast track solution could be to put the last released jar files into an
excalibur-releases module with project ids matching the current set of
ids, and disable the existing excalibur descriptors pending resolution
of gump/maven equation (see below).
Yes, that might be an ad-hoc solution and it might work for now since 
there are not so many maven projects in our tree anyway (just checked).

Can you provide such a 'fake' descriptor? i think it would be much 
faster than me trying to hack one up.

The problem with maven is that I don't know how we can inject the 
gump-generated dependency jars into maven.
Maven is fine on the injection stuff - basically it used a jar
override property that tells maven to use the jar file named in a
property value as the actual jar to bind against.  The problem is the
generation of the property files (by gump's maven builder).
Ok, good to know.

Does anybody have an idea?
Gump uses a namespace made of a project id and an optional output key.
Maven uses a combination of group and artifact name combination.  If we
take for example - the jar file produced by ant containing the junit
optional task is referenced in gump as:
   project: ant
   id: junit
In Maven the same jar file is normally referenced as:
   groupId: ant
   artifactId: ant-junit
When Gump's maven builder generates the proprieties file used during the
maven build, it uses the gump project model to establish the set of
dependencies and for each dump declared dependency (with full
inheritance of dependencies) create a property with the following name
and value:
maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
jar
Problem here is that:
  1. this property definition does not correspond to anything 
 declared in the target project's project.xml (because the 
 property is derived from the gump based dependencies - not
 the project's declared dependencies)

  2. the strategy for mapping of gump artifact keys to maven 
 artifact keys is basically broken in that duplicate property
 names can be generated (e.g. the property name generated for 
 the main JUnit project jar file is maven.jar.junit)

The solution to this problem is to drive the property file generation
off the project.xml file and NOT the gump dependency graph. This will
solve most issues because it will result in a much smaller set of
properties - but an underlying problem needs to be solved - namely the
declaration within a maven project of any mappings between maven
artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit).
These mappings need to be used by the maven gump task when generating a
maven project descriptor.
I'm sorry, but I have lost you.
If the strategy is broken, why don't we fix it? [but I think I'm missing 
a point here obviously]

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: How to run gump?

Hi, Adam,
 Yup. Please open up the workspace.xml and edit it to use the full gump
 profile, not the minimal one (which only includes up to Ant, and is
 mainly for testing). See the individual had placed it in there, and
 commented it?
 Once you get the full profile, that ought include ws-jaxme, so it
 ought find the project. If you build just it you may (or may not,
 not sure) run into the need for some packages (downloaded jars).
 Gump doesn't (today) handle that for you (partially 'cos of license
 agreements you might need to click upon) If you get stuck on this
 please post here.
changed the profile, but now I am getting the following.
Regards,
Jochen
[EMAIL PROTECTED] gump]$ python gump.py -w metadata/workspace.xml ws-jaxme
- 
-Apache Gump
- 
- GUMP run on host   : stujwi
- GUMP run @ : 07 Oct 04 21:52:33
- GUMP run @  UTC: 07 Oct 04 19:52:33
- GUMP run by Python : '2.3.3 (#1, May  7 2004, 10:31:40) \n[GCC 3.3.3 
20040412 (Red Hat Linux 3.3.3-7)]'
- GUMP run by Python : '/usr/bin/python'
- GUMP run by Gump   : 2.0.2-alpha-0003
- GUMP run on OS : 'posix'
- GUMP PYTHONPATH  :  /home/jwi/gump/python
Execute : svn update --non-interactive
At revision 54010.
Executing with CWD: [metadata]
Execute : cvs -q update -dP
Password:
M workspace.xml
Execute : /usr/bin/python bin/integrate.py -w metadata/workspace.xml 
ws-jaxme
Traceback (most recent call last):
  File bin/integrate.py, line 109, in ?
irun()
  File bin/integrate.py, line 83, in irun
run=gump.run.gumprun.GumpRun(workspace,ps,options)
  File /home/jwi/gump/python/gump/run/gumprun.py, line 71, in __init__
gump.utils.timing.Timeable.__init__(self, workspace.getName())
AttributeError: 'NoneType' object has no attribute 'getName'
Process Exit Code : 1

--
http://lilypie.com/baby1/050423/1/5/1/+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project ant.xml barcode4j.xml depot.xml excalibur.xml gump.xml j2ee-connector.xml jaas.xml jakarta-cactus.xml jakarta-velocity.xml jstl-jsp-12.xml jts.xml jython.xml mx4j.xml scarab.xml ws-axis.xml ws-juddi.xml wss4j.xml xml-xalan.xml


 On Thu, 07 Oct 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

  so what are the changes?
 
jvmargs can be an empty element inside ant

 I don't know, but maven probably supports it as well.

Yup, anything on the Java platform does.

  and
 
debug= can be an attribute inside ant

 ditto.  Not sure about nant either.

All builders (Ant|Maven|NAnt) and updaters (CVS|SVN|P4 -- I think) support:

debug=true|false
verbose=true|false

Certainly would be nicer if I'd coded these as level=debug|verbose (or
none) I guess...

regards,

Adam


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

failure of ant-contrib busts Forrest (Was: [vote] move the descriptors in our hands)

2004-10-07 Thread David Crossley

Stefano Mazzocchi wrote:
 David Crossley wrote:
 
  As far as i can tell, it is failing because ant-contrib
  is failing and we get some previous build of that.
  Not our failure, so i didn't do anything.
  We have had this one before.
 
 no, it's not because ant-contrib is failing, but because it's no longer 
 there!
 
 where did ant-contrib go btw?

It is not ant as in Apache Ant. It is a SourceForge project.
Last time this happened it was because SF.net was failing
or their CVS or something, IIRC. Last time, we mistakenly
tried to add an entry to our Gump descriptor, thinking that
we were missing something. Adam stepped in and found the cause
and asked us to remove it. So i suppose it is defined elsewhere.
I am lost sorry.

-- 
David Crossley


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

Re: cvs commit: gump/project ant.xml barcode4j.xml depot.xml excalibur.xml gump.xml j2ee-connector.xml jaas.xml jakarta-cactus.xml jakarta-velocity.xml jstl-jsp-12.xml jts.xml jython.xml mx4j.xml scarab.xml ws-axis.xml ws-juddi.xml wss4j.xml xml-xalan.xml

2004-10-07 Thread Peter Janes

Adam R. B. Jack wrote:
All builders (Ant|Maven|NAnt) and updaters (CVS|SVN|P4 -- I think) support:
debug=true|false
verbose=true|false
I didn't include anything specifically for debug/verbose in the P4 updater, 
so it probably ignores those attributes.  There's not much extra info that 
it can give anyway, so I think it's okay to have them as no-ops.
--
Sometimes the Universe needs a change of perspective.
  --J. Michael Straczynski


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [status] main issues


   3) the maven integration is poor and hacky

How much do you actually know about this integration? I don't know that it
is poor, and I believe it is not hacky. Where are you getting your
information?

 But the *most* serious concern is that we seem to have no way to build
 with Maven and, due to excalibur, this is holding up basically 15
 percent of our projects (including, yes, you guessed right, cocoon).

 The problem with maven is that I don't know how we can inject the
 gump-generated dependency jars into maven.

We are doing it. Clearly you've next to no idea on how this works.

We use the technique that Mavenites told us was appropriate:


http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies

 Does anybody have an idea? we can't expect excalibur to fix this on
 their own since this is obviously a gump issue, more than an excalibur
 issue.

So what is the problem?

regards,

Adam


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

RE: [status] main issues

2004-10-07 Thread Stephen McConnell



 -Original Message-
 From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]


 But the *most* serious concern is that we seem to have no way to build
 with Maven and, due to excalibur, this is holding up basically 15
 percent of our projects (including, yes, you guessed right, cocoon).

Fast track solution could be to put the last released jar files into an
excalibur-releases module with project ids matching the current set of
ids, and disable the existing excalibur descriptors pending resolution
of gump/maven equation (see below).

 The problem with maven is that I don't know how we can inject the
 gump-generated dependency jars into maven.

Maven is fine on the injection stuff - basically it used a jar
override property that tells maven to use the jar file named in a
property value as the actual jar to bind against.  The problem is the
generation of the property files (by gump's maven builder).

 Does anybody have an idea? 

Gump uses a namespace made of a project id and an optional output key.
Maven uses a combination of group and artifact name combination.  If we
take for example - the jar file produced by ant containing the junit
optional task is referenced in gump as:

   project: ant
   id: junit

In Maven the same jar file is normally referenced as:

   groupId: ant
   artifactId: ant-junit

When Gump's maven builder generates the proprieties file used during the
maven build, it uses the gump project model to establish the set of
dependencies and for each dump declared dependency (with full
inheritance of dependencies) create a property with the following name
and value:

maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.
jar

Problem here is that:

  1. this property definition does not correspond to anything 
 declared in the target project's project.xml (because the 
 property is derived from the gump based dependencies - not
 the project's declared dependencies)

  2. the strategy for mapping of gump artifact keys to maven 
 artifact keys is basically broken in that duplicate property
 names can be generated (e.g. the property name generated for 
 the main JUnit project jar file is maven.jar.junit)

The solution to this problem is to drive the property file generation
off the project.xml file and NOT the gump dependency graph. This will
solve most issues because it will result in a much smaller set of
properties - but an underlying problem needs to be solved - namely the
declaration within a maven project of any mappings between maven
artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit).
These mappings need to be used by the maven gump task when generating a
maven project descriptor.

Stephen.

 we can't expect excalibur to fix this on
 their own since this is obviously a gump issue, more than an excalibur
 issue.
 
 --
 Stefano.
 



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

Re: [vote] move the descriptors in our hands

 no, it's not because ant-contrib is failing, but because it's no longer
 there!

 where did ant-contrib go btw?

ant-contrib comes and goes (I think) as it's gump descriptor fails to get
read from SF.net's viewcvs. One days that service barfs ant-contrib is
missing (it was for a month when they had a hardware failure). I checked
yesterday and I think it is back. Is it not being found by others?

regards

Adam


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

Re: [status] main issues

Adam R. B. Jack wrote:
So what is the problem?
Problem is
http://brutus.apache.org/gump/public/excalibur/
maven integration might not be hacky (true, I had no idea we were 
injectin stuff in, so I take that back) but it does not work at all.

Now, tell me, is this just a matter of fixing the excalibur.xml file or, 
like Stephen suggested, the problem is much deeper?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Maven and excalibur

maven integration might not be hacky (true, I had no idea we were
injectin stuff in, so I take that back) but it does not work at all.

Wanna take that back also? ;-) It works for a number of Maven projects.

e.g.

http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html

See:

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

Problem is

http://brutus.apache.org/gump/public/excalibur/

Basically, the first one I looked at either needed more Gump depends in the
descriptor (or changes to 'jar ids', see next) that lead to Maven jar
overrides. BTW: The 'gump' goal for a Maven project takes this information
from the POM and creates the correct Gump descriptor. Have you tried that?

Now, tell me, is this just a matter of fixing the excalibur.xml file or,
like Stephen suggested, the problem is much deeper?

I'm on diaper duty today, so I haven't had chance to read Stephen's
concerns. I also don't know if 'Magic' is involved here. That said, Stephen
did mention groupId and artifactId -- whereas Gump has 'jar id' (which we
map only to artifact id). As I understand it Maven 1.0 is still ok w/
artifact id, it isn't yet requiring groupId, that is coming soon. When it
comes we'll probably use the module name as the groupId default, and allow
overrides.

The main problem we have is that Gump jar ids are not sufficiently unique,
so we've decided to (bit by bit) change ours to match theirs.

When I get time I'll look at these closer.

regards,

Adam

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

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

Dear Gumpmeisters,

The following 1 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Project invicta (in Module invicta) failed
*** G U M P
[EMAIL PROTECTED]: Project invicta (in Module invicta) 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 folk at [EMAIL PROTECTED]

Project invicta has an issue affecting its community integration.
This issue affects 1 projects.
Project State : 'Failed'
The following are affected:
- invicta :  Open-source build management tool.


Full details are available at:

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

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole output [invicta-07102004.jar] identifier set to project name
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: ant-contrib unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository



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


--
Gump E-mail Identifier (within run) #6.
Produced by Gump 2.1.0-alpha-0003.
[Run (13001607102004, brutus:brutus-public:13001607102004)]
http://brutus.apache.org/gump/public/index.html
http://brutus.apache.org/gump/public/options.html


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

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

The magically disappearing ant-contrib (Gump Project)

2004-10-07 Thread Adam Jack

I think there is a new reason for ant-contrib disappearing, and I suspect it
is related to the spam that SF.net seem to be putting at the top of their
viewcvs. When I curl this URL from brutus I get HTML not XML

http://cvs.sourceforge.net/viewcvs.py/*checkout*/ant-contrib/ant-contrib/src/etc/gump-descriptor.xml

We've changed SF.net viewcvs URLs in the past to work past issues, and we've
had numerous transient outages here also. I think it is time to move these
descriptors into Gump CVS (perhaps as step one as part of Stefano's
centralization.) If anybody can't access them there, I'm sure Gumpers/ASFers
will help out with changes.

Any objections?

regards

Adam


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

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

2004-10-07 Thread Brett Porter

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

That gives XML.

Cheers,
Brett

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


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

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