[jbosstools-dev] Re: [Soa-tools-list] Example of why consistent jar usage is important

Denny Xu dxu at redhat.com
Wed Feb 18 08:56:05 EST 2009


Max Rydahl Andersen wrote:
>
>>>> set up a development environment by
>>>> a standalone ESB runtime and there is not a ESB specified classpath 
>>>> container, how could he do?
>>>>       
>>> Eh - how do you do if there is not an ESB in the runtime ? You would be 
>>> in the same situation, right ?
>>>     
>> For current ESB project, there are two separate functions, the first one
>> 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.

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

Denny



More information about the jbosstools-dev mailing list