[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
