jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: coming back on the OCM reorg
Date Fri, 21 Sep 2007 12:26:17 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message