1 2 Previous Next 15 Replies Latest reply: Apr 14, 2011 11:52 AM by David Ward RSS

    Utility classes

    Keith Babo Master

      Where should we put common utility code which spans multiple modules in SwitchYard?  We discussed this at the F2F and I said I would start a forum thread on the subject so we could add in examples of common utility code and decide where it should live.  Finally getting around to that task item. ;-)


      Since our utility module will be used from many modules, we should try and keep external dependencies at a minimum.  Ideally, the utility module would have no external dependencies.


      If you can think of current utility classes that belong in this module, please reply to the thread.  Moving forward, if you come across an example of general purpose code, come back to this thread and add it to the list.

        • 1. Utility classes
          Magesh Bojan Master

          I have a very generic one org.switchyard.component.soap.util.XMLHelper at the moment. I feel, any util that is used starting from API can live at api/src/main/java/org/switchyard/common/util and the ones that are needed starting from runtime alone can live at runtime/src/main/java/org/switchyard/runtime/common/util. I know we have a task t ochange the package of runtime .

          • 2. Utility classes
            Keith Babo Master

            I was actually thinking that the utility classes would be a separate module.


            Re: the package change for runtime, my recollection is that we excluded core API and core runtime from that naming requirement.  Of course, modules have moved around since then (core/core was removed), so maybe we need to revisit that decision.

            • 3. Utility classes
              Magesh Bojan Master

              I was actually thinking that the utility classes would be a separate module.

              Yeah, I thought about that too. Having a module "common" and then the core "api" module adding that as a dependecy seemed odd to me.

              • 4. Utility classes
                Keith Babo Master

                Core API should not depend on any other module.  Reading between the lines, I can see how this is significant to you because you want to put XML helper classes in there which would be used from metadata.wsdl.  Did I get that right?

                • 5. Utility classes
                  Magesh Bojan Master

                  Exactly 100%

                  • 6. Utility classes
                    David Ward Master

                    Everything in core/config/src/main/java/org/switchyard/config/util/**/* are potential candidates.

                    • 7. Utility classes
                      Keith Babo Master

                      OK, I've been giving this a bit more thought and I wonder if what we really want here is an extensions parent module (i.e. core/extensions) which can contain individual extension modules.  One extension would be the XML helper classes referred to above (e.g. switchyard-extensions-xml).  This helps avoid a situation where we add a bunch of different utility classes to a single util/common module and also allows individual extensions to use external dependencies where appropriate without risking a situation where a single module has a bazillion dependencies (as an aggregated common/util might).


                      I would also like to see the org.switchyard.metadata.wsdl stuff go in the switchyard-extensions-xml (or whatever we decide to call it) module.  I don't want the API module to depend on anything external and it should be easy enough for clients to pull in the additional module if WSDL interfaces are used.

                      • 8. Utility classes
                        Tom Fennelly Master

                        My 2c.... I'd prefer a single commons/utils module that has all our commons code.  I'm sure I'll be on my own on this, but I don't like the idea of fragmenting this into a slew of commons/utils modules.  I think we should at least just start with one and see how we go.  I think the trick to managing external depdendencies is firstly to try not having them, but where we can't avoid having them (e.g. perhaps the wsdl stuff)... scope them as "provided", which would mean that a module using that commons code would need to provide that dependency itself.

                        • 9. Utility classes
                          Keith Babo Master

                          Marking them as provided takes care of the maven dependency, but you will still need them at runtime which is my real concern.  It would be nice if the user could pick up specific extensions/utils based on the needs of their environment.  Maybe we move forward here by starting in the middle.  Let's create a common module and stick and xml module in that.  We can put Magesh's XML helpers in there and then evaluate other cases as they come up (e.g. David's config util).  If we see a proliferation of small modules in common, then it's a sign that we may need to bring it back to common/util alone.  On the other hand, if we just have a few modules and it turns out to be a useful separation, then we are good to go.

                          • 10. Utility classes
                            Magesh Bojan Master

                            Agree with both of you. So there is no extension module as of now, I guess.

                            • 12. Utility classes
                              Magesh Bojan Master

                              So there is no extension module as of now, I guess.

                              Strike that. The interface.wsdl will live in extensions/wsdl and will depend on core/api and common/xml.

                              • 13. Re: Utility classes
                                David Ward Master

                                Okay, so I know I'm late to the ballgame here, but I wholeheartedly agree with Tom Fennelly.  I don't want to see a bazillion switchard-common-* modules.  Yuck. I undertand the concern of dependencies, but how about this?:


                                     If you put something in common, it cannot have ANY dependencies outside of common itself.


                                Then we don't have any dependency concerns, and we also won't end up with too many "common" modules (which doesn't even sound right when you say it out-loud).


                                So instead of what we have now:




























                                I would prefer to see this (1 common module):


























                                Please, pretty-please, pretty-please with a cherry on top?

                                1 2 Previous Next