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 Pötz <re...@gmx.net> on 2006/03/20 12:47:55 UTC
Cleanup trunk directory structure
As we are at it to mavenize the missing blocks, we should also cleanup trunk
which is quite a mess. I propose following structure
cocoon/trunk
+- blocks
| +- cocoon-apples
| +- ...
+- core
| +- cocoon-core <-- will finally go completly into blocks but that needs
| more refactoring
| +- cocoon-blocks-fw
+- tools
| +- archetypes
| +- cocoon-deployer
| +- daisy-plugin
| +- sitemap-tags-2daisy
+- site
+- common (legal stuff, awards, graphics, ...)
WDOT?
--
Mag. (FH) Reinhard Pötz Beratung, Training, Coaching
web(log): http://www.poetz.cc mail: contact@poetz.cc
mobile: +43-(0)664-4544829 fax: +49-(0)89-1488-289439
-----------------------------------------------------------------------
Re: Cleanup trunk directory structure
Posted by Jorg Heymans <jh...@domek.be>.
Reinhard Poetz wrote:
> thanks for the hint.
>
> Where do we have our Continuum instance running? How can I get acces to it?
>
I've created a link on the zone home page.
Best way to experiment with this is to install continuum locally though.
It really is just a matter of unzipping, starting, follow the initial
configuration screen and adding the URL to our root pom as maven2 project.
I've upgraded the instance to 1.0.3-SNAPSHOT over the weekend, it still
needs a bit of work. Feel free to play around with it though, there is
nothing you can break by clicking around.
Regards
Jorg
Re: Cleanup trunk directory structure
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> Reinhard Pötz wrote:
>
>
>>cocoon/trunk
>> +- blocks
>> | +- cocoon-apples
>> | +- ...
>> +- core
>> | +- cocoon-core <-- will finally go completly into blocks but that
>>needs
>> | more refactoring
>> | +- cocoon-blocks-fw
>> +- tools
>> | +- archetypes
>> | +- cocoon-deployer
>> | +- daisy-plugin
>> | +- sitemap-tags-2daisy
>> +- site
>> +- common (legal stuff, awards, graphics, ...)
>>
>
>
> Whatever refactoring you do, please make sure that the pom structure is
> consistent with continuum. This basically means you should create a
> blocks/pom.xml with all blocks etc - same for core/pom.xml and
> tools/pom.xml. Otherwise you will need to modify each pom with an <scm>
> element for it to work under continuum.
>
> The easiest way to test this yourself first is to add only the root pom
> as an m2 project in continuum and see if maven recursively finds all
> blocks from there.
>
> If you need help with this let me know.
thanks for the hint.
Where do we have our Continuum instance running? How can I get acces to it?
--
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: Cleanup trunk directory structure
Posted by Jorg Heymans <jh...@domek.be>.
Reinhard Pötz wrote:
> cocoon/trunk
> +- blocks
> | +- cocoon-apples
> | +- ...
> +- core
> | +- cocoon-core <-- will finally go completly into blocks but that
> needs
> | more refactoring
> | +- cocoon-blocks-fw
> +- tools
> | +- archetypes
> | +- cocoon-deployer
> | +- daisy-plugin
> | +- sitemap-tags-2daisy
> +- site
> +- common (legal stuff, awards, graphics, ...)
>
Whatever refactoring you do, please make sure that the pom structure is
consistent with continuum. This basically means you should create a
blocks/pom.xml with all blocks etc - same for core/pom.xml and
tools/pom.xml. Otherwise you will need to modify each pom with an <scm>
element for it to work under continuum.
The easiest way to test this yourself first is to add only the root pom
as an m2 project in continuum and see if maven recursively finds all
blocks from there.
If you need help with this let me know.
Regards
Jorg
Re: Cleanup trunk directory structure
Posted by Antonio Gallardo <ag...@agssa.net>.
Antonio Gallardo wrote:
> Reinhard Poetz wrote:
>
>> Jorg Heymans wrote:
>>
>>> Antonio Gallardo wrote:
>>>
>>>
>>>> I know, but IIRC Giacomo told the directory name is not important for
>>>> jar generation since there is a directive in pom.xml to change the jar
>>>> name. Looking at the current trunk the "cocoon-" prefix create a
>>>> lot of
>>>> "noise". And this is why I am asking again if this is the best way we
>>>> can go. ;-)
>>>>
>>>
>>>
>>> Yes <finalName/> allows you to control the artifact name.
>>>
>>> The reason why we've named these directories was that in continuum
>>> there
>>> is a mapping between the module name and the repository directory name.
>>>
>>> So if you declare in a top level module pom
>>>
>>> <modules>
>>> <module>cocoon-apples</module>
>>> </modules>
>>>
>>> and
>>>
>>> <scm>
>>> <connection>scm:svn:http://repo/trunk</connection>
>>> </scm>
>>>
>>> then continuum will resolve the checkout path for moduleA as
>>> http://repo/trunk/cocoon-apples.
>>>
>>> Now at the time i did not take the possibility of using <finalName/>
>>> into account. Advice from the maven guys was
>>> module-name=module-location
>>> so that's what i went for.
>>>
>>> I suggest that before we decide to go for this approach, someone
>>> experiments with this layout and tests continuum and eclipse-plugin
>>> integration (they are the most picky with module poms) and reports back
>>> before we start another mass rename.
>>>
>>> Either way i'm not too bothered at all by a repo structure with
>>> "noise".
>>> Maven is there to help you not having to look at the repo structure in
>>> it's totality.
>>
>>
>>
>> In one of my projects we had problems when artifactId and directory
>> name were different, now I remember.
>>
>> I hesitate to change it as "working against the system or
>> recommendations" can be very frustrating and after daily using M2 for
>> about 3 months I know that it's best to follow every recommendation
>> that you can get. Often when I tried something different (e.g. not
>> putting the Java sources into ./src/main/java but somewhere else
>> causes problems in some reporting plugins) I got problems.
>>
>> Can somebody ask a M2 expert (IRC, dev@maven, etc), if it is really
>> save to use the <finalName/> element for JAR artifacts?
>
>
> Not necesary. Please keep the current hierachy with the "cocoon-"
> prefix. We have a lot of others things to do, hence keep moving. Later
> we can get back and improve this issue if we found it necesary at all.
> ;-)
The reply seems to be no clear: I meant your suggested cleanup dir
structure enhancement is ok. I am +1 for the change. :-)
Best Regards,
Antonio Gallardo.
Re: Cleanup trunk directory structure
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Poetz wrote:
> Jorg Heymans wrote:
>
>> Antonio Gallardo wrote:
>>
>>
>>> I know, but IIRC Giacomo told the directory name is not important for
>>> jar generation since there is a directive in pom.xml to change the jar
>>> name. Looking at the current trunk the "cocoon-" prefix create a lot of
>>> "noise". And this is why I am asking again if this is the best way we
>>> can go. ;-)
>>>
>>
>>
>> Yes <finalName/> allows you to control the artifact name.
>>
>> The reason why we've named these directories was that in continuum there
>> is a mapping between the module name and the repository directory name.
>>
>> So if you declare in a top level module pom
>>
>> <modules>
>> <module>cocoon-apples</module>
>> </modules>
>>
>> and
>>
>> <scm>
>> <connection>scm:svn:http://repo/trunk</connection>
>> </scm>
>>
>> then continuum will resolve the checkout path for moduleA as
>> http://repo/trunk/cocoon-apples.
>>
>> Now at the time i did not take the possibility of using <finalName/>
>> into account. Advice from the maven guys was module-name=module-location
>> so that's what i went for.
>>
>> I suggest that before we decide to go for this approach, someone
>> experiments with this layout and tests continuum and eclipse-plugin
>> integration (they are the most picky with module poms) and reports back
>> before we start another mass rename.
>>
>> Either way i'm not too bothered at all by a repo structure with "noise".
>> Maven is there to help you not having to look at the repo structure in
>> it's totality.
>
>
> In one of my projects we had problems when artifactId and directory
> name were different, now I remember.
>
> I hesitate to change it as "working against the system or
> recommendations" can be very frustrating and after daily using M2 for
> about 3 months I know that it's best to follow every recommendation
> that you can get. Often when I tried something different (e.g. not
> putting the Java sources into ./src/main/java but somewhere else
> causes problems in some reporting plugins) I got problems.
>
> Can somebody ask a M2 expert (IRC, dev@maven, etc), if it is really
> save to use the <finalName/> element for JAR artifacts?
Not necesary. Please keep the current hierachy with the "cocoon-"
prefix. We have a lot of others things to do, hence keep moving. Later
we can get back and improve this issue if we found it necesary at all. ;-)
Best Regards,
Antonio Gallardo.
Re: Cleanup trunk directory structure
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> Antonio Gallardo wrote:
>
>
>>I know, but IIRC Giacomo told the directory name is not important for
>>jar generation since there is a directive in pom.xml to change the jar
>>name. Looking at the current trunk the "cocoon-" prefix create a lot of
>>"noise". And this is why I am asking again if this is the best way we
>>can go. ;-)
>>
>
>
> Yes <finalName/> allows you to control the artifact name.
>
> The reason why we've named these directories was that in continuum there
> is a mapping between the module name and the repository directory name.
>
> So if you declare in a top level module pom
>
> <modules>
> <module>cocoon-apples</module>
> </modules>
>
> and
>
> <scm>
> <connection>scm:svn:http://repo/trunk</connection>
> </scm>
>
> then continuum will resolve the checkout path for moduleA as
> http://repo/trunk/cocoon-apples.
>
> Now at the time i did not take the possibility of using <finalName/>
> into account. Advice from the maven guys was module-name=module-location
> so that's what i went for.
>
> I suggest that before we decide to go for this approach, someone
> experiments with this layout and tests continuum and eclipse-plugin
> integration (they are the most picky with module poms) and reports back
> before we start another mass rename.
>
> Either way i'm not too bothered at all by a repo structure with "noise".
> Maven is there to help you not having to look at the repo structure in
> it's totality.
In one of my projects we had problems when artifactId and directory name were
different, now I remember.
I hesitate to change it as "working against the system or recommendations" can
be very frustrating and after daily using M2 for about 3 months I know that it's
best to follow every recommendation that you can get. Often when I tried
something different (e.g. not putting the Java sources into ./src/main/java but
somewhere else causes problems in some reporting plugins) I got problems.
Can somebody ask a M2 expert (IRC, dev@maven, etc), if it is really save to use
the <finalName/> element for JAR artifacts?
--
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: Cleanup trunk directory structure
Posted by Jorg Heymans <jh...@domek.be>.
Antonio Gallardo wrote:
> I know, but IIRC Giacomo told the directory name is not important for
> jar generation since there is a directive in pom.xml to change the jar
> name. Looking at the current trunk the "cocoon-" prefix create a lot of
> "noise". And this is why I am asking again if this is the best way we
> can go. ;-)
>
Yes <finalName/> allows you to control the artifact name.
The reason why we've named these directories was that in continuum there
is a mapping between the module name and the repository directory name.
So if you declare in a top level module pom
<modules>
<module>cocoon-apples</module>
</modules>
and
<scm>
<connection>scm:svn:http://repo/trunk</connection>
</scm>
then continuum will resolve the checkout path for moduleA as
http://repo/trunk/cocoon-apples.
Now at the time i did not take the possibility of using <finalName/>
into account. Advice from the maven guys was module-name=module-location
so that's what i went for.
I suggest that before we decide to go for this approach, someone
experiments with this layout and tests continuum and eclipse-plugin
integration (they are the most picky with module poms) and reports back
before we start another mass rename.
Either way i'm not too bothered at all by a repo structure with "noise".
Maven is there to help you not having to look at the repo structure in
it's totality.
Regards
Jorg
Re: Cleanup trunk directory structure
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Poetz wrote:
> Antonio Gallardo wrote:
>
>> Reinhard Pötz wrote:
>>
>>>
>>> As we are at it to mavenize the missing blocks, we should also
>>> cleanup trunk which is quite a mess. I propose following structure
>>>
>>> cocoon/trunk
>>> +- blocks
>>> | +- cocoon-apples
>>> | +- ...
>>> +- core
>>> | +- cocoon-core <-- will finally go completly into blocks but
>>> that needs
>>> | more refactoring
>>> | +- cocoon-blocks-fw
>>> +- tools
>>> | +- archetypes
>>> | +- cocoon-deployer
>>> | +- daisy-plugin
>>> | +- sitemap-tags-2daisy
>>> +- site
>>> +- common (legal stuff, awards, graphics, ...)
>>>
>>> WDOT?
>>>
>> +1.
>>
>> Question: Why "cocoon-apples"? Should not be easy to use just "apples"?
>
>
> This question was raised a couple of weeks ago and Jorg answered it,
> but I can't find a pointer.
>
> IIRC there are some reasons for it:
>
> - naming of the artifact --> cocoon-apples-1.0.jar instead of
> apples-1.0.jar
> - it is recommended by the M2 folks
> - ... there was more, but can't remember, Jorg can you?
>
I know, but IIRC Giacomo told the directory name is not important for
jar generation since there is a directive in pom.xml to change the jar
name. Looking at the current trunk the "cocoon-" prefix create a lot of
"noise". And this is why I am asking again if this is the best way we
can go. ;-)
WDYT?
Best Regards,
Antonio Gallardo.
Re: Cleanup trunk directory structure
Posted by Reinhard Poetz <re...@apache.org>.
Antonio Gallardo wrote:
> Reinhard Pötz wrote:
>
>>
>> As we are at it to mavenize the missing blocks, we should also cleanup
>> trunk which is quite a mess. I propose following structure
>>
>> cocoon/trunk
>> +- blocks
>> | +- cocoon-apples
>> | +- ...
>> +- core
>> | +- cocoon-core <-- will finally go completly into blocks but
>> that needs
>> | more refactoring
>> | +- cocoon-blocks-fw
>> +- tools
>> | +- archetypes
>> | +- cocoon-deployer
>> | +- daisy-plugin
>> | +- sitemap-tags-2daisy
>> +- site
>> +- common (legal stuff, awards, graphics, ...)
>>
>> WDOT?
>>
> +1.
>
> Question: Why "cocoon-apples"? Should not be easy to use just "apples"?
This question was raised a couple of weeks ago and Jorg answered it, but I can't
find a pointer.
IIRC there are some reasons for it:
- naming of the artifact --> cocoon-apples-1.0.jar instead of apples-1.0.jar
- it is recommended by the M2 folks
- ... there was more, but can't remember, Jorg can you?
--
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: Cleanup trunk directory structure
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Pötz wrote:
>
> As we are at it to mavenize the missing blocks, we should also cleanup
> trunk which is quite a mess. I propose following structure
>
> cocoon/trunk
> +- blocks
> | +- cocoon-apples
> | +- ...
> +- core
> | +- cocoon-core <-- will finally go completly into blocks but
> that needs
> | more refactoring
> | +- cocoon-blocks-fw
> +- tools
> | +- archetypes
> | +- cocoon-deployer
> | +- daisy-plugin
> | +- sitemap-tags-2daisy
> +- site
> +- common (legal stuff, awards, graphics, ...)
>
> WDOT?
>
+1.
Question: Why "cocoon-apples"? Should not be easy to use just "apples"?
Best Regards,
Antonio Gallardo.
Re: Cleanup trunk directory structure
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Pötz skrev:
>
> As we are at it to mavenize the missing blocks, we should also cleanup
> trunk which is quite a mess. I propose following structure
>
> cocoon/trunk
> +- blocks
> | +- cocoon-apples
> | +- ...
> +- core
> | +- cocoon-core <-- will finally go completly into blocks but that
> needs
> | more refactoring
> | +- cocoon-blocks-fw
> +- tools
> | +- archetypes
> | +- cocoon-deployer
> | +- daisy-plugin
> | +- sitemap-tags-2daisy
> +- site
> +- common (legal stuff, awards, graphics, ...)
>
> WDOT?
+1
/Daniel