Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » P2 » Blending Packages(Consider letting Eclipse packages 'share' components)
Blending Packages [message #1016995] Fri, 08 March 2013 14:16
a platypus is currently offline a platypusFriend
Messages: 2
Registered: December 2012
Junior Member
Hi gang!

Here's a quick overview of something I think the Eclipse project will need to consider eventually. Try to think about 'how' and 'when' rather than 'why'.

After I used the Upgrade function on Juno / JDT today, it crashed spectacularly. It won't run. Looks like I'm back to a fresh install, new package, etc. Downloading the 'extra' modules, etc. AGAIN.

In truth I don't really want a future where that's the only way to 're-boot' Eclipse. I haven't found too much on making my 'own' package either. This is interesting for people thinking about ways to avoid this cul de sac.

However, again, this isn't my idea of fun. For one thing I'd need to maintain the 'packaging' for as long as I needed and for another it isn't a general solution.

My Preferred Option

I'd like it if there was some way to 'share' components among the downloaded Eclipse packages. So for a simple illustration, I could download the Eclipse Modelling Tools package and the Eclipse IDE for Java and Report Developers, to name two.

These two have slightly different configurations. However they substantially overlap in many key areas, see: How to Combine Packages

So what I'd like to see is how I can keep the 'package' entity but share or reuse the components, plugins, etc. So if the modelling package updates the , then there would be no need for the JDT & Report Eclipse to update Mylyn as well.

That is because the components themselves would rest in a shared repository.

How do you do this? I'm not sure (yet); my outsider view is to use a different ".ini" or ".config" file to list the components that a package registers when it starts. That is kind of like a late binding of the Eclipse.exe runtime to one configuration or the other.

For example; everything uses the same folder structure as at present. The difference might be that there'd be an optional start-up parameter to choose a package configuration, like:

  • Eclipse.exe --config JDT_Report.cnf
  • Eclipse.exe --config MDT.cnf

The default would be as it works now or to look for "Eclipse.cnf". So the .cnf file is like an a la carte selection for the OSGi bundles to load. My expectation is that 99% of the plumbing to achieve this already exists. It could be as straightforward as reorienting the start-up sequence.

Anyway some discussion is worthwhile. Very Happy The main 'pro' for me is with two, three and more packages 'installed' I only need to update each component (e.g. Mylyn) the once. That will save me time.

I'm hopeful too that it is part-way to avoid crashes like today's event, and further avoid some clashes and conflicts I've had between components that don't need to be in the same Eclipse runtime package; they are just there as the next best option to having two or three Eclipse configurations and needing to update the same bits three times. Also the conflict thing ... With this '.cnf' idea, you can edit the file and snip suspect component bundles to identify conflicts. (Well, may be).

Let's see some pros and cons.


Previous Topic:Errors related to Generics while compiling OSGi-Equinox dependent code with JDK 1.7
Next Topic:Dropins Link with $PROJECT_LOC
Goto Forum:

Current Time: Sun Sep 15 12:35:43 GMT 2019

Powered by FUDForum. Page generated in 0.02070 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top