Mark, thanks for your comments.

Currently, the libraries are not separated - OpenUP/DSDM plug-in is part 
of the OpenUP library. There are two separate published web sites though.
My discussion below is indeed relevant to development, as I pointed out. 
>From user perspective, the request is to be able to download plug-ins one 
by one, as needed (see newsgroup for original posting).

Solution b) below is the workaround proposed to the user in the newsgroup.
Solution a) below is the alternative I'm considering for discussion with 
you all. There are pros and cons, as you would expect, that's why I'm 
bringing to the committers' attention - the decision is whether we make 
our lives or EPF users lives easier :-)

I'd love to have the capability of referencing external libraries too, but 
EPF Composer does not provide that.

Cheers,

Ricardo Balduino
IBM Rational Software (www.ibm.com/rational)
Eclipse Process Framework (www.eclipse.org/epf)




[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
08/07/2007 11:29 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@eclipse.org>


To
"Epf" <epf-dev@eclipse.org>
cc

Subject
Re: [epf-dev] Evolving the OpenUP Family






Hi
I won't be able to join the call tomorrow, so here's what I think about 
this.
This looks like a publishing issue. We can rsikly make the libraries 
available as separate downloads very easily. I think that is what we do 
right now.
The majority of the discussion in Ricardo's note seems to address the 
structure of the CVS repository. This seems to me to be development 
concern rather than an end user issue. 
Speaking from hard learned experience, I can say that I definitely do not 
want to be working with the scenario as described. Plugins in the OpenUP 
family should reside in the same library (or EMC should have functionality 
added to enable external libraries to be referenced, as per RMC).
If this really is an end-user issue, then it is a simple matter for users 
to either:
a) download the discrete libraries from the download page; or
b) download the library from CVS and delete the plugins they don't want.

For development, it is much better to leave things in the same library.

Kind regards

Mark
Mark Dickson
EAS Practice
Xansa
0780 1917480
*** sent from my blackberry ***

  ----- Original Message -----
  From: Ricardo Balduino [EMAIL PROTECTED]
  Sent: 08/07/2007 07:04 PM
  To: epf-dev@eclipse.org
  Subject: [epf-dev] Evolving the OpenUP Family


Hi all, sorry for the long email, but I think it's an important topic for 
our planning meeting tomorrow. 

We've got some user feedback expressing it would be much easier to 
assemble libraries with various plug-ins as needed, meaning the OpenUP 
library by default should contain base_concepts and openup plug-ins only, 
then any additions could be download from Eclipse web site. In other 
words, one wants to download OpenUP without having to deal with other 
plug-ins they don't plan to use on near or long term. 

As this is simple to solve from the user perspective, it may pose some 
challenges from content development perspective. 

- From user perspective, EPF Composer offers today the capability for 
exporting and importing plug-ins. We can simply provide OpenUP library 
with openup and base_concepts plug-ins only, then users pick and choose 
any OpenUP/xyz from EPF web site and import it to their library. The web 
site download area would be populated with these plug-ins. For user's 
convenience, we can periodically publish these various configurations and 
make it readily available for download. 

- From development perspective, every extension to OpenUP plug-in should 
*ideally* be created in the OpenUP library itself, because it makes it 
easier from the version control perspective to handle the various xmi 
files individually. If you separate plug-ins in different libraries, 
plug-in authors will have to keep copies of OpenUP in a sandbox location, 
develop their plug-ins as extension to OpenUP, export those plug-ins from 
time to time, add them to CVS as a zip file, them make available for 
download by users. We loose granularity in our version control, and are 
obliged to keep local copies of OpenUP library. 
UNLESS these sandbox locations are also in CVS, in a different branch than 
the main OpenUP library. Authors can work on their plug-ins and commit 
individual xmi files to CVS - the only caveat for plug-in authors is to 
keep this sandbox OpenUP up-to-date with most current main OpenUP. Exports 
of their plug-ins would occur as part of periodically builds, so plug-ins 
can be made available in the download area. 
That approach tries to solve the fact that EPF Composer does not work with 
multiple projects from different workspaces. 

Conclusion: I don't believe separating the OpenUP extensions from the main 
OpenUP library in CVS will harm the concept of OpenUP Family. Moreover, 
that makes it easier for plug-ins to evolve at different pace than the 
OpenUP library itself is evolving, and multiple authors can work their 
solution in parallel. Also, those authors can take the responsibility of 
uploading their plug-ins and updating the web site themselves- sort of 
sharing web master's responsibilities :-) 

What is your take on this? We can discuss it during our planning meeting 
tomorrow. 

Thanks, 

Ricardo Balduino
IBM Rational Software (www.ibm.com/rational)
Eclipse Process Framework (www.eclipse.org/epf)

Whilst this email has been checked for all known viruses, recipients 
should undertake their own virus checking as Xansa will not accept any 
liability whatsoever.

This email and any files transmitted with it are confidential and 
protected by client privilege. It is solely for the use of the intended 
recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
Xansa, Registered Office: 420 Thames Valley Park Drive,
Thames Valley Park, Reading, RG6 1PU, UK.
Registered in England No.1000954.
t +44 (0)8702 416181
w www.xansa.com_______________________________________________
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

Reply via email to