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/9c3fd91f02d7c6ab6014a79f1d0f7444cc3843d2
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
_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev
