Community
Participate
Working Groups
Since there was no Orbit when we started we have been keeping this dependency in ..mylar.context.core. Now that 1.0 is out we should move this out and into an Orbit project.
This will probably have to wait until Mylar 1.0.1 is out (scheduled for Dec 22nd).
Mik, can you please point me to any documentation how Orbit dependencies going to be used? Both at development time and when users will install prebuilt products.
I just found the instructions here: http://wiki.eclipse.org/index.php/Adding_Bundles_To_Orbit Also: http://wiki.eclipse.org/index.php/Orbit Adding Scott to CC since he was also interesting in seeing these plug-ins added to Orbit.
I saw that, but it does not explain how to use these bundles in your own projects. Also, I am very confused about chosen project layouts and the branch structures for Orbit projects... Besides that it is confusing, I have bad feeling that it won't scale over time.
I find out that Orbit actually have no plans to provide update sites and my attempts to convince them to do that wasn't successful. So, plugins would need to be downloaded from the Mylar's own update site. But then they would have to live in a separate feature that can can't be included and yet need to be required. This way uninstalling old version of Mylar won't wipe them out.
Hmmm, my thinking is: * If they get installed with Mylar, they live in a Mylar feature. There is still benefit because a reinstall won't be required when the feature is updated with new Mylar plug-ins. But uninstall of Mylar means they get uninstalled. * If Orbit eventually provides an update site that more than one project can link their downloads to, then we link to that site and they won't get uninstalled.
If you uninstall Mylar feature all its plugins will be wiped out. That also happens when you uninstall old versions of the feature (have to do that manually because Update Managed don't do that). So, the only option is to have separate feature for those plugins, either available from Mylar update site or from Orbit (which they are not planning to provide at this point).
It looks like we won't be ready to to move to Orbit-based dependencies for 2.0M1. One of my main concerns is that this could add significant complexity to our build process if we can't check out the plug-ins with pre-built JARs, or depend on them via an update site. However, as a baby step I have moved all of our dependencies to the org.eclipse.mylar plug-in, which now contains library folders that group them: * lib-axis * lib-httpclient * lib-xmlrpc
Axis has been moved out of org.eclipse.mylar, see comment#3 on bug 172264.
FYI, httpclient was added to Orbit today, I'm working on adding it to the build (https://bugs.eclipse.org/bugs/show_bug.cgi?id=177187)
bug 177187 is now fixed and httpclient should start appearing in Orbit builds soon
I'd like to make an observation. Right now you can just checkout projects from /cvsroot/technology/org.eclipse.mylar right from the IDE and you all set and can hack away. Can't be easier, but we still saw some developers confused about this process (well, actually they wanted to use 3.2 branch). Now, let's say Mylar move to use Orbit stuff. What developer experience going to look like? I might be missing something, but from what I saw, it will be necessary to go to the org.eclipse.orbit tree (in different CVS root), then hunt for specific project name and then hunt again for specific version/branch name. At minimum it looks error prone.
That's why project set files were created.
Unfortunately project set files don't help much. Many developers have no clue about them and the rest don't really want to get all the projects and only interested in some particular subset...
I'm concerned about this too, because it has been important for us to maintain a low bar to contribution by making it possible to get going with Mylar by either checking everything out in our root CVS directory or by checking out a single project set (we encourage the latter). This is particularly important for newcommers to Eclipse. http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Workspace However, perhaps if we update our project sets to include the relevant projects from Orbit this will be easy enough. Chris: could you please point me at the project set?
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.orbit/org.eclipse.orbit.releng/psf/orbit.psf?revision=1.1.2.2&root=Tools_Project&view=markup&pathrev=set1
This has some good references: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg01003.html
Need to postpone.
Given the overhead of the rename it is unlikely that we will be able to do this packaging change in time for Europa.
Any updates to this? The checking out of jar files from org.eclipse.mylyn.web.core perked my interest in scanning bugzilla. Per the Europa Simultaneous Release guidelines' "Must Do #7"... Any third-party plug-ins that are common between projects must be consumed via Orbit; the final Europa release will not have duplicate third-party libraries (note that this only applies to identical versions of the libraries; thus if project A requires foo.jar 1.6 and project B uses foo.jar 1.7, that's ok).[1] ...and the same will be applied to Ganymede.[2] Orbit has Commons Codec 1.3.0, Commons Logging 1.0.4, and Commons HttpClient 3.0.1 (though I do from bug 2034303 that there's a plan to move to 3.1.0) [1] - http://wiki.eclipse.org/Europa_Simultaneous_Release [2] - http://wiki.eclipse.org/Ganymede_Simultaneous_Release
Er, I mean bug 203403.
Yup, this is on the table for Mylyn 3.0. Note bug 203403.
If Mylyn has other 3rd party deps, they will have to be in Orbit also if Mylyn is to participate in the Ganymede train. If there are, IPZilla's should be opened to get them approved and then into Orbit.
An observation. I see few projects consuming orbit bundles (i.e. Spring IDE and q4e projects) and install them with their own features, but then Eclipse Update Manager and Eclipse runtime behave really funny and raise all kind of confusing warnings when they see duplicate bundles installed.
Done. Using WebClientUtil.setupHttpClient() is now deprecated since it sets global protocol handlers.
Created attachment 91286 [details] mylyn/context/zip
Wait, I don't see how this is resolved when the MANIFEST.MF file for o.e.mylyn.web.core still doesn't point at Apache bundles from Orbit but is instead still using Bundle-ClassPath to point at lib-httpclient/commons-httpclient-3.1.jar and friends.
Never mind, I spoke too soon. My connection to CVS was taking way too long to synchronize. It looks good, thanks Steffen.
