[errai-dev] Questions and comments about the POM overhaul

[Jonathan Fuerth]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130613/e8e8d909/attachment.html