Thursday January 27, 2005
Feedback on J2EE Tutorial & deployment descriptors needed

For J2EE 5, Sun is putting a lot of effort into making enterprise applications easier to create, deploy, and use. Deployment descriptors consistently come up as a source of discontent with the J2EE development process. Right now we're scoping the J2EE 5 Tutorial, and would like your feedback on how the Tutorial should deal with deployment descriptors.

Of these three options, which do you prefer?

  1. No discussion of deployment descriptors, provide pre-assembled JARs/WARs/EARs
  2. Provide detailed instructions on assembling the JARs/WARs/EARs with a graphical tool like deploytool
  3. Provide both "fast track" instructions (option 1) and "slow track" instructions (option 2)

Related to this, what is your preferred development environment?

  1. IDE (like NetBeans, Java Studio Creator, Eclipse, JBuilder)
  2. command-line tools & text editor (vi, Emacs, TextEdit, etc.)
Trackback URL: http://blogs.sun.com/ievans/entry/feedback_on_j2ee_tutorial_deployment
Comments:

I do think tutorials related to deployment is important. One of the really nice things about J2EE is the seperation of deployer and developer roles. Over at work, beyond testing my work in the IDE, the deployment is managed by the sysadmin who is geographically sepereated from me. He makes extensive use of Ant build files to manage and automate the build and deploy cycle (like fetching souce from vcs, complie, codegen, packaging etc. We do not use XDoclet but use package structure to indicate our j2ee/java layers.
I think it would be nice to have a tutorial on how to use Ant to manage and automate j2ee build cycles. I know Ant is not directly related to J2EE but I could argue that Ant provides the lowest barrier to entry for setting up a release/deployment management group wihtin organizations. This is critical given that large organizations now have a lot of j2ee applications and the TCO related to release/deployment management is being impacted.

Posted by Avram Levin on January 28, 2005 at 12:48 AM PST #

I think both 1 and 2 would be good ideas - although I'd never use deploytool myself. :)

Posted by Joseph Ottinger on January 28, 2005 at 03:40 AM PST #

From my experience, the deployment role is so minor as opposed to the developer role that we should not concentrate our efforts there. The developer *has* to provide good DDs or the app cannot be deployed, or cannot be tested or debugged! I strongly suggest we invest much more resources in tailoring the j2ee tutorials against a real J2EE tool, targeted to EASE of DEVELOPMENT. Ease of deployment is just a sub case of this EOD (D for development) area. The natural one that comes in mind is NetBeans 5.0 that will support J2EE 5.0. More and more, more DD data will be move from xml files to annotations, so it becomes more a developer activity to control the meta data. So a plan would be:
1/ assess what Netbeans 4.1 can do today. (hint: it does a lot and even more)
2/ asess what J2EE 5.0 spec will bring to even simplify 1/
3/ educate the J2EE developer community that without tools, there are doomed. I hust cannot believe that an EJ Module with some 50 CMP beans (small database, in the enteprise world) can be effectively developed, configure, debugged, deployed witout an IDE. Now the issue is which IDE? Well, Sun is very well invested in NetBeans. You could also pick Eclipse if you can convince upper management this is the right businees decision. Meanwhile, we should invest all the available resources in what we have: J2EE 5.0 implementation, and its support in NetBeans 5.0. This includes:
a/ engineering: we are well covered here
b/QE: tests should be driven by the IDE: this is what the developer will experience
c/Docs and tutorials/samples: tailored to run well wtih NetBeans. As a side effect, they will run well with CLI and ANT, since NetBeans uses ANT as a build system, natively (i.e not import/export, ant IS the build system)

Posted by ludo on January 29, 2005 at 08:29 AM PST #

Ludo: I agree that ease of deployment is the goal, and that it is almost impossible to hand-write deployment descriptors for anything but the most trivial of enterprise apps. You're right: the J2EE platform did emphasize the role of deployer too much.

With that said, there is no standard tool or method of generating deployment descriptors (so far). Not only that, the IDE field is far from standardized. The question is how do we introduce "ease of use" in a way that doesnt' immediately alienate the other 70% of J2EE developers that don't use or like the tool we are pushing?

Posted by Ian Evans on January 31, 2005 at 01:59 PM PST #

Ease of development is extremely important if J2EE is to continue its momentum. I was really disappointed by the previous J2EE tutorial, mostly because there was such a heavy emphasis on deployment/asant etc. without showing much programming. So many pages were filled with stuff to type in at the command line just to get a few simple examples deployed. Beginners just want to pick up a basic tutorial and put together a few small apps. I am not recommending the current J2EE tutorial to any beginners. The purpose of the tutorial is to teach people how to get started with J2EE. Currently it does not do this effectively. It discusses all kinds of techinical terms related to Web Services for the firt few HUNDRED pages. In addition it would make more sense to provide EAR or WAR files which could simply be dropped into "auto-deploy" than to follow pages of instructions on how to deploy from the command line. I think the best option is to suggest that developers use IDE support to generate EAR and WAR files. No developer (especially a beginner should be creating the descriptors by hand (error prone and difficult). State that they could use any tool of their choice which supports this. NetBeans would be a good example to use. People reading a .NET tutorial are shown how to use Visual Studio. Beginners reading the current J2EE tutorial learn that J2EE is difficult and revolves around deployment descriptors. This creates a very bad impression - rather show them real world usage with tools. Perhaps there should be alternative versions of the tutorial for different IDEs. Users can choose to download a JBuilder,..., or NetBeans-centric tutorial. Perhaps you should provide a easier, shorter tutorial for beginners. The current tutorial looks like a reference work rather than a how-to.

Posted by Martin on February 01, 2005 at 12:46 AM PST #

BTW my favourite tool is NetBeans esp. for J2EE. JDeveloper and Studio Creator aren't too bad either. If I am doing J2SE work I use Eclipse because of its better support for refactoring.

Posted by Martin on February 01, 2005 at 12:48 AM PST #

Martin:

We do, in fact, include pre-built JARs/WARs/EARs for all the examples, and they can be dropped into the auto-deploy directory, or deployed with asadmin, or through deploytool, or through the Admin Console. Therein lies some of the problem: if we documented all the possible ways to deploy the JARs/WARs/EARs, the tutorial would be quite confusing.

Another problem with simply using auto-deploy is that our examples require resources outside the JAR/WAR/EAR (database connections, JNDI names, etc.).

Deployment from the command-line is as simple as:

<code>asant build</code>
<code>asant deploy</code>

Not every example can be deployed from the command-line currently, mostly due to resource consraints, but J2EE Tutorial.next will have command-line deployment for all examples.

We do not document how to write deployment descriptors by hand. We never have and never will. We have been documenting how to use deploytool for hand-assembling the apps.

The J2EE Tutorial's big challenge is finding the middle ground between material for the programming novice, J2SE programmers who are just getting into enterprise development, and experienced J2EE programmers who want to learn about new features and technologies. We've tried to provide multiple paths for these disparate users, and for the next release we're trying to find a better solution to this problem.

Posted by Ian Evans on February 01, 2005 at 01:06 PM PST #

Post a Comment:

Name:
E-Mail:
URL:

Your Comment:

HTML Syntax: NOT allowed