Skip to main content

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

Hi all,
I created an IPZilla for this https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3824 and attached the files to it. After approval from Eclipse Legal we can add EPL statement to the document and publish it on the EPF website.
@Bjorn: only committer members can access the URL above I think but I will keep you informed on the progress.
Best Regards,
Onno


On Wed, Feb 24, 2010 at 7:07 PM, The Viking on the French Riviera <bjorn.tuft@xxxxxxxxx> wrote:
Hi Onno,
 
The idea is to contribute the document to the EPF community.
 
I also intend to continue to enhance it and it would nice to have the document reviewed.  There are some open questions in the document which I think should be closed.
 
I can send the word document to anyone interested.
 
Thanks for positive reactions.
 
Best regards,
 
Bjorn


From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Onno van der Straaten
Sent: Wednesday, February 24, 2010 9:53 AM

To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] EPF Manual

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,
Onno

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.
 
Regards,
 
Bjorn
 

Bjorn Tuft

_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev



_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev



Back to the top