Home » Eclipse Projects » P2 » Creating a customized Eclipse CDT distribution
| Creating a customized Eclipse CDT distribution [message #781232] |
Fri, 20 January 2012 21:00  |
 Vynce -
Messages: 6
Registered: January 2012 |
Junior Member |
|
|
I'm having a really hard time figuring out how to build a slightly customized Eclipse distribution. There's not much documentation (that I can find) and there appear to be several methods for doing this kind of thing: RCP, p2, EPP, simply zipping up a configured installation, etc. I'm not even sure if this is the correct forum for this question. The descriptions of these tools/systems don't make sense to someone that's not intimately familiar with the Eclipse internals. I've used Eclipse on and off for a couple of years and a lot of its internals remain a complete mystery to me.
Goal:
I want to build an Eclipse distribution similar to the standard Eclipse CDT distribution, but with a couple of extra plugins and different default settings. This will just be used internally by our smallish development team instead of each of them having to follow a long list of configuration instructions.
Requirements:
- Simple! I'm not trying to distribute a highly customized IDE to customers or support thousands of developers with complex and varying configurations.
- No automatic updates. I would like to be able to control (to at least some extent) the versions of the plugins that are installed by default.
- Customized default settings. I need to be able to customize some of the default settings. For example, the proxy server. I don't care about customized default project settings at this point, since I'll be creating all of the projects. I don't know if I care about the workspace settings because I don't know what's stored there vs what's stored in the Eclipse installation folder.
- Upgradeable. I would like to be able to upgrade the distribution in the future without blowing away a user's customized settings.
- Our IT department uses Run Advertised Programs to install additional software on developers' machines. It would be nice if I could use that for distribution.
The the tools that seem to match these requirements most closely are Yoxos and AID.
Questions:
- Which is the preferred method/tool to use? p2, EPP, AID?
- How are the standard distributions built? Can I use one as a starting point for my distribution?
- Is there a list of settings that get stored in the workspace?
[Updated on: Fri, 03 February 2012 23:54] Report message to a moderator |
|
|
| Re: Creating a customized Eclipse CDT distribution [message #781885 is a reply to message #781232] |
Sun, 22 January 2012 16:14  |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
There are basically three things to handle:
A. A downloadable ready to run package is just "a zipped up configured
installation" - the various methods for publishing all lead up to such a
result.
B. Perhaps most important is what is in this configured/packaged product
and if the various part of it can be updated individually, or if they
are defined to be part of a feature that controls the content (i.e. the
difference between "also included" and "intrinsic part of").
C. The updateability of a configuration is also determined by the
repositories it references (with possible user modifications to the
list). When a check for update takes place, everything in all
available/enabled repositories may apply to the configuration.
The easiest part is naturally A - you can just install stuff into an
Eclipse and then share that. You can also use the p2 director
application to prepare an installation by installing things piece by
piece. Eclipse can also be installed with a read only part, and some of
the configuration being user specific. (Have personally never used that
though, so can't give you advice on best practices for Windows).
Handling B is more difficult, you need to understand how to control the
updateability of what is included in what you distribute - how much do
you want to control vs. how much is controlled by those that publish the
functionality in the first place. How easy or difficult this is depends
on how the respective packages are created and maintained.
A tricky aspect is C since no matter what control you exercise over the
other two, it is possible that your configuration is affected by
patches, new fragments etc. that are published to the visited
repositories. To get full control, you need to setup your own mirrored
repository where you have full control over the content.
If you do not want to get something like Yoxos (which IIRC helps you
with all of the above), you can create your own solution. A combination
of the the b3 aggregator that allows you to compose and mirror your own
repository, and the p2 director to install what you want into platform
specific locations (that is then zipped up and distributed) has been
successfully used by large companies to distribute their own internal
Eclipse distributions (a blessed configuration behind the firewall).
Naturally how much control you will have is a function of how much work
you are willing to put in. If you decide to create your own solution
there is no way around that you must learn how products are defined and
how to work with p2. Then how much control you want over each of the
packages you include and how quirky they are to deal with.
To put the technologies in perspective:
p2 - is always involved in all install/uninstall/update operations.
There really is no choice if you should "use it or not". Some forms of
publication (writing a feature and customizing how it is published in p2
form using a p2.inf will bring you closer to the internals of p2).
RCP - The IDE is an "RCP application", you probably do not need to
define a different IDE product, unless you want to rename it "Myclipse",
have a different logo etc. or want to alter the base product in other ways.
EPP - is used to define packages such as "Classic", you can achieve the
same result in different ways (writing a feature, just installing the
parts you require as if you started with classic and manually added to
it, etc.). EPP is used by Eclipse to package the various distributions.
The result is p2 definitions in a p2 repository.
b3 aggregator - used by Eclipse to create the official aggregated
repositories; helps you define, mirror, aggregate and validate p2
repositories.
p2 director - a command line app that performs p2 install/uninstall
operations.
An no, there is not a lot of documentation - although you will find an
overview of the concepts in more detail in the introductory chapter of
the "Buckminster Book"; downloadable in PDF from the Buckminster
project's download page at Eclipse. (You don't need to use Buckminster
to benefit from that chapter).
Hope that is of help.
Tried to answer some of your questions below...
Regards
- henrik
On 2012-20-01 22:00, Vynce - wrote:
> I'm having a really hard time figuring out how to build a slightly
> customized Eclipse distribution. There's not much documentation (that I
> can find) and there appear to be several methods for doing this kind of
> thing: RCP, p2, EPP, simply zipping up a configured installation, etc.
> I'm not even sure if this is the correct forum for this question. The
> descriptions of these tools/systems don't make sense to someone that's
> not intimately familiar with the Eclipse internals. I've used Eclipse on
> and off for a couple of years and a lot of its internals remain a
> complete mystery to me.
>
> Goal:
> I want to build an Eclipse distribution similar to the standard Eclipse
> CDT distribution, but with a couple of extra plugins and different
> default settings. This will just be used internally by our smallish
> development team instead of each of them having to follow a long list of
> configuration instructions.
>
> hxxp://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers-includes-incubating-components/indigosr1
>
>
> Requirements:
>
> Simple! I'm not trying to distribute a highly customized IDE to
> customers or support thousands of developers with complex and varying
> configurations.
> No automatic updates. I would like to be able to control (to at least
> some extent) the versions of the plugins that are installed by default.
> Customized default settings. I need to be able to customize some of the
> default settings. For example, the proxy server. I don't care about
> customized default project settings at this point, since I'll be
> creating all of the projects. I don't know if I care about the workspace
> settings because I don't know what's stored there vs what's stored in
> the Eclipse installation folder.
> Upgradeable. I would like to be able to upgrade the distribution in the
> future without blowing away a user's customized settings.
> Our IT department uses Run Advertised Programs to install additional
> software on developers' machines. It would be nice if I could use that
> for distribution. hxxp://technet.microsoft.com/en-us/library/bb633225.aspx
>
Basically, if you set up your own repository people really do not need
much distribution of new bits in bulk - they would update from your
repository. Naturally it is possible to use whatever suitable mechanism
you like to push the initial install out.
>
> The the tools that seem to match these requirements most closely are
> Yoxos and AID.
> hxxp://eclipsesource.com/en/yoxos/
> hxxp://code.google.com/a/eclipselabs.org/p/aid/
>
> Questions:
>
> Which is the preferred method/tool to use? p2, EPP, AID?
There is no single preferred method; Eclipse use b3-aggregtor/EPP, some
use their own, or a combination of b3-aggregator/p2-director, Yoxos (or
similar products).
> How are the standard distributions built? Can I use one as a starting
> point for my distribution?
Using b3-aggregator/EPP, yes you can use these as starting point(s).
> Is there a list of settings that get stored in the workspace?
No, this is up to what you install. Some settings are only part of the
workspace (as opposed to being part of project meta data, or part of the
installation). In our organization we distribute standard templates for
workspaces (a very simple solution, but not very scalable). There are
tools that help with these kinds of settings, but I have no experience
from using them.
|
|
| |
| Re: Creating a customized Eclipse CDT distribution [message #782543 is a reply to message #782495] |
Mon, 23 January 2012 23:05 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 2012-23-01 21:33, Vynce - wrote:
> Thanks for the thorough reply! The first two chapters of the Buckminster
> Book were helpful.
>
> Long-term, it sounds like the way to go is with a b3-aggregator mirrored
> repository and new installations done on each client machine with p2
> director which installs a custom-defined feature from that repository.
>
> Questions:
>
> Are you saying that if I create a custom feature that specifies that CDT
> 8.0.0 be installed, but CDT 8.0.0 says that it should always include the
> latest version of the GNU toolchain plugin, that it is possible the GNU
> toolchain might be updated without any changes having been made to the
> custom root feature?
You will be including CDT with some version range (or exact), and CDT in
turn includes other things with a version range (or exact). If versions
are exact there will be no surprise updates (except if there are things
like optional features, fragments, and patches that appear in the
repositories that a p2 agent visits on behalf of the user.
> Is a repository mirror even necessary? Couldn't the feature define which
> plugin/feature versions to install?
To have 100% control you need to be in control of the repository
content. Remember: some dependencies work "the other way".
> Related to 1 and 2 above, can you publish an updated feature which then
> tells the clients to update to the newly specified versions of the plugins?
IIRC, auto updates update only if the micro/qualifier change (not if
major/minor change). A user can decide to update by requesting install
of a newer version (if available in the repository). It is possible to
configure the auto update.
Sometimes you may have to do complicated "surgery" on what is installed
when performing an update. We recently undertook such an operation in
Geppetto where we decided to split our top level feature to allow
included features to be updated separately. That required some
complicated operations and an updater bundle to re-write information in
the "installed profile".
> Is p2 director typically run on the client machine to perform the
> installation or is it just run on the side to create a zipped
> installation that gets deployed to the client machines?
> How do you specify default settings for plugins/features with p2? Do you
> have to create a "settings plugin" or something that p2 can pull in?
>
I would say that the typical way is to start by downloading a zip and
unzipping it. From that point, the user updates their installation
(automatic updates).
The director is available as a standalone application, but is also part
of every eclipse. Typically the user controls their own configuration
using the ui in eclipse, but can do so from the command line (useful if
having done something "clever" and Eclipse does not start).
>
> Argh, this is so confusing. I wish there was a step-by-step tutorial for
> this use case.
>
1. What to install
2. From where
3. Once installed, where does updates come from
> In the short term, I'll probably just zip up my configured installation
> and not worry about updates for now.
That is a good start.
Then, depending on how much control you want to give your developers; if
you want to know exactly what is being installed and from where, and
when things are updated you need to set up your own mirror and clean up
all the references "outside". (Some corporations require this as part of
their policies).
If you care less about control over repositories, you can write your own
top-level features in terms of the official eclipse repositories.
Publishing them in a p2 repository that can be access by your
developers. The using the director, create installations (and zip them
up) from the combination of your repository and the official Eclipse
repositories (your repository can be an aggregate repository that
includes your feature repo, and with references to the Eclipse ones (so
your developers only need to visit your aggregate repository).
Next thing is to control the repositories - use b3 aggregator to setup
what you want, and make sure to clean all the referenced repository URLs
(unless you want users to get them and thus potentially and too easily
stray from the path you have blessed).
Then create the zipped products from your repository.
I would estimate several weeks of work for the initial setup (defining a
cleaned up and coherent master mirrored repository) for someone
reasonable experienced in the work, and then 1-2 weeks of work per
eclipse release that you want to support (depending on how much
detective work you need to do, how many 3d party things you add from
outside of the Eclipse release train (where everything is verified to be
installed together)).
Doing this in small steps is a good way to learn.
Regards
- henrik
|
|
| | | |
Goto Forum:
Current Time: Thu Dec 26 21:41:01 GMT 2024
Powered by FUDForum. Page generated in 0.03228 seconds |
] 
Search
Help
Register
Login
Home
.