Did anyone else have any opinions on this? Would everyone really
prefer to navigate two extra folder levels in CVS to get to plugins?
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / Services Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
*Michael Elder/Cambridge/IBM@IBMUS*
Sent by: stp-dev-bounces@xxxxxxxxxxx
04/06/2006 03:06 PM
Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>
To
STP Dev list <stp-dev@xxxxxxxxxxx>
cc
STP Dev list <stp-dev@xxxxxxxxxxx>, stp-dev-bounces@xxxxxxxxxxx
Subject
Re: [stp-dev] CVS Commits
Hi Naci,
I'm going to jump out here and disagree with you just a little
-- so perhaps it would be good to get feedback from the community as a
whole on this topic to make a more formal decision ...
I may have jumped the gun in contributed the core plugins to
the repo (last Friday), but I went with a flat structure (in
conformance with the base Eclipse approach) instead of the WTP layout
because I think that it makes it easier to find things. Having more
structure does potentially make it more "scalable" I suppose, but if
we follow the pattern in WTP, most folders only expand to show 3-7
children. I think this adds more effort to actually find plugins or
features that you're looking for. I think the subproject folders makes
sense, but I would end the "componentization" in the CVS repo at that
point. We can always create features to combine these plugins into any
number of consumeable units; the CVS structure doesn't necessarily
have to mimic those units.
I do like the idea of having Team Project Sets defined that
would provide a quick start for fetching all plugins in a logical
unit. One of my TODO items is to push out a Team Project Set for the
STP Core plugins to make it easier for teams to consume. I had planned
to add a "org.eclipse.stp.core.releng" plugin to define the *.map
files and *.psf files for the STP Core project. If you prefer a
different structure or project name for this, I can go along with it.
I like "releng" in the name since that is the pattern that Eclipse
proper forms, and it makes it easier when looking for this plugin for
each subproject.
I'll throw out the caveat that having a "features" directory
just under each subproject directory might make sense; but I do like
having all plugins in the subproject directory so that you can see
everything that's available, and fetch what you want. If we have 10
plugins in each subproject, we're still going to be fine; I'd prefer
to see all 10 function and test plugins rather than 3 "CVS component"
folders that each contain 3-4 plugins individually.
I also like having the <subproject>.tests.* plugins on the same
level as the functional plugins to reinforce the mentality that tests
are not an after thought; if you check out any plugin, you should
bring along its corresponding test plugins and be sure that you (1)
don't break tests before you release and (2) add new tests where
appropriate. This is the Eclipse Home Repo style
(dev.eclipse.org/home/eclipse -- Platform/JDT/PDE), and it's my
preference, but I'll go along with the decision from the community
either way.
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / Services Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
*Naci Dai <naci.dai@xxxxxxxxxxxxx>*
Sent by: stp-dev-bounces@xxxxxxxxxxx
04/06/2006 11:38 AM
Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>
To
STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject
[stp-dev] CVS Commits
It is great to see more code in CVS. So my sincere apologies to taint
such an event for a bit of process and organizational stuff - I will use
the *[STP_Project]
<http://dev.eclipse.org/viewcvs/index.cgi/?cvsroot=STP_Project#dirlist>
/ org.eclipse.stp.core sub project* as an example, but these comments
are more general than those.
The STP project is divided in to sub project and each has a root folder
in CVS tree:
(dir) org.eclipse.stp.b2j/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.b2j/?cvsroot=STP_Project>
(dir) org.eclipse.stp.bpmn/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.bpmn/?cvsroot=STP_Project>
(dir) org.eclipse.stp.contrib/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.contrib/?cvsroot=STP_Project>
(dir) org.eclipse.stp.core/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/?cvsroot=STP_Project>
(dir) org.eclipse.stp.servicecreation/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.servicecreation/?cvsroot=STP_Project>
(dir) org.eclipse.stp.soas/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.soas/?cvsroot=STP_Project>
We need to organize a little better under the projects to scale better
in the future. Instead of commiting the plugins, tests and features as
flat hierarchy, I will suggest that these are divided to features,
plugins and tests as initial sub-containers. For example, if we
transform the core project in this manner, it will look like:
org.eclipse.stp.core
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core/?cvsroot=STP_Project>
features/
org.eclipse.stp.core
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core/?cvsroot=STP_Project>
org.eclipse.stp.core-sdk
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core/?cvsroot=STP_Project>
org.eclipse.stp.core-tests
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core/?cvsroot=STP_Project>
plugins/
(dir)org.eclipse.stp.core/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core/?cvsroot=STP_Project>
(dir)org.eclipse.stp.core.infrastructure.emf/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core.infrastructure.emf/?cvsroot=STP_Project>
tests/
(dir)org.eclipse.stp.core.tests/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core.tests/?cvsroot=STP_Project>
(dir)org.eclipse.stp.core.tests.infrastructure/
<http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.stp.core/org.eclipse.stp.core.tests.infrastructure/?cvsroot=STP_Project>
Same applies to all other sub projects.
If it is ok with everybody, we will refactor these components and ask
the webmaster to remove the others.
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
------------------------------------------------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
