[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[pde-ui-dev] Re: [eclipse-pmc] Build on the plan
|
> 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