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
