11 Replies Latest reply on Feb 10, 2010 2:00 PM by Andrew Rubinger

    Reorganizing the demos

    Dan Allen Master

      I think we need to reorganize the demos within the Arquillian source tree. If nothing else, I think we should rename demos to demos-junit to be consistent with demos-testng.

       

      But to be consistent with the terminology of other projects, we should really be referring to the demos as examples. The term demo comes from the perspective of the project team member wanting to showcase the project. But the term example is more logical to our users (aka developers) that will be downloading the project. So that brings us to example-junit and example-testng.

       

      The final step, which I haven't formed an opinion on yet, is to go ahead and put the examples underneath a folder named examples. If we do that, then we should think about doing that for all logical grouping in the project, the next candidate being the containers.

        • 1. Re: Reorganizing the demos
          Andrew Rubinger Master

          dan.j.allen wrote:

           

          I think we need to reorganize the demos within the Arquillian source tree. If nothing else, I think we should rename demos to demos-junit to be consistent with demos-testng.

          Yep.

           

          dan.j.allen wrote:

          But to be consistent with the terminology of other projects, we should really be referring to the demos as examples. The term demo comes from the perspective of the project team member wanting to showcase the project. But the term example is more logical to our users (aka developers) that will be downloading the project. So that brings us to example-junit and example-testng.

          Agree.

           

          dan.j.allen wrote:

          The final step, which I haven't formed an opinion on yet, is to go ahead and put the examples underneath a folder named examples. If we do that, then we should think about doing that for all logical grouping in the project, the next candidate being the containers.

          I think the most important step (and I may have mentioned this in other Threads) is that the current demos are in fact our own integration tests, and they need to run against all target containers from a single build command (ie. mvn install).  Right now they're organized into logical profiles, so you select one profile at a time.

           

          In terms of reorganization I'd suggest:

           

          • Extracting out the container non-specific parts into a consumable "example" component
          • Extending these generic bases to add metadata (annotations)
            • To specify a target container
            • To configure the container with vendor-specific properties

           

          In fact, we're blocked from any new development until this is done as we have no way of knowing if we're breaking existing features.

           

          So what are the tasks necessary to get this componentization?

           

          1. Refactoring out generic (container non-specific) bits
          2. Adding the annotations features to denote a target container
          3. Anything else?

           

          S,

          ALR

          • 3. Re: Reorganizing the demos
            Dan Allen Master
            Oops. I apologize for not checking JIRA first. Well, this is still a great discussion. I'll link to it
            • 4. Re: Reorganizing the demos
              Aslak Knutsen Master
              Dan, good.. I forgot to link Jira to this..
              • 5. Re: Reorganizing the demos
                Andrew Rubinger Master

                Dan; the issue is now assigned to you; do you have cycles to be starting this now?

                 

                I'm under some pressure to be making progress each night (and this is now my blocker), so I can take it over if you're on other things.

                 

                S,

                ALR

                • 6. Re: Reorganizing the demos
                  Dan Allen Master

                  Go for it. I just assigned it to myself because it was previously unassigned. I'll be continuing to work on Arquillian, so I can review/consult as you go.

                   

                  Btw, definitely use the Weld project as a Maven/project layout cheatsheet. Pete put a lot of thought and sought advice about how best to setup the project. For instance, one thing we should have for Arquillian is a triology of build poms: parent, bom and dist. I'll follow up with details in another thread or IRC.

                  • 7. Re: Reorganizing the demos
                    Andrew Rubinger Master

                    How do you feel about the ShrinkWrap setup?  I don't find the trilogy is always necessary; for instance we use the Aggregator POM to create the dist.  Though the aggregator is separate from the parent (==build) POM.

                     

                    S,

                    ALR

                    • 8. Re: Reorganizing the demos
                      Dan Allen Master

                      What you call the aggregator, I call the dist. So we are basically talking about the same thing.

                       

                      The only additional artifact I'm proposing the the bom. That just makes it easier for extensions to inherit our parent and then consciously choose to import our matrix of dependency versions. We can try it, and if it proves to have little utility, we can just move the contents into the parent.

                      • 9. Re: Reorganizing the demos
                        Andrew Rubinger Master
                        Cool, what's a BOM?   Linky?
                        • 10. Re: Reorganizing the demos
                          Dan Allen Master

                          Ah, yes. A definition would be nice:

                          BOM - a bill of materials

                           

                          The Maven team explains the purpose of this artifact in the Importing Dependencies section from the Introduction to the Dependency Mechanism on the Maven project website:

                          Imports are most effective when used for defining a "library" of related artifacts that are generally part of a multiproject build. It is fairly common for one project to use one or more artifacts from these libraries. However, it has sometimes been difficult to keep the versions in the project using the artifacts in synch with the versions distributed in the library. ...a "bill of materials" (BOM) can be created for use by other projects.

                           

                          There is an example following that explaination.


                          Basically, it identifies all the dependency version numbers and repositories.

                          • 11. Re: Reorganizing the demos
                            Andrew Rubinger Master

                            Ah cool.

                             

                            In EJB3 and ShrinkWrap the BOM and parent are one and the same.  Course, for EJB3 there's no external importers (yet) and for ShrinkWrap there's no external dependencies!

                             

                            S,

                            ALR