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.t...@gmail.com> 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-boun...@eclipse.org [mailto:epf-dev-boun...@eclipse.org] *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 < > bjorn.t...@gmail.com> 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@eclipse.org 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@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/epf-dev >> >> > > _______________________________________________ > epf-dev mailing list > epf-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/epf-dev > >
_______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
