<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi guys,<br>
<br>
here are my comments<br>
<br>
<br>
<pre>>><i> I'm not sure I'm keen on this "separation of demo topics" approach. We're not planning to keep a ton of demos in the project (we decided that together in last week's hangout). So I think it would be best to throw all the demo projects under a single directory.
</i></pre>
Ok, this would certainly look better, but every examples "separated
by topics" do have quite different requirements wrt its pom's <br>
In case all the examples will be in the same folder, then how do you
want to aggregate the things examples have in common <br>
<pre>>><i> One other thing that I think is different from what we had planned to do: in 3.0_p, the bus demos still depend on a parent POM. JDF required demos to have top-level poms (no reference to a parent), and we were planning to follow that. We can & should still have an errai-demos pom which refers to all the demos as submodules, so the demos are built when we build errai-parent. But we don't want the demo poms pointing back up to that parent.
</i></pre>
in the .../errai-demos/errai-bus/pom.xml there is no dependency on
errai/pom.xml anymore ... as it was before<br>
or can you point me, where you see the dependency on parent pom ?<br>
<br>
<pre>>><i> I *do* think we should develop a 'depchain' or 'BOM' type pom that can be imported. These would be useful for demos, archetypes, and anybody's end-user project.
>> We should probably have a separate depchain for each appserver we support (as7, eap6, tomcat, jetty). We should design these depchains so the demo poms are as small
>> as possible (unfortunately, we can't import plugin configurations, so they will be somewhat larger than what we have now).
</i></pre>
<br>
This is an interesting idea, yes we could have a BOM's, which could
keep dependencies, but as you say.. still there must be plugin
configurations<br>
and we need separated profiles. So we must be careful not to have in
the end the configuration even harder, then now.<br>
<br>
<pre>>><i> Finally +1 for stack POMs. This is what I started with the errai-javaee-all module. As far as I know it still works. Very helpful if users can pull in a single dependency and have a working setup on a given container.
</i></pre>
Yeah, I like this approach... the stack pom project as
errai-javaee-all looks great and simple...<br>
On the other hand, do we want to introduce like stack projects for
every "demo topic" ... or do you have any other suggestion how to
differentiate between the stacks projects , other then<br>
the "demo topic" ?<br>
This can turn into having much more configuration overhead just
because of demos...<br>
<br>
looking at errai/errai-javaee-all/pom.xml ... it keeps dependencies
only<br>
so its practically the same as, what we can reach with BOM here...<br>
<br>
<pre> <dependencies>
<dependency>
<groupId>${groupId}</groupId>
<artifactId>bom</artifactId>
<version>${version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</pre>
<br>
I would not care too much about dependencies here, as we can easily
simplify it via BOM's or stack projects... as shown above, what
keeps me concerned is how to simplify profiles & plugin
configurations<br>
Do you have any ideas, how we could simply inherit or import
those... ?<br>
with the idea behind to keep the actual demo poms tiny ?<br>
<br>
cheers<br>
Pavel<br>
<br>
<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>