10 Replies Latest reply on Mar 18, 2011 9:06 AM by sperkins

    Implicit dependency specification sans Maven

    sperkins

      I am trying to implement Arquillian on JBoss 5.0.1 without Maven. One big concern I have so far is the need to explicitly specify dependencies in a method annotated with @Deployment. I've been through roughly a billion posts and wiki pages showing different ways to do this (e.g. specify a package, specify a jar, etc), but haven't yet seen anything that can make dependency specification more implicit. For example, it seems possible to walk through all import statements in the test to determine the classes needed for the test to run. Am I simply missing an obvious way to do this?

       

      -S

        • 1. Implicit dependency specification sans Maven
          alrubinger

          Sounds like you may be interested in this discussion:

           

          http://community.jboss.org/thread/163711

           

          S,

          ALR

          • 2. Implicit dependency specification sans Maven
            sperkins

            Andrew,

             

            Thanks for the reply. I found that discussion in my searches and it describes almost exactly the kind of functionality I was hoping for. However, it seems to be unimplemented and specific to Maven. Do you happen to know of any existing functionality that can help manage implicit dependencies?

             

            Thank you,

             

            -S

            • 3. Implicit dependency specification sans Maven
              alrubinger

              Well, beyond the Maven integration parts, it's also ClassPath scanning.

               

              I'm not opposed to entertaining some configuration to scan for potential deployments and implicitly make a @Deployment archive for the user; but I think the difficult question is: how do we determine what goes into that archive?  If you want to dig in with some suggestions to that end, I'm all ears.

               

              S,

              ALR

              • 4. Implicit dependency specification sans Maven
                sperkins

                Andrew,

                 

                The classpath scanning portion of that user proposal was spot-on from my perspective. I just haven't seen availability of that functionality in the existing Arquillian system.

                 

                Although I definitely don't fully understand the problem domain or how to reduce the explicitness of dependency declaration, it would seem logical to, by default, include all classes that are explicitly imported in the test class, their explicit imports, etc. I know there are scenarios this concept doesn't cover, but that seems like a good start. If nothing else, I could see using annotations to declare which imports to ignore, which to introspect further, etc. Is that even close to a viable solution?

                 

                -S

                • 5. Implicit dependency specification sans Maven
                  alrubinger

                  Welcome to murky waters.

                   

                  Import statements are ditched by the compiler, so we can't introspect the bytecode to walk a dep tree based on the imports.

                   

                  Short answer is that I don't have an intelligent solution lined up yet. Other vendors are scanning everything on the ClassPath for annotations or deployment descriptors...so far we have the archive-based deployment approach.

                   

                  S,

                  ALR

                  • 6. Implicit dependency specification sans Maven
                    sperkins

                    I understand the difficulty better now. I haven't a more implicit solution either, but I'll continue to mull it over. Thank you for clarifying for a beginner.

                     

                    -S

                    • 7. Implicit dependency specification sans Maven
                      alrubinger

                      I personally love explicit deployments.  Mabye someone can explain to me why on Earth you'd want the container to scan/guess at what you what to deploy?   Just to cut down on the work in defining a @Deployment?  I consider that a minimal investment in order to know exactly what's going intothe container.

                       

                      S,

                      ALR

                      • 8. Implicit dependency specification sans Maven
                        sperkins

                        Andrew,

                         

                        My main concern with explicit dependency declaration in each test is that it could become a nightmare to maintain in large projects. And that was just for defining the first layer of dependencies - I didn't find any documentation indicating whether Arquillian manages the dependencies of the explicitly-defined dependencies (but given our conversation, I would guess it doesn't). If I'm testing something that uses 3 objects, that each use another 3 objects, etc, I could wind up declaring a LOT of dependencies. If some of those dependencies should change, I now have to propagate those changes to the tests. In addition, getting developers to start writing a test by declaring its dependencies does not seem like a battle that would go well. Further, the concept runs pretty hard against the idea of Test-Driven Development, where the tests are to be written before the code is - and the dependencies of the class under test are not necessarily known.

                         

                        -S

                        • 9. Implicit dependency specification sans Maven
                          alrubinger

                          Keep in mind that these are INTEGRATION tests, so the old addage of "test first" doesn't apply here in my experience.  That's for unit testing (course, given that integration tests themselves should be written to interfaces, sure, go write the tests first.  Just don't expect them to deploy).  Even when writing unit tests before they're implemented you'll get failures.

                           

                          And in my view, this isn't really defining dependencies; it's defining deployments.  Deployments are a known construct defined by the EE specs.

                           

                          Course, I'm getting the sense that the community isn't too happy with my more limited viewpoints on the subject, and as I say, you can't argue with what people want.

                           

                          So all I need to do is figure out how to implement this in a reliable, predictable fashion.

                           

                          S,

                          ALR

                          • 10. Implicit dependency specification sans Maven
                            sperkins

                            To your first point: fair enough. Integration tests don't need to be painted with the same brush as unit tests. At the same time, I'm sure you see the likelihood of developers to using a seemingly-appropriate tool for both. You're still right, but I think the topic of using Arquillian for in-container unit tests is going to come up again.

                             

                            Defining deployment packages seems out of place in the tests themselves. From my lofty position of knowing nothing about Arquillian I feel as though deployment package definition should be done at a higher level - perhaps at a "test group" level or something to that effect. Tightly coupling the test with the deployment package definition seems to go against natural flow.

                             

                            Back to the main thrust, though: what if the test source were examined instead of the compiled class? That would provide access to the import statements of the test. In my opinion that would be a huge leap toward more implicit deployment package definition. Unless the source to dependency classes were also available, this would still require the test author to define dependencies of the test dependencies (and on up the tree), but personally I'd consider that a reasonably usable solution.

                             

                            Also: groupthink doesn't always point in the right direction

                             

                            -S