[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi all, Bjorn,
The review is complete and the content was approved. I added the manual to the CVS repository and updated the
Getting Started page.
Thanks again Bjorn for sharing this!
Best Regards,
Onno
On Mon, Mar 1, 2010 at 9:48 PM, Onno van der Straaten
<onno.van.der.straaten@xxxxxxxxx> wrote:
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,
OnnoOn 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
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
