1 2 Previous Next 17 Replies Latest reply on Feb 17, 2010 1:12 PM by Dan Allen

    Arquillian Design Kickoff

    Andrew Rubinger Master

      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

        • 1. Re: Arquillian Design Kickoff
          Andrew Rubinger Master

          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

          • 2. Re: Arquillian Design Kickoff
            German Escobar Newbie
            I'm in!. I like #jbosstesting but as you wish!
            • 3. Re: Arquillian Design Kickoff
              Aslak Knutsen Master
              I prefere #jbosstesting, auto logged for summaries..
              • 4. Re: Arquillian Design Kickoff
                Dan Allen Master
                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.
                • 5. Re: Arquillian Design Kickoff
                  Dan Allen Master
                  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.
                  • 6. Re: Arquillian Design Kickoff
                    Dan Allen Master

                    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.

                    • 7. Re: Arquillian Design Kickoff
                      Dan Allen Master

                      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.

                      • 9. Re: Arquillian Design Kickoff
                        Jason Porter Master

                        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.

                        • 10. Re: Arquillian Design Kickoff
                          jaikiran pai Master
                          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?
                          • 11. Re: Arquillian Design Kickoff
                            Andrew Rubinger Master

                            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

                            • 12. Re: Arquillian Design Kickoff
                              Andrew Rubinger Master

                              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

                              • 13. Re: Arquillian Design Kickoff
                                John Bailey Novice

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

                                • 14. Re: Arquillian Design Kickoff
                                  Dan Allen Master

                                  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.

                                  1 2 Previous Next