Re: cvs commit: gump/project jakarta-tomcat-connectors.xml

2004-12-17 Thread Stefan Bodewig
On 17 Dec 2004, [EMAIL PROTECTED] wrote:

   Since httpd isn't being compiled to support dynamic modules, can't
   use apxs.

We could also try to enable dynamic modules support.

Stefan

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



Re: [revelation!!] circular dependencies do NOT exist!

2004-12-17 Thread Stefan Bodewig
On Thu, 16 Dec 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

 Until today, i thought that no matter how well maintained, a
 dependency graph would always be a general graph, and cycles would
 develop, sooner of later (it is still amazing that gump reached 750
 projects without explicit circular dependencies).

Because we've already used the time-travel approach to break them in a
couple of places

packaged-dom4j - jaxen-from-packaged-dom4j - dom4j - jaxen

and

packaged-jcs - bootstrap-ojb - jcs - db-ojb

(hmm, the later used to be the case, but right now I don't see any
difference between bootstrap-ojb and db-ojb anymore)

Stefan

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



Re: [revelation!!] circular dependencies do NOT exist!

2004-12-17 Thread Leo Simons
Stefano Mazzocchi wrote:
It came to me as a revelation today: one of the problems with gump that 
I could never figure out is the fact that circular dependencies prevent 
the ability to bootstrap after a certain point.
snip/
In fact, a particular version is the crystallization of all the time 
dependencies across the above trallis, but if we take into consideration 
the time axis, there is no such a thing as circular dependencies.
:). Aye.
A common approach in physics (or in math) is to add in another variable, 
constant, dimension, whatever, in order to get around annoying 
limitations of a model. The key problem with that is that the model 
becomes harder and harder to understand and work with, up to the point 
where like 3 people on the planet really understand it (I certainly 
don't get why string theorists think there's 13 dimensions. 7, maybe. 
But after that I get lost).

The same is true of bootstrapping. Someone who's doing, for example, 
linux from scratch (linuxfromscratch.org I think), is almost certainly 
not thinking about

 A:0---A:1-
  ^/
   \  /
  needs needs
 \  /
  \v
 -B:1-
but is using one very specific often-used snapshot provided by someone 
else (the (A,B):bootstrap distro).

Extending the above mechanism to 40 (or 4000!) projects all with 
time-invariant circular dependencies among themselves is kind of a pain, 
and I think most, for example, cocoon developers certainly aren't aware 
of their time-variant dependency graph.

So while we can probably build gump to work like this (heck, it already 
works like this manually), we'd need to do some powerful visualisation 
to make people understand what's going on.

A:20041215 failed because B:20041214 depends on C:20041213 for 
bootstrapping which depends on behaviour of A:20041212 that was broken 
from A:20041213 on.

try and figure that out for 700 projects, and explain it properly! :-D
So while circular dependencies don't exist if we ingrain our graph with 
the time dimension completely, it will at the same time become a lot 
more difficult to understand the graph and act upon changes to it. :/

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


RE: [revelation!!] circular dependencies do NOT exist!

2004-12-17 Thread Eric Pugh
Isn't the fallback idea for artifacts that is already in Gump something
like the time travel?  If project A depends on B, and A.today can't build
with B.today, then try with B.yesterday.  If that fails, then try
B.daybeforeyesterday.  If that fails, then try
B.daybeforedaybeforeyesterday!

I agree that the visualization would be hard, makes me think of all the
various tools (like FishEye) that attempt to visualize the branching of code
in CVS.

(Sorry for the crypto timestamp notation!)

Eric


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



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

2004-12-17 Thread brutus
Dear Gumpmeisters,

The following 9 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Module struts success, but with warnings.
[EMAIL PROTECTED]: Module lenya success, but with warnings.
[EMAIL PROTECTED]: Project nant (in module nant) failed
[EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) 
success, but with warnings.
[EMAIL PROTECTED]: Project jtidy-cvs (in module jtidy) failed
[EMAIL PROTECTED]: Project jetty-plus (in module jetty) failed
[EMAIL PROTECTED]: Project groovy (in module groovy) failed
[EMAIL PROTECTED]: Project maven (in module maven) failed
[EMAIL PROTECTED]: Project maven-bootstrap (in module maven) failed
*** G U M P
[EMAIL PROTECTED]: Module struts success, but with warnings.
To whom it may engage...

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

Module struts contains errors.
The current state of this module is 'Success'.

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -ERROR- *** Failed to update from source control. Stale contents ***



The following work was performed:
http://brutus.apache.org/gump/public/struts/gump_work/update_struts.html
Work Name: update_struts (Type: Update)
Work ended in a state of : Failed
Elapsed: 1 min 16 secs
Command Line: svn --quiet update --non-interactive struts 
[Working Directory: /usr/local/gump/public/workspace/cvs]
-
svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn: 
Cannot replace a directory from within

-

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

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

*** G U M P
[EMAIL PROTECTED]: Module lenya success, but with warnings.
To whom it may engage...

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

Module lenya contains errors.
The current state of this module is 'Success'.

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -ERROR- *** Failed to update from source control. Stale contents ***



The following work was performed:
http://brutus.apache.org/gump/public/lenya/gump_work/update_lenya.html
Work Name: update_lenya (Type: Update)
Work ended in a state of : Failed
Elapsed: 59 secs
Command Line: svn --quiet update --non-interactive lenya 
[Working Directory: /usr/local/gump/public/workspace/cvs]
-
svn: Working copy 'lenya/src/webapp/lenya/resources/bxe/plugins' not locked
-

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

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

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

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

Project nant has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- nant :  NAnt is a free .NET build tool. In theory it is kind of like...
- nant-install :  NAnt is a free .NET build tool. In theory it is kind of 
like...


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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work 

Re: [revelation!!] circular dependencies do NOT exist!

2004-12-17 Thread Stefano Mazzocchi
Stefan Bodewig wrote:
On Thu, 16 Dec 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

Until today, i thought that no matter how well maintained, a
dependency graph would always be a general graph, and cycles would
develop, sooner of later (it is still amazing that gump reached 750
projects without explicit circular dependencies).

Because we've already used the time-travel approach to break them in a
couple of places
packaged-dom4j - jaxen-from-packaged-dom4j - dom4j - jaxen
and
packaged-jcs - bootstrap-ojb - jcs - db-ojb
(hmm, the later used to be the case, but right now I don't see any
difference between bootstrap-ojb and db-ojb anymore)
Cool, see how many things we don't know.
Stefan, before we finish Gump 3.0 make sure you don't get hit by a truck ;-)
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [revelation!!] circular dependencies do NOT exist!

2004-12-17 Thread Stefano Mazzocchi
Leo Simons wrote:
So while we can probably build gump to work like this (heck, it already 
works like this manually), we'd need to do some powerful visualisation 
to make people understand what's going on.
eheh, here is where the fun (for me, as a research scientist) starts :-)
A:20041215 failed because B:20041214 depends on C:20041213 for 
bootstrapping which depends on behaviour of A:20041212 that was broken 
from A:20041213 on.

try and figure that out for 700 projects, and explain it properly! :-D
So while circular dependencies don't exist if we ingrain our graph with 
the time dimension completely, it will at the same time become a lot 
more difficult to understand the graph and act upon changes to it. :/
I've been spending a few weeks now studying hard about pretty much 
everything there is to know about user interface design for data 
visualization tecniques.

I'm not done yet (I have some 20 books to go ;-) but I'm seeing the 
light at the end of the tunnel.

more (and some screenshots) soon.
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [revelation!!] circular dependencies do NOT exist!

2004-12-17 Thread Wade . Stebbings
Stefano, my responses below...

Stefano Mazzocchi [EMAIL PROTECTED] wrote on 12/16/2004 05:51:17 PM:

 [...]
 
   A --(needs)-- B
 
 and
 
   B --(needs)-- A
 
 Until today, i thought that no matter how well maintained, a dependency 
 graph would always be a general graph, and cycles would develop, sooner 
 of later (it is still amazing that gump reached 750 projects without 
 explicit circular dependencies).

Is this all a matter of the scope of the node in the graph?  In other
words, and I think you get to this in a temporal way, but there are
parts of A on which B depends, and likewise the other direction.  These
parts are build at different times (sequenced), thus you are allowed
the perception of something within that is built before the whole.


 [...]
 
 Let's start with changing the above diagram a little:
 
   -A-
   /
needs
 /
v
   -B-
 time
 
 let's call them A:1 and B:1 to indicate their name and their time 
 coordinate (1 could be a timestamp or a version, doesn't matter), so
 
   A:1-
   /
needs
 /
v
   B:1-

It seems to me it is more of a matter of decomposition than temporal,
that each larger node ie, A, can be decomposed into its smaller
components, A:0, A:1, and B is decomposed into its components.


 no, the previous diagram said that A needs B and B needs A... but the 
 fact is that at the time of B:1, A:1 was not even existing, so it's 
 impossible to draw the above uses line bidirectionally. The 
 appropriate diagram is
 
   A:0---A:1-
^/
 \  /
needs needs
   \  /
\v
   -B:1-
 
 and we can continue like that backwards until we reach the *initial 
 stage* of one of the projects where one of them did *NOT* exist at all, 
 therefore the thing.

The question I have is: It really the case where the dependency on a
portion of another node is really time (version) based, or is it simply
time-based because of the way the entire node is built?

Another way of saying that is: Is what you are doing simply by extending
the model a series of decompositions to get to the smallest nuggest of
significance on which something could depend?  And the only reason why
time is involved is because of the sequencing of the building process?


 [...]
 
 In fact, a particular version is the crystallization of all the time 
 dependencies across the above trallis, but if we take into consideration 

 the time axis, there is no such a thing as circular dependencies.

I think you can come to the same conclusion by way of sufficient
decomposition and remove the time element.  Are we on the same
track of thought?

wade

Updating mono(?)

2004-12-17 Thread Davanum Srinivas
Can we upgrade the mono install to Debian/EXPERIMENTAL found at
http://pkg-mono.alioth.debian.org/? Can someone please walk me through
this process? Am looking at the man pages of apt-get etc...but want to
be sure that i don't break anything.

thanks,
dims

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

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



Re: Updating mono(?)

2004-12-17 Thread Stefano Mazzocchi
Davanum Srinivas wrote:
Can we upgrade the mono install to Debian/EXPERIMENTAL found at
http://pkg-mono.alioth.debian.org/? Can someone please walk me through
this process? Am looking at the man pages of apt-get etc...but want to
be sure that i don't break anything.
don't worry, if you break something we'll fix it ;-)
--
Stefano.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]