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
SOA Architect
Sun Microsystems, Inc.
New Zealand
Phone x69822/+64 9 9766822
Mobile +64 21 2711179
Email Dougal.Fraser@...
|