Re: [epf-dev] EPF Installation and User Manual

[Bruce Macisaac <bmacisaa@xxxxxxxxxx>]

Hi Bjorn,

The separation of process plug-ins from
method plug-ins is a good architectural pattern that we used for the practices.
However, I'm not convinced that we need
to enforce this by having separate plug-in types in the tool .  While
it is often good to define processes that cross plug-ins (which is what
you see in the practices library), we also have cases where plug-ins want
to show a typical workflow, and it helps to keep that in the same plug-in.

The need for a 'default configuration'
for a process is going away - because you're right - it makes things too
convoluted.
Hopefully that will address your concern.

Bruce MacIsaac
Manager RMC Method Content
bmacisaa@xxxxxxxxxx
408-250-3037 (cell)

The Viking on the French Riviera <bjorn.tuft@xxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx

02/10/2010 10:10 AM

Please respond to
Eclipse Process Framework Project Developers List        <epf-dev@xxxxxxxxxxx>

To	"'Eclipse Process Framework Project Developers List'" <epf-dev@xxxxxxxxxxx>
cc
Subject	[epf-dev] EPF Installation and User Manual

Please find included a document with an EPF Installation,
Tutorial and Manual which I have written.  The starting point was
the help files and for the rest I relied on trying out the product.  I
am a novice user of the application and thought it was the most appropriate
moment for documenting it.  Since there is a risk that some statements
may not be correct, I would be most grateful for input.  Gerhard has
already helped with the installation part.
 
One point bothered me in the EPF Composer.  I would have found it
more natural to have the Plug-ins split into two different types: Method
Plug-ins and a Process Plug-ins.  It does not seem natural, once the
subject area has been nicely decomposed into an hierarchical model with
sub-areas having their own plug-ins and content packages, to have to have
processes in one of these plug-ins access the method content in the other
plug-ins.  The need for the processes to use the services of an outside
service, i.e. a default configuration, to be able to access the content
in the other plug-ins, makes it even more convoluted.  It would be
more logical to separate out the processes code from the method content
plug-in into a process plug-in type and move/copy the code from the configuration’s
"Plug-in and Package" selection over to this new plug-in type
so that the process by its very nature can access other method content
plug-ins/packages.  The Configuration would then no longer have the
hybrid functions of both providing access assistance to processes and configuration
for publishing.  It would seem to be a cleaner separation: the method
content plug-in provides static method content, the process plug-in provides
processes and configuration provides configurations for publishing.
 
It seems that the authors of EPF Practices have made the same observation,
since they have created a method plug-in with the name of "Process",
accessing content packages in the "Practice" method content plug-in.
Regards,
 
Bjorn[attachment "EPF_Tutorial_2010024_v14.doc"
deleted by Bruce Macisaac/Cupertino/IBM] [attachment "EPF_Tutorial_2010024_v14.pdf"
deleted by Bruce Macisaac/Cupertino/IBM] _______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev