It's all about the answers!

Ask a question

Best way to implement a change to common extension code?

Cliff Gardiner (921234) | asked Oct 30 '18, 8:03 a.m.

Hello all, I have already successfully implemented some advisors and participants; common, shared methods and constants are in their own plugin project.  I am now testing a new advisor, and have needed to add new constants and methods to the common code.  All this works just fine when I test from a JETTY-launched v407 server. 

I have upversioned the common project 1.0.1, made that version a dependency of the new advisor's project, specified version 1.0.1 of the common plugin in the new advisor's feature, and built the update site.  I can see in the plugins folder (v502).

Having added the provision site and update site and restarted CCM in the normal manner, the Provision Status tells me that the new version of the common bundle won't load because the old version is already installed.

Is there a way to force loading of a specific version of a jar or am I obliged to rebuild, redeploy and retest all the update sites that use the common code?  That would seem to discourage using common code in favour of deployment simplicity.  Have I missed a trick somewhere along the line?

I'm bracing myself for disappointment :(

2 answers

permanent link
Ralph Schoon (63.3k33646) | answered Oct 30 '18, 9:21 a.m.
edited Oct 30 '18, 9:23 a.m.

 Have you requested a server re-provisioning/server reset? See

Cliff Gardiner commented Oct 30 '18, 9:34 a.m.

  Hi Ralph, yes, of course.

I had a brainwave and I'm experimenting with abandoning the common code as a discrete plugin project, and linking to its source folder from the new advisor's project.  That means an extension would take whatever was in the common code at compilation time, same as happens for batch stuff.  If this works I'll have been able to answer my own question - update to follow!

Cliff Gardiner commented Oct 31 '18, 5:31 a.m.

Well, it didn't work.  I could find no way to include the common source via a link and have its classes expressed in the new advisor's jar file.  This may be some Eclipse knowledge I'm missing, but if there is a way it must be well hidden!

Consequently, I've had to copy the common code into my new advisor in order to make it an atomic deployment unit, and avoid having to rebuild/redeploy/retest all my advisors and participants because of changes to the common code.

I'm wondering if the common plugin project should have its own feature and updatesite, and the other features amended to exclude it.  This might provide a means to load the common stuff once so all the other plugins can use it.  I feel some more experimentation coming on .....

Ralph Schoon commented Oct 31 '18, 5:43 a.m. | edited Oct 31 '18, 5:44 a.m.

I am not sure, but I would think you might have to create a feature and deploy that feature with its own provision profile. The Consumers would have to require the feature. 

I have not tried that myself, but I think that is how the platform works.

Have you looked into the extension workshop how that uses features to combine the server and common components?

permanent link
Cliff Gardiner (921234) | answered Nov 07 '18, 10:33 a.m.

I found what seems to be the right approach.  I had used the extension workshop approach Ralph mentioned with features combining server and common components, and that was the problem.

I built a 6.0.6 development environment and reworked my code there; I created a provision profile and update site for the common code, and for all the other plugin projects I added the common plugin as a dependency as before but did not add the common plugin to their feature projects.  I did not make the extensions' features require the common feature.

Request server reset, restart the server and the Provision Status shows all the bundles starting cleanly.  All extensions tested successfully.

The final test, which I haven't had time for yet but am confident will work, is to amend and redeploy the common code and test the extensions again.  Because the extensions' features don't specify the common plugin's version, I reckon this will work just fine.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.