Where do we want to put

[tfennelly]

1. We have code in the "rosetta" codebase. This is the "core" of the ESB - listeners, actions, couriers, lifecycle code etc.
2. We have "services" code. These are modules that supply a specific service capability to a .esb module. They're packaged as a .esb.

Something that's been missing (IMO) is a home for "commons"/"support"/"utilility" type code e.g. stream, string, http etc utility code. At the moment, this seems to be getting dumped in the "rosetta" codebase, meaning that if you have a service that needs a particular utility, it ends up being dependent on the core of the ESB. Couldn't we have an "esb-commons" (ala apache commons) type module that just contains support type utility code?

OK, we could continue with the monolithic approach that we currently have, or perhaps we could create an "jbossesb-commons" in "extras". Another alternative might be to create a .esb for it (yeuck :-) ).

I know we had the "rosetta" codebase before and we've just got rid of it. Not sure that was really all that "common" anyway.

[tfennelly]

Sorry... the title got truncated. Was supposed to read... "Where do we want to put support/utility code".

[marklittle]

Everything depends on rosetta. What's the advantage of introducing something else for it to depend on? If there was some way you could use the services without needing rosetta and yet needing "common stuff", then I might agree. apache commons works because it's used by a range of other projects. We're not quite there yet.

The refactoring of core to rosetta made sense given what we'd done with the services. This seems like refactoring for the sake of it. But maybe I'm missing something ;-)?

[tfennelly]

If that's what you want ;-(

[marklittle]

"tfennelly" wrote:
At the moment, this seems to be getting dumped in the "rosetta" codebase, meaning that if you have a service that needs a particular utility, it ends up being dependent on the core of the ESB.

I think this statement is the one that really confused me. What services are we developing that don't have a dependency on the core of the ESB ;-)?!

[marklittle]

Owing to a conflict, I won't be able to make the meeting today. In case this comes up: I'm not against the idea of common jars. We do the same thing in TS and other projects have similar approaches. The issue I have is whether or not it makes sense for us given that everything depends on rosetta anyway and we're fast approaching the GA release date.

[tfennelly]

"tfennelly" wrote:
At the moment, this seems to be getting dumped in the "rosetta" codebase, meaning that if you have a service that needs a particular utility, it ends up being dependent on the core of the ESB.

I think this statement is the one that really confused me. What services are we developing that don't have a dependency on the core of the ESB ;-)?!

soapui-client

I need to add some Commons HttpClient support code that both the "soapui-client" and "soap" services will depend on. Don't worry about it. I'll just add it to rosetta and make the soapui-client depend on it :-(

[kconner]

"tfennelly" wrote:
soapui-client

I thought this was a "JBoss MBean" service, not an ESB one.

In any case, doesn't it already include jbossesb-rosetta.jar?

[tfennelly]

"tfennelly" wrote:
soapui-client

I thought this was a "JBoss MBean" service, not an ESB one.

Right, but that doesn't mean it can't have a dependency on common utilities.

In any case, doesn't it already include jbossesb-rosetta.jar?

You're actually right there Kev - I forgot that. You know why this is? Because it depends on some utility code (OGNLUtils and YADOMUtil) that's bundled in rosetta (the core of the ESB). It actually has no dependencies on the real core ESB code.

Anyway guys, as I said... lets make it (leave it) dependent on rosetta. I personally think that sucks but ... :-)

Thanks.

[marklittle]

I created a JIRA for it, so we can at least track it later.