Community
Participate
Working Groups
When including only the STP-IM component of the STP list on Galileo M7 and no plugins from SCA, then the whole installation process fails with the following exception message: Cannot complete the install because one or more required items could not be found. Software currently installed: org.eclipse.stp.im.feature.feature.group 1.0.1.200903191021-7B--7kMO1Mwa1YMkY Missing requirement: org.eclipse.stp.im.out.sca 1.0.0.200903191021 requires 'bundle org.eclipse.stp.sca 0.0.0' but it could not be found Cannot satisfy dependency: From: org.eclipse.stp.im.feature.feature.group 1.0.1.200903191021-7B--7kMO1Mwa1YMkY To: org.eclipse.stp.im.out.sca [1.0.0.200903191021] All other dependencies are normally found automatically, but it seems this is not the case for STP-IM. Probably you should have a look at the before Galileo RC. Best regards, Florian
The IM reuses the BPMN and SCA models from these other projects. The issue here is that the dependencies haven't been specified correctly in the IM feature. I've changed the component, and reassigning this one to the component lead(s) to work out what's the best way to sort it out.
The approach to take here would be to split the IM into three features: 1. IM Core - no dependency on SCA or BPMN models 2. IM BPMN Extension - contains all BPMN-related plugins, transforms, etc 3. IM SCA Extension - contains all SCA-related plugins, transforms, etc While we are at it, it may be a good idea to pull out the runtimes as separate features too 4. IM BPEL generation 5. IM JBI/ServiceMix generation Does the IM have the kind of extensions architecture to make this feasible. I really don't think we have the time this near to RC1 to fix this in a 'nice' way. We may have to fall back on just documenting it somehow, or being tricky with the build. Opinions from the team?
Hi Oisin, At the moment there's no JBI or BPEL code generation plugin for code generation in the IM SVN tree. The plugin you see only defines the services availables ( for annotation ) for a JBI runtime ( ServiceMix ) and for a BPEL runtime, to get an annotated BPMN model and the intermediate model. The extension point for definining new runtimes is already defined in o.e.s.im.runtime Regardd the code generators - The JBI Code generator is provided by the spagic project in the OW2 svn forge ( This mainly because the code is licensed under LGPL ) - There is a bugzilla entry for BPEL code generation part but the code attached in bugzilla entry is not the last that we have in spagic stuff. Wrt to BPEL, we are thinking to contribute the code generation plugin, but as you said is to late, so i think we'll address this after galileo. Andrea
Hi guys, First of all thanks Florian for raising this issue, it is an important question. Oisin, I think your suggestion to split the IM set of plugins into several features makes sense and it should work. Basically the IM Core feature would do "noting" useful as it just contains the core elements, with no transformations. Then, the SCA feature would bring in the transformation plugins and would depend on the IM Core feature. But of course, if you were to download it, you'd need the SCA features as well. So it's just a matter of dependencies, it doesn't require refactoring of the code. So, regarding the existing plugins, I suggest we put them in features as follows: IM Core: org.eclipse.stp.im org.eclipse.stp.im.edit org.eclipse.stp.im.editor org.eclipse.stp.im.resources org.eclipse.stp.im.tests IM BPMN Support org.eclipse.stp.im.in.bpmn org.eclipse.stp.im.tool.in.bpmneditor IM SCA Support org.eclipse.stp.im.in.sca org.eclipse.stp.im.out.sca IM Runtime Support org.eclipse.stp.im.runtime org.eclipse.stp.im.runtime.bpel org.eclipse.stp.im.runtime.jbi.smx Andrea, all, any comments / suggestions? If not I can try to do this quickly. Oisin, if I create the 4 new features and I just put them into the "features" folder, will these be picked up automatically by the builder and added to the update site? Cheers, Adrian.
Ok for me. Cheers Andrea
The update won't be picked up automatically, but it is be straightforward to update the overall build to be changed to pick them up - it's just a matter of updating the top-level build feature.xml at svn+ssh://dev.eclipse.org/svnroot/stp/org.eclipse.stp.build/build/trunk/stp/org.eclipse.stp.toplevel.feature/feature.xml You should have commit rights to that - once you make the change and commit it, a new build will kick off within the next half hour and an email will be sent to stp-dev (and also a tweet to @eclipse_stp). If the build is successful, a p2 site will appear in http://build.eclipse.org/stp/committers/ so you can download and check it.
OK, I created the 4 features and changed the top-level build feature. Keeping my fingers crossed now for the build! :)
(In reply to comment #7) > OK, I created the 4 features and changed the top-level build feature. Keeping > my fingers crossed now for the build! :) Ok, I can see it building at https://build.eclipse.org/hudson/view/STP/job/stp.toplevel.trunk.jdk5/ Don't forget to make sure that the metadata in the features include the correct provider and URL information, as that will appear in the update wizard.
The build succeeded, but for some reason the p2 site didn't get generated in the correct place. I'll check to see what's going on and start a new build later.
Thanks a lot Oisin! I've also just updated the providers and descriptions for the features.
I reopened this one, because I think that there may be a better way to solve this. If you take a look at the update (p2) site build at http://build.eclipse.org/stp/committers/im/1.0.1.200905132032/ you will see that there are the required BPMN and SCA features in place. The downside is that BPMN and SCA weren't designed to be consumed in this way, so this build has basically pulled in *all* of BPMN editor, including all of the UI contributions, and a *lot* of SCA. IM doesn't need that much stuff, really. And I'm sure that the UI (including GMF and all that) is a lot of overhead. I think there might be value in updating the 'new' IM features to depend on the BPMN/SCA *plugins* that are required to make IM work - so, don't depend on other features, instead drill in and have the features depend on only the plugins that are required. Then, the next step is to update svn+ssh://dev.eclipse.org/svnroot/stp/org.eclipse.stp.intermediate-model/org.eclipse.stp.model/trunk/build/im/org.eclipse.stp.im.build/feature.xml and remove the <includes id="org.eclipse.stp.bpmn.feature" version="0.0.0"/> <includes id="org.eclipse.stp.sca.feature" version="0.0.0"/> feature includes. Commit that and a Hudson build will kick off. The build is configured to look in the right place for the extra plugins. See https://build.eclipse.org/hudson/view/STP/ for the results.
I completely agree that the bpmn.feature and the sca.feature should NOT be included in the build. Basically, they should not be in the svn+ssh://dev.eclipse.org/svnroot/stp/org.eclipse.stp.intermediate-model/org.eclipse.stp.model/trunk/build/im/org.eclipse.stp.im.build/feature.xml Not sure why they are there, perhaps this file has been generated automatically? What I did in the 'new' BMPN and SCA features was simply declare a *dependency* to BPMN and SCA features respectively. This was meant to simply alert the user when installing these IM features that other features are required. So basically a dependency enforcement mechanism, NOT an inclusion mechanism. We do not want/need these features to be contained in the IM. All I need is that the user installs them before or together with the respective IM plugins. Perhaps (most likely) I do not completely understand how the build system works, but feature dependencies should not be built, they should just be used. On the same line of thought, the org.eclipse.stp.model/trunk/build/im/org.eclipse.stp.im.build/feature.xml file should probably NOT include any of the IM features, as we do not need an uber IM feature containing these 'new' features, we just need the 4 'new' features to be available for instalation separately. I can of course remove the two inclusion lines from the build feature.xml. I could also try and declare dependencies to just the plugins that are needed, in the 'new' features. But I'm afraid this would also entail, at installation time, several alerts of type "plugin org.eclipse.sca.blabla" needs to be installed for the IM SCA feature to work, rather than a much cleaner "the SCA Feature needs to be installed" message (the user would probably always install a complete feature, not just plugins). By the way, would it not suffice if I just simply removed the two include lines from the build feature.xml, or am I too optimistic? So I'm waiting for your answer Oisin before moving forward with this, and thanks again for all your help on this!
> Not sure why they are there, perhaps this file has been generated > automatically? I think it's my fault they are there - so I'll remove them. Thanks for the cogent explanation of your intent! > On the same line of thought, the > org.eclipse.stp.model/trunk/build/im/org.eclipse.stp.im.build/feature.xml file > should probably NOT include any of the IM features, as we do not need an uber > IM feature containing these 'new' features, we just need the 4 'new' features > to be available for instalation separately. That's actually a 'fake feature' that's used as the 'root' target to kick off the resolution of what's needed to build. It disappears later and you are just left with the features that are included in that 'fake feature' definition. So - I'll go remove those two extra-IM features now, and I'll resolve this as fixed.
Great, thanks a lot Oisin!
