[errai-dev] Questions and comments about the POM overhaul
pslegr
pslegr at redhat.com
Fri Jun 14 10:09:31 EDT 2013
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
>
> 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.
>
> 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
>
> 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
>
> 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
>
> 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...)
cheers Pavel
>
> -Jonathan
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
--
Pavel Slegr
JBCP Product Lead & WFK Productization
Red Hat Czech s.r.o. Purkynova 99 612 45 Brno
email: pslegr at redhat.com
office phone: +420 532 294 152
mobile: +420 605 858 132
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130614/3a7bfda5/attachment-0001.html
More information about the errai-dev
mailing list