[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] Evolving the OpenUP Family

Another possibility is to use a new capability in EPF Composer that we'
ve been starting to take advantage of at IBM. The browser now displays
plug-ins hierarchically by interpreting the dot notation of the plug-in
name. So if we name plug-ins something like opn.openup, opn.extend.dsdm,
core.base_concepts, etc., The result would look something like this
(assuming we created Scrum and GDD plug-ins):

 



 

All the plug-ins that extend OpenUP would be hidden under the extend
package. This would also set us up for having base OpenUP exist in
multiple plug-ins in the future (under the opn package). 

 

- Jim

 

____________________

Jim Ruehlin, IBM Rational

RUP Content Developer

Eclipse Process Framework (EPF) Committer www.eclipse.org/epf

email:   jruehlin@xxxxxxxxxx

phone:  760.505.3232

fax:      949.369.0720

 

________________________________

From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ricardo Balduino/Cupertino/IBM
Sent: Tuesday, August 07, 2007 3:42 PM
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] Evolving the OpenUP Family

 


>> If you *really* want to separate 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. 

I'm aware of your concerns in points 1, 2 and 3 below, Mark. 
And what I initially proposed reflects your comment extracted above. I
didn't mean to keep copies in local machines, but in different branches
in CVS. 
However, you have a good point on whether this approach scales or not,
as the plug-ins community grows and more and more dependencies are
needed between plug-ins. 

Thanks for giving your input, even with you kids bouncing on your head
:-) 

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




Mark.Dickson@xxxxxxxxx 
Sent by: epf-dev-bounces@xxxxxxxxxxx 

08/07/2007 02:19 PM 

Please respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>

To

"Epf" <epf-dev@xxxxxxxxxxx> 

cc

 

Subject

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, 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)



Mark.Dickson@xxxxxxxxx 
Sent by: epf-dev-bounces@xxxxxxxxxxx 

08/07/2007 11:29 AM 

Please respond to
Eclipse Process Framework Project Developers List
<epf-dev@xxxxxxxxxxx>

To

"Epf" <epf-dev@xxxxxxxxxxx> 

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 [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
_______________________________________________
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 

Attachment: image002.jpg
Description: JPEG image