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

[Max Rydahl Andersen]

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

In what situations today is an ESB project useful without having a 
targeted runtime ?

/max
>
> Denny
>
>
>    
>>> Currently, there are two options for creating  ESB classpath container,
>>> 1. get ESB runtime jars from specified AS runtime
>>> 2. get jars from a specified ESB runtime which predefined in
>>> preference page.
>>> for now, AS classpath container is used as non-facet related
>>> classpath, I don't think it can pick up jars
>>> for all project facet, there maybe JBossWS facet, it need JBossWS
>>> runtime, JBoss ESB facet need
>>> ESB runtime, and  Seam facet Seam runtime,  AS classpath container
>>> almost don't know where the
>>> location and structure of an new added runtime.
>>>        
>> Seam facet is not doable because Seam jar's are not part of the AS
>> runtime (it is "outside" and needs deploying inside the app),
>> ESB and WS are all "inside" the AS runtime and AS could calculate these.
>>
>> btw. I think all of this is more for jbosstools-dev than SOA tools since
>> it is not soa specific.
>>      
>>> If AS classpath container can provide a extension point for new facet
>>> and runtime,  every new facet
>>> just need extend the extension point by providing a jars calculation
>>> logic and AS runtime pick jars
>>> from extensions.   that would be good.
>>>        
>> Yes - maybe runtime components can do this ?
>>
>> /max
>>      
>>> Denny
>>>
>>>
>>>        
>>>> Nor do I understand how users is supposed to know which jars' to
>>>> compile/run against with the current platform
>>>> setup we have ;)
>>>>
>>>> /max
>>>>          
>>>>> I've been looking into this during the morning, and so far here is what
>>>>> I've got:
>>>>>
>>>>> This appears to be a case of SOA-P using an AS capability that the
>>>>> tooling has no easy way to accommodate at present. That is, SOA-P is
>>>>> able to override certain libraries contained in AS by default for its
>>>>> own use, and thus applications written for SOA-P (as opposed to just
>>>>> AS)
>>>>> need to be configured accordingly. Now, we might wish that the world is
>>>>> flat, but reality intrudes with much more complex demands. The simple
>>>>> fact that there are library/classloader scope capabilities in AS that
>>>>> are not readily supported by the current tools means that other more
>>>>> complex enterprise applications could run into similar issues.
>>>>> A potential solution (though not in this release of tools) is to
>>>>> provide
>>>>> a Eclipse launch configuration that allows for classpath container
>>>>> manipulation and perhaps makes some educated guesses ("if ESB and
>>>>> duplicate jar between ESB and AS, remove AS jar from classpath" for
>>>>> example) in the default settings. This would enable users to handle a
>>>>> host of classpath configuration details when developing with AS, not
>>>>> just for ESB.
>>>>>
>>>>> For the short term (this release), I think the only viable option is to
>>>>> identify the known overlap and work-around it as best as possible. This
>>>>> might include dropping known problematic jars from the classpath or
>>>>> simply user documentation.
>>>>>
>>>>> -- John
>>>>>
>>>>> On Fri, 2009-02-13 at 15:22 +0000, Mark Little wrote:
>>>>>            
>>>>>> Hi Max. I'm not sure why this email is blank (at least I can't use
>>>>>> it). Anyway, I've asked John to take a look at the problem from our
>>>>>> side since I'm on vacation next week. I think we all know what we want
>>>>>> to be able to do with tooling, so let's identify the issues and get
>>>>>> them fixed. I don't believe this is an insurmountable issue.
>>>>>>
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 Feb 2009, at 14:46, Max Rydahl Andersen wrote:
>>>>>>
>>>>>>              
>>>>>> ----
>>>>>>
>>>>>>
>>>>>> Mark Little
>>>>>> mlittle at redhat.com
>>>>>>
>>>>>>
>>>>>> JBoss, a Division of Red Hat
>>>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>>>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in
>>>>>> UK and Wales under Company Registration No. 3798903 Directors:
>>>>>> Michael Cunningham (USA), Charlie Peters (USA), Matt
>>>>>> Parsons (USA) and Brendan Lane (Ireland)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Soa-tools-list mailing list
>>>>>> Soa-tools-list at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>>>>              
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Soa-tools-list mailing list
>>>> Soa-tools-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>>          
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090218/33f65639/attachment.html