Re: [stem-dev] SVN Directory Structure

[Stefan Edlund <edlund@xxxxxxxxxxxxxxx>]

Sounds okay, with me. Here's a first crack trying to map the paths, some of these are most likely completely wrong, we should iterate it a few times.

Old Path	New Path
org.eclipse.ohf.stem.doc	/trunk/components/doc/bundles/org.eclipse.stem.doc
org.eclipse.ohf.stem.feature	/trunk/components/core/features/org.eclipse.stem.feature
org.eclipse.ohf.stem.feature.core	/trunk/components/core/features/org.eclipse.stem.feature.core
org.eclipse.ohf.stem.feature.prereq	/trunk/components/core/features/org.eclipse.stem.feature.prereq
org.eclipse.ohf.stem.releng	/trunk/components/releng/org.eclipse.stem.releng
org.eclipse.ohf.stem.analysis	/trunk/components/analysis/bundles/org.eclipse.stem.analysis
org.eclipse.ohf.stem.analysis.automaticexperiment	/trunk/components/analysis/bundles/org.eclipse.stem.analysis.automaticexperiment
org.eclipse.ohf.stem.core	/trunk/components/core/bundles/org.eclipse.stem.core
org.eclipse.ohf.stem.data.diseasemodels.models	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels.models
org.eclipse.ohf.stem.data.diseasemodels.scenarios	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels.scenarios
org.eclipse.ohf.stem.data.geography	/trunk/components/geography/bundles/org.eclipse.stem.data.geography
org.eclipse.ohf.stem.data.geography.infrastructure.transportation	/trunk/components/transportation/bundles/org.eclipse.stem.data.geography.infrastructure.transportation
org.eclipse.ohf.stem.data.geography.models	/trunk/components/geography/bundles/org.eclipse.stem.data.geography.models
org.eclipse.ohf.stem.data.geography.population.human	/trunk/components/geography/bundles/org.eclipse.stem.data.geography.population.human
org.eclipse.ohf.stem.data.geography.population.human.models	/trunk/components/geography/bundles/org.eclipse.stem.data.geography.population.human.models
org.eclipse.ohf.stem.definitions	/trunk/components/core/bundles/org.eclipse.stem.definitions
org.eclipse.ohf.stem.diseasemodels	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels
org.eclipse.ohf.stem.diseasemodels.example	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels.example
org.eclipse.ohf.stem.diseasemodels.experimental	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels.experimental
org.eclipse.ohf.stem.diseasemodels.externaldatasource	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels.externaldatasource
org.eclipse.ohf.stem.diseasemodels.forcing	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseasemodels.forcing
org.eclipse.ohf.stem.diseases	/trunk/components/diseasemodels/bundles/org.eclipse.stem.data.diseases
org.eclipse.ohf.stem.geography	/trunk/components/geography/bundles/org.eclipse.stem.geography
org.eclipse.ohf.stem.internal.data	/trunk/components/data/bundles/org.eclipse.stem.internal.data
org.eclipse.ohf.stem.internal.data.geography	/trunk/components/data/geography/bundles/org.eclipse.stem.internal.data
org.eclipse.ohf.stem.internal.data.geography.infrastructure.transportation	/trunk/components/data/transportation/bundles/org.eclipse.stem.internal.geography.infrastruture.transportation
org.eclipse.ohf.stem.internal.data.geography.models	/trunk/components/data/geography/bundles/org.eclipse.stem.internal.data.geography.models
org.eclipse.ohf.stem.internal.data.geography.population	/trunk/components/data/geography/bundles/org.eclipse.stem.internal.data.geography.population
org.eclipse.ohf.stem.internal.data.geography.population.human	/trunk/components/data/geography/bundles/org.eclipse.stem.internal.data.geography.population.human
org.eclipse.ohf.stem.internal.data.geography.population.human.models	/trunk/components/data/geography/bundles/org.eclipse.stem.internal.data.geography.population.human.models
org.eclipse.ohf.stem.internal.diseasemodels.models	/trunk/components/data/diseasemodels/bundles/org.eclipse.stem.internal.diseasmodels.models
org.eclipse.ohf.stem.internal.diseasemodels.scenarios	/trunk/components/data/diseasemodels/bundles/org.eclipse.stem.internal.diseasemodels.scenarios
org.eclipse.ohf.stem.jobs	/trunk/components/jobs/bundles/org.eclipse.stem.jobs
org.eclipse.ohf.stem.jobs.nl1	/trunk/components/jobs/bundles/org.eclipse.stem.jobs.nl1
org.eclipse.ohf.stem.sample	/trunk/components/sample/bundles/org.eclipse.stem.sample
org.eclipse.ohf.stem.sequencers	/trunk/components/core/bundles/org.eclipse.stem.sequencers
org.eclipse.ohf.stem.tests.automaticexperiment	/trunk/components/analysis/tests/org.eclipse.stem.tests.automaticexperiment
org.eclipse.ohf.stem.tests.core	/trunk/components/core/tests/org.eclipse.stem.tests.core
org.eclipse.ohf.stem.tests.definitions	/trunk/components/core/tests/org.eclipse.stem.tests.definitions
org.eclipse.ohf.stem.tests.diseasemodels	/trunk/components/diseasemodels/tests/org.eclipse.stem.tests.diseasemodels
org.eclipse.ohf.stem.tests.diseasemodels.example	/trunk/components/diseasemodels/tests/org.eclipse.stem.tests.diseasemodels.example
org.eclipse.ohf.stem.tests.diseasemodels.experimental	/trunk/components/diseasemodels/tests/org.eclipse.stem.tests.diseasemodels.experimental
org.eclipse.ohf.stem.tests.diseasemodels.externaldatasource	/trunk/components/diseasemodels/tests/org.eclipse.stem.tests.diseasemodels.externaldatasource
org.eclipse.ohf.stem.tests.diseasemodels.forcing	/trunk/components/diseasemodels/tests/org.eclipse.stem.tests.diseasemodels.forcing
org.eclipse.ohf.stem.tests.jobs	/trunk/components/jobs/tests/org.eclipse.stem.tests.jobs
org.eclipse.ohf.stem.tests.sequencers	/trunk/components/core/tests/org.eclipse.stem.tests.sequencers
org.eclipse.ohf.stem.tests.transport	/trunk/components/transport/tests/org.eclipse.stem.tests.transport
org.eclipse.ohf.stem.tests.ui	/trunk/components/core/tests/org.eclipse.stem.tests.ui
org.eclipse.ohf.stem.tests.ui.ge	/trunk/components/jobs/tests/org.eclipse.stem.tests.ui.ge
org.eclipse.ohf.stem.tests.util	/trunk/components/util/tests/org.eclipse.stem.tests.util
org.eclipse.ohf.stem.transport	/trunk/components/transport/bundles/org.eclipse.stem.transport
org.eclipse.ohf.stem.ui	/trunk/components/core/bundles/org.eclipse.stem.ui
org.eclipse.ohf.stem.ui.diseasemodels	/trunk/components/diseasemodels/bundles/org.eclipse.stem.ui.diseasemodels
org.eclipse.ohf.stem.ui.diseasemodels.externaldatasource	/trunk/components/diseasemodels/bundles/org.eclipse.stem.ui.diseasemodels.externaldatasource
org.eclipse.ohf.stem.ui.diseasemodels.forcing	/trunk/components/diseasemodels/bundles/org.eclipse.stem.ui.forcing
org.eclipse.ohf.stem.ui.ge	/trunk/core/diseasemodels/bundles/org.eclipse.stem.ui.ge
org.eclipse.ohf.stem.ui.nl1	/trunk/components/diseasemodels/bundles/org.eclipse.stem.ui.nl1
org.eclipse.ohf.stem.ui.reports	/trunk/components/analysis/bundles/org.eclipse.stem.ui.reports
org.eclipse.ohf.stem.util.analysis	/trunk/components/analysis/bundles/org.eclipse.stem.ui.analysis
org.eclipse.ohf.stem.util.loggers	/trunk/components/util/bundles/org.eclipse.stem.util.loggers
org.eclipse.ohf.stem.utility	/trunk/components/util/org.eclipse.stem.utility

Stefan Edlund
Public Health and Computer Science Research
IBM Almaden Research Center 
(408) 927-1766   edlund@xxxxxxxxxxxxxxx

Matthew Davis---06/04/2009 08:57:17 AM---I went back to look at some of the existing conventions, a few extra notes:

Matthew Davis/Almaden/IBM@IBMUS
Sent by: stem-dev-bounces@xxxxxxxxxxx

06/04/2009 08:46 AM

Please respond to
STEM developer mailing list <stem-dev@xxxxxxxxxxx>

To	STEM developer mailing list <stem-dev@xxxxxxxxxxx>
cc
Subject	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_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev