Versioning of NetBeans JBI Components

[Dougal Fraser]

Hi everybody,
We are creating a custom jbi service engine for a legacy mainframe system.  We have hit a snag relating to the creation of NetBeans Plugins to support multiple versions of the same service engine.
At the service engine level, it is straight-forward - branch the code, rename the service engine internally, and a new version of the service engine is created; however in NetBeans life is trickier.  The problem stems from the fact that you can't just share code between two NetBeans modules, it takes some work.

We have started work on a second NetBeans plugin.  The NetBeans JBI CDK generated these plugins for me and they contain a large number of very similar classes - 15 of them. Trying to maintain initially 4 copies of these classes across the four service engines is obviusly a bad idea that will lead to serious maintenance problems. So we set about to extract the common code into a seperate project.  In order to make this code usable from the other NetBeans modules, we needed to make this a NetBeans module too, rather than just a standard Java jar library.
A problem is that you can not make one NetBeans module in your workspace reference another NetBeans module in your workspace; they can only reference modules installed into NetBeans itself.
Fortunately, there is a way around this - you can setup a NetBeans Module Suite, which is a collection of NetBeans Modules grouped together that can be tested together, and importantly reference each other.  This also solved another problem - two service engine NetBeans plugins and I could test each of them independently by spawning NetBeans with that plugin deployed, but was unable to create a composite app containing both service engines. This allows us to run them both simultaneously.

This causes several problems for versioning.

   1. It makes the entire set of NetBeans plugins a single deployable unit.  If you care about regression testing of NetBeans plugins, then this will be a problem.
   2. Unlike the service engines, where a copy of the shared code is deployed with each service engine, with NetBeans the shared code is deployed separately, meaning there is only one copy, and thus any update to the shared code impacts all the plugins. We could consider versioning this code by renaming it too to allow multiple versions to be deployed simultaneously, though I don't know if NetBeans can handle the same class with the same name loaded multiple times.
   3. Deploying all the plugins as a suite means we must deploy all versions of all plugins simultaneously - so it is no longer good enough to checkout a single branch of the code, instead you need all branches checked out and built together.

One possible option (but still only a partial solution) is to make the NetBeans plugins version-aware, so a single plugin can target multiple versions of the same service engine.

Any help that can be given would be appreciated.

[Dougal Fraser]

BUMP!

Any takers please?

Dougal Fraser wrote:

Hi everybody,
We are creating a custom jbi service engine for a legacy mainframe system.  We have hit a snag relating to the creation of NetBeans Plugins to support multiple versions of the same service engine.
At the service engine level, it is straight-forward - branch the code, rename the service engine internally, and a new version of the service engine is created; however in NetBeans life is trickier.  The problem stems from the fact that you can't just share code between two NetBeans modules, it takes some work.

We have started work on a second NetBeans plugin.  The NetBeans JBI CDK generated these plugins for me and they contain a large number of very similar classes - 15 of them. Trying to maintain initially 4 copies of these classes across the four service engines is obviusly a bad idea that will lead to serious maintenance problems. So we set about to extract the common code into a seperate project.  In order to make this code usable from the other NetBeans modules, we needed to make this a NetBeans module too, rather than just a standard Java jar library.
A problem is that you can not make one NetBeans module in your workspace reference another NetBeans module in your workspace; they can only reference modules installed into NetBeans itself.
Fortunately, there is a way around this - you can setup a NetBeans Module Suite, which is a collection of NetBeans Modules grouped together that can be tested together, and importantly reference each other.  This also solved another problem - two service engine NetBeans plugins and I could test each of them independently by spawning NetBeans with that plugin deployed, but was unable to create a composite app containing both service engines. This allows us to run them both simultaneously.

This causes several problems for versioning.

   1. It makes the entire set of NetBeans plugins a single deployable unit.  If you care about regression testing of NetBeans plugins, then this will be a problem.
   2. Unlike the service engines, where a copy of the shared code is deployed with each service engine, with NetBeans the shared code is deployed separately, meaning there is only one copy, and thus any update to the shared code impacts all the plugins. We could consider versioning this code by renaming it too to allow multiple versions to be deployed simultaneously, though I don't know if NetBeans can handle the same class with the same name loaded multiple times.
   3. Deploying all the plugins as a suite means we must deploy all versions of all plugins simultaneously - so it is no longer good enough to checkout a single branch of the code, instead you need all branches checked out and built together.

One possible option (but still only a partial solution) is to make the NetBeans plugins version-aware, so a single plugin can target multiple versions of the same service engine.

Any help that can be given would be appreciated.