On Apr 5, 2011, at 19:45 , Bram de Kruijff wrote: > 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.
Let's first make sure that each of the subprojects we defined becomes a separate project. Within the subproject I agree its desirable to keep track of sub-subprojects for the artifacts you release so you at least keep the option open to: a) Release only a subset of all possible artifacts: in case not all of them are yet "fit for release". b) Release artifacts separately: in case you need to do a "bugfix" that only affects one artifact. > 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. Agreed. > 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. >From a modularity point of view, that is indeed the most important aspect. For >the whole development cycle, just having access to the API/SPI packages must >be enough. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
