Arquillian Design Kickoff

[alrubinger]

Now that we've had the chance to review the current state a bit, I think it's time we start taking inventory of things to do, what's already accounted for, etc.  The stuff we've got is making for a fine proof-of-concept which clearly has excited (me and) the community.

So I think it'll be nice for us to all sync up initially to decompose our larger concerns into stuff we can split apart and work in parallel.  How do we feel about meeting at 19:00 UTC this Monday?

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2010&month=2&day=15&hour=19&min=0&sec=0&p1=187&p2=43

Expected Inputs:

• Attendees familiarize themselves with APIs/SPIs and come with questions in mind
• Aslak to prepare a dive and introduction for us

Expected Outputs:

• Everything JavaDoc'd
• Series of JIRA action items
• Ranking of priorities
• Unified vision amongst contributors for what we're aiming to achive, and how we'll do it

Also feel free to propose other meeting times or suggest changes to the agenda; I'm just seeding this discussion.

And how do we feel about format?  #jbosstesting is nice, or we can do a conf call via Skype.  I don't mind so long as it's open to all and can be logged for posting to the community afterwards.

S,

ALR

[alrubinger]

Just a note that when we did this for ShrinkWrap we were forced to reconsider nearly every design decision, and it was time-consuming (2hours+).

S,

ALR

[germanescobar]

I'm in!. I like #jbosstesting but as you wish!

[aslak]

I prefere #jbosstesting, auto logged for summaries..

[dan.j.allen]

Monday is President's Day, but by the same token, perhaps that would make it easier for non-JBoss folks to show up. I'm going to go ahead and say "Yeh" for that time and date.

[dan.j.allen]

Let's use #jbosstesting on IRC. Jay Balunas has been using IRC for the RichFaces meetings with a lot of success. We can always decide to initiate a Skype call mid-meeting if the need arises.

[dan.j.allen]

While we're on the topic of things to fix...

We need to avoid using the term "jboss" to refer to the JBoss Application Server (AS). Instead, we should be using "jboss-as". That would mean changing the container modules to:

• container-jboss-as-remote-60
• container-jboss-as-remote-51
• container-jboss-as-embedded (not 60?)

(anyone else thin that "container" should be moved to the groupId?)

The same change needs to be made in other places as well.

[dan.j.allen]

We also need to talk about where the server boot lifecycle plays into the test execution. With remote servers, all you are doing is binding to the service port. Cheap. With embedded servers, you are responsible for booting them. Expensive.

They way I see it, when the test suite is started, that's when the server needs to come up. The server needs to stay up while individual test artifacts are run (to avoid the startup tax). Then the server comes down when it's all done (and only then). The server going up and down need to be distinct phases. And we need to be responsible with the server output so that the user doesn't just see a frozen commandline.

Note that standalone bean environments (e.g., Weld SE) should absolutely be brought up and torn down for each test artifact. That's effectively like a deployment. There is no start and stop of a server, technically.

[lightguard]

I'm in.  IRC is good

[lightguard]

dan.j.allen wrote:

While we're on the topic of things to fix...

We need to avoid using the term "jboss" to refer to the JBoss Application Server (AS). Instead, we should be using "jboss-as". That would mean changing the container modules to:

• container-jboss-as-remote-60
• container-jboss-as-remote-51
• container-jboss-as-embedded (not 60?)

(anyone else thin that "container" should be moved to the groupId?)

The same change needs to be made in other places as well.

container-jboss-as-version is really verbose.  I saw we drop the container part too.

[jaikiran]

Does the logs from that channel gets saved some place on the server? Or will someone be publishing those logs once the meeting is over?

[alrubinger]

dan.j.allen wrote:

We need to avoid using the term "jboss" to refer to the JBoss Application Server (AS). Instead, we should be using "jboss-as".

True.

dan.j.allen wrote:

(anyone else thin that "container" should be moved to the groupId?)

I wonder if the containers should eventually have their own release cycle too.  They're really optional extension components; implementations of the core with their own dependencies.  In other projects this kind of thing often goes into "extras" or "contrib" namespaces.

S,

ALR

[alrubinger]

Not implicitly, but we'll publish it on the forums or Wiki manually.

I imagine the proposed meeting time isn't too friendly to our Asian friends.

S,

ALR

[johnbailey]

I realize I have been hiding for some time, but I will be joining as well.

[dan.j.allen]

I wonder if the containers should eventually have their own release cycle too.  They're really optional extension components; implementations of the core with their own dependencies.  In other projects this kind of thing often goes into "extras" or "contrib" namespaces.

Yes, containers are extensions. How the release cycles will go, I don't know. But there will be containers we don't write (for instance, someone might create a Spring, Weblogic, or Websphere container). We want to encourage the community to take on responsibility for some containers. People might even want to have their own impl for a container.

I don't think we need to go to "extras" or "contrib" because to me that downplays the importance. Let's just create a "containers" module. Those will be the containers that we maintain. Then we decide how to offer a whatever goes contrib space (github?), which itself could have a containers module.

I think it's okay for the containers to be individually listed in the project (e.g., the Maven 2 test dependencies). As we talked about before, we just don't want container selection based on what is in the classpath.