Hi, >Those cases should probably be fixed.
OK, for those who say they should be fixed, please go ahead and do it. It would be really good if it's fixed. My point is: I think it's not yet fixed because it's complicated. And it's complexity that has no visible advantage (not for the end user, and not for the developer). And it has many disadvantages. For example, it slows down development. > But I don't think there are too many >projects inside Jackrabbit. So a single class project / jar file is desirable? >Compare it to Apache Sling I don't know Sling very well, but I don't think you can compare Jackrabbit with Sling. I believe more appropriate are Apache Lucene, Apache Derby, HSQLDB, and H2. Those are all "single project" projects AFAIK. >OSGi helps there. I don't think we can force users of Jackrabbit to use OSGi. >Forcing ... separation ... due to separate modules helps There are better ways to write clean code than to split things into many tiny projects. Specially, if 95% of all users don't care about the split. >It might be good to let Jackrabbit 3 >concentrate on the internal persistence architecture and not on >web-interfaces or remoting. +1 Regards, Thomas
