Re: [epf-dev] Evolving the OpenUP Family

[Mark.Dickson@xxxxxxxxx]

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 [balduino@xxxxxxxxxx]
  Sent: 08/07/2007 07:04 PM
  To: epf-dev@xxxxxxxxxxx
  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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev