Post a Comment
.. is: http://www.jboss.com/products/devstudio
or: http://www.redhat.com/developer_studio/?intcmp=70160000000HETe
or: http://www.press.redhat.com/2007/12/10/introducing-jboss-developer-...
not some ad-ridden site that doesn't link back to the source material [/rant]
Edited 2007-12-11 17:31 UTC
When will they learn? While certainly not expensive, I can't imagine that many prospective users will shell out $99 to download and kick the tires on this package. Most enterprise users can't just plunk down $99! You think they're going to go thru the IT purchasing process to try JBoss Studio!?
RH, you're letting your grip on the enterprise slowly but surely slip thru your fingers with this nonsense. Get your products into the hands of users! Your enterprise client-base will come through with the subscriptions.
Edited 2007-12-11 17:44
In many enterprises there are a set of approved software, and you don't download things that are not approved if you like your job. So going through the IT department would have been necessary even if it was free of charge. I wouldn't call $99 expensive. The process of getting it approved for use, probably costs more in many companies.
So, the $99 price is most likely a bigger problems to amateur users, that program for fun and don't make money from their software, than it is to enterprises.
Quit being a leech on society. Red Hat went out and bought this closed source software and then released it under the GPL. How many companies do stuff like that. Then they only charge $99, which includes a copy of RHEL and a RHN subscription to keep the box up to date using Red Hat's repo's. And you are complaining about $99. This would cost thousands of dollars from Microsoft. Plus, in a matter of weeks, it will be added to all the other distros anyway, so quit whining. While free is nice, the free is really about freedom. Not being a cheapskate.
Well, as long as you're going to use the word leech, you might want to ask the Eclipse developers their opinion of RH's choice of GPL licensing, which effectively locks them out of this wonderful gift RH is "giving" the community. As with the GPL and obtaining RH for free, the license permits it, but as you point out, there is a question of reciprocity and fairness, right?
Edited 2007-12-11 21:07 UTC
What do Eclipse developers have against Red hat? Why can't they use this IDE? I don't know what you are inferring so please tell me.
The plugins are GPL, which is incompatible with the EPL licensing of Eclipse. It's like taking existing BSD code and modifying it with GPL code, which is permissable by the license but ensures that the original developers of the platform code aren't able to benefit from your modifications by incorporating it into the community base.
I don't want to detract from Red Hat's move here, it's admirable that they acquired a proprietary company and open the code up, but let's keep in mind that they are leveraging a different OSS community's platform to do so, and in effect proprietarizing their contribution by use of the GPL to the exclusive benefit of the RH/JBoss/GPL community.
There's nothing inherently wrong with what Red Hat did, and I'm not trying to turn this into a license war, I'm just trying to point out the irony of complaining about people insisting on using Red Hat code for free without reciprocation as being leechers, while Red Hat is somewhat doing the same thing with the Eclipse community. That's all.
After reading the licenses and thinking about it, I have come to an opinion about the Eclipse devs. Its there own fault for getting screwed. They picked a license that allowed for companies to close up the stuff they built on top of Eclipse. It was fully their choice. They shouldnt have any beef against Red Hat who simply opened up what was once closed. The Eclipse devs didnt lose anything. They just dont get the chance to benefit from Red Hat like everyone else, because they chose a different license. If they GPL their stuff, they can add in the new code and everyone will be better off. I dont see how anyone can be ticked at Red Hat here.
So, the article leaves much to the imagination...
Okay, so it's got complete jboss integration, but what about other app/web containers like weblogic, geronimo, glassfish, etc?
what about other frameworks such as struts 2, axis 2, etc?
Anyway, great to hear there's even more choice in the IDE arena.
btw, right now I'm using MyEclipse IDE and it does the job. It's got it's problems, but nothing's perfect.
Redhat bought a closed source IDE to improve JBoss's offering. You know that Redhat owns JBoss, right? Since IBM, Sun, Oracle, and Bea all ship IDE's with their app server stacks, it makes sense for JBoss to follow suit.
This is a pretty good move for Redhat. Since it is based on Eclipse, any plugin for the other containers / app servers will work (no surprises there).
When it comes to free java IDE, you are pretty much talking about netbeans or eclipse.
IMO the best Java IDE (or just best IDE.) is IDEa by jetbrains (http://www.jetbrains.com/idea/) Back in my j2ee days, I single handedly got the whole team using it, everyone liked it so much we managed to put enough pressure on management to buy us licenses, which they REALLY didn't want to do, as our contract with Oracle gave us a free JDeveloper site license.
Try PIDA. VIM supports code completion for Python and PIDA is a full IDE with VIM embedded.
http://pida.co.uk/
http://pida.co.uk/trac/wiki/ConfiguringVimForPython
- it is popular
- Because Java is fast and portable, Java IDE's are written in Java, it is proven that this is a much better choice than c++.
- it is much easier to write intelligent IDE's for strongly typed languages. dynamic nature of scripting languages makes many IDE tricks (smart code completion, refactoring, formatting etc) very difficult.
Edited 2007-12-12 01:36
Also java as big corporate support ($$$) behind his shoulder.
As for strongly type languages, I don't think that's really a issues, pydev eclipse plugin for python provide all your tricks. There will probably other issues than this one. (no compile validation, runtime validation just discover bug at runtime, when it shouldn't happen)






