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 <mingf...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
