10:22 p.m.
This refactor is done (except for some details in the soa profile)
GWT compilation by default now does just 1 permutation (instead of 36),
so a normal build:
mvn -DskipTests clean install
that previously took *5:29s* on my machine, now takes *3:18s* (so *> 60%
faster*).
To run the full build, use the full profile.
mvn -DskipTests -Pfull clean install
*The old profiles (eclipse, documentation, cibuild, ...) have been
replaced by that full profile.*
I recommend to use the full profile when generating eclipse/intellij
configuration. (Feel free to ignore).
It takes longer to generate, but refactorings and find usages will
respect the examples and the eclipse-plugins classes too.
Also the eclipse/intellij's indexing background task will be faster
because it ignores the target folders of examples and the eclipse-plugins.
More information in the /README.txt file.
From the README.txt file:
Run the build
$ mvn -DskipTests clean install
Or better yet, run the full build (so with the profile "full")
$ mvn -Pfull -DskipTests clean install
The first build will take a long time, because a lot of dependencies
will be downloaded (and cached locally).
It might even fail, if certain servers are offline or experience hiccups.
In that case, you 'll see an IO error and just run the build again.
After the first successful build, any next build should be fast and stable.
There are 3 profiles:
- default (no profile): Fast, for during development
- full: Slow, but builds everything (including eclipse plugins and
documentation). Used by hudson and during releases.
- soa: prunes away the non-enterprise stuff
Op 27-10-10 13:43, Geoffrey De Smet schreef:
I 'd like to refactor the maven build to use exactly 3 profiles
and
remove all other profiles:
* default
o Fast, for during development
* full
o Slow, but builds everything. Used by hudson, releases and
before you go to sleep
* soa
o Prunes the non-soa stuff away
What do you think?
Long explanation:
* The maven build is too slow atm:
o GWT compilation of all permutations (during development 1
permutation is enough)
* yet some parts of the code don't build with maven
o such as
+ in the past GWT compilation
+ antlr generation
+ eclipse plugin
+ examples
o 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
o 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")
o Build these too
+ drools-clips
+ drools-planner
+ drools-pipeline
+ drools-simulator
+ osgi-bundles
o Proposition: don't build those in soa
* documentation
o Build drools-docs too
o Proposition: merge into profile full
* build-eclipse
o Build drools-eclipse too
o Proposition: merge into profile full
* cibuild (hudson)
o Build these too:
+ drools-docs
+ drools-eclipse
+ drools-examples too
o In drools-process, build these too:
+ drools-bpel
+ drools-jpdl
o Proposition: merge into profile full
* soa
o in drools (parent)
+ assembly: use soa assembly description alternatives
o in drools-guvnor
+ change some tokens in some files (ant based, not
maven filtering yet)
+ run pre-integration-test
o in drools-eclipse
+ Don't build org.drools.eclipse.task
o in drools-docs
+ Don't build drools-docs-planner and
drools-docs-integration
* grammars
o in drools-core and drools-compiler
+ runs the antlr file generation
o 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)
o Proposition: Leave it alone until we deal with that
commented out module bulk-importer-util
* ydoc-doclet (commented out on drools parent pom)
o 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
--
With kind regards,
Geoffrey De Smet