[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] CVS Commits


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