I am adding a WIKI page with the new proposed Subversion layout, see http://amdatu.org/confluence/display/Amdatu/Subversion+layout I also try to map existing modules onto the new layout, I'll send another mail when I'm finished...
-----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: zaterdag 9 oktober 2010 18:04 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Repository layout and build On 9 Oct 2010, at 0:23 , Bram de Kruijff wrote: > I've been going through the build today. Sofar I have compiled a list of > things I'd like to do (see below). However before we start refactoring the > build infra we need to define the basic svn layout. As discussed before > offline it would be a good idea to seperate bootstrap, platform (or 'core'), > frameworks and applications into 'subprojects' and I think that should be > reflected in the svn layout. The trickiest aspect of creating an SVN layout is that it is strictly hierarchical and that you can only provide one view on our files, where one can argue about the value of more than one view (from your examples below: sometimes its helpful to look at all the gadgets in the system, whilst at other times a more application centric view makes sense). So, there is no "best" choice here, we have to compromise, and at least make sure we're consistent. > Basic layout questions: > 1) Should we keep the core components and all composite frameworks and > foundation services in the same repository in the same trunk/branches/tags > layout or give each its own? (I think one for now to keep it simple, maybe > seperate later) If with "same repository" you mean "same physical SVN repository" then I definitely think we should keep everything together. To give an example, Apache has *all* its projects in a single physical repository (that just broke the 1.000.000 commits barrier) so I see no technical reason for a split. At the logical level we can just as well create a hierarchy in one repository, so I would suggest we stick with that. I also agree with your observation to keep it simple and relatively flat right now. Moving things around in SVN is easy, so we can make the move when the current layout becomes too flat to work with. > 2) If we keep als artifacts in one trunk/branches/tags layout, do we use a > flat layout or a n level multiproject (Eg. amdatu-jaxrs or > frameworks/amdatu-jaxrs)? (I think flat for now again to keep it simple) KIS for now... > Maybe a little abstract questions but it may become a little clearer when > thinking about the new layout in terms of subprojects by example. Right now > the layout is somewhat artifact type based (eg. gadget-bundles) where I think > it should be subproject / composite based. > This will for example allow the subproject to centralize its own specific > build configuration in its own parent pom as opposed to the current situation > where everything is aggreageted in the root pom (eg. amdatu core pom should > be concerned with the build wide junit version but NOT with the wink version > as wink is just a framework implementation) I'd like to start with "inheritance is evil" here, because mainly it means it becomes harder to release a single subproject (because the build has a dependency on the parent pom). But I guess it's hard to avoid that with maven. When things become bigger, probably people/teams will work on subprojects to organizing the hierarchy that way makes sense to me. > Below a first proposal based on my preferences described above just to get > the brainstorm going: > > - amdatu-maven-plugin (enables initial software provisioning and/or > bootstrap from maven) > - amdatu-launcher (minimal amdatu bootstrap artifact/assembly > - felix > - ace agent > - preferences > - useradmin > - ... I would make the launcher even smaller than this: just a launcher + framework implementation + management agent. Everything else we can bootstrap with the management agent. > - amdatu-core (base composite of amdatu artifacts provisioned for each > deployment) Just a little remark here. We are component based. Components will have some dependencies, but other than that, I want to avoid deploying artifacts just because they're part of some "core" we defined. I'm probably over reacting, but I don't want us to build the next Spring or even worse, Java EE framework that contains everything, three kitchen sinks and some stuff that sounded like a good idea at the time. I'm probably over reacting a bit here, but the point is to keep it lean and mean. > - tenants > - topology > - rs > - ... > - amdatu-manager (manager composite for cluster/deployment management, > depends on amdatu-opensocial?) Why would deployment and cluster management depend on opensocial? I'm not sure if it makes sense to use gadgets for a management interface. I mean we could, but there are probably richer, nicer UI frameworks around for this purpose. > - ace server With or without OBR? With or without client UI? > - management gadgets > - amdatu-web (framework composite for j2ee web pursposes) > - pax web Pax Web should probably either be dumped completely or fixed. It has serious issues. Alternative: Felix Http Server (yes that does not support non-spec extensions but we should not rely on those anyway). > - httpcontext > - ... > - amdatu-jaxrs (framework composite for REST pursposes, depends on > amdatu-web) Again, this should not need to depend on amdatu-web. REST services can be published whiteboard style and don't need to know who's listening for them. So perhaps there's a logical dependency on something that can publish REST services, but that's about it. > - wink > - ... > - amdatu-semanticweb (framework composite for semantci web pursposes, > depends on amdatu-web) > - sesame > - sparql > - ... > - amdatu-opensocial (framework composite for opensocial pursposes, > depends on amdatu-web) > - shindig > - ... > - amdatu-casandra (foundation composite for applications that require > nosql storage) > - cassandra > - ... > > > I probably should put a more extensive setup on the wiki, but I am curious to > get your initial thoughts :) I like the subprojects you've defined so far, with the remarks made above. :) > * refactor structure to seperate subprojects > * switch to maven 3 (AMDATU-95) Let's wait until all known issues with third party tooling are resolved before moving to maven 3. > * allign version and repositories > * split of project metadata into a 'parent' pom @ pom/pom.xml > * complete project metadata > - mailingLists > - scm > - ciManagement > - distributionManagement > * format poms (formatting convention spaces only / indent 2) > * name unnamed artifacts to get a nice reactor > * add codechecking and reporting (checkstyle / findbugs / xref / cobertura > * move subproject specific config out of parent pom > * replace antrun workarounds proper assembly > * add reporting and site generation > * add deployment to repository (repository.amdatu.org / repo1.maven.org?) > * add amdatu site layout Good points. We should make JIRA issues out of them I guess? Greetings, Marcel _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
