Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Adam Jack <aj...@trysybase.com>]

All,

Would somebody with the requisite permissions please add jUDDI (see
http://juddi.sourceforge.net) to profile/gump.xml:

  <module
href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/juddi/juddi/gump.xml"
/>

Perhaps here between junit and jython (since the list appears alphabetical
by project name), i.e.:

<!-- SourceForge -->
	[...]
  <module href="project/junit.xml"/>

  <module
href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/juddi/juddi/gump.xml"
/>

  <module href="project/jython.xml"/>
	[...]

Thanks in advance.

Note: With the SF.net 24 hour delay that URL above probably won't be valid
until some time tonight.

regards,

Adam
--
<http://www.try.sybase.com>
Experience Sybase Technology ...

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Wed, 23 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> BTW: I really wish we could improve gump to be smarter and (1) only
> re-build something if something inside it (or below) has changed

Only talking about the existing shell/XSLT Gump:

Detecting whether a module has changed is rather simple in update.sh,
just grep through the cvs output for lines starting with "P " or "U "
or lines that contain "is no longer in the repository".  This would be
almost the same for svn as well.

Likewise it would be rather easy to write yet another processor that
would calculate the projects that need to be rebuilt and it wouldn't
be too difficult to make build.sh use that.

It may even be possible to do that without the intermediate step -
i.e. make update.sh write status information and build.sh check that
before doing rsync and/or build.

This would obviously lead to even more XSLT to be written and even
longer and more complicated shell scripts.  How is the Python effort
coming along? 8-)

Stefan

Re: depend types was: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Thu, 24 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:
> Stefan Bodewig wrote:

>>Are there any compile time dependencies (i.e. things your code
>>imports) that are not runtime dependencies as well?
> 
> Yes log4j,  is required to compile, but at runtime we fallback to
> System.out.

Ah, interesting.  The other way around is more common, require JAXP at
compile-time and in addition a parser/transformer as runtime.

Do you use log4j as <option> with conditional compilation then?

Anyway.  We seem to need 

<depend runtime="true"/>
<depend/>

and yet another one.  <depend/> should probably be left as "compile"
and we could add buildonly="true" or similar for things like Ant.

Or we add a type attribute and morph runtime="true" into
type="runtime".  This certainly scales best if we ever stumble over
more types (like DD's test-compile) and find we really need them.

Stefan

depend types was: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Nick Chalko <ni...@chalko.com>]

Stefan Bodewig wrote:

>On Thu, 24 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:
>
>  
>
>>But can we capture teh difference betwwen "build" time and "compile"
>>time dependencies into gump
>>    
>>
>
>Are there any compile time dependencies (i.e. things your code
>imports) that are not runtime dependencies as well?
>

Yes log4j,  is required to compile, but at runtime we fallback to 
System.out.

>
>"build time" would be things like Ant, JavaCC, JUnit, Checkstyle for
>most projects.  But I think "compile time" with the definition above
>is a subset of runtime.
>
>  
>
>>Or is ant special enough that we just recommend people use a
>>"released" ant.
>>    
>>
>
>Maybe in the case of Ant, but what about JavaCC (two different, binary
>and API incompatible new versions over the past two months)?
>  
>
Good point.

perhaps there is three types of depends  build / compile / runtime. 

>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Thu, 24 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:

> But can we capture teh difference betwwen "build" time and "compile"
> time dependencies into gump

Are there any compile time dependencies (i.e. things your code
imports) that are not runtime dependencies as well?

"build time" would be things like Ant, JavaCC, JUnit, Checkstyle for
most projects.  But I think "compile time" with the definition above
is a subset of runtime.

> Or is ant special enough that we just recommend people use a
> "released" ant.

Maybe in the case of Ant, but what about JavaCC (two different, binary
and API incompatible new versions over the past two months)?

Stefan

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Nick Chalko <ni...@chalko.com>]

Stefan Bodewig wrote:

>On Thu, 24 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:
>
>  
>
>>>Ant is almost always a "compile time only" dependency.
>>>
>>>      
>>>
>>Most the time it is not a compile time dependency, just the tool
>>used to compile.
>>    
>>
>
>s/compile/build/ in my sentence.
>
>OK?
>  
>
agree,.

But can we capture teh difference betwwen "build" time and "compile" 
time dependencies into gump
Or is ant special enough that we just recommend people use a "released" ant.

>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Thu, 24 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:

>>Ant is almost always a "compile time only" dependency.
>>
> Most the time it is not a compile time dependency, just the tool
> used to compile.

s/compile/build/ in my sentence.

OK?

Stefan

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Nick Chalko <ni...@chalko.com>]

Stefan Bodewig wrote:

>On Thu, 24 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:
>
>  
>
>>Maybe a choice could be to ignore changes for components that are a
>>"runtime" dependency.
>>    
>>
>
>You mean *not* a runtime dependency, right?  Ant is almost always a
>"compile time only" dependency.
>  
>
Most the time it is not a compile time dependency,  just the tool used 
to compile. 

Many many projects will compile using any version of ant.   The 
build.xml  may not work with any ant,   but most projects java code does 
not rely on ant.

>That would require properly marking up the runtime attributes, which
>is not the case for most current definitions, though.
>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Thu, 24 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> 	You mean *not* a runtime dependency, right?  Ant is almost
> 	always a "compile time only" dependency.
> 
> Only for clarity ('cos we are agreeing) I was trying to speak
> "gump". I meant:
> 
> 	<depend name="ant" inherit="runtime" />

While I meant <depend name="jakarta-log4j" runtime="true"/>

> 	That would require properly marking up the runtime
> 	attributes, which is not the case for most current
> 	definitions, though.
> 
> Ant is the big runtime dependency (many more folk build with ant
> that write ant tasks),

No, Ant is not a runtime dependency at all.  We are still agreeing,
just not on the terms we use 8-)

To me project A is a "runtime dependency" of B if B needs A at runtime.
In this case, B will have <depend project="A" runtime="true"/> - and
this type of marker is missing for most project definitions ATM.

<depend name="ant" inherit="runtime" /> means that I need Ant at build
time (not runtime) and all the things that Ant has as runtime
dependency as well.

Stefan

RE: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Adam Jack <aj...@trysybase.com>]

	You mean *not* a runtime dependency, right?  Ant is almost always a
	"compile time only" dependency.

Only for clarity ('cos we are agreeing) I was trying to speak "gump". I
meant:

	<depend name="ant" inherit="runtime" />

	That would require properly marking up the runtime attributes, which
	is not the case for most current definitions, though.

Ant is the big runtime dependency (many more folk build with ant that write
ant tasks), and we do have that in most definitions today. Other than that
one project I suspect we'd have period of "quiet" with each sub-stack.

regards,

Adam

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Thu, 24 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> Maybe a choice could be to ignore changes for components that are a
> "runtime" dependency.

You mean *not* a runtime dependency, right?  Ant is almost always a
"compile time only" dependency.

That would require properly marking up the runtime attributes, which
is not the case for most current definitions, though.

Stefan

RE: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Adam Jack <aj...@trysybase.com>]

	> BTW: I really wish we could improve gump to be smarter and (1) only
	> re-build something if something inside it (or below) has changed

	At least for the "full" Gumps this will be more or less useless as Ant
	changes quite often - and all projects depend on Ant.

Maybe a choice could be to ignore changes for components that are a
"runtime" dependency. Gump isn't meant as an ant script unit test (althogut
that is useful), it is for code integrations. Full gump has more
cycles/time/patience than some of us.

regards

Adam

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Wed, 23 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> BTW: I really wish we could improve gump to be smarter and (1) only
> re-build something if something inside it (or below) has changed

At least for the "full" Gumps this will be more or less useless as Ant
changes quite often - and all projects depend on Ant.

Stefan

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Adam Jack <aj...@trysybase.com>]

>
> As soon as you've patched it and the patch has propagated to WebCVS,
> that is 8-(

My bad, sorry:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/juddi/juddi/gump.x
ml

I needed the *checkout* words.

Thanks for your help.

regards

Adam

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On 23 Jul 2003, Stefan Bodewig <bo...@apache.org> wrote:

> Let's give it a try, then.

As soon as you've patched it and the patch has propagated to WebCVS,
that is 8-(

,----
| Failed to expand module with href http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/juddi/juddi/gump.xml
|    - org.xml.sax.SAXParseException: Dokumentwurzelelement fehlt
| No cache cache/http___cvs.sourceforge.net_cgi-bin_viewcvs.cgi_juddi_juddi_gump.xml.xml available.
`----

Dokumentwurzelelement fehlt == missing document root - don't you love
localized error messages?

Ah, the link simply didn't point to the file but it's CVS overview.
Will commit shortly.

Stefan

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Wed, 23 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> it depends upon AXIS, commons-logging, WSD4L, and quite a few
> others.

Let's give it a try, then.

Stefan

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Adam Jack <aj...@trysybase.com>]

> On Wed, 23 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:
>
> > But there is the other side: does jUDDI relay on gumped projects?
>
> Granted.  I didn't say that I'd roll back a commit that added jUDDI,
> just wanted to know the rationale for it.
>

Sorry guys, I am reading mail from an odd location w/ no filters and a tonne
to wade through. Getting them backwards. Totally understood on why you
question it, it is a fair question. And yes -- it depends upon AXIS,
commons-logging, WSD4L, and quite a few others.

BTW: I really wish we could improve gump to be smarter and (1) only re-build
something if something inside it (or below) has changed (2) share pre-built
components not duplicate work. The current "brute force" (always download,
always build) is accurate, but very intensive. I think checking if something
had change in CVS, or in a CVS callign stack, is tricky -- but it might be
worth it for gump to be able to grow. [I guess the question becomes, home
many things worth gumping are stable -- but at 4 (or more) worldwide gumps a
day, I'd say there was likely "stacks" of "stable" code.]

regards,

Adam

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Wed, 23 Jul 2003, Nick Chalko <ni...@chalko.com> wrote:

> But there is the other side: does jUDDI relay on gumped projects?

Granted.  I didn't say that I'd roll back a commit that added jUDDI,
just wanted to know the rationale for it.

Currently Gump takes eight and a half hours on my machine (with Jaxen
and excalibur-component failing to build, otherwise it would take a
lot longer) almost six of which are being spent in CVS updates.  Will
Gump ever manage to check out the jUDDI module?

Stefan

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Nick Chalko <ni...@chalko.com>]

Stefan Bodewig wrote:

>On Tue, 22 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:
>
>  
>
>>Would somebody with the requisite permissions please add jUDDI
>>    
>>
>
>given the current speed of SourceForge's CVS I'm a bit reluctant to
>add new SF hosted projects just because we can.  Will any other
>project currently built by Gump use it?
>
But there is the other side: does jUDDI relay on gumped projects?
The more dependencies an exiting project gains the more testing it gets.

And jUDDI will want to know early that something has changed.

>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>  
>

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Adam Jack <aj...@trysybase.com>]

> > Would somebody with the requisite permissions please add jUDDI
>
> given the current speed of SourceForge's CVS I'm a bit reluctant to
> add new SF hosted projects just because we can.

Hey, with SF.net randomly dropping anonymous connections I'd have thought
it'd be next to free to add SF.net projects. ;-)

Seriously though, it isn't big.

>  Will any other
> project currently built by Gump use it?

Isn't this putting the cart before the horse? Doesn't jUDDI being built on
gump lead to more folk gumping via it? No, nobody yet -- to my knowledge. It
does have a toolkit though, so is something folks ought be able to
rely/build upon.

That said, the main reason I'd like it on gump is because I use it, it
depends upon some (sometimes significantly) changing components (AXIS,
WSDL4J, etc.) and I'd like to ensure that it keep track with the components
it uses. Isn't that a fair use for gump also?

regards,

Adam

Re: Please add jUDDI (http://juddi.sourceforge.net) to Gump...

[Stefan Bodewig <bo...@apache.org>]

On Tue, 22 Jul 2003, Adam Jack <aj...@trysybase.com> wrote:

> Would somebody with the requisite permissions please add jUDDI

given the current speed of SourceForge's CVS I'm a bit reluctant to
add new SF hosted projects just because we can.  Will any other
project currently built by Gump use it?

Stefan