JSR-170 successfully passes Final Approval Ballot

Home

News: JSR-170 successfully passes Final Approval Ballot

  1. As the Spec-Lead of JSR-170, I am happy to report on behalf of the Expert Group that the Executive Committee of the JCP approved the Content Repository API for Java Technology. After over three years of a very productive collaboration in the Expert Group the final release is expected shortly.

    The final approval of this Specification marks the beginning of a new era for the "Content Industry" since it will allow for the first time to truly compare functionality and performance of Content Repositories and also allows application developers to leverage actual content repository infrastructure. This means that application developers will no longer have to implement services such as versioning, fulltext-search or locking themselves but can use a standardized API to interact with any open-source or commercial content repository.

    As far as I know this is the first JSR to be entirely licensed with an Apache-style license including the Technology Compatibility Kit (TCK) and the Reference Implementation (RI), which should allow for a painless adoption.

    If you would like to see what a content repository can do for you, take a look at the Apache Jackrabbit Project (currently in incubation) http://incubator.apache.org/jackrabbit or just have a quick look at a public content repository in action at http://jcr.day.com.

    **Editors Note:** See also an article on Jackrabbit and JCR on artima.com.

    Threaded Messages (6)

  2. Nice news.

    I have developed a desktop based document mangement system, called jLibrary (http://jlibrary.sourceforge.net). jLibrary is Open Source. It uses several successful open source projects like Lucene (indexation), PDFBox/POI/Multivalent PDF Tools/textmining (text extraction), Hibernate(persistence/transaction management),EHCache(2nd level caché),Axis(Web Services API), ...

    jLibrary includes a standalone server, and a client developed with Eclipse Rich Client Platform. I don't want to bore you with the details, you can check the web documentation (http://jlibrary.sourceforge.net) to find more information. I think there are enough details there.

    Well, the case is that I would like to create a JSR-170 driver to obtain two things:

    1 - Be able to use jLibrary to access to any JSR-170 compatible repository.
    2 - Be able to expose jLibrary repositories to any other JSR-170 compatible tool.

    It won't be a very difficult task, but I don't have time to tackle this problem only by myself. So if anyone is interested on learning this spec., and is interesting on jLibrary, we could work together to get this ahead.

    Regards,
    Martin
    mpermar@gmail.com
  3. sounds interesting, maybe the codebase of jackrabbit can be helpful to give you a quick start...

    regards,
    david
  4. Sure there is[ Go to top ]

    Sure David. jackrabbit could be a very good base for a jLibrary JSR-170 adapter.

    I hope that with some time and help we could get something ahead.
  5. First, a big congratulation to David, you can now take some vacations

    On our side (eXo JCR), we will try to pass the TCK tests as soon as possible. Having several early repository implementations (moreovr open source) to use or to test your application should help the quick adoption of the specification.
    Well, the case is that I would like to create a JSR-170 driver to obtain two things:1 - Be able to use jLibrary to access to any JSR-170 compatible repository.

    That should be easy as almost all JCR implementation will provide an easy way through JNDI to lookup the repository. Then the manipulation on the repository are done through the API
    2 - Be able to expose jLibrary repositories to any other JSR-170 compatible tool.It won't be a very difficult task, but I don't have time to tackle this problem only by myself. So if anyone is interested on learning this spec., and is interesting on jLibrary, we could work together to get this ahead.

    That will be much more work as the spec does not define the interfaces that will be used to map to real storages like filesystem, RDBM or in your case jlibrary. In other words to make jLibrary viewable as a JSR 170 tree you will need to provide one driver for each JCR implementation. Of course the interface methods should be close and the code reusable but at least I prefer to tell you the challenge :)

    Benjamin Mestrallet
    http://www.exoplatform.com
  6. A challenge, maybe.[ Go to top ]

    Thanks for the tips Benjamin.

    Well, I believe you when you say that it could be a difficult task. You have more experience with JSR-170 stuff.

    Anyway, as Jlibrary has its own repository storage system (remember that jLibrary is a client but is also a server -filesystem based), I think that I would only have to create a JSR-170 complicance driver over that implementation. Other products, able to access to generic JSR-170 repositories, should use that driver to access jLibrary information. Am I wrong?
  7. A challenge, maybe.[ Go to top ]

    Anyway, as Jlibrary has its own repository storage system (remember that jLibrary is a client but is also a server -filesystem based), I think that I would only have to create a JSR-170 complicance driver over that implementation. Other products, able to access to generic JSR-170 repositories, should use that driver to access jLibrary information. Am I wrong?

    You are correcct, in fact I probably misunderstood your point 2. I was thinking that you would like to make your product as the backend storage of several JCR implementations.

    But your work will not be that easy either as making a maping of JSR 170 to your implementation may require some time. This is basically what most of the companies that already have a content repository will do.