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

[Edson Tirelli]

   Hey Geoffrey,

   It all sounds good, except for the antlr generation. My experience
with it in the past was that sometimes, for no apparent reason*, the
parser would break when regenerated and no one would know why. So, I
would like to keep the antlr generation non-automatic, and the
generated files committed. I have no problem in using the maven antlr
plugin if it works fine, and I would love to have the task (or maven
plugin) to use the exact same antlr version used in the project
dependencies.

* "no apparent reason" was always related to a dependency change or
some other action that would cause a side effect on the parser
breaking it without us noticing before release. Test coverage is much
better nowadays and antlr more stable, but I would still prefer to
keep it as a separate non-automatic profile, as that makes much easier
for us to track down the root cause of a parser break.

   My .02c.

   Edson

2010/10/27 Ming Fang <mingfang at mac.com>:
> +1
> This will be great.
> On Oct 27, 2010, at 7:43 AM, Geoffrey De Smet 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
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com