directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [Studio] Improvement proposal for Studio's Maven build
Date Fri, 11 Jun 2010 17:23:36 GMT
Hi Stefan,

On 11 juin 2010, at 12:26, Stefan Seelmann wrote:

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

Nope, it is just copied to be more accessible, without a long command-line like :
$ open application/application-macosx/target/ApacheDirectoryStudio-macosx/Apache Directory
Studio.app

But you're right, it is not absolutely necessary.
Then I believe the 'application-unpack module' can be removed and we can gain a few (precious)
seconds while building.


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

Actually I was talking about the 'application-updatesite' module, the one at the top-level
directory can be removed.
BTW, I forgot to mention that the updatesite module is not built by default, but only with
the 'updatesite' profile.


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

Sure, this is something I was thinking about too.

I will modify the build on the branch in order to only build the 'code' plugins:
- aciitemeditor
- apacheds
- apacheds-configuration
- common-ui
- connection-core
- connection-ui
- jars
- ldapbrowser-common
- ldapbrowser-core
- ldapbrowser-ui
- ldif-parser
- ldifeditor
- rcp
- schemaeditor
- valueeditors

Am I missing something in the list ?


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

I do exactly the same as we modify these projects very rarely.


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

Sounds good to me.
I'll make the modifications in the branch.

As a summary, here's the list of all the profiles that we'll be able to use:
- 'linux-x86'  ->  Forces the generation of the Linux x86 application (even if the machine
is not running Linux x86)
- 'linux-x86_64'  ->  Forces the generation of the Linux x86_64 application (even if the
machine is not running Linux x86_64)
- 'macosx'  ->  Forces the generation of the Mac OS X application (even if the machine
is not running Mac OS X)
- 'win32'  ->  Forces the generation of the Windows application (even if the machine is
not running Windows)
- 'update'  ->  Adds the update site to the build
- 'full'  ->  Adds features and help plugins to the build
- 'release'  ->  Adds the generation of the Mac OS X DMG, Windows Installer Exe and folder
containing signed distributions and updatesite


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

Héhé. Not that painful, but time consuming.


Thanks,
Pierre-Arnaud
Mime
View raw message