[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ohf-dev] cvs pattern

I agree being as close to the common Eclipse theme.
Striving towards a uniform pattern inside the project is preferred, though
some like the CTS and maybe the ohf/server will have to do something a bit
different.

well, we sort of lead the way in this sense - maybe we can try to establish a pattern for these kind of projects in Eclipse?

The pattern you suggested is good, though I got few questions.
What are the "releases" folder for? (isn't the CVS tagging enough?)

binary releases. agree we would use cvs for the source for the releases. maybe some name other than release would be appropriate

What about having in the plugin folder "META-INF", "bin",  "src", and if
applicable also "schema" and "icons" folders?

I guess. I've been letting eclipse do those. In jiva we have src,
which is standard, and src_tests, for junit tests, to keep them separate, and "resources" where we put schema and other things.


I think we should have "docs" and "tests", folders in the component level.
In which level do you think they should be (if at all)?

agree. next to plugins

Grahame


Eishay

ohf-dev-bounces@xxxxxxxxxxx wrote on 03/13/2006 05:35:23 PM:

Hi all

I'm turning my attention to booking some code into cvs.
Looking through the other technology projects, I see
a range of patterns for how to set up the code in the cvs.

It'd be nice if we have a general approach to get some
consistency. I propose, as a strawman, that we adopt
the following general policy for how we use cvs.

 under the root folder (ohf on dev.eclipse.org), we
 have a folder for each component. For each component,
 we have a set of folders dividing the cvs content into
 functional areas. At this level, each component will have
 a folder "plugins", which contains a series of folders
 with name org.eclipse.ohf.*. Each folder is a working
 eclipse project for the plug-in.

 The Component may also contain other folders, with likely
 candidate names being "releases", "examples", "resources".

So, that's my strawman proposal. What do you think? I note
that this pattern doesn't fit what CTS very well, so I
expect we'll have further discussion there, and I'm not sure
whether we should hold CTS as a relevent case for our general
approach.


Grahame



_______________________________________________
ohf-dev mailing list
ohf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ohf-dev

_______________________________________________ ohf-dev mailing list ohf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ohf-dev

--
Grahame Grieve
CTO, Jiva Medical Software Integration Tools
CTO, Kestral Computing Healthcare Applications