> So you are not only interested by Nuxeo Runtime, but you are willing > to use other components, right? > Could you share some details about your application's scope/goals? In > which components are you interested in (if it's not the whole > platform of course)?
Sure, just bear in mind that I'm not really making any official representation on this - it's more my personal view of potential overlap and collaboration possibilities, although I am trying to get others to think about and discuss this. The project is DSpace - an open source digital preservation / institutional repository project written in Java. Although the goals are somewhat different, many of the problems of storage, retrieval, transformation, workflow management share a lot of similarities. Therefore we may make a lot of the same decisions when relying on outside specifications and technologies (ie. OSGi, JCR, jBPM, etc.), even if we weren't building on (and contributing to) your codebase. So, there is quite a lot - potentially the whole infrastructure of the enterprise platform (if not the same data model, to whatever extent they can be separate) - that could be useful. But specifically the focus that I came away from the architecture meeting with was frameworks and modularization, ie. OSGi or Spring. And although OSGi in general seems preferable, and the direct integration of an OSGi platform feasible, I at least think your Runtime components provide some very useful additional features that more closely align to our intentions of modularization than simply going it alone. > Is that a requirement for you to be able to run your application > without a Java EE application server or you just do not want ot use > JBoss? The current application/distribution runs as on 'any' servlet container (not sure what spec we support as a minimum). We don't have any other EE container usage. We do have an explicit goal that it should have an easy/minimal setup capability - although setting up JBoss *instead* of Tomcat doesn't really break that wish, and we could even have something similar to the EP RC2 installer that you distribute. But, most of our existing users will have installations on Tomcat, and we wouldn't want to mandate those into moving to a different server. Also, having JBoss as the *only* server platform would be / is seen as a problem. But combining a servlet/OSGi bridge and Runtime would solve both those issues, and allow the future possibility of hosting components in alternative environments - be it JBoss, or Eclipse RCP, or something else - as and when it is required (and which IMHO, is a significant advantage compared to anything we've been discussing). > Definitely. For the flexible deployment, we need to study if Equinox > can provide a hook to register a custom deployer. If yes, we could > port our JBoss deployer to Equinox and allow the same flexibility on > JBoss and on Equinox. Hmmm... possibly. An OSGi provider (or even custom code) within an application can manage dynamic loading/unloading/deploying. But as long as you bundled your application into a WAR and deployed that to the servlet container, the original, unmodified WAR would still be sitting around inside the container, and could potentially cause problems later on. G This email has been scanned by Postini. For more information please visit http://www.postini.com _______________________________________________ ECM mailing list [email protected] http://lists.nuxeo.com/mailman/listinfo/ecm
