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

[John Graham]

> How to change the order of classpaths ? Press F1 :)

You might laugh, but in a previous life I dealt with a product team that
was convinced users are not going to know about F1, and thus wanted big
"Help" buttons added all over the product. ;)

> With respect to more specifically in ESB then sure, find a good spot
> in the ESB docs and add it in.

Yes, specifically about the jars we know are impacted: scout and juddi.

Denny: Can you coordinate getting this information added to the JBDS ESB
documentation? 

-- John

On Thu, 2009-02-19 at 16:48 +0100, Max Rydahl Andersen wrote:
> On 19-02-2009 16:47, John Graham wrote: 
> > > That is something the user can fix then.
> > >     
> > 
> > Can we document this somewhere in the product?
> >   
> How to change the order of classpaths ? Press F1 :)
> 
> With respect to more specifically in ESB then sure, find a good spot
> in the ESB docs and add it in.
> 
> /max
> > -- John
> > 
> > On Thu, 2009-02-19 at 16:42 +0100, Max Rydahl Andersen wrote:
> >   
> > > On 19-02-2009 07:54, Denny Xu wrote:
> > >     
> > > > John and Max, today ESB cp container has been being in front of AS cp 
> > > > container on ESB project classpath, after you
> > > > create a esb project, you can look at the .classpath file, the default 
> > > > order is that the ESB cp container is in front of AS cp.
> > > > 
> > > >       
> > > okey, sounds good...so what was the cause of the original error ?
> > > Does it just work outside the box ?
> > >     
> > > > There might be a problem for a ESB client project, users might create 
> > > > a Java project as ESB client project and then
> > > > add ESB and AS library to the project with wrong order manually, so 
> > > > the wrong scout.jar would be loaded.
> > > >       
> > > That is something the user can fix then.
> > > We can help by creating a "ESB client project" wizard (or facet?)
> > > 
> > > /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
> > > > > >           
> > 
> >   
>