Re: [stp-dev] CVS Commits

[Michael Elder <mdelder@xxxxxxxxxx>]

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