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

[Max Rydahl Andersen]

>> We can help by creating a "ESB client project" wizard (or facet?)
> I don't think creating a "ESB client project" wizard or facet can 
> solve this problem, since the ESB client can be any types of
> project, such as java project, ESB project and sometimes it's might be 
> a J2ee project,  all need to for ESB client is just adding
> ESB classpath to the project, 
The same can be said about any type of java project in eclipse - they 
can all be configured manually if you want ;)

It would solve it in the sense users could see how it should work - but 
if we don't need a ESB client project then i'm fine with that;
I think there are too many specialized project wizards in eclipse already ;)

> so I think we can just provide a popup menu "Set Up ESB Classpath" by 
> pop up a wizard to select
> all available ESB classpath container.
I don't understand what that does differently than adding ESB classpath 
under standard classpath dialog for java projects ?

/max



>
> Denny
>>
>> /max
>>>
>>> Denny
>>>
>>> John Graham wrote:
>>>> Denny,
>>>>
>>>> Max and I discussed this, and for the time being (this release), we'd
>>>> just like to move the ESB cp container ahead of the AS cp container on
>>>> the project classpath. This will allow override libs in the ESB
>>>> classpath container to be loaded first.
>>>> Is this possible, and, if so, can you take care of this?
>>>>
>>>> -- John
>>>>
>>>> On Wed, 2009-02-18 at 21:56 +0800, Denny Xu wrote:
>>>>> 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
>>>>
>>>
>>
>