Community
Participate
Working Groups
IMP Runtime 0.1.102 has a dependency on lpg.runtime. Please correct this to lpg.runtime.java to support usage of LPG2 from Orbit.
But the spelling isn't wrong on the IMP dependency - the ID of the original bundle is lpg.runtime (see the SourceForge sources). The Orbit bundle shouldn't have been created with a different ID than we'd been using in the past. BTW, IMP isn't using the Orbit bundle at this point. It will soon, but not yet; it will take a bit of work to convert over.
(In reply to comment #1) > But the spelling isn't wrong on the IMP dependency - the ID of the original > bundle is lpg.runtime (see the SourceForge sources). Yes, IMP is consistent. > The Orbit bundle shouldn't have been created with a different ID than we'd been > using in the past. I can only go on https://bugs.eclipse.org/bugs/show_bug.cgi?id=288666#c3, which suggests that a change was agreed. If that was a misunderstanding, now would be a very good time to remove the confusion. You may want to watch/comment on Bug 298562. I don't think that MDT/OCL cares about the spelling. M2M/QVTd would prefer a spelling that maximises IMP compatibility. > BTW, IMP isn't using the Orbit bundle at this point. It will soon, but not yet; > it will take a bit of work to convert over. For M2M/QVTd I have successfully used IMP-Runtime 1.0.102 with Orbit's LPG 2.0.17 after creating an lpg.runtime to delegate to lpg.runtime.java, though my actual usage may be little more than a build check.
>> The Orbit bundle shouldn't have been created with a different ID than we'd been >> using in the past. > >I can only go on https://bugs.eclipse.org/bugs/show_bug.cgi?id=288666#c3, which >suggests that a change was agreed. Yes, this probably shouldn't have happened - the "agreement" on the Orbit bundle's ID was made without the knowledge/consent of any of IMP's or LPG's owners (Philippe Charles and me). Probably just an oversight, though. To be fair, though, I've long thought that it's a bit unfortunate that the LPG Java runtime's project name and bundle ID don't match. The original reasoning was that the ".java" suffix was unnecessary, since Java is the only kind of runtime it makes sense for an OSGi bundle to hold. Even so, the disparity causes a minor inelegance in the LPG and IMP Ant build scripts, which generally assume that the project name and bundle ID are the same. So I'm open to the possibility of changing the bundle ID. It seems though that you're uncomfortably in the middle of all this, being the only person who needs both the Orbit LPG runtime and the IMP runtime. For IMP, we'll need to open up a CQ to use the Orbit version of the LPG 2.0.17 runtime. I haven't actually started that yet. That'll take a week or two (at least), and I'm technically on vacation right now. So this isn't an immediate solution.
It seems you favour the new name, so I assume IMP rather than Orbit will change. Since the IMP build has to change to reference Orbit anyway, changing the plug-in reference can easily be done at the same time. Getting IP approval is very quick since use of LPG 2.0.17 by MDT/OCL (a +1 project) is already approved. Use by M2M/QVTd piggy-backs and was all but approved within 12 hours. IMP should be formally approved as soon as your PMC +1's. You could copy https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3669. 'on vacation' - best time to get work done ... I hope you can get a 0.1.103 out comfortably before M5. For now I'll have to have my redirecting plug-in.
Hi all, I'm back from my vacation's time :) > Yes, this probably shouldn't have happened Sorry for not realizing that the project name doesn't match the plugin's one, my fault :\ > - the "agreement" on the Orbit > bundle's ID was made without the knowledge/consent of any of IMP's or LPG's > owners (Philippe Charles and me). Probably just an oversight, though. However, in my defense I have to contradict Robert because I have some private mails which suggested that lpg.runtime.java was an appropiate bundle's name. I also added Robert to every bugzilla/ipzilla related to the inclusion of the bundle into Orbit. So, let me say that I have tried by any means to be synchronized with Robert. In any case, that's not important now, we must focus on agreeing about how to align all the interested parts. Fortunately, we are in time to solve this. I think have this three different options: a) Leave the current Orbit's bundle as it's + Project and bundle's name matches. + No changes to Orbit's bundle is required. - Orbit's bundle name is different from SourceForge one. The bundle's name would have changed. Any project which wants to depend on the Orbit's LPG runtime, will have to change its dependency (because the bundle's name changes). b) Change the current Orbit's bundle symbolic name. - Project and bundle's doesn't match. - Minor changes to Orbit's bundle is required (Manifest and build files changes), + Orbit's bundle is the same as SourceForge one. c) Create a new Orbit's bundle. + Project and bundle's name matches. - Major changes to Orbit's repository. (A new project, branch, removal of the older one, etc...). + Orbit's bundle name is the same as SourceForge one. I'm happy with a) option. If Robert prefers b) or c) I would CC David, to check any implication of changing the Orbit's repository. For example, For b) is there any inconvenience from any Orbit's policy or whatever, about having different project and bundle names ? For c) can we freely remove the current lpg.runtime.java project ?. BTW, Have a happy 2010 :) Cheers, Adolfo.
How about d) Add a delegating lpg.runtime plug-in to Orbit (just a manifest file) but only if anyone actually needs SourceForge compatibility.
(In reply to comment #6) > How about > > d) Add a delegating lpg.runtime plug-in to Orbit (just a manifest file) I'm not quite sure you refers to. Could expand the explanation ?. Cheers, Adolfo.
Created attachment 155220 [details] Delegating lpg.runtime plug-in Attached exists as lpg.runtime and so resolves any references that may require it, and contains a reference to lpg.runtime.java so that the code that was nominally referenced as lpg.runtime is provided by lpg.runtime.java.
Ed, I don't like this very much, specially since we are in time to change the Orbit's bundle. Some arguments - No stable build (milestone) has been created with the recently created lpg.runtime.java bundle. We can still change it without any pain. - Orbit's bundles are repository for third party libraries. A promoted bundle without any code may be confusing. Actually, I'm not sure if it could be sensible from Orbit's perspective. - Having an lpg.runtime and a lpg.runtime.java library may be confusing. - Introducing a new version of the library could imply creating two new branches for both bundles. - Orbit's bundles is supposed to be a common repository for Eclipse's project. Changing the source of the LPG runtime from Sourceforge to Orbit by a project such us IMP or MDT-OCL, only implies a change in the name of the dependent bundle in a manifest file. I think that this simple change isn't worth to do d), specially when I think we are in time to do some modifications to Orbit's repository, In the past having net.sourceforge.lpg.lpgruntime has not been a problem at all. From my point of view it shouldn't be a problem having an lpg.runtime.java. I agree that electing a more appropiate bundle's name (lpg.runtime) to make (probably only one) IMP project avoid changing its dependency to a different lpg.runtime bundles was valuable. Now changing the elected name is not it (worthy), IMHO. Anyway, we are in time to do it, so Robert if you feel that the bundle's name should be "lpg.runtime" please say b) or c) (if no inconveniences from David), otherwise you will have to change IMP's dependency to "lpg.runtime.java" to use LPG Runtime Orbit's bundle. Cheers, Adolfo.
Hi Bob, Have you got any conclusion about this ?. Cheers, Adolfo
Hi Bob, Taking from dev-orbit lists: "Helios M5 for +0 projects is next week so we should think about promoting one of our builds for use. I've just finished making some changes (breaking a few things but hopefully fixing them all!). Is there anyone else who has changes that they would like to make before a build is promoted. If possible, we should aim to have a build promoted by end of day on Wednesday so it has time to replicate and +0 teams can consume it and run their test builds. Thoughts?" I need some participation from you to make any concensous change if desired. Otherwise, we will keep "lpg.runtima.java" Orbit's project and bundle's symbolic name for LPG v2.0.17 and furture releases. Actually, it seems that we will have to rush for it if we decided to adopt any option different to a) now. Due to the fact that you are not so reluctant to change IMP's manifest to make it depend on Orbit bundle's one, and we are now a little bit in a hurry, I would definitely leave all af it is in Orbit. Opinions ? Regards, Adolfo.
Ideally, I think the best thing would be to have the project and bundle name be "lpg.runtime", as the ".java" suffix is unnecessary. However, given your time constraints, and given the long history of the ".java" suffix on the SourceForge project, and given that it's more important for the project and bundle IDs to match, I suggest: Let's leave the current Orbit bundle as is, and I'll adjust the IMP bundle dependency to match that. I've been working on the IMP release process, and will probably need another day or so to complete that. I also have to start the CQ for IMP to depend on the Orbit bundle. I'll do that today. Can you help me understand what I need to do for IMP to consume the LPG Runtime Orbit bundle? Is the binary plugin jar checked into Orbit CVS? Do the project/bundle IDs match there?
(In reply to comment #12) > Ideally, I think the best thing would be to have the project and bundle name be > "lpg.runtime", as the ".java" suffix is unnecessary. > > However, given your time constraints, and given the long history of the ".java" > suffix on the SourceForge project, and given that it's more important for the > project and bundle IDs to match, I suggest: > > Let's leave the current Orbit bundle as is, and I'll adjust the IMP bundle > dependency to match that. > > I've been working on the IMP release process, and will probably need another > day or so to complete that. > > I also have to start the CQ for IMP to depend on the Orbit bundle. I'll do that > today. > > Can you help me understand what I need to do for IMP to consume the LPG Runtime > Orbit bundle? Is the binary plugin jar checked into Orbit CVS? Do the > project/bundle IDs match there? Yes, the Stable build was done Yesterday, so I guess it's better to leave the Orbit's bundle as it is. I'm afraid, I'm not familiar on releng tasks, so I can't help too much on how to make IMP project consume LPG Orbit's bundle. However, I could give you some known things: - Orbit's download page: http://download.eclipse.org/tools/orbit/downloads/ - The last Orbit's stable build (M5 candidate) is dropped in the following URL: http://download.eclipse.org/tools/orbit/downloads/drops/S20100120144102. There, you can obtain both, the binary and the source bundles (jar files). - All the current MDT-OCL releng's stuff is located in the following CVS location: dev.eclipse.org:/cvsroot/modeling/org.eclipse.mdt/org.eclipse.ocl/releng I guess that if you look into it, you could figure out how to make your project consume Orbit's LPG bundle. - The code into Orbit's CVS have some peculiarities so that the Orbit's building process may produce the bundles dropped in the URL I provided above. If you want to exactly know how the project looks like, you can go throught the following CVS location: dev.eclipse.org:/cvsroot/tools/org.eclipse.orbit/lpg.runtime.java - Yes, the Orbit's project name and the bundle symbolic name match (lpg.runtime.java) I hope this helps. Cheers, Adolfo.
Can you update IMP runtime in SVN to the new name please? Can you do a new IMP runtime update site release please?
FYI, as discussed, I've created the necessary wrapper plugin (bundle ID "lpg.runtime") on LPG's sourceforge repository, and changed the bundle ID of the existing plugin to "lpg.runtime.java". I'm now in the process of switching IMP over to the new arrangement. I'll post again when I've got that done.
This has been fixed in LPG versions 2.0.17 and greater, and in the IMP runtime since version 0.1.104.v201003141548.
