You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2006/04/03 10:28:19 UTC

Re: What's going on with gump?

Bertrand Delacretaz wrote:
> Le 3 avr. 06 à 09:08, Gump a écrit :
> 
>> ... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to  
>> project name
>>  -INFO- Failed with reason missing build outputs
>>  -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/ 
>> lib/optional/chaperon-20040205.jar
>>  -ERROR- No such directory (where output is expected) : /usr/local/ 
>> gump/public/workspace/cocoon/lib/optional...
> 
> 
> What's up here? Is gump trying to build the trunk with the old ant  
> build system?
> 
> I'm not too sure about where to look for details on what exactly gump  
> is trying to do....

The error above seems to be caused by the missing lib/optional directory as I 
removed them last week.

If somebody wants to reactivate gump again, he should start incrementally and 
write a gump descriptor for cocoon-core but please make sure that we don't have 
any svn:externals in trunk; I removed the svn:externals link to gump.xml.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: What's going on with gump?

Posted by David Crossley <cr...@apache.org>.
I don't know if it helps us just yet, but look what
our dear departed friend did recently ...

http://marc.theaimsgroup.com/?l=gump&m=114280451625397
[gump3] mavenization2 of dynagump completed

-David

Re: What's going on with gump?

Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.04.2006 17:32, Carsten Ziegeler wrote:

> I think they are doing this "somehow" by using an own local repository
> which always delivers the "correct" version.

They put the results of building the trunks of our dependencies into 
this local repository.

Jörg

Re: What's going on with gump?

Posted by Carsten Ziegeler <cz...@apache.org>.
Upayavira wrote:
> Ralph Goers wrote:

> 
>> Thanks.  I sort of knew all that, but what I guess I'm missing is how it
>> actually does what you are saying it does.  With a maven2 build how do
>> they "force" you to pick up the latest version (actually - I already
>> know the answer to that since I have a Jira bug opened on Maven 2 to do
>> just that. The answer is, you can't).
> 
> Well, that's the Gump/Maven people's problem to solve, eh?
> 
I think they are doing this "somehow" by using an own local repository
which always delivers the "correct" version.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: What's going on with gump?

Posted by Upayavira <uv...@odoko.co.uk>.
Ralph Goers wrote:
> Upayavira wrote:
> 
>> Ralph Goers wrote:
>>  
>>
>>> Reinhard Poetz wrote:
>>>   
>>>> yes, according to the mails above sometime in the future it will work.
>>>>
>>>>                                   - o -
>>>>
>>>> If somebody has time to fix gump.xml so that it builds at least
>>>> cocoon-core it would be a good idea. If not, we should simply ask the
>>>> Gump folks to remove the descriptor.
>>>>
>>>> WDOT?
>>>>
>>>>     
>>> Everytime gump breaks I find myself wondering why anybody cares?  Can
>>> someone educate me on what is better about gump then us running
>>> Continuum?
>>>   
>>
>> Firstly, I am no expert on Gump.
>>
>> You can see Gump as more of a social thing - it not just related to our
>> own pretty little project - it builds _everything_. It checks out trunk
>> on a huge number of projects and builds them, thus ensuring that all
>> projects continue to work together in their trunk versions. So think of
>> it as one huge Continuum for _all_ Apache software and beyond, not just
>> for Cocoon.
>>
>> As such, it will tell us if, for some reason, Cocoon wouldn't compile on
>> Kaffe, or if one of our dependencies changed its interface and that
>> broke our code.
>>  
>>
> How can that work?  We specify the versions in the pom.xml. It will just
> keep rebuilding the same thing until the pom is changed.  I guess I'm
> not sure how that even worked in the old system since we had all the jar
> files in our own repository.

Heck, that's the point. Gump ignores specific versions and just builds
against trunk for _everything_. That is the point of it - find out
quickly if someone broke something.

>> Cocoon is a fantastic project for the Gump people, because we have soooo
>> many dependencies. If Cocoon builds, that means all of its dependencies,
>> and their dependencies, etc, all built too, which as I understand it
>> doesn't happen that often :-)
>>  
>>
> See the above comment. How does that happen if we still have the old
> version?

See above answer :-)

>> So, yes, it is a valuable resource, but on a broader scale than just our
>> own project.

> Thanks.  I sort of knew all that, but what I guess I'm missing is how it
> actually does what you are saying it does.  With a maven2 build how do
> they "force" you to pick up the latest version (actually - I already
> know the answer to that since I have a Jira bug opened on Maven 2 to do
> just that. The answer is, you can't).

Well, that's the Gump/Maven people's problem to solve, eh?

Heck, I said I was no gump expert :-)

Regards, Upayavira


Re: What's going on with gump?

Posted by Ralph Goers <Ra...@dslextreme.com>.
Upayavira wrote:

>Ralph Goers wrote:
>  
>
>>Reinhard Poetz wrote:
>>    
>>
>>>yes, according to the mails above sometime in the future it will work.
>>>
>>>                                   - o -
>>>
>>>If somebody has time to fix gump.xml so that it builds at least
>>>cocoon-core it would be a good idea. If not, we should simply ask the
>>>Gump folks to remove the descriptor.
>>>
>>>WDOT?
>>>
>>>      
>>>
>>Everytime gump breaks I find myself wondering why anybody cares?  Can
>>someone educate me on what is better about gump then us running Continuum?
>>    
>>
>
>Firstly, I am no expert on Gump.
>
>You can see Gump as more of a social thing - it not just related to our
>own pretty little project - it builds _everything_. It checks out trunk
>on a huge number of projects and builds them, thus ensuring that all
>projects continue to work together in their trunk versions. So think of
>it as one huge Continuum for _all_ Apache software and beyond, not just
>for Cocoon.
>
>As such, it will tell us if, for some reason, Cocoon wouldn't compile on
>Kaffe, or if one of our dependencies changed its interface and that
>broke our code.
>  
>
How can that work?  We specify the versions in the pom.xml. It will just 
keep rebuilding the same thing until the pom is changed.  I guess I'm 
not sure how that even worked in the old system since we had all the jar 
files in our own repository.

>Cocoon is a fantastic project for the Gump people, because we have soooo
>many dependencies. If Cocoon builds, that means all of its dependencies,
>and their dependencies, etc, all built too, which as I understand it
>doesn't happen that often :-)
>  
>
See the above comment. How does that happen if we still have the old 
version?

>So, yes, it is a valuable resource, but on a broader scale than just our
>own project.
>
>Regards, Upayavira
>  
>
Thanks.  I sort of knew all that, but what I guess I'm missing is how it 
actually does what you are saying it does.  With a maven2 build how do 
they "force" you to pick up the latest version (actually - I already 
know the answer to that since I have a Jira bug opened on Maven 2 to do 
just that. The answer is, you can't).

Ralph




Re: What's going on with gump?

Posted by Upayavira <uv...@odoko.co.uk>.
Ralph Goers wrote:
> 
> 
> Reinhard Poetz wrote:
>>
>> yes, according to the mails above sometime in the future it will work.
>>
>>                                    - o -
>>
>> If somebody has time to fix gump.xml so that it builds at least
>> cocoon-core it would be a good idea. If not, we should simply ask the
>> Gump folks to remove the descriptor.
>>
>> WDOT?
>>
> Everytime gump breaks I find myself wondering why anybody cares?  Can
> someone educate me on what is better about gump then us running Continuum?

Firstly, I am no expert on Gump.

You can see Gump as more of a social thing - it not just related to our
own pretty little project - it builds _everything_. It checks out trunk
on a huge number of projects and builds them, thus ensuring that all
projects continue to work together in their trunk versions. So think of
it as one huge Continuum for _all_ Apache software and beyond, not just
for Cocoon.

As such, it will tell us if, for some reason, Cocoon wouldn't compile on
Kaffe, or if one of our dependencies changed its interface and that
broke our code.

Cocoon is a fantastic project for the Gump people, because we have soooo
many dependencies. If Cocoon builds, that means all of its dependencies,
and their dependencies, etc, all built too, which as I understand it
doesn't happen that often :-)

So, yes, it is a valuable resource, but on a broader scale than just our
own project.

Regards, Upayavira

Re: What's going on with gump?

Posted by Ralph Goers <Ra...@dslextreme.com>.

Reinhard Poetz wrote:
>
> yes, according to the mails above sometime in the future it will work.
>
>                                    - o -
>
> If somebody has time to fix gump.xml so that it builds at least 
> cocoon-core it would be a good idea. If not, we should simply ask the 
> Gump folks to remove the descriptor.
>
> WDOT?
>
Everytime gump breaks I find myself wondering why anybody cares?  Can 
someone educate me on what is better about gump then us running Continuum?

Ralph

Re: What's going on with gump?

Posted by Reinhard Poetz <re...@apache.org>.
Upayavira wrote:
> Reinhard Poetz wrote:
> 
>>Upayavira wrote:
>>
>>>Reinhard Poetz wrote:
>>>
>>>
>>>>Bertrand Delacretaz wrote:
>>>>
>>>>
>>>>>Le 3 avr. 06 à 09:08, Gump a écrit :
>>>>>
>>>>>
>>>>>
>>>>>>... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to
>>>>>>project name
>>>>>>-INFO- Failed with reason missing build outputs
>>>>>>-ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/
>>>>>>lib/optional/chaperon-20040205.jar
>>>>>>-ERROR- No such directory (where output is expected) : /usr/local/
>>>>>>gump/public/workspace/cocoon/lib/optional...
>>>>>
>>>>>
>>>>>What's up here? Is gump trying to build the trunk with the old ant
>>>>>build system?
>>>>>
>>>>>I'm not too sure about where to look for details on what exactly
>>>>>gump is trying to do....
>>>>
>>>>The error above seems to be caused by the missing lib/optional directory
>>>>as I removed them last week.
>>>>
>>>>If somebody wants to reactivate gump again, he should start
>>>>incrementally and write a gump descriptor for cocoon-core but please
>>>>make sure that we don't have any svn:externals in trunk; I removed the
>>>>svn:externals link to gump.xml.
>>>
>>>
>>>Well that is going to break things. That SVN external was to allow Gump
>>>people write access to our gump descriptor. How come you removed it? It
>>>was placed there in discussion with this list and with the Gump peeps.
>>
>>Sorry for not bringing this issue to the list.
>>IIUC I didn't delete the descriptor but only the link to it as gump.xml
>>is located in the gump SVN. We can add the svn:external to our
>>repository for convenience but please don't do it within trunk -
>>/cocoon/gump would be a better idea IMHO.
> 
> 
> Actually, this is fair enough, as we no longer depend upon Gump for our
> build process.
> 
> 
>>                                   - o -
>>
>>More generally, we need to decide what we do with it as gump.xml as it
>>is today is totally broken because of the move to Maven 2 (e.g. we are
>>relying on many libraries within the repository; many source directories
>>have changed, etc.).
>>
>>Basically the gump descriptor expresses the same dependencies as the
>>pom.xml and I doubt our community will take care of both. BTW, is
>>anybody taking care of a working Gump descriptor? The best solution
>>would be Gump that can work based on pom.xml descriptors ...
> 
> 
> I did see some discussion on Gump working with Maven2, but have since
> unsubscribed from general@gump, as I was hardly reading it.

Found this thread: http://marc.theaimsgroup.com/?t=114347541700002&r=1&w=2

> So in time, maybe Gump itself will run off pom files where they exis

yes, according to the mails above sometime in the future it will work.

                                    - o -

If somebody has time to fix gump.xml so that it builds at least cocoon-core it 
would be a good idea. If not, we should simply ask the Gump folks to remove the 
descriptor.

WDOT?

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: What's going on with gump?

Posted by Upayavira <uv...@odoko.co.uk>.
Reinhard Poetz wrote:
> Upayavira wrote:
>> Reinhard Poetz wrote:
>>
>>> Bertrand Delacretaz wrote:
>>>
>>>> Le 3 avr. 06 à 09:08, Gump a écrit :
>>>>
>>>>
>>>>> ... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to
>>>>> project name
>>>>> -INFO- Failed with reason missing build outputs
>>>>> -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/
>>>>> lib/optional/chaperon-20040205.jar
>>>>> -ERROR- No such directory (where output is expected) : /usr/local/
>>>>> gump/public/workspace/cocoon/lib/optional...
>>>>
>>>>
>>>> What's up here? Is gump trying to build the trunk with the old ant
>>>> build system?
>>>>
>>>> I'm not too sure about where to look for details on what exactly
>>>> gump is trying to do....
>>>
>>> The error above seems to be caused by the missing lib/optional directory
>>> as I removed them last week.
>>>
>>> If somebody wants to reactivate gump again, he should start
>>> incrementally and write a gump descriptor for cocoon-core but please
>>> make sure that we don't have any svn:externals in trunk; I removed the
>>> svn:externals link to gump.xml.
>>
>>
>> Well that is going to break things. That SVN external was to allow Gump
>> people write access to our gump descriptor. How come you removed it? It
>> was placed there in discussion with this list and with the Gump peeps.
> 
> Sorry for not bringing this issue to the list.
> IIUC I didn't delete the descriptor but only the link to it as gump.xml
> is located in the gump SVN. We can add the svn:external to our
> repository for convenience but please don't do it within trunk -
> /cocoon/gump would be a better idea IMHO.

Actually, this is fair enough, as we no longer depend upon Gump for our
build process.

>                                    - o -
> 
> More generally, we need to decide what we do with it as gump.xml as it
> is today is totally broken because of the move to Maven 2 (e.g. we are
> relying on many libraries within the repository; many source directories
> have changed, etc.).
> 
> Basically the gump descriptor expresses the same dependencies as the
> pom.xml and I doubt our community will take care of both. BTW, is
> anybody taking care of a working Gump descriptor? The best solution
> would be Gump that can work based on pom.xml descriptors ...

I did see some discussion on Gump working with Maven2, but have since
unsubscribed from general@gump, as I was hardly reading it.

So in time, maybe Gump itself will run off pom files where they exist.

Regards, Upayavira




Re: What's going on with gump?

Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Le 3 avr. 06 à 10:51, Reinhard Poetz a écrit :
> 
>> ...More generally, we need to decide what we do with it as gump.xml as
>> it is today is totally broken because of the move to Maven 2...
> 
> While gump is unable to build our trunk, we could at least have it build
> the 2.1.x branch?
> 
> I assume this requires pointing gump to the old 2.1.x descriptor, but I
> don't know how to do that.

The point of having the SVN external was that all Apache committers have
commit rights to the Gump area. So, if someone wanted to have Gump build
2.1.x (which makes some sense to me), it would be:

a) Check that's okay with the Gump community
b) Commit the 2.1.X gump.xml on top of the existing one in the gump SVN
c) Create an SVN external in 2.1.X SVN to the gump SVN

Upayavira

Re: What's going on with gump?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 3 avr. 06 à 10:51, Reinhard Poetz a écrit :

> ...More generally, we need to decide what we do with it as gump.xml  
> as it is today is totally broken because of the move to Maven 2...

While gump is unable to build our trunk, we could at least have it  
build the 2.1.x branch?

I assume this requires pointing gump to the old 2.1.x descriptor, but  
I don't know how to do that.

-Bertrand

Re: What's going on with gump?

Posted by Reinhard Poetz <re...@apache.org>.
Upayavira wrote:
> Reinhard Poetz wrote:
> 
>>Bertrand Delacretaz wrote:
>>
>>>Le 3 avr. 06 à 09:08, Gump a écrit :
>>>
>>>
>>>>... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to 
>>>>project name
>>>> -INFO- Failed with reason missing build outputs
>>>> -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/
>>>>lib/optional/chaperon-20040205.jar
>>>> -ERROR- No such directory (where output is expected) : /usr/local/
>>>>gump/public/workspace/cocoon/lib/optional...
>>>
>>>
>>>What's up here? Is gump trying to build the trunk with the old ant 
>>>build system?
>>>
>>>I'm not too sure about where to look for details on what exactly gump 
>>>is trying to do....
>>
>>The error above seems to be caused by the missing lib/optional directory
>>as I removed them last week.
>>
>>If somebody wants to reactivate gump again, he should start
>>incrementally and write a gump descriptor for cocoon-core but please
>>make sure that we don't have any svn:externals in trunk; I removed the
>>svn:externals link to gump.xml.
> 
> 
> Well that is going to break things. That SVN external was to allow Gump
> people write access to our gump descriptor. How come you removed it? It
> was placed there in discussion with this list and with the Gump peeps.

Sorry for not bringing this issue to the list.
IIUC I didn't delete the descriptor but only the link to it as gump.xml is 
located in the gump SVN. We can add the svn:external to our repository for 
convenience but please don't do it within trunk - /cocoon/gump would be a better 
idea IMHO.

                                    - o -

More generally, we need to decide what we do with it as gump.xml as it is today 
is totally broken because of the move to Maven 2 (e.g. we are relying on many 
libraries within the repository; many source directories have changed, etc.).

Basically the gump descriptor expresses the same dependencies as the pom.xml and 
I doubt our community will take care of both. BTW, is anybody taking care of a 
working Gump descriptor? The best solution would be Gump that can work based on 
pom.xml descriptors ...

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: What's going on with gump?

Posted by Upayavira <uv...@odoko.co.uk>.
Reinhard Poetz wrote:
> Bertrand Delacretaz wrote:
>> Le 3 avr. 06 à 09:08, Gump a écrit :
>>
>>> ... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to 
>>> project name
>>>  -INFO- Failed with reason missing build outputs
>>>  -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/
>>> lib/optional/chaperon-20040205.jar
>>>  -ERROR- No such directory (where output is expected) : /usr/local/
>>> gump/public/workspace/cocoon/lib/optional...
>>
>>
>> What's up here? Is gump trying to build the trunk with the old ant 
>> build system?
>>
>> I'm not too sure about where to look for details on what exactly gump 
>> is trying to do....
> 
> The error above seems to be caused by the missing lib/optional directory
> as I removed them last week.
> 
> If somebody wants to reactivate gump again, he should start
> incrementally and write a gump descriptor for cocoon-core but please
> make sure that we don't have any svn:externals in trunk; I removed the
> svn:externals link to gump.xml.

Well that is going to break things. That SVN external was to allow Gump
people write access to our gump descriptor. How come you removed it? It
was placed there in discussion with this list and with the Gump peeps.

Regards, Upayavira