[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 PathNew 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


Inactive hide details for Matthew Davis---06/04/2009 08:57:17 AM---I went back to look at some of the existing conventions, a fMatthew 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

GIF image

GIF image

GIF image