| Re: [stem-dev] SVN Directory Structure |
I went back to look at some of the existing conventions, a few extra notes:
- Looks like UI components are generally not split from their underlying logic components. They exist in the same sub-directory, so an "rcp" top directory may not be necessary. For example, org.eclipse.stem.core and org.eclipse.stem.ui would probably stay together.
- I don't see a consistent pattern for "internal" projects, so maybe we just need to bin the components dealing with data into a "data" directory.
Stefan, we might want to bring some of your list up to a higher level in the structure (to be consistent with other projects). For example:
/trunk/components/core
/trunk/components/diseasemodels
/trunk/components/transport
/trunk/data(?)/geography
/trunk/data(?)/transport
/trunk/data(?)/diseasemodels
/trunk/releng
/trunk/utility
/trunk/doc
...etc
I guess the problem with being too granular is it makes it harder to checkout (instead of just selecting all the items from a singe list). An Eclipse Project Set for single checkout will be a nice entry in the releng folder or top-level.
Thoughts?
-Matt
stem-dev-bounces@xxxxxxxxxxx wrote on 06/03/2009 05:30:11 PM:
> Re: [stem-dev] SVN Directory Structure
>
> Stefan Edlund
>
> to:
>
> STEM developer mailing list
>
> 06/03/2009 05:30 PM
>
> Sent by:
>
> stem-dev-bounces@xxxxxxxxxxx
>
> Please respond to STEM developer mailing list
>
> Assuming we have to do this "split up" into components right now (so
> we don't create svn artifacts that we can't delete later). Otherwise
> I'd prefer if we made the move as painless as possible.
>
> So like:
>
> /trunk/components/core
> /trunk/components/rcp
> /trunk/components/geography
> /trunk/components/transport
> /trunk/components/diseasemodelling
> /trunk/components/releng
> /trunk/components/utility
> /trunk/components/doc
> ...
> Anything else? Where does internal.data belong containing the master
> ant script? Should we try and come up with a mapping table, old path
> -> new path for every project?
>
> / Stefan
>
>
> Stefan Edlund
> Public Health and Computer Science Research
> IBM Almaden Research Center
> (408) 927-1766 edlund@xxxxxxxxxxxxxxx
>
>
> [image removed] Daniel Ford ---06/03/2009 02:23:59 PM---Seems like a
> reasonable structure. Breaking out STEM so that diseases and
> geography are completely separate would be a good thi
>
> Daniel Ford <daford@xxxxxxxxxxxxxxx>
> Sent by: stem-dev-bounces@xxxxxxxxxxx
> 06/03/2009 02:21 PM
>
> Please respond to
> STEM developer mailing list <stem-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
> [image removed]
> STEM developer mailing list <stem-dev@xxxxxxxxxxx>
>
> [image removed]
> cc
>
> [image removed]
>
> [image removed]
> Subject
>
> [image removed]
> Re: [stem-dev] SVN Directory Structure
>
> [image removed]
>
> [image removed]
>
>
> Seems like a reasonable structure. Breaking out STEM so that
> diseases and geography are completely separate would be a good
> thing. Ideally, STEM would be a small RCP that then goes to an
> update site that pulls in the disease modeling and geography
> features that turn it into a disease modeling system (rather than
> something else) would be a good thing. The basic RCP and its
> "extensions" could be developed and maintained independently.
> Decoupling is good. Perhaps "designing" separate "components" in the
> repository would map to such an approach.
>
> Maybe the next step is to discuss a breakdown of STEM into its "Components".
>
> Strawman components:
> Core Models (graph, scenario, experiment, etc.)
> RCP
> Geography
> Transportation
> Disease Modeling
> ...
>
> Thoughts?
>
> Dan
>
>
> [image removed] Matthew Davis---06/03/2009 05:06:13 PM---Hi all,
>
> Matthew Davis/Almaden/IBM@IBMUS
> Sent by: stem-dev-bounces@xxxxxxxxxxx
> 06/03/2009 05:04 PM
>
> Please respond to
> STEM developer mailing list <stem-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
> [image removed]
> stem-dev@xxxxxxxxxxx
>
> [image removed]
> cc
>
> [image removed]
>
> [image removed]
> Subject
>
> [image removed]
> [stem-dev] SVN Directory Structure
>
> [image removed]
>
> [image removed]
>
>
> Hi all,
>
> On the call today, there was a discussion about directory structure
> for the SVN move. It was decided that we should follow a consistent
> naming scheme to what other Eclipse projects are using.
>
> For SVN, you have the three default roots, used for tagged revision control:
>
> - trunk
> - tags
> - branches
>
> Some Eclipse Projects are moving toward a more standardized sub-
> convention based on workspace project type.
>
> For example, in the Equinox repository, in the trunk they have:
>
> - compendium
> - components
> - framework
> - incubator
> .. etc
>
> and then inside of some of those directories, you see:
>
> - bundles
> - features
> - examples
> - tests
>
> In my opinion, separating bundles, features, examples, and tests is
> a good strategy (although it slightly complicates checkout). Should
> there be any higher granularity to the separation (maybe data,
> models, or geography?) Also, should there be a higher level
> separation between logical components of STEM (core, diseases, UI, etc)?
>
> -Matt_______________________________________________
> stem-dev mailing list
> stem-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stem-dev
> (See attached file: pic12986.gif)
> _______________________________________________
> stem-dev mailing list
> stem-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stem-dev
> [attachment "pic19086.gif" deleted by Matthew Davis/Almaden/IBM]
> [attachment "pic12986.gif" deleted by Matthew Davis/Almaden/IBM]
> _______________________________________________
> stem-dev mailing list
> stem-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stem-dev