Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.198.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=PgXu5pD14Dy8r+wQI07ud7RBq3Xzru7T4aMcLxVPP8l6h2S70XACYZg6DAa6cBMHjSflVRJ8XmtD/Yq7i0awVgH0EApNHR4fuDN9FqrL1kHo7xJLk5hwsrvwe3ZUSaS66PpLIcCF6KkCBDyh2HC6R4rTh+4Gaq91tjykLlZrMFI=
Message-ID: <510143ac0709210103u48c73672i300a4d6d3b0059fd@mail.gmail.com>
Date: Fri, 21 Sep 2007 11:03:45 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: coming back on the OCM reorg
In-Reply-To: <f767f0600709210051y6f44048an35fb51abb856156c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3b728ee90709201303n15028d14y879d9942a03ff152@mail.gmail.com>
	 <f767f0600709210026m12e84a31n556305252427312@mail.gmail.com>
	 <3b728ee90709210045y5b5f620axf577360b38b993ae@mail.gmail.com>
	 <f767f0600709210051y6f44048an35fb51abb856156c@mail.gmail.com>

Hi,

On 9/21/07, Bertrand Delacretaz <bdelacretaz@apache.org> wrote:
> On 9/21/07, Christophe Lombart <christophe.lombart@gmail.com> wrote:
> > On 9/21/07, Bertrand Delacretaz <bdelacretaz@apache.org> wrote:
> > > ...The obvious suggestion would be to drop java 1.4 support for the OCM,...
>
> > ...Even if the OCM is moving outside the contrib area, why not to make a
> > separate build process ?...
>
> I don't think it needs to be completely separate, a few different
> settings in the POMs would probably do. But I'm not the right person
> to talk about this, others here know the current build process and
> roadmap much better than I do.

I typically do the release builds on JDK 1.4 to make sure I catch any
references to new methods in the Java 5 class libraries (the POM
options only cover the language features), so from that perspective
keeping a Java 5 OCM out of the standard build would make sense.

I'd still have jackrabbit-ocm on the same directory level and with a
similar POM (i.e. referencing the same parent POM) as the other
release components, but I wouldn't include it in the normal
multimodule build.

Using Java 5 as the baseline for OCM would also remove the strict
requirement for placing the different mapping mechanisms in different
components, so I'd actually advocate using Java 5 and putting all the
mappings in the same main component.

BR,

Jukka Zitting