| Re: [epf-dev] Evolving the OpenUP Family |
Ricardo
Your original email threw me a bit there, as it opened by saying that you were prompted by feedback from the user community, which I took to mean "not the developer community." That's why I assumed we were discussing what is essentially a publishing issue.
I don't have access to the newsgroup discussion right now, so I cannot comment on the original post on the subject.
I have a substantial objection to the idea of seperating out the plugin(s) from the main OpenUP CVS repository. The approach of periodically uploading export files does not sound acceptable to me, as it means that the real source lives locally on someones machine, outside of the eclipse CVS servers. I see 3 problems with this:
1. We effectively limit plugin development to 1 user teams. This was a big problem for me on the openup/DSDM work, as it was very difficult to share the definitive source.
2. We have an obvious config mgmnt risk around source content residing on someone's personal computer.
3. I am not sure that this model of development is in the spirit of open source, as it does not allow unrestricted access to the latest source.
If you *really* want to seperate out the plugins from the core, then you will need to create a CVS location for each extending plugin and put a copy of OpenUP and base_concepts in there, so that more than 1 user can work on that plugin at a time.
Furthermore, if that plugin project wants to reuse content from other plugins in the OpenUP family, then guess what? You have to put copies of those plugins in there too.
As the plugin community grows, I am sure that this approach will quickly break down, as it doesn't look like it is going to scale too well.
It seems much simpler to me to keep the OpenUP family in one library. We can accommodate end user requirements through publishing discrete libraries for those who want them.
I am on holiday right now but am concerned enough about this issue to reply. I can't join the call though. Can I ask that you don't make any final judgement on this until I get back from leave on w/c Aug 20? I would like to discuss this in person as email exchanges don't always work too well as a discussion medium (especially if you're thumbing away on your blackberry while the kids are trying to bounce on your head).
Cheers
Mark
Mark Dickson
EAS Practice
Xansa
0780 1917480
*** sent from my blackberry ***
----- Original Message -----
From: Ricardo Balduino [balduino@xxxxxxxxxx]
Sent: 08/07/2007 08:25 PM
To: Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
Subject: Re: [epf-dev] Evolving the OpenUP Family
| Mark.Dickson@xxxxxxxxx
Sent by: epf-dev-bounces@xxxxxxxxxxx 08/07/2007 11:29 AM
|
|
----- 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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
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