I finished the WIKI page describing the new SVN layout on
http://amdatu.org/confluence/display/Amdatu/Subversion+layout
Please read and give your opinion on it.
Comments I have concerning remarks below:
"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)."
I agree, however at the moment we still need JSP support (filter support was
needed before but not anymore since we replaced JSecurity by UserAdmin).
Regarding the list of todo's, some of them are already in progress:
* implement new subversion layout
* switch to maven 3 (See AMDATU-95; on hold until third party tools/plugins
work properly)
* align version and repositories
* split of project metadata into a 'parent' pom @ pom/pom.xml
* complete project metadata
- mailingLists (already fixed)
- scm (in progress)
- ciManagement
- distributionManagement (in progress)
* format poms (formatting convention spaces only / indent 2) (already done)
* 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 (in progress)
* add deployment to repository (repository.amdatu.org / repo1.maven.org?) (in
progress)
* add amdatu site layout (in progress)
Regards, Ivo
-----Original Message-----
From: amdatu-developers-bounces at amdatu.org
[mailto:[email protected]] On Behalf Of Ivo Ladage-van Doorn
Sent: maandag 11 oktober 2010 10:47
To: amdatu-developers at amdatu.org
Subject: Re: [Amdatu-developers] Repository layout and build
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
_______________________________________________
Amdatu-developers mailing list
Amdatu-developers at amdatu.org
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
