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
