Re: [eclipse-pmc] Build on the plan

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

> It would be great to have a wiki page for people to contribute ideas and 

> thoughts to.  Not everyone who might contribute to PDE is currently a 
> PDE committer.  Can we coopt http://wiki.eclipse.org/PDE/Ideas for that 
> purpose?  Note I am distinguishing here between what people want and 
> what they are willing to contribute. Both are interesting. 

The WIKI and the pde-ui-dev mailing list are fine places for gathering 
ideas (in fact, let's move this discussion to pde). The plan, now 
available at http://www.eclipse.org/pde/pde-ui/dev_plans/r3_5/plan.php, is 
simply a more solid combinatoin of the WIKI and mailing list - where 
people can committ to work items for 3.5.

> 
> > * Support target platform definition by creating/modifying a p2 
> > installation of bundles (download and install bundles into a target 
from 
> > update sites) 
> > 
> Can you clarify the intentions here?  "Create/modify a p2 installation" 
> I read as "... p2 profile" but the download/install part does not 
> necessarily match.  Having the target as an actual profile is sort of 
> interesting but it is not clear that one would want to (or can) actually 

> "install/configure" things into the target "profile".  Before going into 

> all the issues, can you clarify the intent?

How does one start a sentence with p2? :-) Target management/definition is 
basically keeping track of which bundles are in which configuration. This 
sounds alot like something p2 can do as well (at a slightly differnet 
level - IUs?). Using p2 adds power to the story of provisioning target 
platforms.

I agree that sometimes users just want to do something less structured - 
like point to a directory of bundles that might not even execute or be 
complete w.r.t required bundles. However, perhaps we can also use p2 in 
this case? (dunno).

Leveraging a p2 API to understand what is in a target and to add things to 
it would make PDE more flexible to changes in the underlying runtime. 
Currently there is a lot of brital code that assumes things about the 
shape of an install... we'd like to get out of that business.

> > * Support multiple target platform definitions in the workspace, with 
one 
> > active target platform that workspace projects are compiled against 
> > (preference page with check box for active target) 
> > * Investigate sharing target platform definitions with a development 
team 
> > * Source code should be installed in/part of a target platform (source 

> > bundles) rather than a global setting 
> > 
> How does this relate to target definition files? 

Good question. Target definition files were introduced for describing a 
target (and we need to keep them working). I'm wondering if we can enhance 
them, or if we need to create something more rich, or if we just have to 
support different target definition formats... Eventually we want to share 
portable target definitions with a team (platform and machine/file system 
path independent). If p2 had a mechanism for sharing profile descriptions, 
this would seem like a good avenue to investigate.

> 
> Stepping back, it would be very good to unify the way we talk about 
> targets, products, features and launch configs.  They all need the very 
> similar sets of function and currently there are several workflows that 
> are disjoint such that you really "can't get there from here" (try 
> creating an Equinox based app e.g., servers in which you want the 
> launcher etc but are not using product/app extensions...)

Exactly - we need better integration and simpler work flow.

> > * Support target management for non-p2 installs (update manager) in a 
> > similar fashion
> > 
> What is the motivation for supporting update manager scenarios with new 
> tooling?  I agree completely with good support for non-p2 based systems 
> but am not sure about the demand for new fancy tooling for update 
> manager scenarios (unless it just works)

Backwards compatibility. We are always fighting with this... but if we can 
use p2 to understand what's in a target, we also want to use update 
manager to manipulate pre-p2 targets. I'm not sure what the right 
terminology is here... but perhaps its just a matter of using the right 
"configurator manipulator" :-) Who cares if it's p2 or update manager 
underneath. PDE just needs to be insulated from having to understand 
intricate details/shape of an install.

Darin