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 christophe.lombart@gmail.com
 designates 64.233.182.191 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:references;
        b=IcoM5EtURDvtroyZt7j29+UsC46adKXHTxEIxvTw9G3yEcHDNqomA8bmBV63dvpLm9Rl0tYQ+LlGtmNN8mAV2qA452qvzIHNT8MWFnpcFd4uoNHqo0Sz1Y5XuiB3cYzDjnLklkY9S2edYp8jAjQnTvRHypIA/8cURcWFT9htTCA=
Message-ID: <3b728ee90709210526q36de458by88dfc8e2ceb63164@mail.gmail.com>
Date: Fri, 21 Sep 2007 14:26:17 +0200
From: "Christophe Lombart" <christophe.lombart@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: coming back on the OCM reorg
In-Reply-To: <510143ac0709210103u48c73672i300a4d6d3b0059fd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_44412_18276402.1190377577164"
References: <3b728ee90709201303n15028d14y879d9942a03ff152@mail.gmail.com>
	 <f767f0600709210026m12e84a31n556305252427312@mail.gmail.com>
	 <3b728ee90709210045y5b5f620axf577360b38b993ae@mail.gmail.com>
	 <f767f0600709210051y6f44048an35fb51abb856156c@mail.gmail.com>
	 <510143ac0709210103u48c73672i300a4d6d3b0059fd@mail.gmail.com>

------=_Part_44412_18276402.1190377577164
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/21/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>
> 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.


ok

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.


ok. It will simplify the ocm project structure but even if you are using the
annotations, the core will depend on the digester jars.
For me, this could be a tempory situation and see later depending on the
mapper usages.


BR,
>
> Jukka Zitting
>

------=_Part_44412_18276402.1190377577164--