arquillian-setup should be optional

[agoncal]

Like all the other Forge artifacts, arquillian-setup should be optional, meaning, it should just setup all the defaults if the command is not invoked. If the command arquillian-setup is not invoked, by default, it should setup Arquillian with JUnit and JBoss 7

[ArqEntity.java]$ scaffold-generate --targets org.arqproject.model.ArqEntity
[ArqEntity.java]$ cd ~~
[arqproject]$ arquillian-create-test --value arqproject/src/main/java/org/arqproject/view/ArqEntityBean.java
***ERROR*** No Facet of type [class org.jboss.forge.arquillian.api.TestFrameworkFacet] is installed.

[aslakknutsen]

Why JBoss7 and not WildFly8?

I'm a bit puzzled you even see arquillian-create-test at this point, but I guess you ran arquillian-add only? (not arquillian-setup)

[agoncal]

Good point. The question I have with Wildfly8 vs JBoss7 is more about the JBoss Forge add-on. From a developper point of view, I would like to : without leaving Forge, I create an app, generate some tests, start JBoss/WildFly and execute the tests. If the JBoss add-on is ready for WildFly, then having Wildfly as the default would be ok.

@aslakknutsen Yes, I ran arquillian-add before

[aslakknutsen]

I'm not a fan of prioritizing one over the other here, but if we have some external 'hint' that that's what the user wants to do, then yes, we could add that.

[gastaldi]

I agree that JUnit should be the default. Who uses TestNG these days? :)

Em 11/06/2014, às 07:16, Aslak Knutsen notifications@github.com escreveu:

I'm not a fan of prioritizing one over the other here, but if we have some external 'hint' that that's what the user wants to do, then yes, we could add that.

— Reply to this email directly or view it on GitHub.

[aslakknutsen]

@gastaldi not sure that was the correct thread to reply, but..

[gastaldi]

Sorry, it was not, that's what happens when you reply via e-mail :P

[agoncal]

@aslakknutsen It's just to have some defaults. In Forge, if you don't setup JPA, it uses Hibernate. When you know it and need to change it, you use jpa-setup.

Same should happen with Arquillian. If the default is JBoss7, then you know it, and if you need to change it, you type arquillian-setup

[aslakknutsen]

@agoncal sure, we make Tomcat the default then. Based on usage. ;)

[gastaldi]

HERETIC! jBoss AS is the supreme leader! :P

[aslakknutsen]

Giving this a 2 sec thought.. There are a lot of the plugins that kinda depend on a general 'target'. JPA, Arquillian are two that pop up here.But scaffolding probably do to some extent as well..

Possible a 'global target profile' of some sort would be useful in Forge. Something that sets the defaults for all commands that care:

set-ee-target-profile redhat/jboss

jpa-setup now defaults to hibernate
arquillian defaults to some jboss container

set-ee-target-profile glassfish

jpa-setup now defaults to eclipselink
arquillian defaults to some glassfish container

?

That would allow the user to care about the 'Target stack', not all the individual components within that stack in detail.

[aslakknutsen]

set-java-ee-target jboss --version 7

[agoncal]

Yes, I agree with you. That's an old discussion we had in Forge 2 (I can't find the JIRAs). First, setup a EE version (Java EE 6, Java EE 7...) and then generate the code accordingly (namespace in deployment descriptor are different depending on the version for example).

But I think that won't happen yet

[aslakknutsen]

It wouldn't have to be more complicated then agreeing on two global variable names / values.

java.ee.version = 5|6|7 java.ee.vendor = Red Hat | JBoss | GlassFish | WebLogic

What that means is up to the individual Addons.

@gastaldi ^

[agoncal]

Yes, some project level configuration

project-setup --javaEEversion 6 --javaEEvendor JBoss

[gastaldi]

This is the idea behind this issue: https://issues.jboss.org/browse/FORGE-957 We need to review it asap