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 [email protected] 408-250-3037 (cell) The Viking on the French Riviera <[email protected]> Sent by: [email protected] 02/10/2010 10:10 AM Please respond to Eclipse Process Framework Project Developers List <[email protected]> To "'Eclipse Process Framework Project Developers List'" <[email protected]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
