<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi guys,<br>
<br>
see inline <br>
<br>
On 06/13/2013 11:43 PM, Jonathan Fuerth wrote:<br>
</div>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div>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.</div>
<div><br>
</div>
<div>In that process, I came across some things that I changed
and/or have questions about.</div>
<div><br>
</div>
<div>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?</div>
</blockquote>
Actually, the idea behind an errai-bom & errai-version-master is
following<br>
errai-version-master is the only place to manage 3rd party
dependencies versions and thus it contains only
dependency-management<br>
errai-bom is the place to keep dependency-management for all errai
modules<br>
<br>
where errai/pom.xml (errai parent pom) will inherit from
errai-version-master, which will inherit from jboss-parent,<br>
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<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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?</div>
</blockquote>
well, errai parent can be everything in fact :) in case we leave it
as it is now<br>
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.<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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 :)</div>
</blockquote>
ok<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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?</div>
</blockquote>
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<br>
<a class="moz-txt-link-freetext" href="https://github.com/errai/errai/blob/master/errai-version-master/pom.xml">https://github.com/errai/errai/blob/master/errai-version-master/pom.xml</a><br>
check it again please<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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."</div>
</blockquote>
yeah answered above... version master will inherit it<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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?</div>
</blockquote>
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<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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.</div>
</blockquote>
yeah, importing versions via boms of 3rd parties is better IMHO then
redefining version along the way<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/errai/errai/commit/9c3fd91f02d7c6ab6014a79f1d0f7444cc3843d2">https://github.com/errai/errai/commit/9c3fd91f02d7c6ab6014a79f1d0f7444cc3843d2</a></div>
<div><br>
</div>
<div>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.</div>
</blockquote>
errai-bom is intended to play this role - for developers, who will
want to use Errai in their projects, I mean<br>
<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
Possible Solutions:
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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*.</div>
</blockquote>
<br>
Not sure what is the best solution to define scopes... for demos I
tried to use scope properties... within profiles<br>
have a look
<a class="moz-txt-link-freetext" href="https://github.com/errai/errai/blob/master/errai-demos/errai-cdi-demo-mvp/pom.xml">https://github.com/errai/errai/blob/master/errai-demos/errai-cdi-demo-mvp/pom.xml</a><br>
<br>
wrt 2. I checked that approach, and in the end (when there were many
dependencies to ban, looked messy to me)<br>
wrt 1. not aware about this, I will check it out<br>
<br>
<br>
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...)<br>
<br>
<br>
cheers Pavel <br>
<br>
<blockquote
cite="mid:0DE2370D-89BD-454C-B950-3E4A5F1D2E3D@redhat.com"
type="cite">
<div><br>
</div>
<div>-Jonathan</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
errai-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/errai-dev">https://lists.jboss.org/mailman/listinfo/errai-dev</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Pavel Slegr
JBCP Product Lead & WFK Productization
Red Hat Czech s.r.o. Purkynova 99 612 45 Brno
email: <a class="moz-txt-link-abbreviated" href="mailto:pslegr@redhat.com">pslegr@redhat.com</a>
office phone: +420 532 294 152
mobile: +420 605 858 132
</pre>
</body>
</html>