11:43 p.m.
Yesterday and today, I've been working on the todo-list demo. I had made a bunch of
changes to the demo in its old location (/errai-jpa/demos), so this effort has been to
merge in those changes to the older version of the demo (with a new pom.xml) in the new
location at /errai-demos.
In that process, I came across some things that I changed and/or have questions about.
1. There were only a handful of errai modules defined in the <dependencyManagement>
section of errai-parent. Also, most but not all errai modules were listed in the
<dependencyManagement> section of errai-bom. In both cases, I added the complete
set. Is this a bad idea?
2. Do we actually need a separate errai-bom project? I used to think so, but after my
changes, errai-parent now has the same <dependencyManagement> section as errai-bom.
Can errai-parent just be both?
3. I also added hibernate-validator to errai-javaee-all, because it's required at
compile time for apps that use Bean Validation within the GWT part of the app. I'm
pretty sure this is okay, so this one isn't really a question :)
4. I noticed the new demos are importing errai-version-master like a BOM, but it only has
property definitions in it. These are not importable (they can only be inherited from a
parent pom) -- so does this import do anything? If not, should we just move these
properties into errai-parent so they are at least accessible from all the (non-demo) errai
module poms?
5. The errai-parent project doesn't have jboss-parent as its parent yet. Are you still
planning to do this, or did it not work out? I think that doing this would help shorten
the errai-parent pom a bit, because we'd get all our plugin versions and many
dependencyManagement versions "for free."
6. There are still a bunch of hardcoded versions in the <dependencyManagement>
section of errai-parent. Are these just waiting for the properties we'll inherit with
we transition to jboss-parent?
7. I added an assortment of transitive dependencies from Hibernate and Weld to the
<dependencyManagement> section of errai-parent, such as weld-api, weld-spi, and
hibernate-commons-annotations. All three of these are bear traps, because their versions
don't match the frameworks they seem to be associated with. If there's a BOM we
can import to get the correct versions for these components, that would be WAY better than
what I did.
The above stuff is on the master branch now so we can have a look at it together. We can
undo anything that I shouldn't have done. The commit is here:
https://github.com/errai/errai/commit/9c3fd91f02d7c6ab6014a79f1d0f7444cc3...
And one final issue, which is a bigger question: how do we make the poms for projects
using Errai as simple as possible? To keep the question focused, let's assume the poms
only need to be simple for projects that will deploy to AS7 or EAP6 (and eventually
WildFly). We'll set aside the question of Jetty and Tomcat.
Projects using Errai need a large number of provided dependencies: Java EE APIs like CDI,
JAX-RS, JPA, plus Hibernate itself have to be on the classpath during the GWT compile. But
none of these things are allowed to end up in the war file.
The problem is, I only know of one way in Maven to bring provided dependencies into a
project with transitivity: they have to be declared as compile-scope dependencies in some
pom, and that pom needs to be imported into the project with provided scope. BUT this
mechanism is weak: it does not modify the scope of any transitive dependencies that were
already at compile scope. It just "fills in the gaps" with provided-scope
dependencies. So we end up with things in our .war files that aren't allowed to be
there.
Possible Solutions:
1. can we mark all of the non-appserver-deployable dependencies in the various errai
modules as "optional?" This would mean that by default, nothing that uses
servet, cdi, jax-rs, ejb, and so on would compile: these API dependencies are excluded by
default. BUT we could then supply another depchain pom called
"errai-javaee-provided." You would depend on it at "provided" scope if
deploying to an EE app server, but at "compile" scope if deploying to a simple
web container like Tomcat or Jetty.
We could use maven-enforcer-plugin rules (banishing from compile scope all dependencies
provided by an EE 6/7 app server) to ensure we do not accidentally violate this scheme by
accident in the future.
It would be a big up-front investment, but I think with the help of enforcer, it would not
be likely to regress over time.
2. can we configure maven-war-plugin to exclude a whole list of dependencies (basically
all the same ones that we would have told the enforcer plugin about in option 1 above)?
This way, we could be "sloppy" about scoping API jars and EE impl jars.
3. is there a better solution? I hope so! Both of the above increase the complexity of the
pom of *every project that uses errai*.
-Jonathan