Thanks Hugo! On 02-Oct-2012, at 5:30 AM, Hugo Trippaers <htrippa...@schubergphilis.com> wrote:
> Hey guys, > > I'm working very hard to get the maven stuff working in the master branch. > I'll try not to disrupt the existing ant builds of master, but sooner or > later we need to go either left or right. For now I've updated the page > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven > with instructions on how to use maven. If you feel there is information > missing or not clear, let me know and I'll try to update it. > > The short term goal is to have maven compile the code and build the following > artifacts: > > * Client.war (the management website including dependencies) > > * Usage.jar (executable jar for the usage server including deps) > > * Awsapi.war (awsapi website including deps) > > * Systemvm.iso > > * Agent.zip I'd added a TODOs sections for Maven: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven#BuildingwithMaven-TODOs Let's update on that, to keep us updated asynchronously. And there are couple of bugs on JIRA as well. > > Next to this: > > * Developer support, deploydb, refreshdb, start debug server For the developer workflow, why not move the plugins to top level pom under a profile? Right now I see they are in a profile already? Although, if we were to move db properties, assemblies etc, moving stuff into the developer/ makes sense. I've some working in progress to use exec plugin to do some of the deploy db/server commands. After I deploy with ant, I was able to run the server using Jetty: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven#BuildingwithMaven-Runningaserverfortest%2Fdebugpurposes. I'm still not able to configure/use the tomcat plugin correctly. Also if you could you fix your editor to insert spaces instead of tabs as it distorts for me on vim. 2 spaces/1tab for .xmls :D > If anyone wants to help feel free! Just testing, working with the maven build > and sending feedback will help enormously. +1 Alright, can we now discuss the packaging strategy as well? Will we continue using waf+maven+ant hack or use maven plugins for packaging, or specs and control files for the purists? Deb packaging is working fine, just some resolvable issues. RPM was WIP, but I pre-empted that work after the discussion on IRC last week. Okay, here are the pros and cons I can think of if we use packaging using maven plugins; (in the following package means deb or rpms) Pros: - Each submodule/artifacts gets its own package - With this design, it's possible to develop, test and package each submodule individually - With this design, it's possible for a plugin developer and developers in general to just focus on their work and not be bothered by learning the build system, they can just drop in their code in plugins/ and not touch any other part of the source tree. - It's very fast, right now it takes 30-50 mins to test any build/source changes. - Variables in pom.xml can be imported dynamically in control/conf files using [[ ]] . Cons: - I was told on IRC that build system folks and purists prefer their specs, control files. - I'm still to figure out how to expand variables like @SYSDIR@ in several .in scripts which are expanded by waf now. Exec plugin is one option. (Purists will still require waf or something to expand vars in these .in scripts before they can call rpm build or debuild) Pl. add pros/cons you may think and let's decide based on build system maintainability, ease for developers. > I know this work is happening parallel to the 4.0 release, but I already > planned to spend this week in the states with Edison to work on this. None of > the work we do will affect the 4.0 branch anyway. +1 let's do this in parallel, without removing any ant build system parts for now, and do housekeeping only after we've a stable build system with maven. How about making rule that all build patches go though reviews, as build bugs become blockers. Regards. > > Cheers, > > Hugo
