[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epf-dev] EPF Manual

Thank you Bjorn for providing this user manual, and thank you Onno for volunteering to take care of this.

Just a couple thoughts: for appropriate tracking, there needs to be a Bugzilla item created with this contribution attached to it. The final document posted on the EPF web site will have to contain the standard EPL license statement at the bottom of each page. Given the length of this document, I'm afraid it will have to go through Eclipse legal approval. Onno, please confirm with emo-ip-team@xxxxxxxxxxx  if that is needed, or if just an attachment to Bugzilla will suffice.

Thanks again.

Ricardo Balduino.

From: Onno van der Straaten <onno.van.der.straaten@xxxxxxxxx>
To: Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
Date: 02/24/2010 12:53 AM
Subject: Re: [epf-dev] EPF Manual
Sent by: epf-dev-bounces@xxxxxxxxxxx

Hi Bjorn,
It got through in the end? I can see the text and I can open the file.

This looks to me like a very useful and comprehensive document on EPF. Nice work! Do you want to contribute this to the EPF community? If this is the case I think we can publish it on the EPF site with the other
Getting Started stuff. I am willing to take care of that if there are no objections to posting it there.

The developer list 'was' also used btw for sending inputs on EPF Composer but it has not been used that way recently. IMHO the dev list should be used this way, to discuss amongst other things, ideas on EPF Composer. The dev list discussion and sharing of ideas opinions could lead to a record being created in Bugzilla for more formal tracking of a change/request.

There is also a newsgroup but that group is more focused on supporting end users. So the newsgroup could also be a good place to share this work with the community. Or we can do both: add to the EPF site and share the link in the newsgroup.

Best Regards,

On Tue, Feb 23, 2010 at 3:37 PM, The Viking on the French Riviera <bjorn.tuft@xxxxxxxxx> wrote:
I must be doing something wrong in attempting to communicate with the EPF developer community.  I have sent the following text and file multiple times to the epf-dev@xxxxxxxxxxx list but it does not seem to get through.  I have noticed that the mailing list is mostly used for coordination purposes.  The wiki seems to be used for the practices and I am not quite sure how to send inputs concerning the EPF Composer itself.

I have written a manual for the EPF Composer, containing installation and configuration instructions, tutorials and a user manual.  It is a draft version, created from the help files and from the experience gathered while experimenting with the application.
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.

Bjorn Tuft

epf-dev mailing list


epf-dev mailing list