incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: Updates to maven build
Date Wed, 03 Oct 2012 05:55:43 GMT
Thanks Hugo!

On 02-Oct-2012, at 5:30 AM, Hugo Trippaers <> 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
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
> *

I'd added a TODOs sections for Maven:
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:

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.


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)

- 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 [[ ]] .

- 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.


> Cheers,
> Hugo

View raw message