Slashdot Mirror
Lutris Closes Enhydra Source
Ron van Balen writes: "Lutris has retracted the open source Entreprise Enhydra product. The old version will remain open source, but the open source community will not get access to the new J2EE compliant product. The decision was made because Sun J2EE license requirements don't allow an open source release, Lutris says. Lutris also says it wil refocus its efforts to its commercial products and support the open source community at a lower priority. It seems there is one less commercially supported OSS project on the planet." Newsforge has an excellent piece on this as well which gets into the reasoning and details on this move.
As indicated above, the reason for the closing of source is the J2EE license from Sun. All complaints should be addressed to Sun Microsystems.
My office has been taken over by iPod people.
They're only hurting themselves and developers with their idiotically stubborn unwillingness to get with the program.
I know about Kaffe, but I just checked www.kaffe.org and it hasn't been updated for over a year. Why has it died? Legal reasons? Lack of interest?
Japhar is another implementation, but it is in a very early stage (current version 0.10).
Do other implementations exist?
Are there different licenses for projects like Tomcat? Can you deploy them legally?
If what Lutris is saying is true, will the JBOSS project be able to continue? They are shipping an open source J2EE project now..
No way. Java is more prevalent than it has been ever before; cell phones, pagers and now cars rely on it more than ever. Java isn't going anywhere, you silly troll.
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
For lots of projects, XMLC is good enough. Let's keep using the open source part, and avoid J2EE when we don't have to. This is the kind of message we need to give back to Sun.
This tidbit ran sometime last week on LinuxToday- and the title they're closing the source to Enhydra's misleading; it's Enterprise Enhydra that they're closing the source to, not Enhydra itself.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
According to the comments at newsforge, complaints should not be addressed to SUN. See these comments.
If they would just hand over Java to some standards body, it would immediately be promoted from 'Sun technology' to 'Industry Standard'. How they can consider this a bad thing is beyond me.
Oh, wait. If Java becomes a standard, people won't have to pay Sun anymore to be 'Java compliant'.
It's sad that a developers choice of language/tools can make him lose control over his own licensing policy.
Send your complaints to Sun. We have seen the same with eg. Microsofts Mobile something developers kit, and it is very sad.
The policies governing Java technologies never blended well with open source/free software. Given recent events, we should not expect Java to become more open, on the contrary.
Law enforcement agencies will probably demand closed-source, backdoor-enabled encryption and security subsystems. Open source doesn't lend itself to that.
What is also a problem, is the fact that free software yields incredible consumer surpluses, but very little in terms of company profits. Since the government needs companies to make profits, so that they can levy taxes, they will not encourage free software.
The most dangerous assault will, however, come from the copyright cartels. They will not rest until computers fully implement digital rights management in unalterable binary-only distributions, with source code locked up.
In this light, It will become increasingly difficult to defend the values behind free software.
You mean the Scandinavian Air Lines?
Well, they're about to go under so perhaps you could convince them to drop a few planes on Osama and claim the insurance instead...
I'm not sure why someone looking for a J2EE implementation would go to Enhydra. JBoss is a much better, robust, mature platform for that sort of thing than Enhydra. None of this is to say that Enhydra is worthless - it's very good at what it does, which is a much more lightweight Java web platform than DB + EJB + Servlets + the kitchen sink which is what full J2EE servers are. In fact, most projects would be better off with the lighter-weight Enhydra, especially published-content type projects.
I guess what I'm trying to get at is Lutris should have kept Enhydra the way it was, and not screwed around with J2EE. We have JBoss for that, and Enhydra filled a much different need. The whole mess could have been avoided.
If it ain't broke, you need more software.
SourceForge has nice projects: Open Business or Enigma for J2EE business software. It is still far from finish, but at least you can help to make it happen.
--
Error 500: Internal sig error
Are there supposed to be stories there? All I get is the fluff around the edges and links to the previous and next stories (which are also empty).
--
E_NOSIG
Does anyone remember the beginnings of InstantDB and the Enhydra project? When I originally picked it up, the buzz (and the statements on their webpages) was that its not Open Source yet, but "it will be Real Soon Now (tm)".
After embedding it in my application, I needed to make a couple of changes and went to look for the source, and there was no more talk of 'open source' but rather 'Low deployment license fees'.
Is this somehow related to the J2EE problem (how? its just a SQL db)? Was there another announcement I missed? Or did Lutris excercise their legally allowable but ethically questionable right to say "Its not open source now, we need $$, this is now a product."?
If its the latter, then it makes one wonder how hard they negotiated with Sun.
Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
I would really love to roll a distribution, like the Blackdown group did with Java3D for Linux, but I don't know how to get the OK from Sun.
What is required? The present solution I see is leaving the user to sign the Sun's Communite Source License himself, and just offering a source patch set. For application a blessed binary release would be much nicer.
Again, is anyone from the Blackdown guys here, how could explain what is needed?
Regards,
Marc
I replaced my usage of InstantDB with McKoi (http://www.mckoi.com/database) which is GPL'ed.
Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
Anyhow, how can JBoss have an open source J2EE implementation ?(which is lightyears better, in my opinion) Maybe becasue they don't have so many suits trying to put a spin on the product in order to get it to sell.
It really seems like Lutris is just trying to transition back to the closed source model because they can't sell an inferior, late J2EE application server when you can see what is 'really under the hood' - an almost J2EE 1.1 compliant application server. They are chasing JBoss' and others' tails on a prior standard even.
I used enhydra 3.01 for a major project and it was/is quite good: scalable, robust and fault tolerant, but it seems to have been poisoned by commercial interest and delays in implementing J2EE.
Remember MySQL's old documentation, where it poo-pooh'ed the whole concept of transactions, which they didn't implement at the time? That which they couldn't or wouldn't implement, they trashed with FUD. I read something similar from Lutris in their "making waves" column that basically trashes J2EE for being, from what I can decipher from the article, an overall platform name and version for several technologies. The gist seems to be that the name J2EE has so much marketing power that you can no longer use the single pieces of it you need in your application and discard the rest, simply because in order to be branded J2EE, you have to (gasp) comply with the spec. And of course, since the spec is versioned, then well, the little guys can't keep up, so this is Sun's ploy to squeeze them out.
I suppose this confusion is normal when his application happens to be a J2EE app server, but it's utterly absurd and wrong to say that an application running on a J2EE app server is somehow forced into a monolithic API. It sounds like Lutris is just facing the fact that they started with an app server that was not J2EE then went on a crash program to make it so, and are running into a shortage of manpower. So to compensate, they are including the code from Sun's own J2EE reference implementation.
No, I'm not a fan of Sun's closed and expensive testing process, but Lutris's argument isn't about that, and it simply doesn't hold any water. Lutris is using Sun's code, not just their specs, and they are griping that they can't sublicense it however they wish. They might have been better off pulling a Zope instead, and just building on their existing app server and damn the J*-acronyms from Sun. Enhydra was damn functional, but as far as front-ends go, they have a lot of catching up to do with Zope.
I've finally had it: until slashdot gets article moderation, I am not coming back.
1: Sun is closer to Open Source than Microsoft is: It is equally true that Seattle, WA is closer to Mexico than Vancouver, BC is. That doesn't mean they're actually close.
2: IBM: What a load of Lamborghini exhaust! With IBM, you know exactly where you stand. This is Open, that is Closed. Period. There's no lawyer-speak, snake-in-the-grass, hidden-gotcha licence like Sun Community Source License to worry about.
This sig intentionally left blank.
When MS' licence agreement doesn't allow Open Source programs to be developed with it, the world is coming to an end. When Sun's License agreement doesn't allow it, it's just matter of fact. Why the difference in views? Is Sun magically immune from all of the flames that MS gets?
The problem is that Enhydra is based on Sun's reference implementation of J2EE, not on a clean-room implementation like JBOSS. Sun's license for the reference implementation is the problem, not the J2EE license.
OSS and J2EE work together.
but since I'm not a Java developer it's sort of an "on the outside looking in" thing.
Sun developed the J2EE SDK, and released it to developers with the licensing requirements (and whatnot) fully disclosed. Lutris then comes along later and is upset that Sun won't rewrite their licensing procedures and open source their language interface just to suit them?
And the people here are actually upset about this?
How is Sun the bad guy for not giving away the sourcecode to their product (when they've never had any intention of doing so) just because some other company (I imagine the 'Good Guy') thinks they should?
'Life is like a spoonful of Drain-O, it feels good on the way down but leaves you feeling hollow inside'
The risk is too high that somebody like Microsoft with a huge blind user base will jump on that one and ship an implementation that behaves differently than the reference one from Sun. This would split and kill Java right away.
The problem is that Lutris used the Sun reference code to build the J2EE Enhydra server. It would be kind of like Mono releasing a GPL'ed .NET based on Microsoft's reference code submitted to ECMA.
Sun, on the other hand, has no problem with JBoss, which is a clean-room implementation of the J2EE spec.
If it ain't broke, you need more software.
Well, I really think the situation now is quite self-inflicted.
The companies that now sees their stocks go through the floor just DOESN'T MAKE MONEY. And if you don't make money you can't justify that others should by your stocks for lots of $$$. And in the long run you can't pay your salaries and bills.
Companies needs to make money, it's as simple as that.
sig: for your daily dose of fanatism visit www.taliban.com, www.hamas.org or www.gnu.org
This is the exact reason that I do not use Java anymore. The Sun Community Source License (SCSL) is a farce. Is it *really* open-source? Not in my opinion. It could be closed at anytime, anyplace, without notice, leaving the community behind. It definitely *not* GPL compatible(see http://www.gnu.org/licenses/license-list.html#GPLI ncompatibleLicenses), so it is not promoting software freedom. So, why does not Sun leave Java as proprietary and closed-source? It is a hell of a lot better than upsetting a bunch of dedicated developers.
If the "next big thing" is web services, Java does not have to be the only alternative to Microsoft .NET. There are others out there....
Coderz 4 Life
Lutris is using the license of the new J2EE draft as an excuse to close the OS initiative on the Enhydra project. The fact is, that license is only a DRAFT and not DEFINITIVE. Older J2EE especifications have different and more permisive licenses, it may be to prevent implementations on a not-yet-approved spec.
Even if this was true, Lutris hasn't ever tried to solve the problem. The attitude of "well, we aren't gonna keep on this, but it's not our fault, blame Sun" is not very clean.
If I had contributed to the OS part of a product that is now going to be closed up by Lutris, I would just be pissed.
I doubt Lutris is going to use much of the RI code. The RI is pretty worthless except for the fact that it passes all the compatibility tests, so if you have access to the code, you can get pointers on how to pass those tests yourself.
.NET, figure out the ones that are really useful, and develop our own platform without using Java or specs controlled by Sun or Microsoft.
The problem is that as long as Sun holds on to SCSL, Java and open source are basically incompatible, especially GPL-based projects. The scary thing about JBoss is that at any time Sun feels that they're a threat, they can send out their lawyers and have all references to J2EE specs removed from JBoss docs and code.
The open source community needs an open source J2EE-like platform which isn't tied to Java. We need to look at the features of J2EE and
Think air rage is bad now? Try arming those drunk businessmen and see what happens.
I worked for Lutris not too long ago, in
their Enhydra side (they also have a service
oriented side to their business - building commercial websites etc)
They were excited about the use of Open Source, but
I could tell then that they didn't fully understand it, and they had troubles figuring out how to keep an open source Enhydra, even though they truly meant to keep it open source. The J2EE issue was the biggest obstacle they faced, but they never thought they would have to give up open source. I worked for a guy there that used to work for Sun, and had even worked on the Java language, so he knew what kind of a company Sun is... and it just turns out that they even if they made a J2EE product thats fully J2EE compliant, they wouldn't
be able to market it as such without an expensive license from Sun, and that was a big difficulty they were having. Now the J2EE problem appears to have "resolved" itself by elliminating the open source side of Enhydra, which is SAD!!!! But, like I said, they seemed to have a mildly slippery grasp of what open source is about.
Lutris is also having financial problems (who isnt?) which is another sad thing. They are a great company. It's sad that they had to give up the open source Enhydra.
Lutris was a consulting services company to start with. Enhydra was developed by bringing together a lot of what they used to develop and deploy customer web applications in previous projects. Since they were a consulting services company first, an open source process served to both (marginally) push forward the development of the applications server with public support, but also create a low barrier to adoption for companies to get the services process in the door. I was a software director at one of those companies that adopted the process and then moved to bring in the consulting side to deploy a very large application on.
Things were going great there when the economy was going great -- consulting services paid all the bills for the engineering crew to continue the primary development of the app server. The problem is when the economy turned south, the first thing to be cut were the consulting groups. Lutris had their contracts drying up and couldn't continue to pay the bills that way. Pretty soon they were left with a model that wouldn't work in an economy without a lot of free cash. There had to be another way to generate revenue or to go out of business. That model had to concentrate on traditional software development and open source companies haven't weathered that storm very well when there were commercial or other products that had more functionality or more entrenched customer bases. The quickest way to catch up was to push the enhydra enterprise process, use as much as possible to get it to a finished state (Sun ref implementation) and try to pull in product revenue with traditional sales. This couldn't be rectified with the open source licenses they were previously working on.
It's economics. Sure Sun's license for using their implementation of things is going to effect that, but its an after the fact reason. The underlying problem is that a consulting services company with no contracts isn't going to stay in business... A software company at least has a fighting chance.
I had friends that work(ed) there and this is not necessarily what they wanted out of things, but the survival instinct can be a powerful one. Has the discovery channel taught us nothing?
Hehe, if my car ran Java.. I'd buy a new car. I need to get to work eventually.
ORP is a research Java VM from Intel with fast JITs and GCs. It's not usable for real work, though.
You are in error. JBOSS makes extensive illegal use of Sun code. In JBoss 2.4, uploaded on Monday, Sept 10th 2001, I see: Sun's JAAS is in JBOSS, supplied under under the internal-use only BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") Sun's JNDI is in JBOSS, jndi.jar in client package, ver 1.2.1), also released under BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") Sun's JavaMail 1.2, released under internal-use BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") Sun's JAF, released under internal-use BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") thanks, keith
The issue is simply that if you want to brand as "J2EE" you have to sign a license, then pass a test (which is A Good Thing, IMO - as a consumer, I like the brand protection). Part of the license you sign holds that your use of all the code you used to pass the test is brought under the control of that license. The SCSL license thereby prohibits the kind of code sharing and changing that is a hallmark of OSS.
JBoss does redistribute Sun RI code without license - lots of it. Take a look! As far as I can tell, the JBoss community isn't concerning itself with their "customer's" future problem of being in violation of Sun copyrights, licenses and deployment restrictions.
SAS? SAS Institute? Well, they're hardly open source, man! (Tho the Software distillery, when it was run out of there made some pretty cool Amiga Apps (c=
A feeling of having made the same mistake before: Deja Foobar
If JBoss is merely taking the existing Sun implementation and packaging it with their software is this a problem? I mean, the SCSL and all that applies to MODIFYING their code, right? To quote the license:
2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions), Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.
I grabbed this section of the license from Sun's JNDI license. It seems that as long as you use their code as is you may simply redistribute their binaries which is what appears to be happening with JBoss. JBoss has lots of code that wraps these various packages and ties them all together, but as long as they are not actually modifiying Sun's code then they SHOULD be in the clear.
This sig has been temporarily disconnected or is no longer in service
Lemme see:
. html
Full open source projects:
OpenOffice
Netbeans
Tomcat (The source was gifted from Sun)
NFS (gifted to the Linux community)
They also have source that free for research and internal use at:
http://www.sun.com/software/communitysource/index
They also have given financial and programming support to:
Gnome
Mozilla
And I'm just scratching the surface! And for the record, Lutris was perfectly able to create a fully open source, J2EE branded server. The catch 22 was that they couldn't open source Sun's code so they would have to write their own. Did they? No.
Geez, you people could at least TRY to understand the issue before shooting off at the mouth.
Disclaimer: This post does not meet established Slashdot doctrine. Go ahead, mod me down. I dare you. Be a censor just like the news media. The truth? You can't handle the truth!
Javascript + Nintendo DSi = DSiCade
More than anything, the anger from their customers is due to the fact that they wouldn't say this outright. They make the decision to go closed source, fine. That is their decision to make and one I can respect. But don't blame Sun for that. Sun has very open licensing procedures and really does try to work with their licencees.
Asking Sun to hand over control of source that they developed is extreme and is not a good excuse under any circumstances. End of story.
Javascript + Nintendo DSi = DSiCade
With things like Resin (very fast servlet runner), Tomcat, jboss, Jonas, and OpenEJB, why would we care about Enhydra? It was always kind of a bizarre product anyway, with one of the lamest templating languages I've seen. Open source Java is alive and well.
gcj 3.0 implements a great deal of 1.2. It's lacking AWT/Swing and RMI. The latter will be in 3.1.
Cloudscape is $99 for a deployment license, too, according to Informix's press release for Cloudscape 3.6 (2/20/2001). So you're not saving any money by switching to Cloudscape, unless you never deploy it, or if you plan to deploy anyway in violation of Informix's license.
Anyway, Lutris never did release the source of InstantDB, and they never made an official statement any stronger than a vague intention to release the source of InstantDB. They own InstantDB, and they have the right to do with it what makes sense for their business.
What some people overlook is that companies do own their software, they don't sell it to you, they license it to you for specific uses, with conditions. This is true of MS Windows, and Java, and InstantDB, and almost everything -- including most open source software!
I'd go for Zope... has the better feelgood factor.
Best regards,
Steen Suder
-- for email: send to
I don't think the issue is Lutris. Lutris probably tried to get the license and failed; after all, they'd be in a much better position if they were open-source and J2EE; that would be a completely unique market position. Per Sun, if you read the J2EE spec, you agree to do nothing unless you license J2EE from them. SCSL is the only J2EE license, and Sun won't let you sign it unless they're sure your open-source (good) won't conflict with theirs (bad). Sun is the only game in town because to interoperate with them, you've got to use their API's, under license. Get the gospel? With the JCP, they lock up all the priests. So we're back to the cathedral, with Sun in charge of gospel and clergy alike. Sun squelches competition in enterprise Java software by reaching backwards with the JCP process and viral licenses that require more licensing to deploy and forwards with SCSL's trademark-based scheme (can't deploy without the trademark; need the license to get the trademark). You want viral? Check out the J2EE spec license, JAXP 1.1, heck, even JavaHelp - they all say you can't implement javax.* namespace without getting a license from Sun. The only exceptions are the special Apache licenses which are designed to get us all onto java based two-tier systems. But Sun would not let lutris do this. Why? My bet is that Lutris had the open-source BUSINESS MODEL of giving it away and making money off services and add-on's. That goes completely against Sun's license-based scheme for using app-server vendors to reach into the pockets of developers. I doubt any vendor with netscape's razors-and-blades model would get a license from Sun, because that would hurt Sun and the other licensees too much. Sun prefers value to be in IP that can be licensed (and contained); they can't reasonable reach into services and other revenues. Licensing law is worse that copyright and patent in this regard; at least for those, there are objective standards. Here, Sun can impose any standard it wishes in its "licenses", even if the only thing it's licensing is the opportunity to play the game. At least when MS was setting de facto standards, they had the burden of delivering a quality implementation that beat the others in the marketplace first.
sadly, I think no one from outside Lutris ever contributed any code to the enhydra enterprise project.
Stock value does not pay the salaries and bills. You may be working for stock options, but that's a dumb move in the first place. Stock value is only what ownership of the company is worth to anonymous investors. Your stock could be zero point nada and that doesn't affect whether a company can run or not. The problem comes when you open yourself up to anonymous ownership, the investors may decide the material assets are worth more than the business. Stock value is based on two things:
1) Current earnings, assets, and dividends.
2) Speculation on future earnings, etc.
Venture capital and stock offerings are a loan, expected to be paid back with interest. What happened to our economy is that people forgot that. $18 Million VC or IPO -- we're rich! No, that means you're poor. You just sold your business to someone else and the money has to be put back into the business. It's like selling your house and agreeing that all the money has to go into upkeep on the house. If home repair is your trade, that might be a good business plan, but only if you manage your business properly.
I would really like to see an actual explaination of how the J2EE license prevents then for going open source on their code. Particualrly intersting to note is that Sun itself donated an open source app server to Apache ("Tomcat").
IMO Enhydra has decided that they can't make money in an open source model and are tyring to blame Sun in order to avoid the PR backlash.
1. It's an excellent implementation of J2EE
:-) project leader/lead programmer, Marc Fleury.
:-) download with embedded Tomcat or Jetty.
2. The project has a really active (like in hyperactive
3. The expertise of the other main programmers on JBoss is impressive.
4. The community is very active
5. Now provides a "turn key" (if that's possible with J2EE
6. Extremely developer friendly with a working hot deployment (no crappy weblogic "compilers" etc. here ), quick to restart if you want to,
and handles load fairly well.
I've used JBoss for some time now and I'm very impressed. JBoss has been rock stable for me, and usable on both Linux and Windows. (The servers on my latest project use JBoss/Tomcat/Debian Potato/Blackdown JDK and it's running 24/7)
Recommended! Check out http://www.jboss.org
At this point, Lutris has too much ground to make up against the J2EE server leaders, and no one is jumping onto their proprietary XML binding bandwagon, so Enhydra needs a way to distinguish itself from other Java application servers to get attention. My own evaluation of Enhydra gave me serious reservations with its architecture, including some issues around its scalability. Pointing to Sun and crying foul over the J2EE licensing issues (and that's all it is: an spat over whether or not their product can have the official J2EE compliant label or not), is just poor form.
Does anyone know of any reviews of the current leading open source platforms?
The only link I could source the explicitly mentions JBoss is CSIRO Australia report.
Suggestions?
Probably the only application server you can have up and running in 2 minutes. Plus since its all python based, you can get tracebacks and debug the thing live. Lots of cool new method-specific caching features all built in. DAs for lots of different DBs, transactions etc. Solid community. Check it out! Ya might like it.
Interactive Visual Medical Dictionary
Hi Keith
You are in error. When you have a close look at all the used binary archives used in JBoss you will figure out that you can use it to distribute with you program as long as you don't change it, don't replace software in this archive and some other legal stuff.
Therefore JBoss does not violate the license for the bundled archives.
Have a nice day - Andy
Lutris used Sun's reference implementation, hence the problems... couldn't they switch in an open source impl of that component (e.g. JBoss's) for an OS release?
BS like this only flies because people who know nothing shoot off their mouths like they do, and others belive them because its easier then doing your own research.
h ol d=-1&commentsort=1&mode=thread&pid=2312751#2312969
The SCSL and the J2EE licenses are totally seperate and dtstinct legal documents and thus seperate and distinct issues.
If you'ld like to actually learn something about them, based on the posts I've seen here I wouldn't try slashdot. I
Instead try the actual pointers contained in the post referenced below:
http://slashdot.org/comments.pl?sid=21699&thres
if i wanted to use a system that separated church (presentation) and state (coding) i'd go with Apache Jakarta's Cocoon XML based server. It's basically takes the concept of JSP, uses XML instead of HTML, and does not allow you to put code into the page. .JSP ...
from what i could tell from a curory reading, this is similar to the Enhydra XMLC component does - reads in your HTML, finds tags and creates stub java code for it. sorta the reverse of JSP - creating code from HTML, instead of inserting or calling code from your
which is better? i would imagine it depends on your shop's bent - if you're more a bunch of Web Monkeys er... HTML coders, then you could just code up the page, and give it over to your java monkeys who could then use Enhydra to XMLC the html to get stubs of code to fill in.
on the other hand, you could have your two monkeys actually work together and plan and design out the system, and then use standard JSP or even Cocoon to work together to create JSP or XSP (cocoon) files which have all the pretty graphix and onMouseover javascripted stuff you want.
i dunno, i suppose enhydra is now yet another way of doing the job.
but on the other hand, it has nice pretty screens to manage the server... maybe someone on the Jakarta project teams can steal er... use that concept in their open stuff. cuz we all know that Apache needs a bit more GUI management for us to really sell its use in the Enterprise.
spike
2001-09-11 07:52:50 J2EE/Enhydra: What game is Sun playing with OSS (articles,sun) (rejected)
This is old news, yes, and, as ever, Slashdot moderators have to be blamed for that.