Hello, web developers!

We’d like to get a sense of the development tools you’re using with Resin and what tools you’d like to use with Resin. If you could post your thoughts, we’d appreciate it and will try to incorporate your ideas into our upcoming development efforts. There are a few framing questions below, but please feel free to comment on any other development issues that we’ve missed:

• Do you use an IDE when developing with Resin? Which one?
• If you use Eclipse, do you use the plugin from http://caucho.com/eclipse?
• If you didn’t know about the Resin eclipse plugin, where do you expect to find it? (e.g. on our webpage, in the Eclipse update system, etc.)
• Do you use other tools such as Maven to develop with Resin?
• If you use Maven or some other command line tool, what plugins and/or features would you like to see from Resin?
• Do you deploy to Resin in production directly from an IDE or command line tool? If not, is that a desirable feature?

You can also reply to this related topic on our forums and/or take the poll there.

I’ve updated our Eclipse plugin to fix bugs, add a couple of features, and generally improve the user experience. It’s up in a snapshot now on our Eclipse update site: http://caucho.com/eclipse. Just add this to the software repositories in your Eclipse set up. The changes include:

• Bug fixes (esp. debug handling)
• Better handling of Resin configuration files
• Support for deploying to a temporary directory

(more…)

Last week, I wrote a post about how to use the new remote deploy functionality in Resin 4.0 using Ant and Maven. Now I’ll show you a click-by-click walkthrough of how to use the same facilities from the Eclipse plugin. Some of the navigation in Eclipse can be tricky if you haven’t used it before, so there’ll be screenshots all along the way. (Warning: there are lots of images below the fold…)

(more…)

Scott and Alex have been working hard to make remote deployment possible in Resin from the server side. For the past couple of weeks, I’ve been working on making clients that can deploy your application to a running server. We have a number of vehicles in the works including an ant task, a maven plugin, and an Eclipse WTP deploy target. The interfaces to those are still under construction, as is the whole remote deploy framework, but I thought I’d give a quick preview of how to configure Resin and deploy to it.

(more…)

Every Friday, the Caucho engineers get together to discuss the work we’ve done over the past week and to plan for the next week and beyond. As an experiment, I’m going to start a new weekly series on this blog giving a summary of our meetings. We hope you enjoy it…

Starting with version 4.0, Resin is moving in a new direction to allow users to take advantage of cloud computing infrastructure more effectively. Of course one of the first problems with “cloud computing” is the name itself. It seems like everyone has a vague (perhaps cloudy?) notion of what cloud computing is, so I did a bit of research before Friday’s meeting to make sure that we weren’t adding yet another definition to the mix. Happily, it turns out that we’re not. While the actual implementation of cloud computing infrastructure and tooling is under construction, the desire to be able to run applications transparently on a dynamically changing set of servers seems to be constant.

Our notion of cloud computing is that numerous instances of Resin will be run within virtual machines on hardware that may or may not be managed by the user. The behavior of these Resin clusters will appear to the application to be the same as if they are running on a single instance. The only thing that changes is the ability to scale as the application is running both up and down. What’s new about our approach is that it introduces distributed sessions, caching, and application deployment for web applications.

One of the other topics that came up at our meeting was Quercus Personal. Whenever we go to tradeshows or talk about Quercus, inevitably people want to run the compiled version for personal or hobby projects, but the full professional version of Resin is a bit out of their price range or they don’t really need clustering features. To address this market, we’re planning Quercus Personal which is exactly like Resin Open Source, except that Quercus compilation is available to speed up PHP. The price point is much lower since enterprise clustering is not included. Our goal is to make this version of Quercus just as easy as installing a LAMP stack or nginx/PHP.

Finally we talked about my work on the Eclipse plugin for Resin. This plugin is based on the Eclipse Webtools generic server functionality. We’ve got a basic version working with the standard .war deployment, but I recently made some modifications to allow running a web app directly from the Eclipse project directory. Resin 4.0 now allows deploying a web app dynamically across the cluster, so we also added a way to access that functionality directly from Eclipse. There are still a few places where we need to add UI elements to make this more natural within the Webtools framework, but the basic operation is now available. Of course, we’ll also be documenting the plugin and making it available for installation from directly within Eclipse.

The new WebBeans spec defines a way to configure beans using a neat XML trick where you place the Java package name for a bean into a namespace. Both Scott and Gavin King have written about this, so I won’t rehash the details. One concern of those looking at this approach is that tooling won’t be easy to write to resolve the package names from XML namespaces.

Lately I’ve been working on the Resin plugin for Eclipse, so I thought I’d give it a shot to write some basic IDE facilities for WebBeans. Here’s a screenshot using an example from Gavin’s blog:

You can see that it was pretty easy using Eclipse’s built-in Java and XML analysis tools to extract the class name of the tag under the mouse pointer and then pull the Javadocs from the class. Now, this plugin is pretty fragile and it doesn’t do a lot yet, but for a guy who doesn’t know much about Eclipse (i.e. me ;-)) to whip this up in a couple days means that tooling for WebBeans XML shouldn’t be difficult.

Just a quick note to let everyone know what’s going on at Caucho this week:

We’ve all got our heads buried in code, preparing to make a 4.0 release. The main goal for this release is TCK compliance, but there’s a whole new dynamic cluster and distributed cache/repository/session infrastructure in place. 4.0 will continue where 3.2 left off and thus will continue to be a development version. We’re just doing a major version bump to let everyone know that there are major changes in this one. I’ve been working on getting our Eclipse plugin in order, which I know a lot of people have been asking for. With some luck, we’ll have it downloadable/installable from directly within Eclipse one way or another. Everyone else is working on cleaning up regressions and clearing out bugs.