8:05 a.m.
+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
8:49 a.m.
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
3:04 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
3:22 p.m.
New subject: Maven profiles (making maven faster and build more): changes done
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
8:36 a.m.
New subject: Maven profiles (making maven faster and build more): changes done => correction
Correction: use -D instead of -P to active the profiles.
So, to run the full build, use -Dfull:
mvn -DskipTests -Dfull clean install
This is because the default and full builds need to also active the notSoaProfile
and -D's are flexible enough to do that, while -P's are not.
Also, the soa profile has now been cleaned up.
Op 03-12-10 22:22, Geoffrey De Smet schreef:
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<== WRONG
*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
5130
days inactive
5170
days old
5 comments
4 participants
participants (4)
-
Edson Tirelli -
Geoffrey De Smet -
Michael Anstis -
Ming Fang