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<http://www.eclipse.org/epf/general/getting_started.php>page.
Thanks again Bjorn for sharing this! Best Regards, Onno On Mon, Mar 1, 2010 at 9:48 PM, Onno van der Straaten < [email protected]> 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, > Onno > > > > On Wed, Feb 24, 2010 at 7:07 PM, The Viking on the French Riviera < > [email protected]> 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:* [email protected] [mailto:[email protected]] >> *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 <http://www.eclipse.org/epf/general/getting_started.php> 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 < >> [email protected]> 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 [email protected] 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 >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/epf-dev >>> >>> >> >> _______________________________________________ >> 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
