Re: [rules-dev] Maven profiles (making maven faster and build more): change propositions
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com