Home » Eclipse Projects » Equinox » [p2] and a new way to work
| [p2] and a new way to work [message #111069] |
Fri, 30 May 2008 17:56  |
Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
Hi [p2] Equionx team
With Eclipse 3.4 just around the corner, and p2 coming together nicely,
I was wondering about a new way to structure my eclipse workflow. Does
this seam technically feasible (and a good idea).
Three directories
/eclipse_3_4
/eclipse_3_5
/bundlePool
/eclipse_3_4 would be my install when Eclipse 3.4 GAs.
/eclipse_3_5 would be an install when Eclipse 3.5 M1 comes out
/bundlePool holds all the bundles for both these (plus any other
bundles, GEF, EMF, etc...)
I would like to keep 3.4 updated whenever new stable releases come out
(Fall / Winter maintenance), and I would like 3.5 to update whenever new
milestones are available. Also, I would be nice to be able to set my
target platform for 3.5 to /eclipse_3_4 so I can test any work I do
against the Eclipse 3.4 release but still use all the fancy development
features of 3.5.
Is this possible? Are the particular update sites for milestones vs.
stable releases available (obviously 3.5 milestones are not available
yet). Does this seem like a reasonable way to work?
Cheers,
Ian
|
|
|
| Re: [p2] and a new way to work [message #111093 is a reply to message #111069] |
Fri, 30 May 2008 19:31  |
 Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
Ian,
This is *exactly* how we are envisioning things!
2 details:
- In order to control what you get in each install, simply control the set
of repositories you make available in each install.
- Make that the p2 folder used to manage those 2 installs is the same.
PaScaL
"Ian Bull" <irbull@cs.uvic.ca> wrote in message
news:g1pf4j$6v6$1@build.eclipse.org...
> Hi [p2] Equionx team
>
> With Eclipse 3.4 just around the corner, and p2 coming together nicely, I
> was wondering about a new way to structure my eclipse workflow. Does this
> seam technically feasible (and a good idea).
>
> Three directories
> /eclipse_3_4
> /eclipse_3_5
> /bundlePool
>
> /eclipse_3_4 would be my install when Eclipse 3.4 GAs.
> /eclipse_3_5 would be an install when Eclipse 3.5 M1 comes out
> /bundlePool holds all the bundles for both these (plus any other bundles,
> GEF, EMF, etc...)
>
> I would like to keep 3.4 updated whenever new stable releases come out
> (Fall / Winter maintenance), and I would like 3.5 to update whenever new
> milestones are available. Also, I would be nice to be able to set my
> target platform for 3.5 to /eclipse_3_4 so I can test any work I do
> against the Eclipse 3.4 release but still use all the fancy development
> features of 3.5.
>
> Is this possible? Are the particular update sites for milestones vs.
> stable releases available (obviously 3.5 milestones are not available
> yet). Does this seem like a reasonable way to work?
>
> Cheers,
> Ian
|
|
|
| Re: [p2] and a new way to work [message #111143 is a reply to message #111093] |
Fri, 30 May 2008 19:49 |
| Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
Cool,
Do you know if the target platform works? i.e. if I point my target
platform in Eclipse 3.5 /eclipse_3_4 will it properly resolve the
bundles in the pool.
1) Are the repositories published yet? i.e. do you know where
milestones and stable builds will be published?
2) What do you mean by make the p2 folder used to manage those 2
installs the same? Won't the bundle pool do this for us?
Finally, it would be really cool to provide a D/L of the SDK as a
repository (with the artifacts and content.xml + binaries / launcher
etc...). This way we can update the installs off-line. p2 seems to
search plug-in and feature directories and can use these for updates,
but the launcher and other things are not available.
Cheers,
ian
Pascal Rapicault wrote:
> Ian,
>
> This is *exactly* how we are envisioning things!
> 2 details:
> - In order to control what you get in each install, simply control the set
> of repositories you make available in each install.
> - Make that the p2 folder used to manage those 2 installs is the same.
>
> PaScaL
>
> "Ian Bull" <irbull@cs.uvic.ca> wrote in message
> news:g1pf4j$6v6$1@build.eclipse.org...
>> Hi [p2] Equionx team
>>
>> With Eclipse 3.4 just around the corner, and p2 coming together nicely, I
>> was wondering about a new way to structure my eclipse workflow. Does this
>> seam technically feasible (and a good idea).
>>
>> Three directories
>> /eclipse_3_4
>> /eclipse_3_5
>> /bundlePool
>>
>> /eclipse_3_4 would be my install when Eclipse 3.4 GAs.
>> /eclipse_3_5 would be an install when Eclipse 3.5 M1 comes out
>> /bundlePool holds all the bundles for both these (plus any other bundles,
>> GEF, EMF, etc...)
>>
>> I would like to keep 3.4 updated whenever new stable releases come out
>> (Fall / Winter maintenance), and I would like 3.5 to update whenever new
>> milestones are available. Also, I would be nice to be able to set my
>> target platform for 3.5 to /eclipse_3_4 so I can test any work I do
>> against the Eclipse 3.4 release but still use all the fancy development
>> features of 3.5.
>>
>> Is this possible? Are the particular update sites for milestones vs.
>> stable releases available (obviously 3.5 milestones are not available
>> yet). Does this seem like a reasonable way to work?
>>
>> Cheers,
>> Ian
>
>
|
|
|
| Re: [p2] and a new way to work [message #111847 is a reply to message #111143] |
Fri, 13 June 2008 01:34 |
Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
> 1) Are the repositories published yet? i.e. do you know where milestones
> and stable builds will be published?
Nothing on the radar yet. We will decide that once we have something to
publish there :)
> 2) What do you mean by make the p2 folder used to manage those 2 installs
> the same? Won't the bundle pool do this for us?
bundle pool and p2 folders are two orthogonal concepts dealing at 2
different levels of abstraction.
The p2 folder contains the profile registry. The profile registry refers
to a set of profiles, and a profile is a p2-level description of what an
installation is made of in terms of IU.
A bundle pool is simply an artifact repository where artifacts have been
added as a result of an install.
> Finally, it would be really cool to provide a D/L of the SDK as a
> repository (with the artifacts and content.xml + binaries / launcher
> etc...). This way we can update the installs off-line. p2 seems to
> search plug-in and feature directories and can use these for updates, but
> the launcher and other things are not available.
Not sure what you mean when you say "launchers" are not available.
As for the dl of the repo, I'm not so keen on the idea. Instead we are
providing mirroring applications. They are not yet super-smart (they don't
do dependency analysis from a root) but they do allow for duplication of
repo. See for some details in the help.
HTH,
PaScaL
>
> Cheers,
> ian
>
> Pascal Rapicault wrote:
>> Ian,
>>
>> This is *exactly* how we are envisioning things!
>> 2 details:
>> - In order to control what you get in each install, simply control the
>> set of repositories you make available in each install.
>> - Make that the p2 folder used to manage those 2 installs is the same.
>>
>> PaScaL
>>
>> "Ian Bull" <irbull@cs.uvic.ca> wrote in message
>> news:g1pf4j$6v6$1@build.eclipse.org...
>>> Hi [p2] Equionx team
>>>
>>> With Eclipse 3.4 just around the corner, and p2 coming together nicely,
>>> I was wondering about a new way to structure my eclipse workflow. Does
>>> this seam technically feasible (and a good idea).
>>>
>>> Three directories
>>> /eclipse_3_4
>>> /eclipse_3_5
>>> /bundlePool
>>>
>>> /eclipse_3_4 would be my install when Eclipse 3.4 GAs.
>>> /eclipse_3_5 would be an install when Eclipse 3.5 M1 comes out
>>> /bundlePool holds all the bundles for both these (plus any other
>>> bundles, GEF, EMF, etc...)
>>>
>>> I would like to keep 3.4 updated whenever new stable releases come out
>>> (Fall / Winter maintenance), and I would like 3.5 to update whenever new
>>> milestones are available. Also, I would be nice to be able to set my
>>> target platform for 3.5 to /eclipse_3_4 so I can test any work I do
>>> against the Eclipse 3.4 release but still use all the fancy development
>>> features of 3.5.
>>>
>>> Is this possible? Are the particular update sites for milestones vs.
>>> stable releases available (obviously 3.5 milestones are not available
>>> yet). Does this seem like a reasonable way to work?
>>>
>>> Cheers,
>>> Ian
>>
|
|
|
Goto Forum:
Current Time: Tue Apr 23 10:32:56 GMT 2024
Powered by FUDForum. Page generated in 0.02981 seconds |
] 
Search
Help
Register
Login
Home
