>> is setting ESB runtime classpath for the project, and another
is
>> deployment. two functions have dependency on project target server
>> runtime, but the two dependencies are different, Setting esb runtime
>> classpath is just ensure that the project can
>> compile against ESB. if the project target runtime does not contain
>> an ESB runtime, users can provide a predefined JBoss ESB runtime, so
>> users can write esb code at least, but if ESB project tight couple
>> with project target runtime server, users can do nothing without
>> setting target runtime correctly.
> I do not see how this requires a different ESB classpath container
> and especially since you would really
> like to make sure that users compile against the same thing they
> deploy against.
Yes, a reasonable logic should be that, but users might deploy the
project to any server which runtime
supports the project facet, as far as I know, wtp deployment does not
have limitation that the project only can be deployed
to the project's target server, that means the project target server
runtime has nothing to do with the deployment,
so it maybe hard to ensure that users compile against the same thing
they deploy against.
afaik, the server needs to support your ESB facet to deploy
it.
>
> In what situations today is an ESB project useful without having a
> targeted runtime ?
Users can select a predefined standalone ESB runtime, so they can
program and then deploy,
not sure if it's the best logic, maybe ask the server runtime pick up
jars is a good solution.
Sure, I'm not saying to *remove* the ESB classpath container, but I'm
saying that in the case of
the runtime is *embedded* inside the server runtime it would make sense
that the server runtime
provides the classpath instead of the separate ESB classpath container.
But lets get back to seeing what we can do now.
We haven't heard why there are different .jar's yet but I guess the
thing we can do know is to ensure that the ESB classpath container
gets added in front of the server runtime - that should solve this
issue, right ?
/max