[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] Sharing Your Shared Install Issues
- From: Domenico Alessi <domenico.alessi@xxxxxxxxxxxx>
- Date: Fri, 23 Sep 2011 10:55:58 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: Acx5+bbAbWiw2/ddTGCcnTZpKudBUQABg+Qg
- Thread-topic: [p2-dev] Sharing Your Shared Install Issues
From our side, we have don't quite a bit of work in the
area of shared installs. We presented something at the demo camp in
Montreal earlier this year. I am not sure if it aligns with the Eclipse
vision, but we found that the shared installs would never meet all of the needs
for teams. People would usually say that the installation has too many/or
lacking plugins they needed. So it didn't scale. I know people could
still install other plugins into their .eclipse folder.
So, what we have done on our side is that we have setup a
shared location on our network (assume performance is optimal over the WAN),
which contains all of the plugins our company needs. We have also added
code to P2 to take advantage of this bundle pool. We have pre-configured
our shared SDK (which only has eclipse SDK + our update P2 code) to point to
this bundle pool. This bundle pool holds all of the features/plugins
already in installed format. So, when a user uses P2 to install from here,
really it just updates the bundles.info, platform.xml and SDK profile to load
from this bundle pool. This way we don't have everyone physically
installing plugins. In the end we have a multi-user bundle pool.
Now, this doesn't prevent users from installing something we don't have.
Also, if a user tries to install something from an update site which we already
have, the code still takes it from our bundle pool. In the end the user is
not aware of any of this happening behind the scenes because we have not changed
the UI. I wanted to present this at this year's eclipsecon, but it got
refused, I hope to get the chance to present it in 2012.
One thing we haven't addresses is CPU/Memory efficiency in
Eclipse with shared installs. I think this would be good to talk about as
As Pascal previously mentioned, we would like to improve the p2 Shared
Install experience in the Juno release. Currently we are gathering a list of
issues to try and help prioritize things. Considering the limited resources we
have, we will not be able to solve all the problems without the help of the
community and we would like to work through the biggest blockers and pain
points. Without help from the community we will not make progress.
created Bug 358471  as an umbrella bug report to cover the plan item and
added other bugs to its dependency list. I've also started a wiki page  to
capture some of the problems we are facing. If you have issues with the Shared
Install scenario, then please add them to the list so we can begin discussions.
Just to be clear we are not only looking for bugs, but constructive
discussion about how to fix problems, background surrounding shared install
setups (what's rpm? ;-), and for people to say "this problem is important to me
and I'd like to help out, what can I do?".
As for discussions, if you
want to talk about a particularly focused problem then the bug report is most
likely the best medium. More general discussions can be directed to the p2
mailing list, along with notes being put on the wiki page. Also note that some
members of the p2 and Equinox teams hang out on the equinox-dev IRC channel 
if you have a quick question. We do encourage most discussion to happen in bug
reports though, as it captures it for everyone to see and reference
I'm looking forward to hearing about your ideas and finding
solutions to your problems.