cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject Re: [DISCUSS] Primary artifact(s) (maven, post 4.0rc1)
Date Mon, 17 Sep 2012 09:24:21 GMT

On 17-Sep-2012, at 2:33 PM, Hugo Trippaers <HTrippaers@schubergphilis.com> wrote:

> Hey all,
> 
> This has been discussed on some other threads as well, but I think it is worthwhile to
get a clear picture on this. While discussing the current release process we basically combined
the build/package process of the sources with the creation of the rpm/deb packages for 4.0RC1
(using a combination of maven, ant and waf). When moving to maven we have the opportunity
to better separate the code build/package process from the creation of any vendor specific
packages. This would for one thing allow others to create packages using their own insights
and combinations of components.
> 
> Also from a maven perspective it is good to know what is expected from it. The way I'm
looking at it is that maven builds a binary release in the form of a tarball. This tarball
will contain everything to run the various components in the source tree. This seems to be
more or less what other Apache projects do as well. I think the components are the following:
> 	* The client webapp (war)
> 		This includes ui components, compiled classes and all dependencies in a standard java
webapp layout
> 		Contains selected optional components based on maven profiles like netapp, vmware,
netscaler etc.
> 		Also systemvm.iso and other components required by the webapp
> 	* The awsapi webapp (war)
> 		This included all awsapi components and dependencies in a standard java webapp
> 	* The usage server (jar)
> 		This includes the usage server and dependencies as an executable jar

Separate further maybe? All plugins shipped as separate packages (users get to pick what deb/rpm
plugin they would want, for example vmware, xen, kvm etc.); agent, api, awsapi, client, core,
console-proxy, server, ui, usage, utils all as separate pkgs.

> 
> Next to these artifacts there will be some scripts that are needed by our builds of the
debs/rpms and do utility work like creating a database etc.

For that we can reuse the exec plugin to do things like deploydb etc.

> 
> Secondary responsibility of maven is to be able to start a debug server for all three
components (with eclipse integration)

+1 use jetty or tomcat plugin w/o debug profile.

> 
> The rpms/debs should ideally be built from the tarball mentioned above. The main change
would be to have the builder include the jars in the webapp. This saves an enormous amount
of trouble when building packages as we don't need to deal with package dependencies anymore.
Potentially this makes the webapps also more portable, people should be able to deploy the
war in any j2ee container and run it.

I don't know how exactly the deploy-server/debug on the tomcat webapp/war/j2ee works now or
would work. Could you please explain that process (future and now) in detail.

> Current status is that I'm testing the war building for the client api by starting a
debug server directly from maven. The tarball build is also almost done with the exception
of the usage server. I'm happy to continue working on this together with Edison Su. 

Update the status on the maven-waf branch please?
Are we going to pull some changes to master or after 4.0. discard the branch and go full-on
maven?

Regards,
Rohit

> 
> Your ideas and feedback please :-)
> 
> 
> Cheers,
> 
> Hugo


Mime
View raw message