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
_________________________________________________________________________