Builders should be able to create flat and jarred versions of extensions or XULrunner applications.
Do we need a preprocessor or some sorts?
- need Makefile in build
- lots of extra tools required
- no good dependency tracking for jars
- easy to ship
- lots of code to duplicate
Note that my Extension Developer's extension has a standalone build system, and it wasn't terribly hard to put together. The hardest part was finding a suitable zip tool on the user's system, and knowing how to call that. --Luser 06:25, 21 Jun 2005 (PDT)
I'd prefer to have something hooked up to eclipse, so at least one implementation will be java based. I'm currently thinking about a helper jar that the ant task and an eclipse builder can hook into. --AxelHecht 08:26, 21 Jun 2005 (PDT)
i dont think ANT is the right solution because the eclipse build process is started very often by eclipse (especially when "incremental build" is enabled) - and ANT builds are somewhat time consuming. i have some experience with both ANT based eclipse builders and custom builders - it will slow down xul development too much. --LarsGersmann 11:10, 23 Aug 2005 (PDT)
- easy to ship, ant already comes with eclipse
- known to quite a few java coders
- ant not really known in the mozilla world
The XUL Builder should only be used to validate/verify the project (check dependencies, error/warning marker creation etc.). I would like to have Export Wizards for creating jarred versions (and for creating xpi's too). The Eclipse JDT/PDE does it the same way - export wizards generate the jars (i.e. installable packages).
It should be possible to provide a wizard to collect all needed informations from the user and to generate an ANT Build File. by the way - +1 for using ANT files (despite its cons) - should be our choice. --Lars Gersmann
- do we want wildcards? (yes, AxelHecht)
- do we want a preprocessor? (yes, AxelHecht)
Let's scratch-pad an XML configuration file to be used to pack content/locale/skin.
<solid:packager> <solid:package type="content" use-preprocessor="yes"> <solid:include pattern="src/content//*.xul"/> <solid:include pattern="src/content//*.js"/> <solid:destination pattern="chrome://foo/content"/> </solid:package> </solid:packager>
Wether the content goes to the build dir, unjarred or is jarred up would best be up to a build.properties file, I guess.