[platform-vcm-dev] RE: RFC: Envy config map like feature for Eclipse

["Rolf Wilms" <rwilms@xxxxxxxxxxxxxx>]

Kevin,

thank you for your feedback. See my comments below. Please correct me if
you think I'm wrong.

Regards,
            Rolf

<kevin_mcguire@xxxxxxx> wrote in news:akm0a7$hnm$1@xxxxxxxxxxxxx...
> John's comment was right - I almost missed this and its of interest to us
> (VCM).  Its something we've discussed in the past (not surprisingly).

Ok, sent it to the vcm mailing list, this post will go there too.
> Q: Are you talking about config maps for any repository type, or just for
> CVS?  If any, how did you envision it would work (ie. what would the API
> look like for providers?).

The plan is to use the IProjectSetSerializer to reference / load projects.
If this is possible, all repository types providing an
org.eclipse.team.core.projectSets extension should work.
If this is not possible, we'd have to implement our own mechanism to
reference / load projects. We would implement one for CVS and might provide
an extension point so that other repository types could add their reference
/ load mechanism.

After all, the planned "config map like feature" is not that different from
TeamSets. It would basically add management of  TeamSet files in their own
projects, nesting/recursive loading, showing conflicts and differences to
the loaded state.

> Q: Are you interested in doing this work as part of the Eclipse open
source
> effort, perhaps as part of the SDK or perhaps as an add-in?

Yes, we are interested in doing this work as part of the Eclipse open
source
effort and we do have management support for this. The plan is to provide
one or more plug-ins which can simply be added. If these plug-ins could be
moved into the SDK, even better.

> Q: As you know, project's can have references to other projects.  Do
these
> factor in in any way?
Not necessarily. In the first place I would see config maps and
project references as independent. But there may be exceptions, i.e. when
adding projects to a config map, it might be a useful option
to automatically add referenced projects to that map.

I also do not think that project references need to influence the project
load order. After a load has been completed, a build can be done.

>
> Cheers,
> Kevin
>
>
>
>
> "Rolf Wilms" <rolf_wilms@xxxxxxxxxxx> wrote in message
> news:akjbo9$5sd$1@xxxxxxxxxxxxx...
> > We (CSC Germany) are considering to implement an Envy config map like
> > feature for Eclipse as a part of the upcoming Eclipse-based IDE for our
> > proprietary insurance products. I believe that this Envy config map
like
> > feature could be useful in general for managing Eclipse projects.
> >
> > This is a rough outline how this could look like and I'd appreciate
your
> > feedback.
> >
> > Regards,
> >             Rolf
> >
> > Requirements:
> >
> > - be nestable
> > - load dependent config maps and projects
> > - visualize difference between defined dependent project version and
> actual
> > version / locally modified state
> > - add project to map
> > - delete project from map
> > - replace defined project with another project version
> > - "qualified" versioning requires that all defined projects are
versions
> > - be versionable
> > - unconditionally load config maps and dependent config maps, even if
> > conflicts occur
> > - conflicts are i.e. different versions of the same project defined in
> > different config maps
> > - list conflicts as tasks / show problem markers
> > - show list of conflicting maps for a load conflict
> >
> > Implementation:
> >
> > - implementation uses one ore more plugins
> > - implement config maps using projects
> > - maybe introduce new project nature for config map projects
> > - one extra project per config map, this means for each config map
there
> is
> > one separate project
> > - use team set file structure as config map definition, manage the team
> set
> > file in the associated project
> > - implement new config map wizard, creating empty team set file
> > - implement editor / viewer displaying defined, available, difference
to
> > loaded state...
> > - implement qualified versioning command (prevent qualified versioning
if
> > not all projects are versions or conflicts present)
> > - implement 'recursively load dependents' command
> > - implement validate (build?) creating/deleting tasks and conflict
markers
> >
> >
> >
>
>