Home » Archived » EPF » Q: How do I avoid circular references and get the job done
|
Re: How do I avoid circular references and get the job done [message #27962 is a reply to message #27882] |
Mon, 29 January 2007 20:16 |
Eclipse User |
|
|
|
Originally posted by: phaumer.xxx.com
Hello Rob.
You got it right. A bit of architectural layering is required here. You
can move elements up a layer or move elements down a layer. You could
set-up a hierarchy of base plug-ins (i.e. more than one base plug-in; higher
layer) if it is possible to partition the interdependent content. You can
also create integration plug-ins (lower layer) that depend on the plug-ins
that they integrate and use contribution to add cross-plug-in relationships.
For example, the integration plug-in could contains tasks that contribute to
a base task input/output relationships to work products from the different
plug-ins that you want to integrate.
--
Thanks and best regards,
Peter Haumer.
____________________________________________________________ __
PETER HAUMER
IBM | Eclipse Process Framework Committer
____________________________________________________________ __
"Rob Robason" <rob.robason@windriver.com> wrote in message
news:epdvle$mbn$1@utils.eclipse.org...
> After experiencing the cons of creating circular references, I'm eager to
> avoid that in the future, but some of the plugins I'm working on seem to
> demand them. I'm looking for a way to structure my information to avoid
> catastrophe.
>
> I've opted to use Option 1: Organizing the content packages along the
> major areas of concern of the plug-in. from the Packaging Guidelines in
> the Plug-in Development Guide. My plugins are structured along the lines
> of the CMMI process areas.
>
> What I'm finding now is that dependencies between process areas are
> forcing me to move more and more content into my top level plugin in order
> to avoid circular references.
>
> So here's my dilemma: I'd prefer to create a single plugin with multiple,
> per-process-area, content packages that can cross reference each other,
> but I need to have multiple people working on these materials in parallel,
> and collisions in the plugin.xmi file seem to preclude that approach.
>
> Am I missing something? Is there a way around this?
>
> --
> Rob Robason
> Software Process Manager
> Wind River Systems
>
|
|
| |
Re: Q: How do I avoid circular references and get the job done [message #28455 is a reply to message #27882] |
Fri, 02 February 2007 13:45 |
jan masaryk Messages: 50 Registered: July 2009 |
Member |
|
|
nice summary. :-)
I also feel dilemma between managing authoring of process areas (access
rights, reviewing)
and Method Plugin reference hell. :-)
what can help, is using continuos integration features/topics
as information summary of authoring changes in repository ...
Rob, what's your Method Library structure now?
How do you manage authoring?
all the best,
jan
On Fri, 26 Jan 2007 23:34:22 +0100, Rob Robason
<rob.robason@windriver.com> wrote:
> After experiencing the cons of creating circular references, I'm eager to
> avoid that in the future, but some of the plugins I'm working on seem to
> demand them. I'm looking for a way to structure my information to avoid
> catastrophe.
>
> I've opted to use Option 1: Organizing the content packages along the
> major
> areas of concern of the plug-in. from the Packaging Guidelines in the
> Plug-in Development Guide. My plugins are structured along the lines of
> the
> CMMI process areas.
>
> What I'm finding now is that dependencies between process areas are
> forcing
> me to move more and more content into my top level plugin in order to
> avoid
> circular references.
>
> So here's my dilemma: I'd prefer to create a single plugin with multiple,
> per-process-area, content packages that can cross reference each other,
> but
> I need to have multiple people working on these materials in parallel,
> and
> collisions in the plugin.xmi file seem to preclude that approach.
>
> Am I missing something? Is there a way around this?
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| | |
Re: Q: How do I avoid circular references and get the job done [message #575813 is a reply to message #27882] |
Fri, 02 February 2007 13:45 |
jan masaryk Messages: 50 Registered: July 2009 |
Member |
|
|
nice summary. :-)
I also feel dilemma between managing authoring of process areas (access
rights, reviewing)
and Method Plugin reference hell. :-)
what can help, is using continuos integration features/topics
as information summary of authoring changes in repository ...
Rob, what's your Method Library structure now?
How do you manage authoring?
all the best,
jan
On Fri, 26 Jan 2007 23:34:22 +0100, Rob Robason
<rob.robason@windriver.com> wrote:
> After experiencing the cons of creating circular references, I'm eager to
> avoid that in the future, but some of the plugins I'm working on seem to
> demand them. I'm looking for a way to structure my information to avoid
> catastrophe.
>
> I've opted to use Option 1: Organizing the content packages along the
> major
> areas of concern of the plug-in. from the Packaging Guidelines in the
> Plug-in Development Guide. My plugins are structured along the lines of
> the
> CMMI process areas.
>
> What I'm finding now is that dependencies between process areas are
> forcing
> me to move more and more content into my top level plugin in order to
> avoid
> circular references.
>
> So here's my dilemma: I'd prefer to create a single plugin with multiple,
> per-process-area, content packages that can cross reference each other,
> but
> I need to have multiple people working on these materials in parallel,
> and
> collisions in the plugin.xmi file seem to preclude that approach.
>
> Am I missing something? Is there a way around this?
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Goto Forum:
Current Time: Thu Sep 26 20:27:14 GMT 2024
Powered by FUDForum. Page generated in 0.08657 seconds
|