<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I agree that a single directory will be sufficient. I don't see any added value by sticking to the hierarchy we had, now that we removed most of the plain bus demos.<div><br></div><div>I am not too excited about introducing a demo BOM but I can live with it as long as the BOM is maintained as part of Errai and not in some other project which makes releasing hell ;).</div><div><br></div><div>AS7/DevMode: We have to be careful that this still remains testable. Arquillian/GWT gives Arquillian full control over container management. The Arquillian GWT extension makes sure to deploy everything necessary for the execution of a GWTTestCase. The JunitShell is a subclass of DevMode, so as long as we are still leveraging the standard GWT configuration options (-server, -noServer (for testing)) we should be fine. So, I think we should use this like the JettyLauncher in errai-weld-integration.</div><div><br></div><div>Christian</div><div><div><br><div><div><div>On 2013-04-05, at 9:35 AM, Jonathan Fuerth <<a href="mailto:jfuerth@redhat.com">jfuerth@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 2013-04-04, at 10:22 PM, Lincoln Baxter, III wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div>+1 to demos in a single sub-directory. This is pretty typical with most projects to have a centralized "examples/" or "showcase/" directory.<br><br></div>Also +1 for import BOM.<br>
<br></div>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. </div></blockquote><br>The 'depchain' idea is something a little different from a BOM or a stack POM. It sits somewhere between: you would still import it (like we do with the JDF BOMs), but it contains actual dependencies (like the errai-javaee-all jar artifact). But because it's imported rather than depended on, it should be able to set certain things to provided scope. In this way, I hope we will be able to blacklist everything provided by the container, while at the same time more faithfully replicating the actual deployment environment (all in provided scope of course). Setting the provided scope 'just so' is something we can't accomplish with a jar-type dependency, nor a BOM in the JDF sense.</div><div><br></div><div>Of course, I'm only assuming this will work. It's something we need to sit down and try. If it works, I think it will simplify our demo and archetype POMs, and also make our DIY getting started experience much easier.</div><div><br></div><div><blockquote type="cite"><div dir="ltr">I think at this point it is safe to assume Servlet 3.0 API as well and use web-fragment.xml to do any necessary servlet configurations. 2.5 config can be documented as things stand now, but 3.0 should be assumed.<br></div></blockquote><div><div dir="ltr"><div><br></div><div>I'm keen to try embedding AS 7/EAP 6 in GWT's dev mode. Dev Mode has a simple SPI for container management, and I'm hoping we can build an adapter to let any Arquillian container connector to be used with Dev Mode.</div><div><br></div><div>If we do that, I vote to up Errai's system requirements to "Servlet 3.0 or better." JSR 315 went final in December 2009. I really think it's just GWT's default embedded Jetty 6 that's blocking us from upgrading to this 3-year-old spec. :-)</div><div><br></div></div></div></div><div>-Jonathan</div><div><br><blockquote type="cite"><div dir="ltr"><div>
<br></div>~Lincoln<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 3:37 PM, Jonathan Fuerth <span dir="ltr"><<a href="mailto:jfuerth@redhat.com" target="_blank">jfuerth@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi everyone,<div><br></div><div>Pavel asked for feedback today on what he's done so far with the demos on the 3.0_p branch:</div>
<div><br></div><div> <a href="https://github.com/pslegr/errai/tree/3.0_p/errai-demos" target="_blank">https://github.com/pslegr/errai/tree/3.0_p/errai-demos</a></div><div><br></div><div>As you can see, there's still a subdirectory for errai-bus. Pavel said his intention is to keep the separation between bus, cdi, jpa, and so on.</div>
<div><br></div><div>Here's my feedback on what's there so far:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>-Jonathan</div></font></span></div><br>_______________________________________________<br>
errai-dev mailing list<br>
<a href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/errai-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/errai-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org/" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
_______________________________________________<br>errai-dev mailing list<br><a href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/errai-dev">https://lists.jboss.org/mailman/listinfo/errai-dev</a></blockquote></div><br></div>_______________________________________________<br>errai-dev mailing list<br><a href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/errai-dev</blockquote></div><br></div></div></div></body></html>