> > - 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.
Ok, let's see how small we can get it :) I'd like to be able to bootstrap on my G1 too 8) > > - 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. Again, I agree :) > > - 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. I did not really think that one through. Just made a first list based on what we have now, but I guess you make a valid point and we need to think about that. > > - ace server > > With or without OBR? Not sure. Can you elaborate on that? > With or without client UI? I'd like ACE management to be integrated into Amdatu management eventually to get a rich and consistent UI. Still, until that time the Ace UI may come in handy to get thing up and running? > > - 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. Good point! Let's see what Ivo comes up with as he is working on a wiki document as we speak! Grz Bram > -----Original Message----- > From: amdatu-developers-bounces at amdatu.org [mailto:amdatu-developers- > bounces at amdatu.org] On Behalf Of Marcel Offermans > Sent: Saturday, October 09, 2010 6:04 PM > 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
