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