Re: [stem-dev] SVN Directory Structure

[Stefan Edlund <edlund@xxxxxxxxxxxxxxx>]

Hi I'm okay with most of the suggestions below, I think we can reorganize so that in the future it's simplifies putting components on update sites for download. Any other thoughts? I'm still not totally clear where the ...internal.data project goes, but that's a minor issue.

Thanks,
/ Stefan

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


Daniel Ford ---06/05/2009 04:54:33 AM---Some thoughts:

Daniel Ford <daford@xxxxxxxxxxxxxxx>
Sent by: stem-dev-bounces@xxxxxxxxxxx

06/05/2009 04:50 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

Some thoughts:
1) I'm not sure what the extra "components" segment adds to the brew. Seems like just an extra thing to type in at this point.
2) The disposition of the current top-level ant script is a release engineering issue. My suggestion is to really break apart the different components of STEM, build them "separately" and put them on the update site as separate features. This would allow different teams working on different components to decouple their activities. This doesn't mean that there can't be something that can build it all, just that it would be useful to decouple these activities.
3) Don't have just one top-level "doc" component. Make each individual sub-component have its own documentation contributions. The Eclipse documentation system handles this quite nicely.
4) Don't have a separate "data" component, there's a geography component that has data, a disease component that has data, etc.

Dan

Stefan Edlund ---06/04/2009 01:24:29 PM---Sounds okay, with me. Here's a first crack trying to map the paths, some of these are most likely completely wrong, we should i

Stefan Edlund <edlund@xxxxxxxxxxxxxxx>
Sent by: stem-dev-bounces@xxxxxxxxxxx

06/04/2009 01:23 PM

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

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
(See attached file: pic01461.gif)_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev
(See attached file: pic24421.gif)(See attached file: pic01461.gif)_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev

Attachment: pic24421.gif
Description: GIF image

Attachment: pic01461.gif
Description: GIF image