Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EPF » Q: How do I avoid circular references and get the job done
Q: How do I avoid circular references and get the job done [message #27882] Fri, 26 January 2007 17:34 Go to next message
Rob Robason is currently offline Rob Robason
Messages: 72
Registered: July 2009
Member
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: How do I avoid circular references and get the job done [message #27962 is a reply to message #27882] Mon, 29 January 2007 15:16 Go to previous messageGo to next message
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: How do I avoid circular references and get the job done [message #28158 is a reply to message #27962] Thu, 01 February 2007 19:56 Go to previous messageGo to next message
Rob Robason is currently offline Rob Robason
Messages: 72
Registered: July 2009
Member
Thanks for confirming.

"Peter Haumer" <phaumer@xxx.com> wrote in message
news:eplknk$idc$1@utils.eclipse.org...
> 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 08:45 Go to previous message
jan masaryk is currently offline 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: How do I avoid circular references and get the job done [message #575559 is a reply to message #27882] Mon, 29 January 2007 15:16 Go to previous message
Peter Haumer is currently offline Peter Haumer
Messages: 228
Registered: July 2009
Senior Member
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: How do I avoid circular references and get the job done [message #575657 is a reply to message #27962] Thu, 01 February 2007 19:56 Go to previous message
Rob Robason is currently offline Rob Robason
Messages: 72
Registered: July 2009
Member
Thanks for confirming.

"Peter Haumer" <phaumer@xxx.com> wrote in message
news:eplknk$idc$1@utils.eclipse.org...
> 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 #575813 is a reply to message #27882] Fri, 02 February 2007 08:45 Go to previous message
jan masaryk is currently offline 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/
Previous Topic:compiling epf composer plugin
Next Topic:Re: Routing Feedback
Goto Forum:
  


Current Time: Fri Jul 25 06:44:12 EDT 2014

Powered by FUDForum. Page generated in 0.02519 seconds