>From your list below... I've done 0 (Tools), 1 (Framework), and 6 (Sandbox). >I moved Richard's original source commit of Oscar2 under the framework >directory.
... might want to do a SVN update ... You'll notice I've also committed my initial maven-osgi-plugin code, and an interim version of Maven2's maven-archiver in my sandbox. More on these commits in another post... I'll let others jump and *thin* down the framework and flesh out the core and standard bundle source structures. I'll be glad to help *maven2-ize* the build process, but I'm going to need some help with the *refactoring* process. I'm afraid I'm not familiar enough with the core and the spec to feel qualified to make those decisions. I'm up for being a worker bee though. -tbennett -----Original Message----- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Mon 8/22/2005 11:24 PM To: [email protected] Cc: Subject: Re: Felix SVN trunk root On Tuesday 23 August 2005 03:53, Bennett, Timothy (JIS - Applications) wrote: > So maybe we need a *framework* directory in the root of the Felix trunk, > and the all of Richard's code moved under that directory. WDYT? Maybe a > different directory name? Just something to differentiate it from the > tools type of source I'll be committing. I agree. (see you have gone ahead already :o) ) > In fact, I envision we'll need other directories under "tools". One for > the maven-osgi-plugin, and at least one other for the work that Andreas > is doing on the Eclipse plugin for Oscar (I guess renamed now as Felix > Studio). Maybe in the future, we might have non-core, non-framework > services and bundles that we'll decided to version control that will > have their own product directory under the trunk root. I think Richard is right to make the "framework" extremely thin, and you add what you need. IMVHO, I would like to see a separation at 'root' level to something like; 0. Tools (ant/maven/other thingies needed to build/test/validate/release the rest) 1. Framework. 2. Core bundles (to enable framework to provide an interface) 3. Standard bundles (for the services specified in the OSGi spec.) 4. Bundle Library (everything else we actively supports) 5. Site. 6. Laboratory/Sandbox. (experiments and premature code) Simple, clean and straight forward. I am not so happy with a flat structure of projects sitting side by side, with little indication what is required, optional and ignorable. I don't think it would be a problem with M2 either. Cheers Niclas
