1/ no, I don't want too much clients jars in my application : quite the opposite : I only want javaee-api.jar in my application, and the rest (the implementation jars compatible with the app server chosen by my customers) would be dynamically downloaded to this client (with a smart "auto-update" mechanism to avoid downloading at each start-up if there's no new version).
2/ no it's not maven related, because I'm looking for a run-time / production feature. Maven is good for development activities. Likewise I'm not looking for Opscode's Chef. I want the app server to deliver its own implementation jars to client apps, taking these jars from its own lib/ directories Maybe I'm asking too much, I don't realize.. Alex On Sun, Dec 9, 2012 at 4:41 PM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote: > Not sure if i still didnt get it but sounds like you either want too much > client jars (== loosing users) or reinventing maven. Isnt it? > Le 9 déc. 2012 16:38, "Alex The Rocker" <alex.m3...@gmail.com> a écrit : > > > You're though with me, but I won't give up without trying harder :) > > > > Here's what I have in mind : providing a "Java EE client JARs > provisioning" > > REST service for : > > 1. client apps which talk to the app server using JMS > > 2. client apps which talk to the app server using EJB > > 3. client apps which talk to the app server using JPA datatypes > > To avoid a service that would also such client apps to download all jar > > files if they need a feature subset, then one could steal some ideas to > > Eclipse plug-ins download. > > In Eclipse, you can select a few plug-ins, and ask to also get their > > dependencies and even better, you can make your fine-grained selection of > > what you'll actually download. > > > > Ideally, all Java EE app servers should provide such "client Java EE > jars" > > provisionning service :for example, WebSphere Application Server could > > also downloading WebSphere MQ client Jars; etc. > > > > That's why in my initial post I was asking whether or not there's a Java > EE > > standard for this need, either in existing Java EE specs or in next or > > future ones. > > If not, then would it make sense for TomEE to provide it, as a working > > "reference implementation" of a future enhancement of Java EE specs ? > > > > Does it sounds better now? > > > > thanks, > > Alex > > > > > > On Sun, Dec 9, 2012 at 8:34 AM, Romain Manni-Bucau < > rmannibu...@gmail.com > > >wrote: > > > > > Hmm, but the point is it depends so much on the needs that it will end > up > > > with the tull server to manage all cases, no? > > > Le 9 déc. 2012 00:28, "Alex The Rocker" <alex.m3...@gmail.com> a > écrit : > > > > > > > Hello, > > > > > > > > Suppose you want to write a Java client application for your web app > > > that > > > > relies on JNDI, JMS and send & receives EJBs to and from the > > application > > > > server. > > > > Then, in your client application (which is not a web app, but rather > a > > > Java > > > > program with a class having a main() entry point method), you'll need > > to > > > > have in our classpath: > > > > - ActiveMQ JARs for using JMS in a way compatible with TomEE's > > ActiveMQ > > > > - TomEE actually uses web service protocols to make remote calls to > > EJB > > > > Session Beans. There still needs to be a client library that knows > > how > > > to > > > > encode an EJB call into XML and extract the returned result as a Java > > > > Object. > > > > - the same idea would also apply to Java Programming Objects > > > > > > > > See jbossall-client.jar for something equivalent provided by JBoss : > > > > > > > > > > > > > > http://docs.jboss.org/jbossas/docs/Installation_And_Getting_Started_Guide/5/html/ch01.html#d0e525 > > > > > > > > Now, better than JBoss client libraries, we'd like to have a REST > > > service > > > > on the app server allowing our "client application" to download the > app > > > > server's client libraries specific to its JMS, EBJ, etc. > implementation > > > > into some directory that would be added to the client application's > > > > CLASSPATH at runtime. > > > > > > > > Is it clearer ? > > > > > > > > Alex > > > > > > > > > > > > On Sat, Dec 8, 2012 at 6:22 PM, Jean-Louis MONTEIRO < > > jeano...@gmail.com > > > > >wrote: > > > > > > > > > +1 > > > > > Don't really understand the question. Could you elaborate a bit > more? > > > > > Le 8 déc. 2012 18:11, "Romain Manni-Bucau" <rmannibu...@gmail.com> > a > > > > > écrit : > > > > > > > > > > > Not sure i got you. These jars are not always mandatory and > depends > > > on > > > > > your > > > > > > needs. > > > > > > Le 8 déc. 2012 17:56, "Alex The Rocker" <alex.m3...@gmail.com> a > > > > écrit : > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > A developer in our company asked me if there's any "clean way > to > > > > > download > > > > > > > "tick client" TomEE-specific JAR files. > > > > > > > > > > > > > > For example, for (not so recent) TomEE 1.5.1 snapshot, his > > > > application > > > > > > > needs to use the following JAR files at runtime: > > > > > > > > > > > > > > activemq-core-5.6.0.jar > > > > > > > javaee-api-6.0-4-tomcat.jar > > > > > > > openejb-client-4.5.1-SNAPSHOT.jar > > > > > > > openjpa-2.2.0.jar > > > > > > > slf4j-api-1.6.6.jar > > > > > > > > > > > > > > Given that: > > > > > > > a/ I have advised him not to include these JARs in his > > > application, > > > > > > > because his application must be compatible with newer TomEE > > > releases, > > > > > > thus > > > > > > > the question about a "provisioning service" for downloading > those > > > > Java > > > > > EE > > > > > > > client-enabling JARs. > > > > > > > b/ His application doesn't need these JARs at build-time : he > > only > > > > > uses > > > > > > > generic (ie, non vendor specific) APIs like JNDI or JMS > > > > > > > c/ The last JAR file quoted above (slf4j-api.jar) is > interesting > > > > > because > > > > > > > it's not directly a Java EE client implementation, but a > > dependency > > > > of > > > > > > some > > > > > > > of the other JARs > > > > > > > > > > > > > > Question: > > > > > > > 1. Is there a generic way to fulfill this requirement in a > vendor > > > > > > > independent way? if not, anything planned in Java EE 7 ? > > > > > > > 2. Would it make sense to have such feature in TomEE to keeping > > > Java > > > > EE > > > > > > > tick clients up to date? If yes, then may I fill a JIRA for it? > > > > > > > > > > > > > > Thanks, > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > >
