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

Fri Jun 14 18:19:28 EDT 2013

On 2013-06-14, at 10:09 AM, pslegr wrote:

> Hi guys,
> 
> see inline 
> 
> On 06/13/2013 11:43 PM, Jonathan Fuerth wrote:
>> 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?
> Actually, the idea behind an errai-bom & errai-version-master is following
> errai-version-master is the only place to manage 3rd party dependencies versions and thus it contains only     dependency-management
> errai-bom is the place to keep dependency-management for all errai modules
> 
> where errai/pom.xml (errai parent pom) will inherit from errai-version-master, which will inherit from jboss-parent,
> errai-bom on the other hand is intended to be the only (in the ideal case) dependency to be imported for errai developers projects, so I think errai-bom is still valuable

I think errai-bom is a nicer name than errai-parent for importing into project poms.

But since imports work recursively, we could still define all errai modules in the <dependencyManagement> section of errai-parent, and just import errai-parent into errai-bom. And errai-parent would have jboss-parent as its parent.

>> 
>> 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?
> well, errai parent can be everything in fact :)  in case we leave it as it is now
> But the intention to separate dependency & plugin management into more modules allows us to import, for example errai-version-master, into examples independently from other errai modules.

Right, but an import only brings in dependencyManagement. It ignores everything else: properties, actual dependencies, plugins and plugin configurations.

>> 
>> 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 :)
> ok
>> 
>> 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?
> no, demos are importing errai-version-master, which has all 3rd party dependency management... it is importable - and properties there... at the begin of errai-version-master pom.xml are for defining dependency version
> https://github.com/errai/errai/blob/master/errai-version-master/pom.xml
> check it again please

Oops. My mistake there. So this does dependency management for all of errai's transitive dependencies. What is the use case for importing this into an app (or demo app) separately from errai-bom?

>> 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."
> yeah answered above... version master will inherit it
>> 
>> 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?
> yes there are waiting for such transition, what we will be able to inherit we will do for sure, the other plugin versions (not defined) in jboss-parent will be defined by us
>> 
>> 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.
> yeah, importing versions via boms of 3rd parties is better IMHO then redefining version along the way

Which BOM(s) should we I use for these things that are related to Hibernate and Weld?

>> 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.
> errai-bom is intended to play this role - for developers, who will want to use Errai in their projects, I mean

Right, that will pin the versions correctly. But my concern is about actually getting all the needed dependencies into a project with the correct scope.

>> 
>> 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*.
> 
> Not sure what is the best solution to define scopes... for demos I tried to use scope properties... within profiles
> have a look https://github.com/errai/errai/blob/master/errai-demos/errai-cdi-demo-mvp/pom.xml
> 
> wrt 2. I checked that approach, and in the end (when there were many dependencies to ban, looked messy to me)
> wrt 1. not aware about this, I will check it out
> 
> 
> Well, I am definitely for some broader discussion. The above thoughts and ideas about version master & project bom I was mostly inspired with many jboss.org projects (Seam, Richfaces, Arq...)

Yeah, maybe the mess is unavoidable. I was hoping that bringing Errai into a project could be as simple as adding one dependency or importing one depchain. At worst, maybe we'd need both. But it seems that we can't get apps away from needing to specify a whole bunch of Errai's transitive dependencies in their own poms, mostly just to set them to provided scope.

There must be a way... we need more options! :-)

Best,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130614/a4c7e72f/attachment-0001.html 