directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: [Studio] Improvement proposal for Studio's Maven build
Date Fri, 11 Jun 2010 10:26:04 GMT
Pierre-Arnaud Marcelot wrote:
> Hi Dev,
> 
> I've been working on some improvements to Studio's Maven build these last days in this
branch [1].
> 
> I tried to improve the way we generate distributions to reduce the amount of tasks (and
time) still done by hand when releasing a new version of Studio.
> I'm tired of wasting almost a full day when a new version needs to be released...
> 
> Basically, I tried to integrate in the build (with 'release' profile enabled) the generation
of the Windows Installer Exe, the Mac OS X DMG, as well as the generation of a folder containing
all our distributions (linux-x86 and linux-x86_64 tar.gz archives, Mac OS X DMG, Windows Installer
Exe) and update site (as an archive to be deployed to the downloads area, and as a folder
for the 'online' update site), all these being signed (ASC, MD5 and SHA1) automatically.
> 
> The complete build with 'release' profile enabled takes a little more time (around 8-9
minutes), but in the end, we get a folder, which is ready to be uploaded on people.apache.org
for deployment.
> 
> A few facts on this new build:
> - There is now a separated Maven module (packaged as a pom) for each "distribution" build
(eg: Mac OS X), which generates a zip file stored into the local repo and accessible as a
dependency to other modules.
> - Same thing for:
>    - Apache Directory Studio features
>    - Apache Directory Studio plugins
>    - Apache Directory Studio Eclipse dependencies

Do we still need to create the parent's target/distribution if
everything is build in application module?

> - The 'updatesite' module now generates two zip files (one which can be used to install
Studio in Eclipse, and another which is meant to be used on people.apache.org.

Same here, do we still need the top-level updatesite project?

> - The new build takes a few more seconds than the current one on daily basic tasks but
not that much considering the added benefit.
>    (On my machine, a complete build takes 3:12 min with the current build and 3:32 with
the new one. A 'fastbuild' takes 1:59 min with the current build and 1:59 with the new one).
>   BTW, in order to gain a few "precious" seconds, I'd also recommend that we exclude
the "features" modules from the 'fastbuild' profile.

+1

Is it possible to make the "fastbuild" the default?

Today, I import all plugins and features into eclipse but close the help
plugin and feature projects afterwards.

If by default build would only contain the the real plugin it would be
faster. As a side effect a studio:eclipse only creates eclipse files for
the plugins but not for the features and help modules, then the eclipse
import wizard only imports the real projects and we avoid that eclipse
shows build errors.

Additionally we would need a profile "full" that builds the features and
help plugins.

> I'd like to know what you think about it, if you could test it, and if we can considering
switching to this new build on trunk.

I think it looks very good. And I trust your opinion, you did all the
releases you know the pain.

Thanks,
Stefan



Mime
View raw message