You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2007/01/15 12:08:13 UTC
module naming
We should come up with some agreement on how to name the modules. Right
now it's a little bit messy:
> [INFO] Apache Cocoon ......................................... SUCCESS [6.734s]
> [INFO] Cocoon Core [modules] ................................. SUCCESS [0.078s]
> [INFO] Cocoon Configuration API .............................. SUCCESS [11.859s]
> [INFO] Cocoon Thread API ..................................... SUCCESS [1.360s]
> [INFO] Cocoon Thread Implementation .......................... SUCCESS [2.250s]
> [INFO] Cocoon Util ........................................... SUCCESS [2.782s]
> [INFO] Cocoon Store Implementation ........................... SUCCESS [2.906s]
> [INFO] Cocoon XML API ........................................ SUCCESS [1.328s]
> [INFO] Cocoon XML Implementation ............................. SUCCESS [7.609s]
> [INFO] Cocoon Pipeline API ................................... SUCCESS [20.000s]
> [INFO] Cocoon Pipeline Implementation ........................ SUCCESS [25.641s]
> [INFO] Cocoon Pipeline Components ............................ SUCCESS [40.094s]
> [INFO] Cocoon Spring Configurator ............................ SUCCESS [19.937s]
> [INFO] Cocoon XML Resolver ................................... SUCCESS [10.313s]
> [INFO] Cocoon Sitemap API .................................... SUCCESS [9.469s]
> [INFO] Cocoon Sitemap Implementation ......................... SUCCESS [17.250s]
> [INFO] Cocoon Sitemap Components ............................. SUCCESS [8.515s]
> [INFO] Cocoon Core ........................................... SUCCESS [16.156s]
> [INFO] Cocoon Blocks [modules] ............................... SUCCESS [0.125s]
> [INFO] Ajax Block [modules] .................................. SUCCESS [0.079s]
> [INFO] Ajax Block Implementation ............................. SUCCESS [15.875s]
> [INFO] Ajax Block Sample ..................................... SUCCESS [1.359s]
> [INFO] Cocoon Apples Block [modules] ......................... SUCCESS [0.031s]
> [INFO] Apples Block Implementation ........................... SUCCESS [3.110s]
> [INFO] Flowscript Block [modules] ............................ SUCCESS [0.093s]
> [INFO] Flowscript Block ...................................... SUCCESS [6.469s]
> [INFO] Forms Block [modules] ................................. SUCCESS [0.094s]
> [INFO] Forms Block Implementation ............................ SUCCESS [42.265s]
> [INFO] Core-samples Block [modules] .......................... SUCCESS [0.047s]
> [INFO] Core-samples-main Block Samples ....................... SUCCESS [8.969s]
> [INFO] Template framework [modules] .......................... SUCCESS [0.047s]
> [INFO] Template framework implementation ..................... SUCCESS [8.437s]
> [INFO] Cocoon samples styles [modules] ....................... SUCCESS [0.063s]
> [INFO] Cocoon Tools [modules] ................................ SUCCESS [0.047s]
> [INFO] Cocoon Deployer [modules] ............................. SUCCESS [0.031s]
> [INFO] Cocoon Deployer - Maven 2 Plugin ...................... SUCCESS [9.500s]
> [INFO] Cocoon-samples-style-default .......................... SUCCESS [2.859s]
> [INFO] Apples Block Samples .................................. SUCCESS [2.516s]
> [INFO] Core-samples-additional Block Samples ................. SUCCESS [11.688s]
> [INFO] Forms Block Samples ................................... SUCCESS [15.312s]
> [INFO] Template Block Samples ................................ SUCCESS [0.906s]
> [INFO] Cocoon Licenses ....................................... SUCCESS [8.016s]
> [INFO] Cocoon Commons [modules] .............................. SUCCESS [0.078s]
> [INFO] Cocoon Blocks Framework Implementation ................ SUCCESS [3.781s]
> [INFO] Cocoon Servlet Service Implementation ................. SUCCESS [3.672s]
> [INFO] Cocoon Servlet Service Sample Blocks .................. SUCCESS [3.250s]
> [INFO] Cocoon Webapp ......................................... SUCCESS [17.891s]
> [INFO] Cocoon Archetypes [modules] ........................... SUCCESS [0.281s]
> [INFO] Cocoon 2.2 Block Archetype ............................ SUCCESS [7.344s]
> [INFO] Cocoon 2.2 Webapp Archetype ........................... SUCCESS [1.890s]
> [INFO] Demo of the Cocoon block deployer ..................... SUCCESS [1.688s]
> [INFO] Cocoon Reloading ClassLoader [modules] ................ SUCCESS [0.031s]
> [INFO] Cocoon Reloading ClassLoader - webapp wrapper ......... SUCCESS [5.531s]
> [INFO] Cocoon Reloading Classloader - Maven 2 Plugin ......... SUCCESS [9.438s]
> [INFO] Cocoon Maven Skin ..................................... SUCCESS [2.375s]
> [INFO] Cocoon Distributions [modules] ........................ SUCCESS [0.187s]
--
Leszek Gawron CTO at MobileBox Ltd.
Re: module naming
Posted by Jorg Heymans <jh...@apache.org>.
Mark Lundquist wrote:
> That reminds me, I was wondering about the artifactIds / names of module
> directories in the svn tree... why do they all start w/ "cocoon-"? It
> seems kinda redundant since the groupId is "org.apache.cocoon". I'm
> sure there must have been a reason, I'm just curious what it is :-).
When i setup the initial structure, Continuum had a bug in it whereby it
wouldn't load a module recursively if its directory location <> artifact
id. This would require you to add all modules by hand when setting up
the continuum server.
Regards,
Jorg
Re: module naming
Posted by Jorg Heymans <jh...@apache.org>.
Jason Johnston wrote:
> One possible reason is that the resulting JAR artifacts only contain the
> artifact name (and version), so having the 'redundant' identifier makes
> the JAR file more identifiable once everything's flattened into e.g.
> WEB-INF/lib.
>
That was one of the reasons yes. A <finalName> element could've resolved
this as well though, see my other post about the real reason.
Jorg
Re: module naming
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 15, 2007, at 6:20 PM, Jason Johnston wrote:
> One possible reason is that the resulting JAR artifacts only contain
> the artifact name (and version), so having the 'redundant' identifier
> makes the JAR file more identifiable once everything's flattened into
> e.g. WEB-INF/lib.
I think that's it (I'd been trying to remember from some previous
discussion...). A <prefix> configuration element for the jar plugin
would be nice.
thx,
—ml—
Re: module naming
Posted by Jason Johnston <co...@lojjic.net>.
Mark Lundquist wrote:
>
> On Jan 15, 2007, at 3:08 AM, Leszek Gawron wrote:
>
>> We should come up with some agreement on how to name the modules.
>
> That reminds me, I was wondering about the artifactIds / names of module
> directories in the svn tree... why do they all start w/ "cocoon-"? It
> seems kinda redundant since the groupId is "org.apache.cocoon". I'm
> sure there must have been a reason, I'm just curious what it is :-).
One possible reason is that the resulting JAR artifacts only contain the
artifact name (and version), so having the 'redundant' identifier makes
the JAR file more identifiable once everything's flattened into e.g.
WEB-INF/lib.
>
> Also it occurs to me that "org.apache.cocoon.core" and
> "org.apache.cocoon.blocks" could be used as groupIds if that were
> thought to help make things clearer...
>
> —ml—
>
Re: module naming
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 15, 2007, at 3:08 AM, Leszek Gawron wrote:
> We should come up with some agreement on how to name the modules.
That reminds me, I was wondering about the artifactIds / names of
module directories in the svn tree... why do they all start w/
"cocoon-"? It seems kinda redundant since the groupId is
"org.apache.cocoon". I'm sure there must have been a reason, I'm just
curious what it is :-).
Also it occurs to me that "org.apache.cocoon.core" and
"org.apache.cocoon.blocks" could be used as groupIds if that were
thought to help make things clearer...
—ml—