[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] p2 export/import features

On Fri, Feb 11, 2011 at 10:28 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> wrote:

On 2011-02-11, at 1:51 AM, Meng Xin Zhu wrote:

> add my comments inline
> On 02/11/2011 10:48 AM, Pascal Rapicault wrote:
>> I gave a try to the plugin and it is pretty good and would definitely be of great help to users. It is something that we (the p2 team) always thought about doing but never got around to. As such I think that this would be great addition to p2.
>> Some of the details would likely have to be tweaked (or at least be sure that we plan for further extensions, see below), but at least we have an initial contribution to build upon and this is great.
>> I'm in support to provide you access to the incubator to rally help continue improving it.
> Incubator could be a good start.:)
   ÂBtw, I notice that you are from WindRiver. Who owns the rights to this code?
If you are all good, then we'll likely need to put it through CQ quickly.
ÂÂÂÂÂÂÂÂ This plug-in is an open source project under EPL that is hosted by Google Code. I did it in my spare time. I'm not sure the property policy of WindRiver, I'll talk with my colleagues.

>> Some notes:
>> - Does it make sense to be able to add this support to the director app.
> It's constructive. Director app always is headless, it could be easy to reuse the implementation of exporting/importing features.

>> - Could we make sure that the file format is extensible to later allow for the description of a profile (so we can replace the long command line we currently have)
> I'm not sure what you mean. Could you give a long command line example?
   ÂThe file you are introducing allows to install several features at once. If we allow for it to be used in the director.app (which I think would be great), then with a little bit of extra efforts we could extend the format to allow for a complete "scripting" of an installation. This would mean that I could say Âsomething like -application p2.director -script sdk.p2f
This file would have to be able to accommodate the specification of things like profile name, etc. (e.g.   -profile SDKProfile  -profileProperties org.eclipse.update.install.features=true  -bundlepool d:/eclipse/  -p2.os linux  -p2.ws gtk  -p2.arch x86  -roaming )

   ÂThis new format could also be used as a replacement for the property file used in the p2.installer

   ÂBut, let's solve the first problem first, and we can deal with this later.
ÂÂÂÂÂÂÂÂÂ I see. It's a great idea.

>> - Should we try to cast this as a new sort of IU so these could also become manageable by p2.
> The location of repository is an important data for quickly installing those features, is it overweight to add them in the profile?
   ÂI agree with you that it is key to be able to pass this file around by email, and this a facility that we don't want to lose. I'm just wondering if there would be cases where one would want to start sharing this through a repository, have it versioned, etc... therefore my desire to somehow cast it as an IU.... But again this is not necessarily important to start with. To just to get the discussion going.
ÂÂÂÂÂÂÂÂÂ Yes. We can do the others firstly, then go back to think about it.

>> PaScaL
>> On 2011-02-10, at 6:38 AM, Meng Xin Zhu wrote:
>>> Hi all,
>>> Do you have the experience to install lots of frequently used features in different eclipse instances? They might be your home and office workstations. You need set up very similar development environments on Windows and Linux.
>>> You have to manually search the location of repository, then add it into eclipse, install them one by one. I think it's a pain for me, installing the same CDT, Mylyn, Subversion, Clearcase and so on for my multiple eclipse on different machines.
>>> I implemented a plug-in[1] to export the list of installed feature to a file, then other eclipse could quickly install the all/part of features listed in that file.
>>> The exported configuration file is simple, which records the id of top IU of exported features and the repository location of those features.
>>> The plug-in would load those repository location firstly then install those top IUs when importing the configuration file in another eclipse instance.
>>> The plug-in also could import the installed features of another eclipse that could save a lot of time to download the artifacts especially the network is slow and unstable.
>>> Meanwhile I see the similar topic in bugzilla[2]. I think it might be a common requirement, I would like to contribute this feature to p2 itself. And I would like to hear more comments from p2 community. :)
>>> [1] http://marketplace.eclipse.org/content/p2-installation-replication
>>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=282419
>>> --
>>> Best Regards
>>> Meng Xin Zhu
>>> _______________________________________________
>>> p2-dev mailing list
>>> p2-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>> _______________________________________________
>> p2-dev mailing list
>> p2-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/p2-dev
> --
> Best Regards
> Meng Xin Zhu
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev

p2-dev mailing list