To me it makes more sense to Add Arquillian to the JDF Quickstarts then to Add Arquillian Quickstarts to JDF. JDF already has Quickstarts for cdi, ejb, events, decorators etc etc etc etc etc.. Why duplicate the tech based Quickstarts just to show how to test it. If we make the JDF Qucikstarts Testable, Arquillian is just along for the ride. It's just there, just like junit/maven/jenkins. Infrastructure shit. (Added bonus is you can automatically verify the Quickstart as well) It's 2013; testing is not something some test people do on the side when they have time. Testing is Development. If you want to learn how to use CDI, you need to learn how to test it as well. (Even if it's not for a lot of people; that should not be our message to the world.) Add a section to all Quickstarts that describe the use of Arquillian in the given example. We might find some special cases that only can be described via an 'Arquillian only Quickstart', but that would target Arquillian/Setup not EE tech. -aslak- ps: I know some of the JDF Quickstarts has Arquillian in them already, but github is down atm so I didn't have a chance to see how many / in what state / if it explained. ----- Original Message ----- > BTW, when I mentioned "fork" in the last message, this is equivalent to > "porting" into JDF as Raf is ably doing. > > S, > ALR > > ----- Original Message ----- > From: "Rafael Benevides" <benevides(a)redhat.com&gt; > To: "Karel Piwko" <kpiwko(a)redhat.com&gt; > Cc: "jdf-dev" <jdf-dev(a)lists.jboss.org&gt;, wfk-pm-list(a)redhat.com, "Sande > Gilda" <sgilda(a)redhat.com&gt;, "Peter Muir" <pmuir(a)redhat.com&gt;, "Aslak Knutsen" > <aknutsen(a)redhat.com&gt;, "Lukas Fryc" <lfryc(a)redhat.com&gt;, "Andrew Lee > Rubinger" <arubinge(a)redhat.com&gt; > Sent: Wednesday, August 14, 2013 8:58:32 AM > Subject: Re: [wfk] (WFK2-49 / JDF-424) Add Arquillian Showcase to Quickstarts > > In this case, shouldn't we want to merge this PR in a 'jdf-quickstart' > branch ? > > As the Jira issue title says "Add Arquillian Showcase to Quickstart", > your previous opinion made total sense to me in this context: > /"Historically, we've been removing all other container Maven profiles > from code as we did community -> product conversion(take RichFaces for > example). If Arquillian Showcase is going from Arquillian org > (community) into JDF (product), we should follow the same path."/ > > > Em 14/08/13 05:09, Karel Piwko escreveu: >> This might be a stupid question, but I though that removing of other >> containers/build tools should happen on JDF level, not as a part of >> arquillian.org. While most of the changes makes sense to have upstream as >> well >> to make fork closer to upstream, I can't agree with removal of profiles and >> build tools in upstream. Shouldn't JDF rather fork and Arquillian update >> Showcase based on a part of JDF work? >> >> For Arquillian Showcase in upstream it is definitely reasonable to show >> other >> possibilities, like GlassFish or Ivy. Arquillian is not tied to JBoss. >> >> Karel >> >> On Tue, 13 Aug 2013 13:11:57 -0300 >> Rafael Benevides <benevides(a)redhat.com&gt; wrote: >> >>> Hi all, >>> >>> I sent the following PR >>> https://github.com/arquillian/arquillian-showcase/pull/17 for an earlier >>> review. SO PLEASE DON'T MERGE IT YET. >>> >>> I made most changes under the cdi/ folder and that's were you should >>> focus. >>> >>> Some changes: >>> >>> - Removed BOMs project/folder >>> - Removed parent project/folder - Quickstarts should be treated as >>> standalone >>> - Removed gradlew, ant + ivy >>> - Removed other containers profile and keep only arq-jbossas-managed and >>> arq-jbossas-remote (removed -7 on the profile name) >>> - Added license headers and Readme.md >>> - Make cdi/pom.xml follow JDF guidelines. >>> - Update GAV to >>> org.jboss.quickstarts.wfk:jboss-arquillian-showcase-cdi:2.4.0-redhat-SNAPSHOT >>> - Minor other changes >>> >>> I'll appreciate any feedbacks on this since I'll apply the same changes >>> to all other folders/quickstarts >>> >