> > Are you talking about building jar/war/ear/rar/sar
> > files from Eclipse UI? To be honest, I never
> > considered this as a useful feature and always
> though
> > that ant script is the way to go when it comes to
> > packaging. I think Eclipse workspace has enough
> > information for the custom deployer
> Well, that's the question. What I'm thinking to offer
> is a checklist of the classpath of a project to
> choose a subset to deploy. So you would deploy always
> the whole set ? For example JBoss client jars needn't
> be deployed. The question is if such a subset this
> a.) increases performance *significantly*
> b.) might avoid trouble (although I can't make up a
> usecase for this)
> But you have more experience with this. If you think
> there is no point for this that's less work and good
> news (:
We can't deploy everything. For example, you'll get ClassNotFoundException if you deploy ejb.jar file from Sun. Current code reads "excludes" list from .classpath.jboss file, but after some thinking I believe that explicit list of what has to be deployed is a better way. Note that it might be necessary to provide different packaging for different server configurations, but it is not a problem because we can create as many EAR projects as we like. Cool!

> Yes, I was thinking of eclipse doing the packaging
> and/or creating the build.script to make use of the
> information we have. The idea with custom ant tasks
> to use this information is very interesting.
I'll start new thread as soon as I find time for it :-(

i have been following this field for some time , it looks to me as if web services is in a mess in terms of number of specs and duplication of standards--e.g (i found jax rpc as a spec much more cryptic than any of the main line j2ee specs because of cross references to so many other specs: soap/wsdl/saaj/jaxm/jaxr/jaxb/ and the list goes on)

In this scenario this link from msdn does provide some clarity on where we are going-- but isnt it only MS perspective

Consider this : following consortiums communities are driving the specs
1.w3c
2.oasis
3.JCP through java communicty
4.microsoft /ibm/bea with others
//i am sure there are more

Would n't it be a better idea to first filter out competing specs...and then come out with a road map.

Rajdeep, good points.

My order of consideration would be:
a) J2EE Web Services (as defined by the J2EE Specifications).
b) Specs that are next in list for adoption by the community like security and driven by users' immediate needs. (while maintaining interoperability as driven by WS-I).

Scott wants to place some of the prominent Specs on the JBossWS roadmap.