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 Tue, 15 Jun 2010 14:19:50 GMT
Done.

I removed the 'application-unpack' module and excluded the help plugins and features modules
from the 'normal' build.
They are now available as a 'studio-full' profile.

On my machine, the difference is very interesting: 3 min 10 sec using the 'studio-full' profile
against 1 min 51 sec with a normal build.

Regards,
Pierre-Arnaud


On 11 juin 2010, at 19:23, Pierre-Arnaud Marcelot wrote:

> 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