OpenEdit Developer Forum

Welcome to the OpenEdit User Forum.

You must be registered and logged in to post a new comment or topic.

This forum is only for developers who want to discuss the technical aspects of the OpenEdit Framework.

For end user technical support please visit the EnterMedia web site.

Preferred procedure

Hi all,

I have spent the weekend reading sources and figuring out how the CVS projects are organized. And I have hopefully a correct idea on how that all works now:

   * The CVS projects are very much tailored for OpenEdit's own
     distribution and update methods
   * They need modification to set up a "project local" distribution site

In general, for smaller projects I would say that a customer project could be organized as a plugin app and the OpenEdit system can be just used as is. In the type of project like I am currently working on (large distributed eCommerce system) I envision the need for a more elaborate scheme:

   * We may need to change and/or add editor behavior
   * If we use the eCommerce plugin we may need to change aspects of
     that too
   * We will have to add customer and site specific plugins etc.
   * In general we need an abstraction from the evolving OpenEdit code
     to incorporate, maintain and merge project specific changes.
   * To accomplish this I think we need to have a situation where the
     customer upgrades apps against a project specific site and not
     against OpenEdit.
   * Yet those updates etc must also incorporate merged OpenEdit updates.
   * Sort of a two stage rocket :-)

The question now is: Is there a preferred procedure from OpenEdit to accomplish this or do we have to create one ourselves?

Thanks in advance,

Peter Friebel

Irritum IdreData

Hi, You might consider hosting your own OE plug-in server. You just need to define the openeditpluginserverpath property in your /openedit/update/plugins/ directory.

Right now the default value is this: http://www.openedit.org/plugins/allplugins.xml

What we hope is that you will not fork any Java code. Since we allow a plugin to override any HTML or Spring Bean then you should be able to extend our base plugins without making your own OpenEdit builds. We would also be glad to host your open source plugin's as well. You can also use the new beans.xml feature to use custom Java beans on an individial catalogid.

Christopher Burkey (OpenEdit) Tue, Oct 28, 12:28 AM

Thanks Christopher for the fast answer,

I am absolutely not planning on changing the OpenEdit java source tree. That would only happen temporarily for debug reasons or to solve a problem in the customer's system. I initially thought some configuration files and eclipse specific files that are in the CVS tree would need changing in order to create a project specific distribution site (plugin server)

Since yesterday I have found some more insight in the workings of the plugin architecture and how the allplugins.xml even controls install scripts etc. So now I see ways to isolate that.

You say that I should host my own plugin server. That I assumed more or less. But can I use more than one plugin server for updates? Or do all plugins need to be on any server.

Maybe im asking stupid questions here but that is why I ask if a documented preferred procedure exists for how to set up projects with open edit. Normally I have enough time to fully examine all details of an architecture before using it in a real world project. (Un)fortunately this is not the case now. So you will have to excuse me for an occasional maybe less intelligent question :-)

Peter

Peter Friebel Tue, Oct 28, 4:09 AM

Peter,

We currently host our own plugin server. You could easily run as many plugin servers as you need - you just need a URL to map to where you can grab your install.js file that governs the update process. Alternatively, you can create ant based upgrade files so that you can do your upgrades at the command line - there is an example of this in openedit-editor /etc/install.xml

There is probably not a lot of reasons to host more than one plugin server - we host multiple independant projects on a single anthill build server that does the continuous integration testing and creates the builds that we deploy against. It works quite well. YOu should also take note of the pluginoverrides.xml capability - basically, OE will load apps in order, based on dependancies between applications, swapping out any required beans, and then swap out anything in /WEB-INF/pluginoverrides.xml at the end. It makes for a very pluggable architecture.

Good luck on the project - let us know if you need more help!

Ian Miller (IJ_Solutions) Tue, Oct 28, 8:11 AM

Thanks Ian,

It's all starting to fall in place. As I said, this project is all a bit untypical for me as I am in a bidding situation and need to do some show & tell without having had my normal research time. But hey, I call it a luxury problem :-) I have no previous experiences with Anthill. Seems like a nice system and I will look into that. Even if I loose the bid this will all be worth it as it speeds up my using and promoting OpenEdit for other porjects here in Scandinavia.

Thanks again and I sure will ask more stuff and after all i think this i will be in a good position to start answering questions here too!