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: OCM: is project alive?
Date Thu, 01 May 2008 08:18:06 GMT
Hi Alex,

I'm still using OCM here but there are some problems with the SVN Apache
server. So, I will commit as soon as possible.

I don't know if other projects are using it. It should be nice to have this
kind of information.

Last week, I made some simplifications on how to manage Collection and Map.
Now, I'm reviewing the Spring support thanks to the work made by others.
I'm going to  add more tutorials, more code simplifications and bug fix in
the upcoming weeks. After that, it will be the good time to work on a cache
support and maybe see the possibilities to support  JPA (at least for the
main annotations like @Entity and a part of the API).

Feel free to suggest simplifications. If you add them into Jira, I will take
them in account. Patch are also welcome. Nevertheless, we need more
committers on this project.


Sorry for the compile error, I will check it. I'm busy with other
activities.
I will ask to Jukka if it is possible to add OCM into Hudson.


br,
Christophe



On Thu, May 1, 2008 at 8:01 AM, Alex Lukin <lukin@stu.cn.ua> wrote:

> Hi, All!
>
> There's no commits in jackrabbit-ocm package for a long time and it does
> not compile after commit of jackrabbit security classes.
> Fix is trivial but question is not in fixing code.
> I'm starting another jackrabit-based project with OCM and I'd like to know
> what is going on with project.
>
> Is OCM still supported? Will it be fully integrated in jackrabbit build
> and release system? Are developers still in the team?
>
> I ought to say that OCM is very important part of jackrabbit project
> because it simplifies and speeds up development and just makes
> life easier.
>
> BTW, there's another implementation of OCM called JCROM (
> http://code.google.com/p/jcrom/) that moves forward very quickly, easier
> and better documented,
> but I just do not want use different implementations in my projects.
>
> --
> SY, Alex Lukin
> RIPE NIC HDL: LEXA1-RIPE
>

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