JBossIDE New Extension Wishlists

[mculpepper]

Currently (in JBossIDE 1.5 Preview) we have good representation from the AppServer, EJB3, Hibernate, AOP, and jBPM projects.

In moving forward, We would like to get a kind of "wishlist" from the leaders of all projects in JBoss as to how they feel that JBossIDE can provide (better?) tooling support for their project. We also hope the community can provide additional feature requests. Please reply with anything that you would consider even remotely possible. There's no guarantee that any or all of it will be implemented, but we want to get an assessment for what the team leads & community want, and from there we can possibly start more serious talks with you guys about stabilizing some sort of roadmap / allocating resources towards those goals.

Just to re-iterate, we are hoping to have _all_ JBoss projects have at least _some_ integration with JBossIDE, even if it is very minimal. Currently we have absolutely zero support for: JBossCache/JGroups, JBossMail, Tomcat (save our *AR deployer), JBoss Portal, JBossWS, the list goes on...

Thanks ahead of time for any input =)

[adrian.brock]

I think for most of the projects there would be a requirement to implement
JSR77 and JSR88 clients.
This also needs to be considered within the context of the admin console.
This would encourage those projects to expose relevent information via
these standard interfaces.

[adrian.brock]

I also want to look at what might be done for the microcontainer project.
i.e. annotate a bean with microcontainer config and install it (similar to jboss-aop).

I can see this being a very visible thing. i.e. Take bean classes from a pallete
and link them together to define depencies.
This can then be saved as pojo server configuration.

This should be very similar to JavaBean guis with the additional features
for constructing dependencies/injections and annotations.
It would also consume some of the features from the jboss-aop ide, e.g.
add a security aspect to the transaction manager using drag/drop and configure.

This is the "Minority Report" style configuration.
One side of the screen beans/services, the other the aspects.
The "server" is constructed by grabbing these and joining them together.

[adrian.brock]

Another thing that would be interesting is to see the server logging on the client.
But only the logging relevent to that client's invocations. i.e. we don't want to
see the whole server log.

There is already a prototype of this aspect in the jboss codebase
where a thread local appender is constructed on the server and the results of
logging on that thread during the request are returned to the client.

This would also allow one thread to see TRACE logging while debugging a particular
request while the rest of the server is at INFO logging.

Integration with the IDE to show this client specific log on the console would be useful I think?

[thomas.diesler]

I would like to see good support for the web services client/server programming model.

Server
--------

This involves adding annotations to the service endpoint interface (SEI) and generate the required WS4EE deployment artifacts. These are WSDL, XML Schema, jaxrpc-mapping.xml

Client
-------
This involves pointing to a local/remote WSDL and generate the WS4EE required client artifacts. These are service interface (SI), SEI, complex user types, jaxrpc-mapping.xml.

There should be a good integration between the jbossws tools project and JBossIDE.

Thanks.

[starksm64]

In conjunction with the j2ee deployment support (JSR-88), I would like to see a guide if not a framework for how projects can support their own plugins. There is no scalability in pushing all work to the ide team, so there has to be some ability for the projects themselves to support their own plugins.

[kukeltje]

I'd like to see reverse xdoclet support, so I can very easily show my bosses that application currently running on Bea can run easily on jBoss (without the runtime deployment converter, cause that scares them although it works for some applications)

[lepe]

Generate a more portable xdoclet-build.xml and packaging-build.xml that could be added to cvs. This would mean that anyone can checkout a project from cvs and do a build in a console.

Today Eclipse has to be used at least once to generate those file. This makes it hard to perform automatic builds á la Cruisecontrol.

/L

[reinerka]

I would second the opinion on portable XDoclet and Build files. I constantly need to switch machines (Windows/Linux) and it's a real pain to manually assemble the XDoclet/Build scripts.

Reiner

[ostaniewicz]

'm waiting for the jbossws support


/programmer from Poland

[dhartford]

Just came out of the EclipseWorld and one of Chris Judd's sessions on the Eclipse WTP project that Jboss-IDE extends on top off. Really excited as going to add a lot for everyone developing J2EE applications!

One of the portions that I've taken a closer look is the Webservices creation from the SessionBeans (or POJO's thereof). Right now, WTP only supports Axis as a webservices engine and by that nature only allows for Tomcat as the deployment server integrated into WTP. Although WTP does have Xdoclet support, the jboss-recommended approach still relies on Sun's WSCOMPILE tools to do a majority of the heavy lifting.

Does Jboss intend to provide additional vendor support on top of WTP by allowing their webservice engine as an optional choice for creating Webservices along with the Jboss server as a deployment option for server-side Webservices? I imagine that is part of the intent of JbossWS toolset :-)

thanks,
-D

[theute]

The JBoss Seam project would need some way to create a canvas for new projects, this can be very simple at first. It is just a question of copying files, with a minimal wizard to name the project.

We have the reverse-engineering tool already working thanks to Max.