Felix Meschberger wrote: > >Hi all, > >Forgive me if I am wrong, but the discussion of whether to structure >the projects as sub-projects with other sub-projects has probably >nothing to do with Eclipse - as long as a parent project is a pom >project and does not contain its own Java source. > >Whether and how to support PDE for bundle development is IMHO a >completely different discussion worth to be held. > >This is simply about structuring the projects to get a better overview >and probably build control. > >As such, I am in favor of hierarchical structuring. > >The question to me is rather, what exactly is structured into lower >levels. IPOJO and mosgi are obvious candidates for sub-structuring. >But how about others ? Is it more like "implementations of OSGi >specified services are not structured ?" But then how about the >eventadmin projects, which IMHO warant substructuring, too. Of is the >substructuring more like help work around the maven issue regarding >the package extensions ? > >So I propose the following : > > Create sub projects of IPOJO, mosgi, eventadmin, upnp and shell projects > > Create a subproject for straight OSGi-componendium implementations >like scr, http.jetty, log > > Create sort of an extension (or contrib or xxx) sub project for >projects not directly related to OSGi specifications like mishell, >jmood, dependencymanager, jmxintrospector, servicebinder. > > Leave the rest (osgi libraries, framework, main, bundlerepository, >..) at the "top". > > Leave the tools as is (for the moment) > >Re tools: Maybe it would be worth a separate discussion on how to >proceed on the different maven plugins in tools/maven2 and maybe >include the IPOJO plugin in this discussion.
My whole point about keeping things simple and not trying to over organize the repo is specifically to avoid having these types of discussions. Even though it makes us feel warm and fuzzy inside to try to organize everything, it is rarely productive and it is definitely impossible to find the perfect hierarchical organization. Thus, this is why I think the best approach is to just say that the trunk contains sub-projects and the sub-projects are organized into modules as they see fit. Simple enough, won´t waste our time, and is reasonably straightforward to implement. -> richard > >Regards >Felix
