[rules-dev] Maven profiles (making maven faster and build more): change propositions

[Michael Anstis]

Standardisation and simplification. Great.

For my benefit, what's considered the soa stuff?

I'd be interested in how you manage to get GWT to compile less (i.e.
presumably no cross-browser or internationalisation support) for the default
profile; as it uses the .gwt.xml file to determine what to compile. Would we
have two gwt.xml files in the source (/resources) and copy the appropriate
one into the classpath at compile time? I think maven's resource plugin
(since 2.3) could achieve this.

On 27 October 2010 12:43, Geoffrey De Smet <ge0ffrey.spam at gmail.com> wrote:

>  I 'd like to refactor the maven build to use exactly 3 profiles and remove
> all other profiles:
>
>    - default
>       - Fast, for during development
>    - full
>       - Slow, but builds everything. Used by hudson, releases and before
>       you go to sleep
>        - soa
>       - Prunes the non-soa stuff away
>
> What do you think?
>
>
> Long explanation:
>
>    - The maven build is too slow atm:
>       - GWT compilation of all permutations (during development 1
>       permutation is enough)
>    - yet some parts of the code don't build with maven
>     - such as
>          - in the past GWT compilation
>           - antlr generation
>           - eclipse plugin
>          - examples
>           - problems with this approach
>        - they use unmanaged dependency versions (antlr generation might
>          use a different version than antlr dependency in pom)
>           - require tool installations (gwt dev kit under
>          /home/Rikkola/gwt :)
>           - commit generated files to svn
>           - adding them to maven will make the maven build even slower...
>       unless...
>
> The profiles are too complicated, currently we have these profiles:
>
>    - default (the one you run with "mvn clean install")
>       - Build these too
>          - drools-clips
>          - drools-planner
>          - drools-pipeline
>          - drools-simulator
>          - osgi-bundles
>       - Proposition: don't build those in soa
>        - documentation
>     - Build drools-docs too
>       - Proposition: merge into profile full
>        - build-eclipse
>       - Build drools-eclipse too
>       - Proposition: merge into profile full
>    - cibuild (hudson)
>       - Build these too:
>          - drools-docs
>          - drools-eclipse
>          - drools-examples too
>           - In drools-process, build these too:
>          - drools-bpel
>          - drools-jpdl
>       - Proposition: merge into profile full
>    - soa
>       - in drools (parent)
>          - assembly: use soa assembly description alternatives
>           - in drools-guvnor
>          - change some tokens in some files (ant based, not maven
>          filtering yet)
>           - run pre-integration-test
>       - in drools-eclipse
>          - Don't build org.drools.eclipse.task
>       - in drools-docs
>          - Don't build drools-docs-planner and drools-docs-integration
>            - grammars
>     - in drools-core and drools-compiler
>          - runs the antlr file generation
>       - Proposition: replace with maven antlr plugin
>          - if fast, do part of the default profile and output to target
>          dir
>          - if slow, do part of the full profile and output to src dir
>          (just as it is now)
>            - gen-brms-import (not part of any top-level build)
>       - Proposition: Leave it alone until we deal with that commented out
>       module bulk-importer-util
>        - ydoc-doclet (commented out on drools parent pom)
>     - Proposition: remove it
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101027/77c27057/attachment.html