You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2008/04/16 14:21:03 UTC

Re: svn commit: r648313 - in /cocoon: subprojects/ trunk/subprojects/

On 15.04.2008 12:23, reinhard@apache.org wrote:

> Author: reinhard
> Date: Tue Apr 15 09:23:00 2008
> New Revision: 648313
> 
> URL: http://svn.apache.org/viewvc?rev=648313&view=rev
> Log:
> mv subprojects into trunk
> 
> Added:
>     cocoon/trunk/subprojects/
>       - copied from r648312, cocoon/subprojects/
> Removed:
>     cocoon/subprojects/

Is there a reason for that? When I want to check out Cocoon trunk I 
don't want to have all the subprojects of it, do I?

Joerg

Re: Location of subprojects in SVN

Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.04.2008 08:35, Reinhard Poetz wrote:

>>> URL: http://svn.apache.org/viewvc?rev=648313&view=rev
>>> Log:
>>> mv subprojects into trunk
>>>
>>
>> Is there a reason for that? When I want to check out Cocoon trunk I 
>> don't want to have all the subprojects of it, do I?
> 
> My first idea was to move our subprojects (SSF, Spring configurator, 
> JNet, Block Deployment) to cocoon/subprojects but this would have mae it 
> more difficult to run a complete build of trunk because you would have 
> to make sure that you build the subprojects first.
> 
> Of course this could be solved by having releases of all subprojects and 
> use them instead of the SNAPSHOTs, but we haven't reached that point yet 
> for JNet and Block Deployer.
> 
> Considering this I propose that we leave the subprojects _for now_ in 
> cocoon/trunk/subprojects and move them out as soon as all 4 subprojects 
> have been released.
> 
> WDYT?

As a temporary solution that's fine.

Joerg

Location of subprojects in SVN

Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> On 15.04.2008 12:23, reinhard@apache.org wrote:
> 
>> Author: reinhard
>> Date: Tue Apr 15 09:23:00 2008
>> New Revision: 648313
>>
>> URL: http://svn.apache.org/viewvc?rev=648313&view=rev
>> Log:
>> mv subprojects into trunk
>>
>> Added:
>>     cocoon/trunk/subprojects/
>>       - copied from r648312, cocoon/subprojects/
>> Removed:
>>     cocoon/subprojects/
> 
> Is there a reason for that? When I want to check out Cocoon trunk I 
> don't want to have all the subprojects of it, do I?

My first idea was to move our subprojects (SSF, Spring configurator, JNet, Block 
Deployment) to cocoon/subprojects but this would have mae it more difficult to 
run a complete build of trunk because you would have to make sure that you build 
the subprojects first.

Of course this could be solved by having releases of all subprojects and use 
them instead of the SNAPSHOTs, but we haven't reached that point yet for JNet 
and Block Deployer.

Considering this I propose that we leave the subprojects _for now_ in 
cocoon/trunk/subprojects and move them out as soon as all 4 subprojects have 
been released.

WDYT?

P.S. I'm going to move the SSF and Spring configurator stuff later this day. If 
there is somebody having pending commits, 'svn switch --relocate' should help.

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________