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.
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 ;). 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. Christian On 2013-04-05, at 9:35 AM, Jonathan Fuerth <[email protected]> wrote: > On 2013-04-04, at 10:22 PM, Lincoln Baxter, III wrote: > >> +1 to demos in a single sub-directory. This is pretty typical with most >> projects to have a centralized "examples/" or "showcase/" directory. >> >> Also +1 for import BOM. >> >> 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. > > 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. > > 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. > >> 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. > > 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. > > 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. :-) > > -Jonathan > >> >> ~Lincoln >> >> >> On Thu, Apr 4, 2013 at 3:37 PM, Jonathan Fuerth <[email protected]> wrote: >> Hi everyone, >> >> Pavel asked for feedback today on what he's done so far with the demos on >> the 3.0_p branch: >> >> https://github.com/pslegr/errai/tree/3.0_p/errai-demos >> >> 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. >> >> Here's my feedback on what's there so far: >> >> 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. >> >> 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 *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). >> >> -Jonathan >> >> _______________________________________________ >> errai-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/errai-dev >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> _______________________________________________ >> errai-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/errai-dev > > _______________________________________________ > errai-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________ errai-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/errai-dev
