You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jorg Heymans <jh...@domek.be> on 2005/11/03 15:21:32 UTC
[M10N] new repo layout
Hi all,
I've just committed an example of how our repository could be structured
to support the ongoing componentization, new (osgi) block structure and
M10N. Daniel suggested this flat structure a while ago [0], maven [1]
and eclipse [2] use a similar layout.
The example is in the whiteboard, under maven2/cocoon-flat-layout.
The concept is the following :
/trunk
pom.xml
/cocoon-core
/cocoon-forms-block
/cocoon-ajax-block
/cocoon-asciiart-block
/... other blocks
/webapp
--> pom.xml
This is essentially just a multi-module pom which acts as the parent of
all module poms.
<module>cocoon-core</module>
<module>cocoon-ajax-block</module>
<module>cocoon-forms-block</module>
....
It allows us to define properties and plugins valid for all modules.
Child modules can still override if necessary.
--> /cocoon-core
This is kept as one maven module for now, we can choose to split this up
further. I didn't separate this one into api/impl as I wasn't sure if it
made sense, but maven-wise it's very easy to do so.
--> /cocoon-forms-block, /cocoon-asciiart-block ...
All modules that we choose to host and support ourselves land in the
repository root. We can either stick to the existing block naming
convention or go for a package based approach like eclipse.
--> /webapp
This is a special module in the sense that it will be used as a
deployment target for blocks during development. The webapp will also
get included in various other package and deployment targets.
To test the usability from the new structure, go to
maven2/cocoon-flat-layout and do
"mvn -Dmaven.test.skip=true install eclipse:eclipse" , it will
create an eclipse project for each module, at the end you should see
something like
[INFO] BUILD SUCCESSFUL
[INFO] ---------------------------------------------
[INFO] Total time: 54 seconds
[INFO] Finished at: Thu Oct 27 00:36:29 CEST 2005
[INFO] Final Memory: 8M/51M
In eclipse, you then do File->Import->Existing Projects Into Workspace
and point the root directory to maven2/cocoon-flat-layout. It should
detect all available projects, complete with library + inter-project
dependencies, source and targetpaths. Note that you'll need to setup the
M2_REPO variable to point to your maven2 repo. Alternatively, the
eclipse plugin can do this for you [3].
Please have a look and tell me what you think.
I'll explain the new block structure in another thread.
Regards
Jorg
[0] http://thread.gmane.org/gmane.text.xml.cocoon.devel/54923
[1] http://svn.apache.org/viewcvs.cgi/maven/components/trunk/
[2] http://dev.eclipse.org/
[3]
http://maven.apache.org/maven2/plugins/maven-eclipse-plugin/add-maven-repo-mojo.html
Re: [M10N] new repo layout
Posted by Jorg Heymans <jh...@domek.be>.
Daniel Fagerstrom wrote:
>> --> /cocoon-forms-block, /cocoon-asciiart-block ...
>> All modules that we choose to host and support ourselves land in the
>> repository root.
>>
> Does the block suffix buy us anything? Everything, core included will be
> a block.
if anything the suffix could be something that people switching from
2.1.x can relate to - other than that I don't see any real benefits.
I'll drop the suffix if people are ok with this.
>> We can either stick to the existing block naming
>> convention or go for a package based approach like eclipse.
>>
>>
> AFAIU either will do, so we could as well stick with the existing name
> convention.
ok.
Jorg
Re: [M10N] new repo layout
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jorg Heymans wrote:
>Hi all,
>
>I've just committed an example of how our repository could be structured
>to support the ongoing componentization, new (osgi) block structure and
>M10N. Daniel suggested this flat structure a while ago [0], maven [1]
>and eclipse [2] use a similar layout.
>
>The example is in the whiteboard, under maven2/cocoon-flat-layout.
>
>The concept is the following :
>
>/trunk
> pom.xml
> /cocoon-core
> /cocoon-forms-block
> /cocoon-ajax-block
> /cocoon-asciiart-block
> /... other blocks
> /webapp
>
>
Looks good.
> --> pom.xml
>This is essentially just a multi-module pom which acts as the parent of
>all module poms.
>
> <module>cocoon-core</module>
> <module>cocoon-ajax-block</module>
> <module>cocoon-forms-block</module>
> ....
>
>It allows us to define properties and plugins valid for all modules.
>Child modules can still override if necessary.
>
> --> /cocoon-core
>This is kept as one maven module for now, we can choose to split this up
>further. I didn't separate this one into api/impl as I wasn't sure if it
>made sense, but maven-wise it's very easy to do so.
>
> --> /cocoon-forms-block, /cocoon-asciiart-block ...
>All modules that we choose to host and support ourselves land in the
>repository root.
>
Does the block suffix buy us anything? Everything, core included will be
a block.
> We can either stick to the existing block naming
>convention or go for a package based approach like eclipse.
>
>
AFAIU either will do, so we could as well stick with the existing name
convention.
...
/Daniel
Re: [M10N] new repo layout
Posted by Jorg Heymans <jh...@domek.be>.
Vadim Gritsenko wrote:
>
> I must be stupid. I re-read it [1] twice but still don't see where tags
> and branches live. :-(
>
well that's because i didn't really specify this :)
I'll have a look at the release plugin and find out where and how it
creates tags.
Jorg
Re: [M10N] new repo layout
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> Vadim Gritsenko wrote:
>
>>>>Where each block is treated as independent project, and has own
>>>>tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
>>>>start having own tags.
>
> Perfect, my proposed layout covers this use case. Each block will have
> its own release cycle, we can even use the maven release plugin to do
> releases. I will experiment with this in the mini repo and document my
> findings.
I must be stupid. I re-read it [1] twice but still don't see where tags and
branches live. :-(
...
>>It seems like a step backward, towards 2.1 situation, where each block
>>is part of single project, instead of moving forward and cutting blocks
>>loose...
>
> The single root pom has no meaning other than tying the other modules
> together and giving us the possibility of a) defining common stuff and
> b) being able to do a full build/release/deploy of all modules with one
> command. It does not prevent separate release cycles of the individual
> modules however.
See [2], IMHO all this can be handled better by 'cocoon-complete', or
'cocoon-with-all-blocks-included' m2 project.
Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113102793729171
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113107109911046
Re: [M10N] new repo layout
Posted by Jorg Heymans <jh...@domek.be>.
Vadim Gritsenko wrote:
>
> Separating meaning they are separate projects with independent release
> cycles, as in:
>
>>> Where each block is treated as independent project, and has own
>>> tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
>>> start having own tags.
>>
Perfect, my proposed layout covers this use case. Each block will have
its own release cycle, we can even use the maven release plugin to do
releases. I will experiment with this in the mini repo and document my
findings.
> Yes, I mean why do you want to combine multiple projects into single
> uber project, in your proposed directory structure:
>
> /trunk
> /block-a
> /block-b
>
...
> It seems like a step backward, towards 2.1 situation, where each block
> is part of single project, instead of moving forward and cutting blocks
> loose...
The single root pom has no meaning other than tying the other modules
together and giving us the possibility of a) defining common stuff and
b) being able to do a full build/release/deploy of all modules with one
command. It does not prevent separate release cycles of the individual
modules however.
Regards,
Jorg
Re: [M10N] new repo layout
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> Vadim Gritsenko wrote:
>
>>IIRC, we already have separated out blocks out of the core, into
>>
>> svn:/cocoon/blocks/
>
> separating meaning to move them to a separate directory ? The flat
> layout doesn't mean they aren't separated.
Separating meaning they are separate projects with independent release cycles,
as in:
>>Where each block is treated as independent project, and has own
>>tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
>>start having own tags.
>
> this concept works well with standard maven release management.
>
>
>>Why do you want to reverse this and combine blocks with cocoon core?
>
> you mean combine them into the same directory ? I'm not sure I'm
> following you here - can you elaborate a bit ?
Yes, I mean why do you want to combine multiple projects into single uber
project, in your proposed directory structure:
/trunk
/block-a
/block-b
Instead of having them as independent projects, as of now:
/trunk
/core
/blocks
/a
/trunk
/b
/trunk
It seems like a step backward, towards 2.1 situation, where each block is part
of single project, instead of moving forward and cutting blocks loose...
Vadim
Re: [M10N] new repo layout
Posted by Jorg Heymans <jh...@domek.be>.
Vadim Gritsenko wrote:
>
>
> IIRC, we already have separated out blocks out of the core, into
>
> svn:/cocoon/blocks/
separating meaning to move them to a separate directory ? The flat
layout doesn't mean they aren't separated.
> Where each block is treated as independent project, and has own
> tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
> start having own tags.
this concept works well with standard maven release management.
> Why do you want to reverse this and combine blocks with cocoon core?
you mean combine them into the same directory ? I'm not sure I'm
following you here - can you elaborate a bit ?
thanks
Jorg
Re: [M10N] new repo layout
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Daniel Fagerstrom wrote:
> The current structure with trunk/tags/branches under each block will
> become rather unconvenient as soon as we start to relase and tag things.
>
> Right now you can just check out svn:/cocoon/blocks without any
> problems, but with a number of tags for each blocks you soon get quite a
> lot to check out, then you either need to check out each
> blocks/<name>/trunk separately or we have to provide a directory with
> externals to each block trunk. But that was extremely slow when we tried
> that a while ago.
>
> Read the links in
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112790057318179&w=2 for
> description of a better way to solve it.
I agree with your proposal.
When I had choose a layout during converting our CVS repository to
Subversion I tried hard to find the layout which best fits our needs.
The most significant argument was, that if you choose the layout with
trunk/tags/branches below every module you have to rename the directory
every time you do a checkout (e.g. .../cocoon/trunk has to be checked
out as cocoon). You don't have the convention anymore that checked-out
directory names are identical with the ones in the repository.
If you do it the other way round (.../trunk/cocoon) your life is much
easier (simply 'Checkout as Project' works again in Eclipse ;-).
Additionally you gain another benefit:
If you want to release multiple modules together you can put the tags
for multiple modules under .../tags/<tagname>/<modulename>. This is not
(easily) possible, if every module has it's own trunk/tags/branches
directory.
Some (badly) written build scripts in other projects even depend on the
correct directory name of their submodules...
Andreas
Re: [M10N] new repo layout
Posted by Jorg Heymans <jh...@domek.be>.
Daniel Fagerstrom wrote:
> Block development
> =================
>
> During block development the block can depend on released versions of
> other blocks. This means that you just need to check out the block you
> want to work with, the rest of the blocks are downloaded from a maven
> repository when you compile. This makes development more stable as
> temporary instabilities in other blocks not will affect your development.
This can be enforced through Maven if you use the release plugin : it
will refuse to do the release if your pom has SNAPSHOT dependencies.
> Maybe there is some mechanism in Maven so that you can force it to use
> the current version of all blocks, for those who need to work on several
> blocks in parallell.
You can use version ranges in Maven to tell it to retrieve the highest
version available.
> Releases
> ========
>
> When we release a block it must always depend on other released blocks.
> So when we release a block we will also provide a POM that describe its
> dependencies. The blocks can have independent release cycles.
>
> For covenience we will probably have some distributions in different
> sizes that contain blocks that work together. And when we do more
> important improvements of the core we will probably want to release new
> versions of all important blocks as well. That will be the closest we
> get to a "Cocoon 2.2".
+1
>
> Branches
> ========
>
> I have written many times about why I think that the current situation
> with parallell work on to branches is a waste of effort and that it
> delays release of new functionality and decrease the quality of the
> trunk. I will not repeat the arguments here.
>
> So IMO there should not be a maintainamce branch like 2.2.x in the
> future. Neither should there be a trunk that we don't release anything
> from during several years. For blocks like the core and CForms that we
> do a lot of work on we should do a relase from the trunk every 6-8 weeks.
>
> If we for some reason need a bug fix release for an older release, say
> that the latest cocoon core release from the trunk was 2.3.1 and that we
> want to apply some bugfixes to cocoon core 2.2.3. Then we just copy the
> released cocoon-core 2.2.3 to cocoon/branches do the bugfixing and when
> we have finished them we release a new version by moving it back to
> cocoon/releases and name it cocoon-core-2.2.4.
>
> If someone want to introduce new ideas and experiments in the trunk of
> some block and is afraid that it will destabilize the block then a
> temporary branch in the whiteboard is the way to go. As soon as the new
> ideas have been proven to work well enough in the whiteboard, it is time
> to ask the community if it accept to merge it back to the trunk.
>
> --- o0o ---
>
> So nearly all work and releases will be from the trunk. Dependencies is
> handled at block level and through Maven. Blocks are supposed to depend
> on released blocks.
>
> Branches are supposed to be short lived. Bug fix branches of old
> releases are put in cocoon/branches and new and unproven ideas are put
> into cocoon/whiteboard.
+1 !
Jorg
Re: [M10N] new repo layout
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>
>> I explained about tags above. For branches it depends, quoting Niclas:
>
>
> I understand about tags. Please help me out with branches. Here is
> current situation, in english:
>
> cocoon 2.1 branch depends on cocoon-blocks-xsp 2.1 branch
> cocoon 2.1 branch depends on cocoon-blocks-forms 1.0 branch
>
> cocoon 2.2 branch depends on cocoon-blocks-xsp 2.2 branch
> cocoon 2.2 branch depends on cocoon-blocks-forms 1.0 branch
> cocoon 2.2 branch depends on cocoon-blocks-template 1.0 branch
>
> cocoon trunk depends on cocoon-blocks-xsp trunk
> cocoon trunk depends on cocoon-blocks-forms trunk
> cocoon trunk depends on cocoon-blocks-template trunk
>
> How this can be translated into the svn directories, in your view? I
> can see how standard m2 layout handles it, I don't see how your
> proposed layout can accomodate this.
For 2.1 we should keep it as is and work hard to be able to offer users
a stable enough 2.2.
After 2.1 should IMO see the core and the various blocks as separate
projects. So I'm not certain that it will make sense to talk about a
"cocoon 2.2 branch" anymore. We will rather have a cocoon-core 2.2 and:
cocoon-xsp 2.2 depends on cocoon-core 2.2 (and some other blocks),
etc, rather than the situation above.
Block development
=================
During block development the block can depend on released versions of
other blocks. This means that you just need to check out the block you
want to work with, the rest of the blocks are downloaded from a maven
repository when you compile. This makes development more stable as
temporary instabilities in other blocks not will affect your development.
Gump and hopefully automatically executed tests can keep a look at that
everything still is integratable.
Maybe there is some mechanism in Maven so that you can force it to use
the current version of all blocks, for those who need to work on several
blocks in parallell.
Leting a block depend only on released block might seem like a radical
and possibly overly burocratic way to go. And with our current release
rate it will obviously not work.
But OTH it will give us motvation for releasing much more often.
Releases
========
When we release a block it must always depend on other released blocks.
So when we release a block we will also provide a POM that describe its
dependencies. The blocks can have independent release cycles.
For covenience we will probably have some distributions in different
sizes that contain blocks that work together. And when we do more
important improvements of the core we will probably want to release new
versions of all important blocks as well. That will be the closest we
get to a "Cocoon 2.2".
Branches
========
> (Note: as soon as 2.2 is out we will have to branch it out for
> maintenance and continue 2.3/3.0 development in the trunk. Above shows
> post 2.2 release situation.)
I have written many times about why I think that the current situation
with parallell work on to branches is a waste of effort and that it
delays release of new functionality and decrease the quality of the
trunk. I will not repeat the arguments here.
So IMO there should not be a maintainamce branch like 2.2.x in the
future. Neither should there be a trunk that we don't release anything
from during several years. For blocks like the core and CForms that we
do a lot of work on we should do a relase from the trunk every 6-8 weeks.
If we for some reason need a bug fix release for an older release, say
that the latest cocoon core release from the trunk was 2.3.1 and that we
want to apply some bugfixes to cocoon core 2.2.3. Then we just copy the
released cocoon-core 2.2.3 to cocoon/branches do the bugfixing and when
we have finished them we release a new version by moving it back to
cocoon/releases and name it cocoon-core-2.2.4.
If someone want to introduce new ideas and experiments in the trunk of
some block and is afraid that it will destabilize the block then a
temporary branch in the whiteboard is the way to go. As soon as the new
ideas have been proven to work well enough in the whiteboard, it is time
to ask the community if it accept to merge it back to the trunk.
--- o0o ---
So nearly all work and releases will be from the trunk. Dependencies is
handled at block level and through Maven. Blocks are supposed to depend
on released blocks.
Branches are supposed to be short lived. Bug fix branches of old
releases are put in cocoon/branches and new and unproven ideas are put
into cocoon/whiteboard.
WDYT?
/Daniel
Re: [M10N] new repo layout
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> I explained about tags above. For branches it depends, quoting Niclas:
I understand about tags. Please help me out with branches. Here is current
situation, in english:
cocoon 2.1 branch depends on cocoon-blocks-xsp 2.1 branch
cocoon 2.1 branch depends on cocoon-blocks-forms 1.0 branch
cocoon 2.2 branch depends on cocoon-blocks-xsp 2.2 branch
cocoon 2.2 branch depends on cocoon-blocks-forms 1.0 branch
cocoon 2.2 branch depends on cocoon-blocks-template 1.0 branch
cocoon trunk depends on cocoon-blocks-xsp trunk
cocoon trunk depends on cocoon-blocks-forms trunk
cocoon trunk depends on cocoon-blocks-template trunk
How this can be translated into the svn directories, in your view? I can see how
standard m2 layout handles it, I don't see how your proposed layout can
accomodate this.
(Note: as soon as 2.2 is out we will have to branch it out for maintenance and
continue 2.3/3.0 development in the trunk. Above shows post 2.2 release situation.)
Vadim
Re: [M10N] new repo layout
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> IIRC, we already have separated out blocks out of the core, into
>>>
>>> svn:/cocoon/blocks/
>>>
>>> Where each block is treated as independent project, and has own
>>> tags/branches. With Cocoon 2.1.8 out this friday, several blocks
>>> will start having own tags.
>>
>> The current structure with trunk/tags/branches under each block will
>> become rather unconvenient as soon as we start to relase and tag things.
>
> I would say "unavoidable" rather than inconvenient. Where would you
> put block's tags if not under the tags, then?
A common tags or rather release area. We only use tags for releases, so
it would be clearer to call it releases.
>> Right now you can just check out svn:/cocoon/blocks without any
>> problems, but with a number of tags for each blocks you soon get
>> quite a lot to check out, then you either need to check out each
>> blocks/<name>/trunk separately or we have to provide a directory with
>> externals to each block trunk. But that was extremely slow when we
>> tried that a while ago.
>
> Yes. That was the known issue (iirc i myself brought this up back
> then), and back then it was recognized that svn:externals is only a
> temporary measure.
>
> Having one external per block is too slow, and having one external for
> all blocks is not possible, so IMHO best way is to write simple sh/bat
> file for checking out trunks of all blocks into pre-defined directory
> structure. Even better if maven somehow can help out here... Either
> through standard tools or custom plugin...
Needing to check out a script for chrcking out Cocoon doesn't seem to
increase usability. Not sure that it would work that well with IDEs either.
>> Read the links in
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112790057318179&w=2
>> for description of a better way to solve it.
>
> It essentially proposes [1] to move ttb's up one level. something like
>
> /trunk
> /cocoon
> /blocks
> /axis
> /forms
> /tags
> /cocoon-2.1.8
> /cocoon-axis-1.0
> /cocoon-forms-1.0
> /branches
> /cocoon-2.1
> ...
>
> (note: 'releases' in [1] is 'tags' here)
>
> Why do you think that this structure should work better?
If you want to work on all of Cocoon you just checkout trunk, no need
for scripts or externals. If you want to work on a single block or a few
of them you just check them out.
> I would think that it is much easier to use standard ttb layout and
> let m2 handle each block as separate project, rather than building non
> standard layout.
Jorg says that the layout above works well with m2.
> If I am not mistaken, following should work with m2 right away:
>
> /cocoon-core
> /trunk
> pom.xml
> /cocoon-blocks-axis
> /trunk
> pom.xml
> /cocoon-blocks-forms
> /trunk
> pom.xml
> /cocoon-standard
> /trunk
> pom.xml (references cocoon-core, cocoon-forms, cocoon-template)
> /cocoon
> /trunk
> pom.xml (references all blocks)
>
> So, what do I miss?
See above.
>>> Why do you want to reverse this and combine blocks with cocoon core?
>>
>> It doesn't reverese anything, all blocks under /trunk will be
>> independent projects, their interdependencies are completely
>> described in the respective POMs.
>
> Where tags and brnaches will live?
It is explained in one of the links I asked you to read:
http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/%3c430C3677.5070706@nada.kth.se%3e
I suggest that you read it. Brett Porter of Maven fame says:
http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/%3c9e3862d8050823183447c38b55@mail.gmail.com%3e
about top level trunk.
I explained about tags above. For branches it depends, quoting Niclas:
>Branches are handled differently depending on whether it is an
>"experiment" (in which case it is just copied to my laboratory) or it is
>"maintenance" of released code, in which case I first copy the "release" into
>a temporary area, do the changes and then create a new "release" make
>readonly and so forth.
>
Substitute laboratory with whiteboard above.
/Daniel
Re: [M10N] new repo layout
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>
>> IIRC, we already have separated out blocks out of the core, into
>>
>> svn:/cocoon/blocks/
>>
>> Where each block is treated as independent project, and has own
>> tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
>> start having own tags.
>
> The current structure with trunk/tags/branches under each block will
> become rather unconvenient as soon as we start to relase and tag things.
I would say "unavoidable" rather than inconvenient. Where would you put block's
tags if not under the tags, then?
> Right now you can just check out svn:/cocoon/blocks without any
> problems, but with a number of tags for each blocks you soon get quite a
> lot to check out, then you either need to check out each
> blocks/<name>/trunk separately or we have to provide a directory with
> externals to each block trunk. But that was extremely slow when we tried
> that a while ago.
Yes. That was the known issue (iirc i myself brought this up back then), and
back then it was recognized that svn:externals is only a temporary measure.
Having one external per block is too slow, and having one external for all
blocks is not possible, so IMHO best way is to write simple sh/bat file for
checking out trunks of all blocks into pre-defined directory structure. Even
better if maven somehow can help out here... Either through standard tools or
custom plugin...
> Read the links in
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112790057318179&w=2 for
> description of a better way to solve it.
It essentially proposes [1] to move ttb's up one level. something like
/trunk
/cocoon
/blocks
/axis
/forms
/tags
/cocoon-2.1.8
/cocoon-axis-1.0
/cocoon-forms-1.0
/branches
/cocoon-2.1
...
(note: 'releases' in [1] is 'tags' here)
Why do you think that this structure should work better? I would think that it
is much easier to use standard ttb layout and let m2 handle each block as
separate project, rather than building non standard layout.
If I am not mistaken, following should work with m2 right away:
/cocoon-core
/trunk
pom.xml
/cocoon-blocks-axis
/trunk
pom.xml
/cocoon-blocks-forms
/trunk
pom.xml
/cocoon-standard
/trunk
pom.xml (references cocoon-core, cocoon-forms, cocoon-template)
/cocoon
/trunk
pom.xml (references all blocks)
So, what do I miss?
>> Why do you want to reverse this and combine blocks with cocoon core?
>
> It doesn't reverese anything, all blocks under /trunk will be
> independent projects, their interdependencies are completely described
> in the respective POMs.
Where tags and brnaches will live?
Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112772867005578
Re: [M10N] new repo layout
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Jorg Heymans wrote:
>
>> The concept is the following :
>>
>> /trunk
>> pom.xml
>> /cocoon-core
>> /cocoon-forms-block
>> /cocoon-ajax-block
>> /cocoon-asciiart-block
>
>
> ...
>
>> Please have a look and tell me what you think.
>
>
> IIRC, we already have separated out blocks out of the core, into
>
> svn:/cocoon/blocks/
>
> Where each block is treated as independent project, and has own
> tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
> start having own tags.
The current structure with trunk/tags/branches under each block will
become rather unconvenient as soon as we start to relase and tag things.
Right now you can just check out svn:/cocoon/blocks without any
problems, but with a number of tags for each blocks you soon get quite a
lot to check out, then you either need to check out each
blocks/<name>/trunk separately or we have to provide a directory with
externals to each block trunk. But that was extremely slow when we tried
that a while ago.
Read the links in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112790057318179&w=2 for
description of a better way to solve it.
> Why do you want to reverse this and combine blocks with cocoon core?
It doesn't reverese anything, all blocks under /trunk will be
independent projects, their interdependencies are completely described
in the respective POMs.
/Daniel
Re: [M10N] new repo layout
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> The concept is the following :
>
> /trunk
> pom.xml
> /cocoon-core
> /cocoon-forms-block
> /cocoon-ajax-block
> /cocoon-asciiart-block
...
> Please have a look and tell me what you think.
IIRC, we already have separated out blocks out of the core, into
svn:/cocoon/blocks/
Where each block is treated as independent project, and has own tags/branches.
With Cocoon 2.1.8 out this friday, several blocks will start having own tags.
Why do you want to reverse this and combine blocks with cocoon core?
Vadim