I do not see how this requires a different ESB classpath container and especially since you would reallyset 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.
DennyCurrently, 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 ? /maxDennyNor do I understand how users is supposed to know which jars' to compile/run against with the current platform setup we have ;) /maxI'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@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@redhat.com https://www.redhat.com/mailman/listinfo/soa-tools-list------------------------------------------------------------------------ _______________________________________________ Soa-tools-list mailing list Soa-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/soa-tools-list