cvs commit: gump/project jakarta-commons.xml jakarta-commons-sandbox.xml

[bodewig]

bodewig 2004/03/01 23:44:28

  Modified:project  jakarta-commons.xml jakarta-commons-sandbox.xml
  Log:
  Commons IO has graduated
  
  Revision  ChangesPath
  1.122 +23 -0 gump/project/jakarta-commons.xml
  
  Index: jakarta-commons.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-commons.xml,v
  retrieving revision 1.121
  retrieving revision 1.122
  diff -u -r1.121 -r1.122
  --- jakarta-commons.xml   27 Feb 2004 13:33:56 -  1.121
  +++ jakarta-commons.xml   2 Mar 2004 07:44:28 -   1.122
  @@ -274,6 +274,29 @@
from="Stefan Bodewig <[EMAIL PROTECTED]>"/>
 
   
  +  
  +org.apache.commons.io
  +Commons I/O Utility Package
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +  
 
   org.apache.commons.jelly
   Commons Jelly Package
  
  
  
  1.154 +0 -23 gump/project/jakarta-commons-sandbox.xml
  
  Index: jakarta-commons-sandbox.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-commons-sandbox.xml,v
  retrieving revision 1.153
  retrieving revision 1.154
  diff -u -r1.153 -r1.154
  --- jakarta-commons-sandbox.xml   27 Feb 2004 13:33:56 -  1.153
  +++ jakarta-commons-sandbox.xml   2 Mar 2004 07:44:28 -   1.154
  @@ -140,29 +140,6 @@
from="Ted Husted <[EMAIL PROTECTED]>"/>
 
   
  -  
  -org.apache.commons.io
  -Commons I/O Utility Package
  -
  -
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -  
 
   org.apache.commons.jjar
   Jakarta Jar Archive Repository
  
  
  

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

Re: [PROPOSAL] End Gump builds for sandbox projects

[Stefan Bodewig]

On Tue, 02 Mar 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> What do you want to stop?  Building of the jars or just publishing
> them?

BTW, this would be the ripple effect if we'd stop building
jakarta-commons-sandbox projects in Gump:

Dropping project jakarta-turbine-fulcrum because of Exception java.lang.Exception: 
project "commons-util" not found processing project jakarta-turbine-fulcrum
Dropping project db-torque because of Exception java.lang.Exception: project 
"commons-io" not found processing project db-torque
Dropping project jakarta-turbine-site because of Exception java.lang.Exception: 
project "jakarta-turbine-fulcrum" not found processing project jakarta-turbine-site
Dropping project jakarta-turbine-3 because of Exception java.lang.Exception: project 
"db-torque" not found processing project jakarta-turbine-3
Dropping project jakarta-turbine-2 because of Exception java.lang.Exception: project 
"commons-email" not found processing project jakarta-turbine-2
Dropping project jakarta-turbine-flux because of Exception java.lang.Exception: 
project "jakarta-turbine-3" not found processing project jakarta-turbine-flux
Dropping project jakarta-turbine-orgami because of Exception java.lang.Exception: 
project "jakarta-turbine-2" not found processing project jakarta-turbine-orgami
Dropping project commons-jelly-tags-jms because of Exception java.lang.Exception: 
project "commons-messenger" not found processing project commons-jelly-tags-jms
Dropping project maven-bootstrap because of Exception java.lang.Exception: project 
"commons-io" not found processing project maven-bootstrap
Dropping project jakarta-turbine-stratum-full because of Exception 
java.lang.Exception: project "commons-messenger" not found processing project 
jakarta-turbine-stratum-full
Dropping project jakarta-taglibs-jmstags because of Exception java.lang.Exception: 
project "commons-messenger" not found processing project jakarta-taglibs-jmstags
Dropping project jakarta-turbine-tdk because of Exception java.lang.Exception: project 
"commons-util" not found processing project jakarta-turbine-tdk
Dropping project commons-jelly-tags-ant because of Exception java.lang.Exception: 
project "commons-grant" not found processing project commons-jelly-tags-ant
Dropping project incubator-altrmi because of Exception java.lang.Exception: project 
"commons-attributes" not found processing project incubator-altrmi
Dropping project jakarta-turbine-stratum because of Exception java.lang.Exception: 
project "commons-io" not found processing project jakarta-turbine-stratum
Dropping project jakarta-turbine-jyve because of Exception java.lang.Exception: 
project "jakarta-turbine-2" not found processing project jakarta-turbine-jyve
Dropping project werkz because of Exception java.lang.Exception: project 
"commons-jelly-tags-ant" not found processing project werkz
Dropping project xml-fop because of Exception java.lang.Exception: project 
"commons-io" not found processing project xml-fop
Dropping project jakarta-jetspeed because of Exception java.lang.Exception: project 
"jakarta-turbine-2" not found processing project jakarta-jetspeed
Dropping project scarab because of Exception java.lang.Exception: project 
"jakarta-turbine-3" not found processing project scarab
Dropping project maven because of Exception java.lang.Exception: project "werkz" not 
found processing project maven
Dropping project incubator-geronimo because of Exception java.lang.Exception: project 
"maven" not found processing project incubator-geronimo
Dropping project excalibur-instrument-client because of Exception java.lang.Exception: 
project "incubator-altrmi" not found processing project excalibur-instrument-client
Dropping project dom4j because of Exception java.lang.Exception: project "xml-fop" not 
found processing project dom4j
Dropping project excalibur-instrument-manager-altrmi because of Exception 
java.lang.Exception: project "incubator-altrmi" not found processing project 
excalibur-instrument-manager-altrmi
Dropping project commons-jelly-tags-jsl because of Exception java.lang.Exception: 
project "commons-grant" not found processing project commons-jelly-tags-jsl
Dropping project db-ojb because of Exception java.lang.Exception: project "db-torque" 
not found processing project db-ojb

The strongest effect stems from commons-io which isn't in the sandbox
anymore, right?  Could you please review

to identify more components that have been graduated without Gump
reflecting the change?  Remember, all Apache committers have karma for
the gump module.

Stefan

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

Re: Ant import problem

[Stefan Bodewig]

On Tue, 02 Mar 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:

> the jicarilla build is assuming that the user has a .jbs
> subdirectory, this is not very cool.

If the build-reactor.xml is really necessary, you can override
jbs.home in the Gump descriptor so that it works against a copy from
somewhere else (a default file from jicarila's CVS?).

If it is more or less optional, please add optional="true" to the
 tasks.

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

[Stefan Bodewig]

I'm not exactly sure what you are asking for, so please help me to
understand the proposal.

Gump builds stuff and under certain circumstances it publishes the
generated jars.  For example, the build system that is currently
sending the nag emails is not publishing the build artifacts at all.

What do you want to stop?  Building of the jars or just publishing
them?

I think building sandbox components is as important as building any
other component.  How would the authors of a sandbox component get to
know that their usage of JDOM relies on jdom-b9 and will not compile
against JDOM 1.0 when released?

Publishing is a different story IMHO.

Stefan

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

Re: Gump project infrastructure needs

[Stefan Bodewig]

On Mon, 01 Mar 2004, Nick Chalko <[EMAIL PROTECTED]> wrote:

> commit mails are still going to [EMAIL PROTECTED]

I think that is OK since gump-cvs is an alias for [EMAIL PROTECTED]

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

[Henri Yandell]

Okay, so you just mean no gump for sandbox [deletes long rant about
importance of nightly builds]. Summary of it is, that I think gump and the
apache repository need to be hooked together so each project is updating
the SNAPSHOT whenever it changes.

Last Lang SNAPSHOT was the end of January.

+1 to kill gump builds for sandbox projects. In fact, +1 to kill it for
all unreleased projects [sorry dIon/Phil/Mark].

Hen

On Mon, 1 Mar 2004, Nick Chalko wrote:

> As long as project don't decide to use gump anyways and cheat relying on
> a version sandbox projects jar checked into CVS then I think this is a
> reasonable thing.
> Stephen Colebourne wrote:
>
> >This is a proposal to begin to end the abuse of the sandbox. (The sandbox
> >was intended as a temporary 'play area' for new ideas, not a long term
> >project home)
> >
> >Gump is the key mechanism used in apache to ensure that everything keeps
> >building. By removing the sandbox projects, we should encourage other
> >projects not to depend on the sandbox unless they are willing to help push
> >the project to a release.
> >
> >Normally decisions such as this have been left to each project, but IMHO its
> >time for commons-dev to take control. Any views? Do we vote or just do it?
> >
> >Stephen
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Wanna join "Gump" : Development

[krishnamoorthy]

Hi,
I am interested to join in this development team.I
checked the "outstanding TODOS " list and I am
interested to invole in this team.Let me know if I
could do something.Btw I do't know " Python".I am from
J2EE/Java background.
regds
Kicha

__
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

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

Re: [PROPOSAL] End Gump builds for sandbox projects

[Adam R. B. Jack]

> This is a proposal to begin to end the abuse of the sandbox. (The sandbox
> was intended as a temporary 'play area' for new ideas, not a long term
> project home)

This is a fascinating approach, and not unlike something that drove me
towards Gump in the first place. I was a heavy user of a common (sandbox)
project that after a lot of (user) investment on my part went badly
stagnant. I felt pretty mift, and wished I had some metrics (or similar) to
help me make my choices of dependencies in the first place.

I turned to Gump to attempt to determine which projects were healthy
(stagnant isn't a bad thing for a feature rich, stable product, with a
stable stack below it) and which weren't. I feel it is only 'open' to give
an assessment of a project's status, and what better way that the
'googlesque' (I'm sure it is a word waiting to enter the dictionary ;-)
approach of letting community usage/satisfaction do the talking. Increase
the rating of a project by using it, depending on it. Decrease it by walking
away (as I did) breaking dependency.

Here Gump attempts to 'rate' a project by 'FOG Factor' (eventually something
mystical, a combination of all, but right now a ratio of successes verse
failures, including those of the dependency stack)  :
http://lsd.student.utwente.nl/gump/gump_stats/project_fogfactor.html

This is by 'count of dependees' (how many projects depend on the project):
http://lsd.student.utwente.nl/gump/gump_stats/module_dependees.html

This is by last updated (on the module) - yup, sadly bogus for commons, I
know. :(
http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html

Gump is far from done, we'll work with folks to create new views/new stats,
but it is amasing valuable (albethem statistical) insights into projects on
a daily basis.

As such - please do NOT remove these things from Gump, please help us use
Gump to publically determine the wheat from the chaff, whilst you apply PMC
or peer means to clean house of projects that have failed to achieve mass.
Gump might be in a position (especially with help of users like you seeking
solutions) to help you determine what course of action to take for each
component...

regards

Adam



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

Re: Gump Database

[Adam R. B. Jack]

This can wait a while, and certainly until after your demo.

I'll try to move it to the Wiki so folks can read/contribute as their time
allows, and not struggle to decipher (Adam English)/comprehend/respond
whilst surviving a day's inbox overload...

regards

Adam
- Original Message - 
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: "Gump code and data" <[EMAIL PROTECTED]>
Sent: Monday, March 01, 2004 7:47 PM
Subject: Re: Gump Database


> Adam R. B. Jack wrote:
>
> > Stefano wrote:
> >
> >
> >>While the question that you should be asking yourself is: what does the
> >>data look like? how stuctured is it?
> >>
> >> From where I stand, the gump metadata is highly structured and can be
> >>perfectly mapped in to a relational structure with reasonable effort.
> >>Also, given its structure, can be indexed precisely and thus queried
> >>very efficiently.
> >
> >
> > So the fact that I can visualize this it into a huge rats nest in my
head
> > (especially when wired into objects) doesn't help me make a case for it
> > being unstructured? ;-) ;-)
> >
> > Ok, I hear you -- and stepping back, looking at the main (named)
entities as
> > entries in tables, I can see a relational schema with relationships as
names
> > with or without RI. What I can't see (though) is what helps me with the
time
> > aspect --- i.e. when a dependency is dropped, what do I compare against?
>
> nonono wait a second. What are you talking about? I was talking about
> putting the historical data into the system, not the gump metadata.
>
> > I guess the data I'm interested in right now is (somehow) relationships
over
> > time. One projects relationship to it's repository, to it's peers, to
> > communities (of users). How that looks, I'm not sure, but I'll try to
answer
> > that in my head before I continue.
>
> I have an email in my draft folder about how we can do perfect nagging
> with gump... but I need to understand the graph complexity before I can
> go on and I don't have much time ATM since we are delivering the first
> demo of our project next week.
>
> >>At that point, once you have the data in the database, you can start
> >>thinking about what to do with it. Dependency graph visualization,
> >>history of dependencies, FoG estimation, all of these are problems that
> >>will result in particular queries and particular use of the result set.
> >
> >
> > I like XML as the human (community) editable interface, and converting
it to
> > relational for each run really doesn't appeal to me.
>
> Of course!! Nonono, I don't want to move from XML descriptors to
> relational data, that would be stupid without an GUI or a webapp to
> guide people, but I wouldn't use it anyway.
>
> > Even if I do, comparing
> > as I load, and detecting changes -- also sounds like work. It also
sounds
> > similar to the XML to Object work that Gumpy is doing, and I was hoping
> > something could help out here w/o me doing it myself in pedestrian
steps.
>
> I am *NOT* proposing to change the way gump loads metadata but the way
> gump stores history information
>
> > I need to do more thinking, but thanks for the direct feedback, I
appreciate
> > that. Another persons clarity helps.
> >
> > BTW: So say we want MySQL [for results and maybe more], how do we set
that
> > up? Do we install, or leverage an existing MySQL install at Apache?
>
> good question, but too early now, let's focus on what we want to do and
> how, the infrastructural details will come after that.
>
> -- 
> Stefano.
>
>


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

Re: [PROPOSAL] End Gump builds for sandbox projects

[Mark R. Diggory]

Henri Yandell wrote:

Okay, so you just mean no gump for sandbox [deletes long rant about
importance of nightly builds]. Summary of it is, that I think gump and the
apache repository need to be hooked together so each project is updating
the SNAPSHOT whenever it changes.
Nick's probably going to insert something to the effect that Gump isn't 
a nightly build publishing system, its a continuous integration testing 
system. ;-)

The dealio with publishing nightly snapshots was to hopefully get them 
into somewhere like

/www/cvs.apache.org/builds/java-repository

the reasoning is that www/www.apache.org is reserved for official 
releases while cvs.apache.org is reserved for nightly builds, stuff that 
really goes out to the world for external projects to build off of 
actually goes into ibiblio in the end, all nightlies stay at Apache. 
[Mark repeats himself yet again...crickets, silence...sigh]

Last Lang SNAPSHOT was the end of January.

+1 to kill gump builds for sandbox projects. In fact, +1 to kill it for
all unreleased projects [sorry dIon/Phil/Mark].
More motivation to get that Math release out sooner ;-)

Hen

On Mon, 1 Mar 2004, Nick Chalko wrote:


As long as project don't decide to use gump anyways and cheat relying on
a version sandbox projects jar checked into CVS then I think this is a
reasonable thing.
Stephen Colebourne wrote:

This is a proposal to begin to end the abuse of the sandbox. (The sandbox
was intended as a temporary 'play area' for new ideas, not a long term
project home)
Gump is the key mechanism used in apache to ensure that everything keeps
building. By removing the sandbox projects, we should encourage other
projects not to depend on the sandbox unless they are willing to help push
the project to a release.
Normally decisions such as this have been left to each project, but IMHO its
time for commons-dev to take control. Any views? Do we vote or just do it?
Stephen



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



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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Gump Database

[Stefano Mazzocchi]

Adam R. B. Jack wrote:

Stefano wrote:


While the question that you should be asking yourself is: what does the
data look like? how stuctured is it?
From where I stand, the gump metadata is highly structured and can be
perfectly mapped in to a relational structure with reasonable effort.
Also, given its structure, can be indexed precisely and thus queried
very efficiently.


So the fact that I can visualize this it into a huge rats nest in my head
(especially when wired into objects) doesn't help me make a case for it
being unstructured? ;-) ;-)
Ok, I hear you -- and stepping back, looking at the main (named) entities as
entries in tables, I can see a relational schema with relationships as names
with or without RI. What I can't see (though) is what helps me with the time
aspect --- i.e. when a dependency is dropped, what do I compare against?
nonono wait a second. What are you talking about? I was talking about 
putting the historical data into the system, not the gump metadata.

I guess the data I'm interested in right now is (somehow) relationships over
time. One projects relationship to it's repository, to it's peers, to
communities (of users). How that looks, I'm not sure, but I'll try to answer
that in my head before I continue.
I have an email in my draft folder about how we can do perfect nagging 
with gump... but I need to understand the graph complexity before I can 
go on and I don't have much time ATM since we are delivering the first 
demo of our project next week.

At that point, once you have the data in the database, you can start
thinking about what to do with it. Dependency graph visualization,
history of dependencies, FoG estimation, all of these are problems that
will result in particular queries and particular use of the result set.


I like XML as the human (community) editable interface, and converting it to
relational for each run really doesn't appeal to me. 
Of course!! Nonono, I don't want to move from XML descriptors to 
relational data, that would be stupid without an GUI or a webapp to 
guide people, but I wouldn't use it anyway.

Even if I do, comparing
as I load, and detecting changes -- also sounds like work. It also sounds
similar to the XML to Object work that Gumpy is doing, and I was hoping
something could help out here w/o me doing it myself in pedestrian steps.
I am *NOT* proposing to change the way gump loads metadata but the way 
gump stores history information

I need to do more thinking, but thanks for the direct feedback, I appreciate
that. Another persons clarity helps.
BTW: So say we want MySQL [for results and maybe more], how do we set that
up? Do we install, or leverage an existing MySQL install at Apache?
good question, but too early now, let's focus on what we want to do and 
how, the infrastructural details will come after that.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] End Gump builds for sandbox projects

[Nick Chalko]

As long as project don't decide to use gump anyways and cheat relying on 
a version sandbox projects jar checked into CVS then I think this is a 
reasonable thing.
Stephen Colebourne wrote:

This is a proposal to begin to end the abuse of the sandbox. (The sandbox
was intended as a temporary 'play area' for new ideas, not a long term
project home)
Gump is the key mechanism used in apache to ensure that everything keeps
building. By removing the sandbox projects, we should encourage other
projects not to depend on the sandbox unless they are willing to help push
the project to a release.
Normally decisions such as this have been left to each project, but IMHO its
time for commons-dev to take control. Any views? Do we vote or just do it?
Stephen



-
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: [Fwd: [GUMP][PATCH] this should make avalon compile in Gump]

[Adam R. B. Jack]

> Spare the beer for a hot summer day... Try to provide a little bit more
> guidance, because I think that most people here (except LSD) are pretty
> scared of Gump.

I don't think a Gump descriptor is any more complex than an ant build
script, or a Maven project file, and it is documented (if imperfectly,
http://gump.apache.org/metadata/index.html) -- but I think it is something
so infrequently visited that folks don't understand it. Maybe somebody
creates it, it works faultlessly for eons [only nagging occasionally], and
then when it breaks perhaps the author is unavailable. Folks don't touch it
every day, in order to get used to it.

What has occur (to me) out of this is the need more annotations in Gump
descriptors, and (I'd like to add) a page per descriptor where Gump
annotates the descriptor it has. I.e. lot of "this was set in this project
therefore (based on doc reference blah) this will occur...".

Gumpy is a lot more transparent than it was, but needs to be even more
transparent to appeal to the general community.

regards

Adam


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

Ant import problem [was Re: jbs (Jicarilla Build System?) and includes...]

[Antoine Lévy-Lambert]

Hi Adam, and jicarilla developers,

(this is feeback about the build of jicarilla on gump, a system doing nightly builds of head revision of open-source projects)

the jicarilla build is assuming that the user has a .jbs subdirectory, this is not very cool.

Antoine



http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/buildsystem/build-basic-reactor.xml?view=markup




   
   
   !-- *this is the case of gump *--> 
   
   


buildfile: build.xml
[property] dropping 
/data3/gump/jicarilla-sandbox/platform/components/collections/target/classes from path 
as it doesn't exist
[property] dropping 
/data3/gump/jicarilla-sandbox/platform/components/collections/target/test-classes from 
path as it doesn't exist
BUILD FAILED
/data3/gump/jicarilla-sandbox/platform/components/collections/build.xml:6: 
Cannot find /home/ajack/.jbs/build-project.xml 
imported from /data3/gump/jicarilla-sandbox/platform/components/collections/build.xml

Total time: 0 seconds

http://lsd.student.utwente.nl/gump/jicarilla-sandbox/jicarilla-collections.html#Build+%3A+build_jicarilla-sandbox_jicarilla-collections



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

Re: Failures in xml-security

[Berin Lautenbach]

> On Mon, 01 Mar 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> If I do so for the latest version, I get a different type of error
> message
>
>[junit] org.apache.xml.security.encryption.XMLEncryptionException:
>Padding: ISO10126PADDING not implemented [junit] Original Exception
>was javax.crypto.NoSuchPaddingException: Padding: ISO10126PADDING
>not implemented [junit]at
>org.apache.xml.security.encryption.XMLCipher.getInstance(XMLCipher.java:285)>
> but it looks as if bouncycastle doesn't get used at all.

Yup - thus my original question :>.  The SunJCE only supports
PKCS5Padding, which is not quite what we need (it's fussy in places that
break the interop testing for xml-security).
But what I don't understand is why it (the SunJCE) is getting called.  I
am running a 1.4 JRE and still getting BC called for all crypt.  I
actually have to explictly remove BC from the CLASSPATH and update some
configurations inside xml-security, to get these errors.
> If I only use the provider jar and nothing else, I again get another
> error (something about not being able to find provider "BC" or not
> being able to verify it).
>
> To me it looks as if we'd have to install things to use bouncycastle
> with JDK 1.4 anyway, at least the unrestricted policy file has to be
> installed.  I'd be glad if anybody with a better JCE background than I
> have could help out here.

That's got me confused as well.  If the policy files are not installed,
then we should be getting errors about unsupported key lengths long before
we get a padding error - or at least that's my experience.
Let me play around on a test system and see if I can replicate the problem
on a test system here.
Cheers,
 Berin




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

patch for testsuite/build.xml

[Antoine Lévy-Lambert]

Hi Sliders,

can you update the build.xml file located in the testsuite subdir, there 
is a leftover of your last change of jdom version,
this is putting the gump build for your software unneedly in the red, 
where it should be green like a prairie in Normandie.

Cheers,

Antoine
Index: testsuite/build.xml
===
RCS file: /home/cvspublic/jakarta-slide/testsuite/build.xml,v
retrieving revision 1.19
diff -u -r1.19 build.xml
--- testsuite/build.xml 18 Feb 2004 09:31:59 -  1.19
+++ testsuite/build.xml 1 Mar 2004 22:54:25 -
@@ -49,7 +49,7 @@
   
 
 
-
+
 
 
   

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

cvs commit: gump/python/gump/document forrest.py

[ajack]

ajack   2004/03/01 14:46:41

  Modified:python/gump/document forrest.py
  Log:
  Well, dotnot ran w/ this 'results linking' code, and didn't fall over,

  but the results don't seem right. Need to dig in...
  
  Revision  ChangesPath
  1.89  +12 -5 gump/python/gump/document/forrest.py
  
  Index: forrest.py
  ===
  RCS file: /home/cvs/gump/python/gump/document/forrest.py,v
  retrieving revision 1.88
  retrieving revision 1.89
  diff -u -r1.88 -r1.89
  --- forrest.py1 Mar 2004 21:28:00 -   1.88
  +++ forrest.py1 Mar 2004 22:46:41 -   1.89
  @@ -1391,6 +1391,8 @@
   serverResults=None
   if isinstance(linkable,Resultable) and linkable.hasServerResults():
   serverResults=linkable.getServerResults()
  +else:
  +log.debug('Have no Resultable for statePair ' + `linkable`)
   
   for server in servers: 
   
  @@ -1398,7 +1400,11 @@
   statePair=None
   if serverResults and serverResults.has_key(server):
   results=serverResults[server]
  -statePair=results.getStatePair()
  +if results:
  +log.debug('Have statePair ' + `statePair`)
  +statePair=results.getStatePair()
  +else:
  +log.debug('Have no results for statePair ' + `server`)
   
   # If we can resolve this object to a URL, then do
   xdocNode=None
  @@ -1413,8 +1419,9 @@
   server.getUrl())  
   
   if xdocNode and statePair:
  +log.debug('Have xdocNode and statePair ' + `statePair`)
   depth=getDepthForObject(linkable)
  -self.insertStatePairIconAtDepth(xdocNode, statePair,depth)
  +self.insertStatePairIconAtDepth(xdocNode,statePair,depth)
   else:
   xdocNode.createText('On ' + server.getName())
   
  
  
  

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

Re: [GUMP@lsd]: avalon/avalon failed

[Adam R. B. Jack]

>
>http://build.try.sybase.com/eclipse-gump/gump_xref/descriptor_project.html

> is this build.try.sybase.com URL supposed to be public ? I cannot open
> it in my Web browser.

Oops, no, sorry -- one of my internal ones. I was using my browser history
to get to an xref link, and didn't look closely.

That said, coincidentally, http://gump.try.sybase.com [a public server] is
under construction once again. Once I get gumpy.py working there (and if the
VMWare ESX on this bigger/more resourced box hold up to full Gumpy load,
like the GSX on lesser hardware didn't) I'll add it to the pool.

Once I get this local box up, I'll look at the foreign world of OSX on
moof...

regards

Adam


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

PSP on Moof?

[Adam R. B. Jack]

Anybody able to determine if this is doable/available on moof? PSP = Python
Server Pages. I'd love to tap into Gump Python modules from HTTP requests,
to provide functionality like (please verify/annotate my Gump metadata at
blah, kinda like Sam's feed validator, but a descriptor validator.) That,
and more.

http://www.onlamp.com/pub/a/python/2004/02/26/python_server_pages.html

Anybody used PSP?

regards,

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


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

Re: [GUMP@lsd]: avalon/avalon failed

[Antoine Lévy-Lambert]

Adam R. B. Jack wrote:

Could you enter this as an enhancement request into JIRA? I (about a month
ago) tried having this information listed in xref, and also on each
project/module, but even though it is in there (see the href attribute)
   http://lsd.student.utwente.nl/gump/avalon/index_details.html#Definition

I somehow failed:

http://build.try.sybase.com/eclipse-gump/gump_xref/descriptor_project.html

 

Adam,

is this build.try.sybase.com URL supposed to be public ? I cannot open 
it in my Web browser.

Yes, I did not see this module definition link on lsd. There are lots of 
useful links in the forrest output present
on LSD, you have done a great job.

Rather than writing a JIRA, I will have a look at the existing docu, and 
add whatever I feel is missing and I understand.
Adding to the documentation is a good way of getting a number of points 
clarified, sometimes discussed..
And then it can help other gump users..

Cheers,

Antoine.

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

Re: Gump Database

[Adam R. B. Jack]

Stefano wrote:

> While the question that you should be asking yourself is: what does the
> data look like? how stuctured is it?
>
>  From where I stand, the gump metadata is highly structured and can be
> perfectly mapped in to a relational structure with reasonable effort.
> Also, given its structure, can be indexed precisely and thus queried
> very efficiently.

So the fact that I can visualize this it into a huge rats nest in my head
(especially when wired into objects) doesn't help me make a case for it
being unstructured? ;-) ;-)

Ok, I hear you -- and stepping back, looking at the main (named) entities as
entries in tables, I can see a relational schema with relationships as names
with or without RI. What I can't see (though) is what helps me with the time
aspect --- i.e. when a dependency is dropped, what do I compare against?

I guess the data I'm interested in right now is (somehow) relationships over
time. One projects relationship to it's repository, to it's peers, to
communities (of users). How that looks, I'm not sure, but I'll try to answer
that in my head before I continue.

> At that point, once you have the data in the database, you can start
> thinking about what to do with it. Dependency graph visualization,
> history of dependencies, FoG estimation, all of these are problems that
> will result in particular queries and particular use of the result set.

I like XML as the human (community) editable interface, and converting it to
relational for each run really doesn't appeal to me. Even if I do, comparing
as I load, and detecting changes -- also sounds like work. It also sounds
similar to the XML to Object work that Gumpy is doing, and I was hoping
something could help out here w/o me doing it myself in pedestrian steps.

I need to do more thinking, but thanks for the direct feedback, I appreciate
that. Another persons clarity helps.

BTW: So say we want MySQL [for results and maybe more], how do we set that
up? Do we install, or leverage an existing MySQL install at Apache?

regards,

Adam


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

cvs commit: gump gumpy.py

[ajack]

ajack   2004/03/01 13:56:23

  Modified:.gumpy.py
  Log:
  The projects expression '*' gets expanded, so pass 'all'.
  
  Revision  ChangesPath
  1.7   +1 -1  gump/gumpy.py
  
  Index: gumpy.py
  ===
  RCS file: /home/cvs/gump/gumpy.py,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- gumpy.py  1 Mar 2004 21:49:30 -   1.6
  +++ gumpy.py  1 Mar 2004 21:56:23 -   1.7
  @@ -214,7 +214,7 @@
   

   workspacePath = os.path.abspath(workspaceName)

   

  -projectsExpr='*'

  +projectsExpr='all'

   if os.environ.has_key('GUMP_PROJECTS'):

   projectsExpr = os.environ['GUMP_PROJECTS']   

   

  
  
  

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

cvs commit: gump gumpy.py

[ajack]

ajack   2004/03/01 13:49:30

  Modified:.gumpy.py
  Log:
  I hate that Gumpy resolves workspaces relative to ../ 'cos it runs under ./python
  
  Revision  ChangesPath
  1.6   +1 -1  gump/gumpy.py
  
  Index: gumpy.py
  ===
  RCS file: /home/cvs/gump/gumpy.py,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- gumpy.py  1 Mar 2004 21:46:52 -   1.5
  +++ gumpy.py  1 Mar 2004 21:49:30 -   1.6
  @@ -212,7 +212,7 @@
   if os.environ.has_key('GUMP_WORKSPACE'):

   workspaceName = os.environ['GUMP_WORKSPACE'] + '.xml'

   

  -workspacePath = os.path.abspath(os.path.join('python',workspaceName))

  +workspacePath = os.path.abspath(workspaceName)

   

   projectsExpr='*'

   if os.environ.has_key('GUMP_PROJECTS'):

  
  
  

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

cvs commit: gump gumpy.py

[ajack]

ajack   2004/03/01 13:46:52

  Modified:.gumpy.py
  Log:
  Trying to get this working in a real Gump...
  
  Revision  ChangesPath
  1.5   +9 -6  gump/gumpy.py
  
  Index: gumpy.py
  ===
  RCS file: /home/cvs/gump/gumpy.py,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- gumpy.py  1 Mar 2004 21:35:31 -   1.4
  +++ gumpy.py  1 Mar 2004 21:46:52 -   1.5
  @@ -118,9 +118,9 @@
   #

   # The return code (from system = from wait) is (on Unix):

   #

  -#a 16 bit number

  -#top byte=   exit status

  -#low byte=   signal that killed it

  +#a 16 bit number

  +#top byte=exit status

  +#low byte=signal that killed it

   #

   exit_code=(((waitcode & 0xFF00) >> 8) & 0xFF)

   

  @@ -265,9 +265,12 @@
   

   #

   # Update Gump from CVS

  -#

  +#

   cvsExit = 0

   if not os.environ.has_key('GUMP_NO_CVS_UPDATE'):

  +cvsroot=':pserver:[EMAIL PROTECTED]:/home/cvspublic'

  +os.environ['CVSROOT']=cvsroot

  +# :TODO: ??? delete os.environ['CVS_RSH']

   cvsExit = runCommand('cvs -q update -dP')

   else:

   log.write('CVS update skipped per environment setting.\n')

  @@ -289,7 +292,7 @@
   if args: args += ' '

   args += arg

   

  -iargs = '-w ' + workspaceName + ' ' + projectsExpr + args

  +iargs = '-w ../' + workspaceName + ' ' + projectsExpr + args

 

   #

   # Run the main Gump...

  @@ -331,4 +334,4 @@
   sendEmail(mailto,mailfrom,logTitle,logData,mailserver,mailport)

   

   # bye!

  -sys.exit(result)
  \ No newline at end of file
  +sys.exit(result)

  
  
  

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

cvs commit: gump gumpy.py

[ajack]

ajack   2004/03/01 13:35:31

  Modified:.gumpy.py
  Log:
  Send url to log, don't send whole log...
  
  Revision  ChangesPath
  1.4   +12 -8 gump/gumpy.py
  
  Index: gumpy.py
  ===
  RCS file: /home/cvs/gump/gumpy.py,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- gumpy.py  25 Feb 2004 00:00:03 -  1.3
  +++ gumpy.py  1 Mar 2004 21:35:31 -   1.4
  @@ -234,7 +234,8 @@
   mailserver=wsw.getAttribute('mailserver')

   mailport=wsw.getAttribute('mailport') or 25

   mailto=wsw.getAttribute('mailinglist')

  -mailfrom=wsw.getAttribute('email')

  +mailfrom=wsw.getAttribute('email') 

  +logurl=wsw.getAttribute('logurl')

   # Extract the mail server/address

   ws.unlink()

   

  @@ -248,6 +249,8 @@
   log.write('- GUMP mail from  : ' + mailfrom + '\n')

   if mailto:

   log.write('- GUMP mail to: ' + mailto + '\n')

  +if logurl:

  +log.write('- GUMP log is @   : ' + logurl + '\n')

   

   #

   # Add Gump to Python Path...

  @@ -314,16 +317,17 @@
   # Cat log if failed...

   catFile(sys.stdout, logFile, logTitle)

   

  -if mailserver and mailport and mailto and mailfrom:

  +if mailserver and mailport and mailto and mailfrom and logurl:

   # :TODO: Sucky to read file into memory...

   # Need to figure out attachments, if that

   # helps & doesn't just do same...

  -tmpStream=StringIO.StringIO() 

  -catFile(tmpStream, logFile, logTitle)

  -tmpStream.seek(0)

  -logData=tmpStream.read()

  -tmpStream.close()

  -tmpStream=None

  +#tmpStream=StringIO.StringIO() 

  +#catFile(tmpStream, logFile, logTitle)

  +#tmpStream.seek(0)

  +#logData=tmpStream.read()

  +#tmpStream.close()

  +#tmpStream=None

  +logData='There is a problem with the run at : ' + logurl

   sendEmail(mailto,mailfrom,logTitle,logData,mailserver,mailport)

   

   # bye!

  
  
  

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

cvs commit: gump/python/gump engine.py

[ajack]

ajack   2004/03/01 13:28:00

  Modified:python/gump/results resulter.py
   python/gump/document forrest.py
   python/gump/test/resources/full1 profile.xml
   python/gump engine.py
  Added:   python/gump/test/resources/full1 server2.xml
  Log:
  Working out the result bugs.
  
  Revision  ChangesPath
  1.7   +2 -4  gump/python/gump/results/resulter.py
  
  Index: resulter.py
  ===
  RCS file: /home/cvs/gump/python/gump/results/resulter.py,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- resulter.py   1 Mar 2004 20:47:02 -   1.6
  +++ resulter.py   1 Mar 2004 21:28:00 -   1.7
  @@ -149,8 +149,7 @@
   #

   moduleResults = self.getResultsForAllServers(module)

   

  -if moduleResults:

  -module.setServerResults(moduleResults)

  +module.setServerResults(moduleResults)

   

   # Add projects

   for project in module.getProjects():

  @@ -161,8 +160,7 @@
   #

   projectResults = self.getResultsForAllServers(project)

   

  -if projectResults:

  -project.setServerResults(projectResults)

  +project.setServerResults(projectResults)

   

   def generateResults(self,where=None):

   """ Generate a results file """

  
  
  
  1.88  +4 -4  gump/python/gump/document/forrest.py
  
  Index: forrest.py
  ===
  RCS file: /home/cvs/gump/python/gump/document/forrest.py,v
  retrieving revision 1.87
  retrieving revision 1.88
  diff -u -r1.87 -r1.88
  --- forrest.py1 Mar 2004 18:58:00 -   1.87
  +++ forrest.py1 Mar 2004 21:28:00 -   1.88
  @@ -1389,7 +1389,7 @@
   serverRow=serversTable.createRow()
   
   serverResults=None
  -if isinstance(linkable,Resultable):
  +if isinstance(linkable,Resultable) and linkable.hasServerResults():
   serverResults=linkable.getServerResults()
   
   for server in servers: 
  
  
  
  1.9   +2 -1  gump/python/gump/test/resources/full1/profile.xml
  
  Index: profile.xml
  ===
  RCS file: /home/cvs/gump/python/gump/test/resources/full1/profile.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- profile.xml   24 Feb 2004 19:32:28 -  1.8
  +++ profile.xml   1 Mar 2004 21:28:00 -   1.9
  @@ -16,7 +16,8 @@
 
 
   
  -  
  +
  +  
 
 
 
  
  
  
  1.1  gump/python/gump/test/resources/full1/server2.xml
  
  Index: server2.xml
  ===
  
  
  
Server 2
http://gump.apache.org
  
  
  
  
  1.68  +1 -2  gump/python/gump/engine.py
  
  Index: engine.py
  ===
  RCS file: /home/cvs/gump/python/gump/engine.py,v
  retrieving revision 1.67
  retrieving revision 1.68
  diff -u -r1.67 -r1.68
  --- engine.py 1 Mar 2004 20:09:52 -   1.67
  +++ engine.py 1 Mar 2004 21:28:00 -   1.68
  @@ -146,8 +146,7 @@
   #
   logResourceUtilization('Before generate results')
   gatherResults(run)
  -
  -  
  +  
   # Update Statistics/Results on full runs
   if run.getGumpSet().isFull():
   
  
  
  

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

cvs commit: gump/blog/SuccessStories blojsom.properties

[nickchalko]

nickchalko2004/03/01 13:17:02

  Modified:blog/SuccessStories blojsom.properties
  Log:
  Added License.  do we need this on all files in the blog ?

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.2   +12 -1 gump/blog/SuccessStories/blojsom.properties
  
  Index: blojsom.properties
  ===
  RCS file: /home/cvs/gump/blog/SuccessStories/blojsom.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- blojsom.properties1 Mar 2004 21:11:14 -   1.1
  +++ blojsom.properties1 Mar 2004 21:17:02 -   1.2
  @@ -1,3 +1,14 @@
  -
  +# Copyright 2004 The Apache Software Foundation
  +# Licensed under the Apache License, Version 2.0 (the "License");
  +# you may not use this file except in compliance with the License.
  +# You may obtain a copy of the License at
  +# 
  +# http://www.apache.org/licenses/LICENSE-2.0
  +# 
  +# Unless required by applicable law or agreed to in writing, software
  +# distributed under the License is distributed on an "AS IS" BASIS,
  +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  +# See the License for the specific language governing permissions and
  +# limitations under the License.
   blojsom.name=Success Stories
   blojsom.description=Problems and Conflicts found early and fixed becuase of Gump
  
  
  

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

Re: jakarta-gump -> gump

[Adam R. B. Jack]

> The thing about the way LSD is installed, is that the gump install
directory
> (which [as of this moment] contains a work directory with stats.db a DBM
> file in it) is within the log. As such, if the name of this install
matches
> the module name, it actually (twice) checks out itself over itself, but
then
> 'cleans' via an rsync. That kills the stats database...

Sorry, I wrote 'log' -- I ought have said workspace base directory - i.e.
where Gump puts the modules (via rsync) in order to work on them.

regards

Adam


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

Re: jakarta-gump -> gump

[Adam R. B. Jack]

> > /data3/gump/jakarta-gump
>
> Please don't bother, I am working in there at this mo, just checking out
> from CVS from scratch & copying the config in. I'll write details when I
get
> time.

The thing about the way LSD is installed, is that the gump install directory
(which [as of this moment] contains a work directory with stats.db a DBM
file in it) is within the log. As such, if the name of this install matches
the module name, it actually (twice) checks out itself over itself, but then
'cleans' via an rsync. That kills the stats database...

Long ago I separated 'jakarta-gump' (module) from 'gump' (install) so we had
two, one 'safe', but the TLP status caught up with me.

We need to move any stuff out of the work area (under the install) and have
it associated with the workspace somehow. I'll add it to JIRA some time
[along with the other bazillion I have in my head.]

regards,

Adam


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

cvs commit: gump/blog/SuccessStories blojsom.properties

[nickchalko]

nickchalko2004/03/01 13:11:14

  Added:   blog/SuccessStories blojsom.properties
  Log:
  More decriptive information for the the Success Stories category.

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.1  gump/blog/SuccessStories/blojsom.properties
  
  Index: blojsom.properties
  ===
  
  blojsom.name=Success Stories
  blojsom.description=Problems and Conflicts found early and fixed becuase of Gump
  
  

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

Re: cvs commit: gump/blog/Issues TakingControlOfModule.txt

[Nick Chalko]

 view at 
 http://gump.chalko.com/gb/blog/Issues?permalink=TakingControlOfModule.txt&preview=true
 
 

Note my cron updates the blog at 0,15,30,45  every hour.  this won't be 
visible even in preview mode until 1:15 PST

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

cvs commit: gump/blog/Issues TakingControlOfModule.txt

[nickchalko]

nickchalko2004/03/01 13:04:43

  Added:   blog/Issues TakingControlOfModule.txt
  Log:
  Preparing comments about Avalon and module.xml

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.1  gump/blog/Issues/TakingControlOfModule.txt
  
  Index: TakingControlOfModule.txt
  ===
  PREVIEW Communtiy Control of Project Metadata
  Please expand and edit 
  view at 
  
http://gump.chalko.com/gb/blog/Issues?permalink=TakingControlOfModule.txt&preview=true
  
  
  Recently the Avalon build on gump has been failing because of a missconfigured 
module.xml
  Avalon keeps it module.xml in it's cvs at ??
  
  Avalon has not been responsive to making changes to this 
  file but many other project in gump relay on it so we considered taking 
  moving it's module.xml to the gump cvs.
  In general gump preferrs module.xml to be kept in it's cvs where all of apache 
can 
  keep it uptodate and running.  However we defer to what ever a project wants as 
  long as the greater community is served.   For gump that means, succesfull builds. 
  
  
  [So what did we do ?]
  
  
  
  

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

cvs commit: gump/blog/News TLP.txt

[nickchalko]

nickchalko2004/03/01 13:03:55

  Modified:blog/News TLP.txt
  Log:
  Fixed links.

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.3   +2 -2  gump/blog/News/TLP.txt
  
  Index: TLP.txt
  ===
  RCS file: /home/cvs/gump/blog/News/TLP.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- TLP.txt   1 Mar 2004 19:51:00 -   1.2
  +++ TLP.txt   1 Mar 2004 21:03:55 -   1.3
  @@ -8,9 +8,9 @@
   We will release when the gump website is ready.
   
   
  -http://gump.apache.org
  +http://gump.apache.org";>http://gump.apache.org
   
  -The Board voted ...
  +On [date] The Board voted ...
   
   
   Quote the board and link
  
  
  

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

cvs commit: gump/blog/Issues - New directory

[nickchalko]

nickchalko2004/03/01 13:03:40

  gump/blog/Issues - New directory

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

cvs commit mails was: Gump project infrastructure needs

[Nick Chalko]

Nick Chalko wrote:


commit mails are still going to [EMAIL PROTECTED]

If we want them to go to [EMAIL PROTECTED]  I will as 
infrastructure to fix it.



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

cvs commit: gump/python/gump/results resulter.py

[ajack]

ajack   2004/03/01 12:47:02

  Modified:python/gump/results resulter.py
  Log:
  Typo
  
  Revision  ChangesPath
  1.6   +1 -1  gump/python/gump/results/resulter.py
  
  Index: resulter.py
  ===
  RCS file: /home/cvs/gump/python/gump/results/resulter.py,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- resulter.py   1 Mar 2004 18:58:00 -   1.5
  +++ resulter.py   1 Mar 2004 20:47:02 -   1.6
  @@ -93,7 +93,7 @@
   results = {}

   

   # Loda on demand

  -if not self.seerversLoaded:

  +if not self.serversLoaded:

   self.loadResultsForServers()

   

   # For all servers, extract any result

  
  
  

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

cvs commit: gump/python/gump engine.py

[ajack]

ajack   2004/03/01 12:09:52

  Modified:python/gump engine.py
  Log:
  Apparently even when I test locally I miss bugs thing, like importing a function to 
call. Don't ask me how...
  
  Revision  ChangesPath
  1.67  +1 -1  gump/python/gump/engine.py
  
  Index: engine.py
  ===
  RCS file: /home/cvs/gump/python/gump/engine.py,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- engine.py 1 Mar 2004 18:58:01 -   1.66
  +++ engine.py 1 Mar 2004 20:09:52 -   1.67
  @@ -32,7 +32,7 @@
   from gump.output.statsdb import *
   from gump.output.repository import JarRepository
   from gump.output.nag import nag
  -from gump.results.resulter import generateResults
  +from gump.results.resulter import gatherResults,generateResults
   from gump.syndication.syndicator import syndicate
   
   
  
  
  

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

Re: [GUMP@lsd]: avalon/avalon failed

[Adam R. B. Jack]

Antoine responded:

> >This much I figured. But the site docs have a large gap between "purpose"
and
> >"details".
>
> I agree, I had to hack my way also to figure out where is the gump
> descriptor for avalon.
>  (used find . -name "*.xml" | xargs grep avalon)
>

Could you enter this as an enhancement request into JIRA? I (about a month
ago) tried having this information listed in xref, and also on each
project/module, but even though it is in there (see the href attribute)

http://lsd.student.utwente.nl/gump/avalon/index_details.html#Definition

I somehow failed:

http://build.try.sybase.com/eclipse-gump/gump_xref/descriptor_project.html


regards,

Adam


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

cvs commit: gump/blog/News TLP.txt

[nickchalko]

nickchalko2004/03/01 11:51:00

  Modified:blog/News TLP.txt
  Log:
  We will release when the gump website is ready.

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.2   +2 -0  gump/blog/News/TLP.txt
  
  Index: TLP.txt
  ===
  RCS file: /home/cvs/gump/blog/News/TLP.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TLP.txt   1 Mar 2004 19:49:23 -   1.1
  +++ TLP.txt   1 Mar 2004 19:51:00 -   1.2
  @@ -4,6 +4,8 @@
   Please expand and edit 
   view at 
   http://gump.chalko.com/gb/blog/News?permalink=TLP.txt&preview=true
  +
  +We will release when the gump website is ready.
   
   
   http://gump.apache.org
  
  
  

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

cvs commit: gump/blog TLP.txt

[nickchalko]

nickchalko2004/03/01 11:49:23

  Added:   blog/News TLP.txt
  Removed: blog TLP.txt
  Log:
  Moved the TLP announcement.

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.1  gump/blog/News/TLP.txt
  
  Index: TLP.txt
  ===
  PREVIEW Gump is now an Apache Top Level Project
  
  Preparing the blog annoucnement of Gump as a TLP
  Please expand and edit 
  view at 
  http://gump.chalko.com/gb/blog/News?permalink=TLP.txt&preview=true
  
  
  http://gump.apache.org
  
  The Board voted ...
  
  
  Quote the board and link
  
  
  
  

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

cvs commit: gump/blog/News - New directory

[nickchalko]

nickchalko2004/03/01 11:48:34

  gump/blog/News - New directory

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

cvs commit: gump/blog TLP.txt

[nickchalko]

nickchalko2004/03/01 11:44:38

  Added:   blog TLP.txt
  Log:
  Starting the Gump TLP announcemnt entry.

  

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.1  gump/blog/TLP.txt
  
  Index: TLP.txt
  ===
  PREVIEW Gump is now an Apache Top Level Project
  
  Preparing the blog annoucnement of Gump as a TLP
  Please expand and edit
  view at 
  http://gump.chalko.com/gb/blog/?permalink=TLP.txt&preview=true
  
  http://gump.apache.org
  
  The Board voted ...
  Quote the board and link
  
  
  
  

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

cvs commit: gump/blog TestPost.txt

[nickchalko]

nickchalko2004/03/01 11:36:05

  Added:   blog TestPost.txt
  Log:
  Test post is back.

  PREVIEW is now working

  you can fiew this post at 

  http://gump.chalko.com/gb/blog/?permalink=TestPost.txt&preview=true

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.4   +0 -0  gump/blog/TestPost.txt
  
  
  
  

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

Posted by was cvs commit: gump/blog/SuccessStories velocity-jdom.txt

[Nick Chalko]

To get "posted by" credit's in the peas and carrots blog add

meta-blog-entry-author=My Name

to the entry file.

R,
Nick
 Index: velocity-jdom.txt
 ===
 RCS file: /home/cvs/gump/blog/SuccessStories/velocity-jdom.txt,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -u -r1.1 -r1.2
 --- velocity-jdom.txt	19 Feb 2004 23:41:01 -	1.1
 +++ velocity-jdom.txt	1 Mar 2004 19:20:54 -	1.2
 @@ -1,4 +1,5 @@
  Velocity adapts Anakia to changes in JDOM
 +meta-blog-entry-author=antoine
  
  On the 18th of February, Stefan Bodewig wrote :
  
 



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

cvs commit: gump/blog/SuccessStories velocity-jdom.txt

[nickchalko]

nickchalko2004/03/01 11:20:54

  Modified:blog/SuccessStories velocity-jdom.txt
  Log:
  Added enty author line

  PR:

  Obtained from:

  Submitted by: 

  Reviewed by:  

  CVS: --

  CVS: PR:

  CVS:   If this change addresses a PR in the problem report tracking

  CVS:   database, then enter the PR number(s) here.

  CVS: Obtained from:

  CVS:   If this change has been taken from another system, such as NCSA,

  CVS:   then name the system in this line, otherwise delete it.

  CVS: Submitted by:

  CVS:   If this code has been contributed to Apache by someone else; i.e.,

  CVS:   they sent us a patch or a new module, then include their name/email

  CVS:   address here. If this is your work then delete this line.

  CVS: Reviewed by:

  CVS:   If we are doing pre-commit code reviews and someone else has

  CVS:   reviewed your changes, include their name(s) here.

  CVS:   If you have not had it reviewed then delete this line.

  
  Revision  ChangesPath
  1.2   +1 -0  gump/blog/SuccessStories/velocity-jdom.txt
  
  Index: velocity-jdom.txt
  ===
  RCS file: /home/cvs/gump/blog/SuccessStories/velocity-jdom.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- velocity-jdom.txt 19 Feb 2004 23:41:01 -  1.1
  +++ velocity-jdom.txt 1 Mar 2004 19:20:54 -   1.2
  @@ -1,4 +1,5 @@
   Velocity adapts Anakia to changes in JDOM
  +meta-blog-entry-author=antoine
   
   On the 18th of February, Stefan Bodewig wrote :
   
  
  
  

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

Re: Gump project infrastructure needs

[Nick Chalko]

Stefan Bodewig wrote:

Dear Infrastructure folks,

Source Control
==


commit mails should go to [EMAIL PROTECTED] for now.

 

commit mails are still going to [EMAIL PROTECTED] 

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

cvs commit: gump/python/gump engine.py

[ajack]

ajack   2004/03/01 10:58:01

  Modified:python/gump/model project.py state.py module.py property.py
workspace.py object.py
   python/gump/document forrest.py
   python/gump/results resulter.py model.py
   python/gump/utils tools.py
   profile  gump.xml
   python/gump engine.py
  Log:
  1) Tinkering w/ adding a Tracker [one day will link to]

  2) Results ...

  2.1) Gathering results from other servers [downloading/parsing results.xml]

  2.2) Generating results.xml for this server

  3) Making 'catDirectoryToFileHolder' do a directory listing also, for debugging.

  
  Revision  ChangesPath
  1.58  +8 -4  gump/python/gump/model/project.py
  
  Index: project.py
  ===
  RCS file: /home/cvs/gump/python/gump/model/project.py,v
  retrieving revision 1.57
  retrieving revision 1.58
  diff -u -r1.57 -r1.58
  --- project.py29 Feb 2004 19:16:19 -  1.57
  +++ project.py1 Mar 2004 18:58:00 -   1.58
  @@ -66,6 +66,7 @@
   
   from gump.model.state import *
   from gump.model.object import ModelObject, NamedModelObject, Jar,\
  +Resultable, \
Mkdir, Delete, JunitReport, Work
   from gump.model.stats import Statable, Statistics
   from gump.model.property import Property
  @@ -178,10 +179,13 @@
   return os.pathsep.join(self.getSimpleClasspathList())
   
   
  -class Project(NamedModelObject, Statable):
  +class Project(NamedModelObject, Statable, Resultable):
   """A single project"""
   def __init__(self,xml,workspace):
NamedModelObject.__init__(self,xml.getName(),xml,workspace)
  + 
  + Statable.__init__(self)
  + Resultable.__init__(self)

# Navigation
   self.module=None # Module has to claim ownership
  
  
  
  1.12  +24 -3 gump/python/gump/model/state.py
  
  Index: state.py
  ===
  RCS file: /home/cvs/gump/python/gump/model/state.py,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- state.py  17 Feb 2004 21:54:20 -  1.11
  +++ state.py  1 Mar 2004 18:58:00 -   1.12
  @@ -148,6 +148,19 @@
   REASON_BUILD_TIMEDOUT : "BuildTimedOut",
   REASON_MISSING_OUTPUTS : "MissingBuildOutputs" }
   
  +namedReasonCode = { "NotSet" : REASON_UNSET,
  +"CompletePackageInstall" : REASON_PACKAGE,
  +"BadPackageInstallation" : REASON_PACKAGE_BAD,
  +"CircularDependency" : REASON_CIRCULAR,
  +"ConfigurationFailed" : REASON_CONFIG_FAILED,
  +"UpdateFailed" : REASON_UPDATE_FAILED,
  +"SynchronizeFailed" : REASON_SYNC_FAILED,
  +"Pre-BuildFailed" : REASON_PREBUILD_FAILED,
  +"BuildFailed" : REASON_BUILD_FAILED,
  +"Post-BuildFailed" : REASON_POSTBUILD_FAILED,
  +"BuildTimedOut" : REASON_BUILD_TIMEDOUT,
  +"MissingBuildOutputs" : REASON_MISSING_OUTPUTS }
  +
   reasonCodeDescriptions = {   REASON_UNSET : "Not Set",
   REASON_PACKAGE : "Complete Package Install",
   REASON_PACKAGE_BAD : "Bad Package Installation",
  @@ -166,6 +179,14 @@
   
   def reasonDescription(reasonCode):
   return reasonCodeDescriptions.get(reasonCode,'Unknown Reason:' + 
str(reasonCode))
  +
  +def reasonForName(name):
  +return namedReasonCode.get(name,STATE_UNSET)
  +
  +def getStatePairFromNames(stateName,reasonName):
  +state=stateForName(stateName)
  +reason=reasonForName(reasonName)
  +return StatePair(state,reason)
 
   class StatePair:
   """Contains a State Plus Reason"""
  
  
  
  1.34  +8 -5  gump/python/gump/model/module.py
  
  Index: module.py
  ===
  RCS file: /home/cvs/gump/python/gump/model/module.py,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- module.py 23 Feb 2004 20:55:08 -  1.33
  +++ module.py 1 Mar 2004 18:58:00 -   1.34
  @@ -67,7 +67,7 @@
   from gump.model.state import *
   from gump.model.stats import Statable, Statistics
   from gump.model.project import *
  -from gump.model.object import NamedModelObject
  +from gump.model.object import NamedModelObject, Resultable
   from gump.utils import getIndent
   from gump.utils.note import transferAnnotations, Annotatable
   
  @@ -192,11 +192,14 @@
   unnamedModule.complete(workspace)
   return unnamedModule
   
  -class Module(NamedModelObject, Statable):
  +class Module(NamedModelObject, St

jbs (Jicarilla Build System?) and includes...

[Adam R. B. Jack]

BTW:


http://lsd.student.utwente.nl/gump/jicarilla-sandbox/jicarilla-collections.html#Build+%3A+build_jicarilla-sandbox_jicarilla-collections

Are we goign to be able to make these includes portable to Gump?

regards

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


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

Re: Gump Database

[Stefano Mazzocchi]

Adam R. B. Jack wrote:

Stefano Mazzocchi wrote:

For this specific problem, I would go relational.
+1. Brain-dead and ugly solution like mysql ;)


When I think about the answers I've received [and thanks for them] I wonder
if folks are thinking more about the ugly/brain dead type problem of results
tracking. I agree, that is fine to do relationally. [That is where this
thread originated, so perhaps I unintentionally led the response.]
BTW: First, let me state for the record, I'm no fan of XML for XML's sake &
don't wish to try to push it where it isn't useful. Also, everybody ought
use relational databases (specifically those wonderful ones from Sybase,
which also happens to have some awesome XML/XQL features, and allows joining
XML and relational data.) Ok, my corporate pitch ;-) ;-) ;-) over...
I realize I was more interested in the XML metadata, and it's changes over
time. The results are why folks invest in granting us/maintaining their
project metadata. The metadata is a map (a graph) of the community, and some
interactions [some, needs to be extended for more], and I was hoping some
form of XML repository could somehow give us a time factor on that.
I might be looking for more than is there, I might be looking for too low
level an assist, but I'd like to know if folks who used to depend upon X no
longer do [change in one XML], and when most migrated away [multiple]. I'd
like to know if a product was a 'huge hit' [multiple], and who was migrating
to it [multiple]. I'd like to see which communities/groups (lamely, for this
mail, based off  repository) were using something. I'd like to know details
like this over time.
I could push this graph into a relational schema but I feel that would be
very restrictive, and would pre-determine the benefits. I guess I can take
deltas, or store historical copies of the whole metadata, but I feel I need
some tool that is into analysing XML over time. Maybe I do need XINDICE, or
something like it.
Again, feel free to correct me -- and/or express your gut feelings against,
but my gut tells me I have a storage problem but I don't know the right
tools for the store, or the query mechanisms.
Adam,

I think you are looking at the problem from the wrong angle: the use of 
the data.

While the question that you should be asking yourself is: what does the 
data look like? how stuctured is it?

From where I stand, the gump metadata is highly structured and can be 
perfectly mapped in to a relational structure with reasonable effort. 
Also, given its structure, can be indexed precisely and thus queried 
very efficiently.

At that point, once you have the data in the database, you can start 
thinking about what to do with it. Dependency graph visualization, 
history of dependencies, FoG estimation, all of these are problems that 
will result in particular queries and particular use of the result set.

Gump data does not exhibit any of the properties that appear in the 
semi-structured of highly connected pseudo-digraph problem space.

For this reason, I see absolutely no reason to avoid using relational 
solutions. Also because they are, by far, much more solid and easy to 
interoperate with than any other DBMS model.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Hmm, not listing reports?

[Adam R. B. Jack]

I suspect something in my change to pure Python for file listing/contents is
causing these not to show. I'll investigate...


http://lsd.student.utwente.nl/gump/jicarilla-sandbox/jicarilla-collections.html#Annotations

regards,

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


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

Re: [VOTE] Add Antoine Levy-Lambert to the gump Unix group

[Adam R. B. Jack]

> Stefan Bodewig wrote:
> 
> >Antoine has expressed interest in helping to maintain the website and
> >I wouldn't want to stop him. 8-)
> >
> >+1 from me.
> >  
> +1 many hands make for quick work.

-- when they are good hands. ;-)

+1 

regards

Adam

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

Re: [VOTE] Add Antoine Levy-Lambert to the gump Unix group

[Scott Sanders]

+1

On Mar 1, 2004, at 1:08 AM, Stefan Bodewig wrote:

Antoine has expressed interest in helping to maintain the website and
I wouldn't want to stop him. 8-)
+1 from me.

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 TLP Site

[Adam R. B. Jack]

> Is this an expected failure?  Ought I use a more recent version of
> Forrest?

Having Nicola on our team we benefit from a lot of the nice extras (like
cool SVGs) but it often demands we have CVS HEAD of forrest. Please try CVS
HEAD.

regards

Adam


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

Re: [VOTE] Add Antoine Levy-Lambert to the gump Unix group

[Nick Chalko]

Stefan Bodewig wrote:

Antoine has expressed interest in helping to maintain the website and
I wouldn't want to stop him. 8-)
+1 from me.
 

+1 many hands make for quick work.

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

Re: Gump TLP Site

[Stefan Bodewig]

On Mon, 1 Mar 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:

> Anybody interested in helping out w/ the Gump site?

Sure.

I just installed Forrest 0.5.1 and get an error:

X [0]   images/gump-logo.pngBROKEN: 
/home/bodewig/ASF/gump/gump/build/tmp/context/resources/images/gump-logo.png (No such 
file or directory)

which I assume is responsible for 

BUILD FAILED
/home/bodewig/apache-forrest-0.5.1-bin/forrest.build.xml:631: Java returned: 1

as there is no other error message.

Is this an expected failure?  Ought I use a more recent version of
Forrest?

Stefan

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

Re: Gump Sync

[Adam R. B. Jack]

> I just now looked into my build.sh again and we don't use -C.  Now you
> have me extra puzzled, since it behaves exactly as if the switch was
> enabled (and I don't think -a includes -C).

I should have said that didn't quite register (but didn't 'cos I didn't have
time to check). I didn't think Gumpy set that. Still, I've seen rsync just
not clean up directories that it ought, a long ways back (and can't recall
details). I just don't trust it.

 > Sync deletes the previous build results, so I think it's less likely
> to be hit by disk space issues than the actual build process.

Yeah, good point -- I was wrong. It was creating xdocs (for a new project)
that dorked when LSD became full.

regards

Adam


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

Re: Gump Database

[Adam R. B. Jack]

> Stefano Mazzocchi wrote:
> > For this specific problem, I would go relational.
>
> +1. Brain-dead and ugly solution like mysql ;)

When I think about the answers I've received [and thanks for them] I wonder
if folks are thinking more about the ugly/brain dead type problem of results
tracking. I agree, that is fine to do relationally. [That is where this
thread originated, so perhaps I unintentionally led the response.]

BTW: First, let me state for the record, I'm no fan of XML for XML's sake &
don't wish to try to push it where it isn't useful. Also, everybody ought
use relational databases (specifically those wonderful ones from Sybase,
which also happens to have some awesome XML/XQL features, and allows joining
XML and relational data.) Ok, my corporate pitch ;-) ;-) ;-) over...

I realize I was more interested in the XML metadata, and it's changes over
time. The results are why folks invest in granting us/maintaining their
project metadata. The metadata is a map (a graph) of the community, and some
interactions [some, needs to be extended for more], and I was hoping some
form of XML repository could somehow give us a time factor on that.

I might be looking for more than is there, I might be looking for too low
level an assist, but I'd like to know if folks who used to depend upon X no
longer do [change in one XML], and when most migrated away [multiple]. I'd
like to know if a product was a 'huge hit' [multiple], and who was migrating
to it [multiple]. I'd like to see which communities/groups (lamely, for this
mail, based off  repository) were using something. I'd like to know details
like this over time.

I could push this graph into a relational schema but I feel that would be
very restrictive, and would pre-determine the benefits. I guess I can take
deltas, or store historical copies of the whole metadata, but I feel I need
some tool that is into analysing XML over time. Maybe I do need XINDICE, or
something like it.

Again, feel free to correct me -- and/or express your gut feelings against,
but my gut tells me I have a storage problem but I don't know the right
tools for the store, or the query mechanisms.

regards,

Adam


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

Re: Gump Sync

[Stefan Bodewig]

On Mon, 1 Mar 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:

> I do think we need our own rsync, but it is good to know of gotcha
> like this prior to writing it.

Quite possible.  In particular we don't need rsync but just sync.

> Do we need/want the .cvsignore functionality?

I don't really think so.

I just now looked into my build.sh again and we don't use -C.  Now you
have me extra puzzled, since it behaves exactly as if the switch was
enabled (and I don't think -a includes -C).

Anyway, we should use a complete sync without any excludes IMHO.

> I suspect we wish to migrate a directory based off existence and
> timestamp, but not contents (we ought rely upon timestamps, no?).

This will probably be good enough for us.

> What to do in case of failure? Just bail at time of issue, or ought
> we attempt to unwind our changes [not likely].

For our purpose a failure isn't as dramatic as for say mirrors.
Making big noise is warranted, but the orginal contents are still
there, so I wouldn't invest too much time into rollback support.

> Sync is likely to get hit with disk full, since many of the other
> aspects of Gump are change in place.

Sync deletes the previous build results, so I think it's less likely
to be hit by disk space issues than the actual build process.

> Ought we keep a track of all we do, so we can report upon that for
> users?  [We capture output of CVS/SVN which ought be the same, but
> it might be nice for us to do similarly.]

Some kind of human readable lock would be nice.

> Ought we design this via the Wiki?

Why not?

Stefan

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

Re: Gump TLP Site

[Adam R. B. Jack]

> Yes, sure.  All when we are ready.  Are we?

Nope. Ought we give it at least a week? No point in hurrying our coming out.
;-) We might wish to update the content/front page to better represent where
we wish to take Gump as a TLP. We might wish to add a reference to a logo
competition.

> Take a look at  and
>  for very simple pages that we can
> use.  Do we want something more fancy?

I did :-) I realized the Ant community had done this recently, so I figured
we'd just stand on their shoulders.

Anybody interested in helping out w/ the Gump site? The xdoc format is very
simple, the message and the content is harder.

regards,

Adam


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

Gump Sync: was (Re: Avalon build (was Re: last night build on lsd))

[Adam R. B. Jack]

> avalon/target is in .cvsignore and since we use rsync's -C switch
> doesn't ever get cleaned out when doing an rsync.

First, Stefan, thanks for being so dogged w/ this problem, I doubt many
could've look into as hard as it needed.

I do think we need our own rsync, but it is good to know of gotcha like this
prior to writing it.
Let's try to specify the functionality before too much code gets laid down,
or thinking gets thunk...

Do we need/want the .cvsignore functionality? Do we need/want similar for
SVN? Do we need a .gumpignore?

I suspect we wish to migrate a directory based off existence and timestamp,
but not contents (we ought rely upon timestamps, no?). I suspect we don't
have to care about anything fancy, as Antoine stated, such as moving between
volumes or following symbolic links.

What to do in case of failure? Just bail at time of issue, or ought we
attempt to unwind our changes [not likely]. We need to ensure that this
automated environment isn't left in a state that a human has to clean up, at
least -- unless we know it. Sync is likely to get hit with disk full, since
many of the other aspects of Gump are change in place. Sync is likely to get
hit with permission problems, and so forth. Error handling is a key aspect.

Ought we keep a track of all we do, so we can report upon that for users?
[We capture output of CVS/SVN which ought be the same, but it might be nice
for us to do similarly.]

I know this is at the same time a simple piece of functionality, but a
critical one. I believe experience has shown that the nastiest problems in
Gump are when the data gets out of sync with CVS/SVN, and we trusted it to
be in sync. Also, since we work in the target area, we really rely upon sync
to clean up each time. That is a heavy burden.

Ought we design this via the Wiki?

regards,

Adam


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

Re: Avalon build

[Stefan Bodewig]

On Mon, 1 Mar 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:

> Ought we just ask the Avalon guys if they mind us taking a copy of
> their metadata yet still sending nags to them, or just doing it? Or,
> are you ok working via patches.

If working with patches finally leads to Avaoln getting built in Gump
and the Avalon community being involved in Gump, that is fine with me.
If it doesn't work, well, then we just need to tell the Avalon
community that they are part of the Gump committers.

Stefan

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

Re: Gump TLP Site

[Stefan Bodewig]

On Mon, 1 Mar 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
>> What changes in other sites would we need?
> 
> I was thinking the left side of here, but this has been done, it
> seems -- although the URL needs to be updated sometime.

Will do, once we feel the gump.apache.org is ready for prime time.
I'd also insert a little redirect to make jakarta.apache.org/gump/ go
to the TLP site.

> http://www.apache.org
> 
> Hmm, ought we be added to 'latest news'?

Not sure who decides which projects are the "featured" project.  It is
supposed to rotate on a regular schedule, but the details have escaped
me.

> I guess similar stuff needs to be done http://jakarta.apache.org
> [left bar, perhaps move us to 'related'], with (to a quick view)
> http://jakarta.apache.org/site/cvsindex.html,
> http://jakarta.apache.org/site/mail2.html,

Yes, sure.  All when we are ready.  Are we?

Take a look at  and
 for very simple pages that we can
use.  Do we want something more fancy?

Stefan

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

Re: Avalon build (was Re: last night build on lsd)

[Adam R. B. Jack]

> I'm currently iteratively working towards a correct list of
> directories needed and will provide a patch against the current
> descriptor so that it is going to work.

Ought we just ask the Avalon guys if they mind us taking a copy of their
metadata yet still sending nags to them, or just doing it? Or, are you ok
working via patches.

regards

Adam


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

Re: Gump TLP Site

[Adam R. B. Jack]

> What changes in other sites would we need?  I have karma for jakarta
> as well as www if you know of things that need to get fixed.

I was thinking the left side of here, but this has been done, it seems -- 
although the URL needs to be updated sometime.

http://www.apache.org

Hmm, ought we be added to 'latest news'?

Also, here: http://www.apache.org/foundation/mailinglists.html (once we get
a mail page).

I guess similar stuff needs to be done http://jakarta.apache.org [left bar,
perhaps move us to 'related'], with (to a quick view)
http://jakarta.apache.org/site/cvsindex.html,
http://jakarta.apache.org/site/mail2.html,

I don't know everywhere, I'm no expert on what is where, these are just a
few things that came to eye quickly. I suspect a google search over
jakarta.apache.org would find a few more.

regards,

Adam,





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

Re: last night build on lsd

[Stefan Bodewig]

On Sun, 29 Feb 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:

> 2) jakarta-slide's build is failing with an irritating message
> saying it cannot copy
> 
> /data3/gump/jakarta-slide/lib/jdom-b9.jar
> 
> http://lsd.student.utwente.nl/gump/jakarta-slide/jakarta-slide.html
> 
> the build should actually be looking for

I think the slide team simply forgot to adapt the build file when they
changed from jdom-b9 to a dated CVS snapshot.  Or they forgot to use a
property instead of a hard-coded filename 8-)



Stefan

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

Re: ICQ or MSN?

[Martin van den Bemt]

martinvandenbemt _at_ hotmail.com and icq is 74842331
Yahoo is martin_van_den_bemt _at_ yahoo.com but hardly used since the
connection is unstable :)
Using gmain..
Don't use the mail accounts associated with the accounts :)

Mvgr,
Martin

On Thu, 2004-02-12 at 18:00, Leo Simons wrote:
> Hey guys,
> 
> are any of you on ICQ or MSN?
> 
> I'm on MSN as mail _at_ leosimons.com, and ICQ as 167900667.
> 
> (replace ' _at_ ' with @ of course)



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

Re: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-12 failed

[Stefan Bodewig]

On Sun, 29 Feb 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:

> 1/ Is there a URL from where I can see the build output (i.e. the
> target-* dirs created by the build)?

pick up target-12.zip from my home directory on cvs.apache.org, it
contains target-12 from last night's build on LSD.

> 2/ Is the line:
> 
> [cactus] configurationOptionStr=null
> 
> generated by Gump? I don't recally this coming from Cactus.

org.apache.log4j.LogManager.java line 96 8-)

Stefan

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

cvs commit: gump/project gump.xml

[bodewig]

bodewig 2004/03/01 06:29:46

  Modified:project  gump.xml
  Log:
  jakarta-gump -> gump
  
  Revision  ChangesPath
  1.23  +4 -4  gump/project/gump.xml
  
  Index: gump.xml
  ===
  RCS file: /home/cvs/gump/project/gump.xml,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- gump.xml  29 Feb 2004 19:16:19 -  1.22
  +++ gump.xml  1 Mar 2004 14:29:46 -   1.23
  @@ -14,18 +14,18 @@
 See the License for the specific language governing permissions and
 limitations under the License.
   -->
  -
  +
   
  -  http://jakarta.apache.org/gump/"/>
  +  http://gump.apache.org/"/>
 
   Cross project build tool
 
   
  -  
  +  
   
 
   
  - 
  +  
   
   
   
  
  
  

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

[GUMP][PATCH] this should make avalon compile in Gump

[Stefan Bodewig]

Hi,

when I looked at the difference between the builds on LSD and those on
gump.covalent.net I was simply searching for the wrong thing, sorry.
Whether framework/target/classes exists at the start of compilation or
not is completely irrelevant as there is never anything getting
compiled to that directory anyway.

The rsync command used by "traditional" Gump doesn't remove
directories that are listed in .cvsignore and thus compiled the tests
against some old classes that have been compiled before you
restructured your build system.  LSD either uses a different rsync
command line or simply has been set up aftre you've changed your
setup.

It turns out that none of the directories listed in  entries
actually gets used.  And the ones that are really needed are missing.

The appended patch should fix the problems and enable avalon's build
inside Gump on LSD.

Cheers

Stefan

--- 
cache/http___cvs.apache.org_viewcvs.cgi__checkout__avalon_buildsystem_gump-integration_project_avalon.xml.xml
   Mon Mar  1 09:19:56 2004
+++ project/avalon.xml  Mon Mar  1 15:16:01 2004
@@ -12,8 +12,11 @@
 because we go from 1 to multiple jars. This is a copied
 descriptor. -->
 
+
+
+
+
 org.apache.avalon
-
 
 
 
@@ -26,14 +29,14 @@
 
 
 
-
-
-
-
+
+
+
+
 
 
 
-
+
 
 
 


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

Avalon build (was Re: last night build on lsd)

[Stefan Bodewig]

On Mon, 01 Mar 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Sun, 29 Feb 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
> wrote:
> 
>> 3) avalon is still failing on gumpy,
> 
> This is extremely strange.
>
> I started out by removing my avalon directory to be sure I'd get a
> clean run - and it fails when I invoke "./build.sh avalon dist".
> Maybe rsync hasn't been cleaning out the avalon working copy
> completely?

I think I'm on the right track now.

avalon/target is in .cvsignore and since we use rsync's -C switch
doesn't ever get cleaned out when doing an rsync.

Both my and gump.covalent.net's installations have the missing classes
in target/classes from an old compilation that has never been cleaned
out.

The directories in Avalon's gump descriptors are more or less all
wrong, nobody evere uses target/api-classes but the classes get
compiled to api/target/classes.  And so on ...

I'm currently iteratively working towards a correct list of
directories needed and will provide a patch against the current
descriptor so that it is going to work.

Stefan

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

Re: last night build on lsd

[Stefan Bodewig]

On Sun, 29 Feb 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:

> 3) avalon is still failing on gumpy,

This is extremely strange.

I tried to pin down what was different between "traditional" and Gumpy
here and started by modifying the build.sh script generated on my box
to look more like Gumpy's command line.  There are only minor
differences:

* "traditional" has the thnigs that will end up on the bootclasspath
  once again on CLASSPATH.

* Gumpy sets build.clonevm unconditionally.

* order of CLASSPATH elements is slightly different.

I started out by removing my avalon directory to be sure I'd get a
clean run - and it fails when I invoke "./build.sh avalon dist".
Maybe rsync hasn't been cleaning out the avalon working copy
completely?

I'll perform a -debug run and hope to get more information here.  But
then again, avalon's build is really complex as you can see when
looking at the end of the build log - eight levels of nested  or
s.

Stefan

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

Re: Failures in xml-security

[Stefan Bodewig]

On Mon, 01 Mar 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Mon, 01 Mar 2004, Berin Lautenbach <[EMAIL PROTECTED]>
> wrote:
> 
>> Could someone check if the bouncycastle JCE has been installed on
>> lsd?
> 
> Yes, version 1.1.6.  This may be too old for xml-security's needs.
> I'll look into upgrading it just now.

Hmm, we've been using bouncycastle's cleanroom JCE for 1.3, actually.

If I do so for the latest version, I get a different type of error
message 

[junit] org.apache.xml.security.encryption.XMLEncryptionException: Padding: 
ISO10126PADDING not implemented
[junit] Original Exception was javax.crypto.NoSuchPaddingException: Padding: 
ISO10126PADDING not implemented
[junit] at 
org.apache.xml.security.encryption.XMLCipher.getInstance(XMLCipher.java:285)

but it looks as if bouncycastle doesn't get used at all.

If I only use the provider jar and nothing else, I again get another
error (something about not being able to find provider "BC" or not
being able to verify it).

To me it looks as if we'd have to install things to use bouncycastle
with JDK 1.4 anyway, at least the unrestricted policy file has to be
installed.  I'd be glad if anybody with a better JCE background than I
have could help out here.

Stefan

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

Re: Gump Database

[Leo Simons]

Stefano Mazzocchi wrote:
For this specific problem, I would go relational.
+1. Brain-dead and ugly solution like mysql ;)

--
cheers,
- Leo Simons

---
Weblog  -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
---
"We started off trying to set up a small anarchist community, but
 people wouldn't obey the rules."
-- Alan Bennett


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

Re: Failures in xml-security

[Stefan Bodewig]

On Mon, 01 Mar 2004, Berin Lautenbach <[EMAIL PROTECTED]> wrote:

> Could someone check if the bouncycastle JCE has been installed on
> lsd?

Yes, version 1.1.6.  This may be too old for xml-security's needs.
I'll look into upgrading it just now.

There doesn't seem to be a clean room JCE for JDK 1.4 anymore, I check
whether it works by just adding the providers, but I doubt so.  If it
fails, I'll try 1.2.1 instead, which seems to be tha last release with
a clean room JCE.

> (BTW - Am assuming I can't do this myself?)

Since bouncycastle doesn't get built from sources but uses an
installed package, this requires an account on the machines running
Gump.

Stefan

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

Re: Gump TLP Site

[Stefan Bodewig]

On Sun, 29 Feb 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:

> 2) I know 'get involved' and 'mailing lists' will take a bit of work
> to fix, since we'll need to work with other sites also (I assume,
> i.e. to add gump as a TLP to them.)

I'd suggest to make mini "mailing-list" and "CVS module" pages of our
own and link to incubator or wherever the current plan assembles the
more general "getting involved" stuff.

What changes in other sites would we need?  I have karma for jakarta
as well as www if you know of things that need to get fixed.

Stefan

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

Failures in xml-security

[Berin Lautenbach]

Peoples,

Could someone check if the bouncycastle JCE has been installed on lsd?

The project is :

http://lsd.student.utwente.nl/gump/jce/jce.html

and it looks like it's never been in place?  I *think* this is what is 
causing xml-security to fail as it's defaulting to the Sun JCE which 
doesn't have all the algorithms we need.  (Or rather it does, but we 
don't have all the configs to use it.)

http://lsd.student.utwente.nl/gump/xml-security/gump_work/build_xml-security_xml-security.html

With thanks!

(BTW - Am assuming I can't do this myself?)

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

cvs commit: gump/project smartfrog.xml

[stevel]

stevel  2004/03/01 02:56:37

  Modified:project  smartfrog.xml
  Log:
  changing location of the license file.
  
  Revision  ChangesPath
  1.12  +1 -1  gump/project/smartfrog.xml
  
  Index: smartfrog.xml
  ===
  RCS file: /home/cvs/gump/project/smartfrog.xml,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- smartfrog.xml 27 Feb 2004 13:33:56 -  1.11
  +++ smartfrog.xml 1 Mar 2004 10:56:37 -   1.12
  @@ -43,7 +43,7 @@
   
   
   
  -
  +
   
   
  
  
  

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

[VOTE] Add Antoine Levy-Lambert to the gump Unix group

[Stefan Bodewig]

Antoine has expressed interest in helping to maintain the website and
I wouldn't want to stop him. 8-)

+1 from me.

Stefan

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

Re: [GUMP@lsd]: avalon/avalon failed

[Stefan Bodewig]

On Fri, 27 Feb 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:

> I had to hack my way also to figure out where is the gump descriptor
> for avalon.  (used find . -name "*.xml" | xargs grep avalon)

Looking into Gump's profile may have been easier:

  http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon/buildsystem/gump-integration/project/avalon.xml"/>

;-)

> Niclas Hedhman wrote:

>>Applied (not that I know why this is needed...)
> 
> Stefan Bodewig figured out that we needed this mkdir [1] [2], he
> thinks that a path containing some classes is not incorporated into
> the build classpath, because at the beginning of the build the
> directory does not exist.

Let me expand this a little.

Some JVMs drop things from the CLASSPATH that don't exist at startup
time - I think all Sun VMs after 1.3 do.  They will not be included in
java.class.path and the application has no control over it.

If the build process creates a directory and compiles classes into
this directory that are later needed in the same build, we need to
ensure that the directory exists prior to starting the JVM to prevent
this.

This doesn't seem to be necessary for all situations, for example:

* forked  and  tasks  don't need a  upfront since
  they'll see the CLASSPATH environment variable.

*  tasks that include the sources of the compiled classes in
  the sourcepath don't need it since javac will use the sources instead.

*  tasks that compile to the  directory won't need it
  since Ant adds the target directory to the classpath.

But in general each  element inside a Gump descriptor will need
a corresponding .

Stefan

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

Re: [GUMP@lsd]: avalon/avalon failed

[Stefan Bodewig]

Niclas Hedhman wrote:

> 1. Why doesn't it pick up Maven project descriptors instead, since
> to me it seems that most is available in that? Does it have to use
> Ant?

These are two different questions.

Maven project descriptors may contain all information that Gump needs,
but there are some discontinuities.  For example, the names for the
projects Maven and Gump use may be different.  AFAIU Maven has a gump
goal that can generate Gump descriptors from Maven project
descriptors.

"Traditional" Gump cannot deal with Maven builds at all, and will
probably never learn it since the way to go is the Python rewrite of
Gump.  "Python" Gump has some initial support for Maven in addition to
Ant and scripts, but it is not completely there yet.

Cheers

Stefan

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

Re: Processing based off statistics

[Stefan Bodewig]

On Fri, 27 Feb 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:

> It is such a balance isn't it, we wish the community to get
> involved, but other areas of the community suffer if one doesn't
> maintain it's metadata.

Absolutely.

The thing to keep in mind is that for Apache projects the community
has full access to a descriptor that lives inside the Gump module.  So
the community that can fix things includes more people - and all
people who could fix things when the descriptor is in a more private
module.

>> If the nags are annoying, committers for the project can simply
>> turn them off.  Same for deferred nags.  After all all committers
>> are able to remove the nag elements.
> 
> I was hoping for a little more than on/off.

I see.

I'm a bit unsure as to what we can do here since we'd need to know
whether the nags simply get ignored (in which case there is no point
in doing anything but turning them off) or just postponed.  Is there
any automatic way to tell?

> I tried to make projects w/o nags generate nags [a single mail] to
> the Gump list, so we could process things like broken packages,
> etc. I need to debug why that isn't occuring.

Seems to work now 8-)

Stefan

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