IBM buys Gluecode

karvind writes "After acquisition of Ascential, Big Blue has bought the application management firm Gluecode. From the article: IBM plans to allow its customers to download Gluecode software, develop their own application server software, and begin using it -- all at no cost. IBM also said it will become an active contributor to the Apache Geronimo open source project and will expand the existing community of developers."

Comments

Diabetes

[Anonymous Coward]

I got diabetes from too much glucode.

Amazing technology!

[Anonymous Coward]

... download Gluecode software, develop their own application server software, and begin using it -- all at no cost

Next up from IBM -- they mail you sand, which you can use to develop advanced microprocessors and chipsets, and begin using them, all at no cost!

Followed by their patented 4k GIF reading "WORK FASTER," intended for use to develop your own source code control system, and begin using it -- all at no cost!

For the coup de grace, an online whiteboard, allowing you to jot arbitrary equations and thus evewntually develop amazing new branches of quantum physics, revolutionizing modern thought. All for just two percent of royalties (plus naming rights)!

Thanks, IBM!

Re:Amazing technology!

[Afrosheen]

"I think they really understand what our computer and tech culture is becoming."

Yeah they sure do. It's a source of great income for those with deep pockets like Dell, Microsoft, and IBM. IBM is just leveraging their power to stay alive and grow. They invested heavily in Linux from a number of angles to benefit themselves first and the rest of us second. I don't have a problem with their methodology, just pointing out that their the primary benefactor of the technology they purchase and open up like this.

Job Losses

[Anonymous Coward]

I thought IBM were trying to save money by getting rid of 13,000 jobs?

Re:Job Losses

[Anonymous Coward]

This is part of their overall plan to return to profitability: Give stuff away and make it up on volume.

Re:Job Losses

[Anonymous Coward]

Few good companies (read: IBM) fire 13,000 people to save money. They fire 13,000 people who are mediocre, under-performing, or difficult to work with and instead make the mass firings the result of an "economic downturn".

Makes it easier on the employee getting fired (less insult to injury) and also reduces the likelihood of a law suit (harder to demonstrate discrimination).

Then they turn around and hire 13,000 people who are (hopefully) exceptional, and though the net employee count is unchanged, the average employee competency has grown.

More info

[kbahey]

Editors: articles are increasingly lacking context. Please editorialize a bit more.

The company's web site and Product overview for Gluecode SE would help next time.

Apache Geronimo

[Nik13]

For all of those who didn't know, it's a J2EE server.

Apache Geronimo Homepage

I knew of [apache jakarta] tomcat, but not geronimo. Sorry, I guess I've been living under a comfy rock for too long.

Re:Apache Geronimo

[TopSpin]

...it's a J2EE server.

So is Websphere...

o.O

Gluecode actually goes beyond J2EE; Apache Derby is supplied as a DBMS. It merges all of these independent parts into a cohesive, turn-key J2EE stack with a few extras, like a web based configuration/management interface.

Jetty is the HTTP listener. I really like Jetty. For most small J2EE apps, if you need something that isn't in Jetty Plus (besides the database,) you need to think hard about whether you're over engineering. If you can live within Jetty Plus, your life will be far more pleasant; you need a JVM, tar/winzip and vi/notepad to manage that server.

Why has JBoss moved away from Jetty anyhow? It use to be the default HTTP listener and servlet engine, but it looks like they've diverged. NIH?

Re:Why not use JBOSS?

[carlfish]

I know. We should all just use JBoss and ignore any other attempt to make an open source Java application server. Competition is a terrible thing to have in any market, and should be discouraged at every opportunity.

Charles

The enemy of their enemy...

[brasten]

Of course they would support Apache Geronimo. It's in IBM's best financial interest to protect WebSphere, and protecting WebSphere means not allowing JBoss to become the de facto open-source AppServer standard. At the same time time, they want to appear friendly to open-source to attract developers.

So, they support Apache Geronimo to compete with JBoss.

Re:The enemy of their enemy...

[mark_lybarger]

the only problem jboss has is it's use of the lgpl. you can't get outside corporate sponsorship for core projects (eclipse) by using the lgpl. with geronimo, any company will be able to donate some serious cash to its development and then make money off packaging, selling, and supporting the product.

i'd guess ibm went with linux only because they had already a corporate server room presence (RHEL/SuSE), and the BSD's most likely have much less deployments.

Apache Harmony

[olafura]

IBM has campaining for open source J2SE.
When Classpath is turning almost compliant, Apache tries to help it's accepance by requesting
them to move the code to the Apache Licence.
The man behind it is a VP at Gluecode.
IBM buys Gluecode.

Also there was a rumor on jpackage about an undisclose three letter company that
was getting them to test a free j2se impementation.

Re:Apache Harmony

[Thumpnugget]

IBM has already written their own JVM. But they made the mistake of looking at Sun's source code and signing a license agreement with Sun for said source code. Now they can't write an actually free-as-in-speech one themselves without Sun suing that JVM out of existence for 'contamination' issues and IBM proper for breaking licensing agreements.

So, all they can do now is encourage other people to hurry up and write a free-as-in-speech JVM and, for example, provide financial incentive to that end without actually providing anyone to do the work itself.

Re:Apache Harmony

[k98sven]

IBM has campaining for open source J2SE.

Right.

When Classpath is turning almost compliant, Apache tries to help it's accepance by requesting them to move the code to the Apache Licence.

Not true. Apache Harmony is an effort for an Apache VM. They haven't decided yet if that means writing their own from scratch or adopting one.

They haven't decided yet if they're going to use GNU Classpath either. Although it is very, very likely.

Apache has not requested that Classpath change its license. Firstly because they haven't decided to use it yet. Secondly because there is no percived reason to; So far noone has brought up any reason to belive the Classpath license is incompatible with the Apache one.

What has happened is that the Classpath hackers have said that if they chose to use Classpath, and if there is some minor problem with the license, then they will be prepared to tweak the license as to be compatible. But relicensing the code under the Apache license has not come up.

In any case. It's not about supporting Classpath or IBM. It's about their own self-interest. Apache has more Open Source java code than any other single entity out there. Why would they not want a Open Source JVM to run it on?

Re:Why not use JBOSS?

[dsgfh]

JBoss is great when you only want to deploy a single application on a single box. Start needing to deploy multiple applications on a single server instance & you quickly get into classloader hell (damn ambiguous specs, and JBoss deciding to take a unique approach to just about everyone else).
Try & set up multiple JBoss instances & ask yourself why pre-packaged JBoss components in the deploy directory (where you deploy your applications) refer to specific ports configured elsewhere, and you have to change a half dozen obscure files to get it to work.

Don't get me wrong, I think JBoss is great. I could just do without some of it's quirks.
The Apache Foundation has become a commercial Java developers best friend, esp license wise. Regardless of how compatible other licenses are to internal development, minimal restrictions on what a client can do with their IP gives them a warmer, fuzzier feeling & lets me get on with not re-inventing the wheel.

Gluecode?

[Anonymous Coward]

IBM plans to allow its customers to download Gluecode software, develop their own application server software, and begin using it -- all at no cost.

Does that mean there's a lot of cutting and pasting involved?

First thought about "IBM buys Gluecode"

[renrutal]

Larry Wall sold Perl?!?!

Re:Why not use JBOSS?

[dsgfh]

very single application server has classloading quirks. with BEA/WAS,etc you get to call them bugs and cry and shout that things aren't working right, then wait two weeks for a potential patch from support, that may or may not work.
Yup... they're bugs b/c they're documented to work one way, and actually work another. However the class-loading heirachy is very clear (until you start deploying applications that do their own class-loading as well ala Sun Portal Server).

Any application server that, when it doesn't find the class it's looking for in your deployed application, goes looking for class files in other deployed applications (& yes, I know you can turn this behaviour off, but recall experiencing other problems when I did).

i think the specs are farily clear regarding the application container provider's responsibilities regarding classloaders.
Actually, the spec is very loose when it comes to class loading. It does state that applications shouldn't assume that classes will be loaded by a different classloader, but doesn't state that the servers shouldn't work this way.
By convention amongst the major vendors, it seems you get a heirachy of classloaders, where your application can only load classes deployed with itself or its ancestors. JBoss by comparison flattens it out, so you can load things from other applications.
Clear specification, rather than phrases like "should not assume that each component is loaded in a separate class loader and has a separate namespace" and "Typically this will require the use of a separate class loader for each application.", where the classloading behaviour/heirachy is mandated would be preferable in my books. & while I'm ranting, so would getting rid of app server specific deployment descriptors.

if you read the jboss docs/examples, you'll see that there's a simple ant execution to setup multiple server instances without port conflicts.
I'm obviously running a different version to you, as I've not seen this in the docs. Instead, I've found that I have to enable the bindmanager (which isn't used by default in 3.2.x), then grep the rest of the server structure for all the ports it could possibly be using (hasingleton comes to mind as one offender). This is as per the instructions on the jboss.org website. Possibly it's changed in the latest versions. Unfortunately my corp clients don't like rapid upgrade cycles.

Re:Smooth move? Can't really tell.

[JamesTRexx]

They know what they're doing. They're shifting more from selling software to selling software services. Think of the way Redhat makes money off of a free OS. Businesses (especially the bigger ones) that need support will most likely turn to those that develop the application suite they're using.

Re:Why not use JBOSS?

[killjoe]

Competition is one thing, competition without purpose is another.

Right now there are two major J2EE engines out there. JBOSS and JONAS what is the purpose of a third? Both JBOSS and JONAS are certified by SUN, both of them are proven enterprise ready, both of them have active developers and userbase.

So I'll ask it again. What is the purpose of a third open source J2EE container? Is there some missing functionality tlhey want to implement?

JBoss and Jetty

[mparaz]

JBoss moved away from Jetty because Mort Bay is part of the Core Developers Network which forked from JBoss. Jboss now supports Tomcat.