Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ormf-dev] Guide to ORMF repository structure

Thanks for the suggestions...

On 6 Oct 2008, at 18:15, Achim Loerke wrote:

Comments on the document:

The overall structure looks good to me.

The current SVN repository contains a few projects which do not use the naming convention "org.eclipse.ormf...", namely plugins/{ormf,useme}/test. Is this the intended form or a leftover from the initial commit? At least it's not a good idea to have more than one Eclipse projects with the same SVN name.

The "test" folders are containers (not projects) in which all of the test plug-in fragments will live. We kept these isolated to reduce the clutter in the parent folder. The rationale was that most adopters would be primarily (at least in the first instance) interested in the real source and not the junit tests. I agree with you absolutely that all projects should have very clear, unambiguous and unique names.

 
I would prefer a more organized approach to the creation of the projects located below the high level folders. This may be a person synchronizing the creation of projects or a simple poll on the ormf-dev list (propose a project directory, tell what it's use and request a simple +1,0,-1). I just want to avoid cluttering of the repository with (partly) redundant projects or projects created by misunderstanding the intended structure. I prefer the ormf-dev poll.

Yes, I think that would be a real good idea. Using the ormf-dev poll way is also my preference. The exceptions that I would make to this are:

  • Library wrappers for approved CQs, e.g. I have just checked in three for apache.collections, apache.lang, and org.dom4j. These are governed by the IP Zilla process, have a very clear purpose and we have a clear naming convention.
  • Junit test fragments as the purpose and naming are automatic
  • Help fragments as the purpose and naming are automatic

My first proposal is org.eclipse.ormf.common. We already have an org.eclipse.ormf.shared.  The reason to create a new plug-in is to cleanly separate new code for the Riena (Hessian) based remoting and the new EMF model (in I2) from the legacy Useme code. Once we have the new EMF (DSL) stuff working we will abandon org.eclipse.ormf.shared.

Cheers,
Joel


Back to the top