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 .
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.
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.
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.
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.
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?