Hi Ivo, 2011/4/5 Ivo Ladage-van Doorn <[email protected]>: > Hi List, > > We discussed the split off of subprojects before, my question is how we > should deal with subprojects depending on other subprojects. In case of the > Cassandra subproject for example, there are a lot of dependencies with other > projects (almost by definition, as Cassandra implements storages defines by > other projects). For example: > > - Gadget store - used by the gadget container (Shindig) > > - Tenant store – used to store tenants (amdatu core). > > - User admin store – implements useradmin storage provider (amdatu > authorization) > > - Token store – implements amdatu token storage provider (Amdatu > oAuth) > > - Consumer registry – implements oAuth consumer registry (Amdatu > oAuth) > > > > In our last discussion the answer was ‘define a new subproject which > includes this artifact’. In this case it means that I would have to > introduce 4 new subprojects; > > > > Amdatu-cassandra-opensocial > > Amdatu-cassandra-core > > Amdatu-cassandra-authorization > > Amdatu-cassandra-oauth > > > > Each having its own lifecycle. I doubt if this is the way to go. There is a > lot of overhead involved when defining these as separate subprojects > (separate JIRA components, separate roadmaps, separate release lifecycle, > separate WIKI pages) and it will become a struggle to manage them. I would > rather see these implementations as modules that are part of the overall > Cassandra subproject. WDYT?
My 2 cents, No we do not want a seperate (sub)projects, as in an organizational structures, for each module / software artifact per se. I think it makes most sense to keep code within the 'logical' subproject. Hence I would implement "OpenSocial Cassandra storage providers" in the OpenSocial subproject. This project may have one release cycle for this, or it may not. I expect more finegrained cycles, but I'd say that is up to the project itself. More important however, and that was my point in the discussion you refer to, is that you keep a clean separation between projects/modules/artifacts by defining clear api/spis and implementing accordingly. Eg. At this point if I want to do anything with shindig I am convicted to dragging cassandra along onto my compile/test/runtime classpaths. That is bad, the "business functionality" of a subproject should be available without leaking anything that is (or should be optional) onto any classpath. grz Bram > Regards, Ivo > > > > GX Software | Ivo Ladage-van Doorn | Product Architect | Wijchenseweg 111 | > 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - > 388 86 21 | [email protected] | www.gxsoftware.com | > twitter.com/GXSoftware > > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
