On Fri, Feb 11, 2011 at 10:28 PM, Pascal Rapicault <[email protected]>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
> >>> [email protected]
> >>> https://dev.eclipse.org/mailman/listinfo/p2-dev
> >>
> >> _______________________________________________
> >> p2-dev mailing list
> >> [email protected]
> >> https://dev.eclipse.org/mailman/listinfo/p2-dev
> >
> >
> > --
> >
> > Best Regards
> > Meng Xin Zhu
> > _______________________________________________
> > p2-dev mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/p2-dev
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
