Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: Jorg Heymans <jh@domek.be>
Subject: Re: Changes in trunk after cleanup + what else needs to be done
Date: Thu, 30 Mar 2006 23:37:54 +0200
Lines: 64
Message-ID: <e0hj1t$ksd$1@sea.gmane.org>
References: <442BEFCB.1020606@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
In-Reply-To: <442BEFCB.1020606@apache.org>
Sender: news <news@sea.gmane.org>


Reinhard Poetz wrote:

> 
> The blocks conversion script by Andreas was very helpful and 
> certainly saved a lot of time. One thing that we would need is a 
> script that moves all resources from src/main/java to 
> src/main/resources. Could some bash-guru out there take care of it 
> please?

i used some oneliner with find a while ago when i did the initial
conversion, i'll see if i can dig it up again.

> I used the version "x-SNAPSHOT" for all pom-modules. Pom-modules are 
> modules that don't generate an artifact but are only used within the 
> build system. I used the "x" as version to show that this is *not* a 
> usual version number. Up-to-now the version number was 2.2.0 which 
> isn't correct as we can start to have separate release cycles for 
> modules soon!

The idea behind versioning the multi-module poms (or pom-modules as you
call them) is that you can effectively have different parent poms for
different module releases. At the moment we don't use the multi-module
poms for anything else but declaring the different modules (except for
the root pom). At some point however we might decide to put some more
information in there that is common to all sub-modules of a module (eg
extra <build> that is only needed from that version onwards), and that's
where the versioning comes in handy.

> Though I'm not sure if this is a good idea to use a letter and not a 
> number. Jorg (and others), WDYT? Would something like "x1" be better?

....... checking maven repo and #maven ........

<quote who="John Casey">
Poms that do not participate in the release cycle of the application can
carry a singledigit version (or "serialnumber" as they call it) to
distinguish the fact that they are "special".
</quote>

Based upon this i would suggest:
- we start all multi-module poms for the blocks at version 1-SNAPSHOT.
- core/pom.xml should follow the current development version ie
2.2.0-SNAPSHOT (or whatever version number we decide to assign to the
next release).

(if all this is not clear let me know i'll clarify with an example)

> I wonder what reasons could cause a version number change there ...

see above about versioning.


> One very important thing: Can somebody take care of the unit-tests of
>  cocoon-core? I got 79 errors and 2 failurs. Either we throw the 
> failing tests away or fix them. Carsten, WDYT?

I'll have a look at this.


Regards,
Jorg

PS And *thanks* for the great work !