|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 38
Messages: 38
Messages: 38
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Raven 1.1: Build Java with Ruby
Raven is a build system that leverages Ruby tools (namely Rake and Gems) to let you build Java projects easily. It provides a way to handle dependencies, specific Rake tasks for Java, all based on Ruby. This release introduces simple tools to install your dependencies directly.
Why base your build system on Rake and Ruby Gems? For one thing, Rake is a very simple build system; it uses domain specific tasks; it's based in Ruby, a script language, rather than using Java in a way Java wasn't necessarily meant for. Ruby Gems is a packaging system, a bit like yum, CPAN or apt-get. It conveniently handles package installation, update and removal.
Here is what Raven will allow you to do:- Your jar files are wrapped in a Ruby Gem (a package). You can then start manage your java jar library just like a Gem library. Tools are provided to convert a Maven jar repository to a Gem repository (both local on your machine or on a public server) or to directly install packages.
- Your dependencies are declared in a Rakefile. You basically say which Gems you need (and so which jars will be included in your classpath) for building. When building, if some Gems are missing, they are automatically installed in your local Gem repository, just like Maven.
- Raven gives you a small library of Rake tasks that you can use to compile your java classes, build a jar file, build a war file, produce javadoc, wrap the jar you built in a Gem, etc.
- This effectively gives you everything you need to build Java projects, using Gems for dependencies management and Rake for scripts.
This latest release introduces simple package installation:
raven install httpclient
raven install -g xstream xstream:1.2
raven install --all -g axis2
Check it out here:
http://raven.rubyforge.org/
|
|
|
Message #221549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Does this tool connect to a Gem server?
Could this tool connect to a Maven repository instead?
|
|
|
Message #221553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Benefits
Ok, as usual, any open source software that comes around and fills some specific niche and/or competes with others is welcomed. Though I always like the know the benefits.
Can you please explain the benefits of using Raven over Maven 2. I understand the ability to extend tasks using Ruby, but what else?
Ilya
|
|
|
Message #221556
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Benefits
What about scripting for a starter? Did you ever get a problem that didn't quite "fit" into Maven2's dogma? Wrote a plugin? How painful was that? Just copying a single file needs a plugin if it doesn't fit in the default directory structure. You have a schema used in 2 modules? Too bad, you'll need a module with just a single schema file in it.
IMHO being able to write simple scripts when you need to do simple things should be the basis of any build system. So I guess that's the biggest differentiation you're looking for. And by the way, how many lines of XML to get started?
Raven also benefits from Gem and Rake, two very good tools in Ruby. The first one gives you a *real* package system. Like RPMs, or debian packages. You can list, install, uninstall in a single command. Check for duplicates. All that good stuff.
Using Raven, you'll get rid of what we dubbed "the Maven uncertainty principle". The source of it being mostly snapshot releases and plugins. And the combination of both being the worst. So Raven doesn't do anything special with snapshots. And that's a feature.
Another thing: Raven doesn't break if a repository is down. It just tells you that it isn't there and that's all. And it will check if other repositories also have what you're looking for. The search for a given dependency is done using regular expressions matching, so it's far less verbose to install a dependency or declare it for your build.
So that's a lot of details but altogether, it makes your life much easier and leaves you more time to do something else. I'm not saying Raven is the silver bullet, there are still many things to implement to be as good as can be, but it's already a good alternative I think.
|
|
|
Message #221571
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
you don't gots tuh rite a plugin tuh copy a file with maven 2
simply execute an ant task fer the right phase, son!
Sheesh!
|
|
|
Message #221573
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: you don't gots tuh rite a plugin tuh copy a file with maven
How many lines of XML to configure the antrun plugin? About 16. Plus the bugs of the antrun plugin.
|
|
|
Message #221576
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Neat tool
Will be checking it out. We do more python than ruby for our scripting, but really interesting tool.
|
|
|
Message #221577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Neat tool
We do more python than ruby for our scripting, but really interesting tool.
Does looking at Ruby code remins anyone of Perl? If we had to pick up another language for scripting (actually dynamic typing) needs, then why not some with better easier syntax? How did Ruby become so popular in last couple of years, when Python/TCL/ML/Haskell/(even)Lisp/Scheme have been around for similar or much longer timeframes and have had much wider developer base (of course Perl continues to have the widest developer base as far as these 'other' languages are concerned)? How did Ruby get this momentu despite its pathetic run-time performance (compared to others in the list)? I know its an off-topic question - but I am interested to learn ths bit of history.
|
|
|
Message #221579
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Neat tool
Does looking at Ruby code remins anyone of Perl? If we had to pick up another language for scripting (actually dynamic typing) needs, then why not some with better easier syntax? How did Ruby become so popular in last couple of years, when Python/TCL/ML/Haskell/(even)Lisp/Scheme have been around for similar or much longer timeframes and have had much wider developer base (of course Perl continues to have the widest developer base as far as these 'other' languages are concerned)? How did Ruby get this momentu despite its pathetic run-time performance (compared to others in the list)? I know its an off-topic question - but I am interested to learn ths bit of history.
You said out loud what I've been wondering silently. Why indeed? I think Python is much better than Ruby, personally. But, like you, I'm interested in knowing what phenomenon made Ruby so popular. I'm not interested in any kind of programming language flame war. So please, information only :-)
|
|
|
Message #221580
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Neat tool
How did Ruby become so popular in last couple of years, when Python/TCL/ML/Haskell/(even)Lisp/Scheme have been around for similar or much longer timeframes and have had much wider developer base (of course Perl continues to have the widest developer base as far as these 'other' languages are concerned)? How did Ruby get this momentu despite its pathetic run-time performance (compared to others in the list)? I know its an off-topic question - but I am interested to learn ths bit of history.
It's the "killer app" phenomenon: Ruby on Rails made it vastly easier to set up basic database-driven web sites. Ruby was pretty obscure until Rails hit the scene.
|
|
|
Message #221581
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Well, even if a dsl (or ruby, python, whatever) makes some specific task easier, there is a definite advantage to have *everything* done in the same language.
Java for programming, and XML for configuration, build files, etc, covers basically everything needed for building enterprise apps. Even if some areas can be simplified by introducing "something else", the advantage would have to be monumental for me to introduce another "knowledge dependency".
My 2 cents.
|
|
|
Message #221587
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Benefits
I have to admit that I find it hard to get attracted by Ruby's syntax. But I have to say that I like the idea to use script language to do a simple thing that doesn't quite fit (as mentioned) in the build process. That's why we've created plugins, to extend a common behaviour.
I'll be checking Raven out.
|
|
|
Message #221589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Even if some areas can be simplified by introducing "something else", the advantage would have to be monumental for me to introduce another "knowledge dependency".
My 2 cents.
It is not just knowledge dependency, it is dependency on software outside of the typical Java + IDE installs, so more to set up and maintain especially if you are working on multiple platforms (as I do).
If a scripting system is preferred (and there can certainly be advantages over the XML approach in this situation) it would seem to me to make more sense to use an approach that runs on the JVM and can currently be integrated with Java IDEs, like http://groovy.codehaus.org/Gant
Even given that it may well be possible to run Raven on JRuby, it seems more appropriate to use a scripting language designed from the start to run on the JVM, and with a close-to-Java syntax.
|
|
|
Message #221600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice to use scripting but ...
OK, i would pick a "normal" scripting language over anything written in XML, but i think this is the wrong direction.
Why we are remaking the same old mistake again, simply changing the implementation language ?
Wouldn't be nice to have an higher level way to describe an application build, instead of just working at the assembler level ?
Something like being able to describe what a module is (for my application), what a deliverable is, what a release is, etc etc ?
No, no product to sell, no even the time to start my own open source project on it :-< ..
Maurizio De Cecco
http://jroller.com/page/dececco.
|
|
|
Message #221611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pant? Pake? Paven?
Does anyone know of similar tools that use Python instead?
I'm tired of Ant 'scripting' and I already kind of know Python. Ruby has failed to excite me, though conceptually it seems very similar to Python. I'd like to keep the number of languages in our environment down to a minimum, though.
|
|
|
Message #221622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
|
|
|
Message #221630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
It's not really that easy. You say, "Say it takes you a day..." Who is "you"? If that's the singular "you", then fine. But it rarely is the singular "you". Most of us work in a team. Introducing a new language (full blown or smaller DSL) has a learning curve. And introducing it to the build cycle is smack dab in the middle of the critical path of development.
I am not saying that this makes Raven a good or bad fit. In my team, we use Maven 2. And I admit, it has it's share of pain points. We recently created some Ruby scripts for SQL script generation and we call these scripts from Ant. It was too hard to find a way to shoehorn this functionality into our build using Maven. While it was probably possible to do within Maven's structure, the ad hoc Ant+Ruby approach was just easier.
That said, we have very little Ruby experience on the team, so there was some time spent getting everybody up to speed on how to execute/update the scripts. So it was not without cost.
One thing developing in Java (or Ruby or other OSS-friendly languages) gives us is tool choice. But you can only go so far with the best-of-breed approach in tool selection. Eventually you can end up with too many tools that "fit just right" for their respective job where the sum of the parts is less than the whole. Sometimes we need to sacrifice selecting the ideal solution for each job for a little homogeneity.
|
|
|
Message #221631
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
You didn't reply to my post but I think you are responding to it.
I don't work in a vacuum. Bring in a new tool affects many other people on my team. It's irresponsible and selfish to not consider the impact of having to support two tools that solve the same problems.
I have not yet actually introduced Python into our tools set formally and if there is no corresponding tool to Rake in Python, then I may reconsider using Python and persue Ruby.
So, will anyone with a *helpful* answer to my question please respond?
|
|
|
Message #221635
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
The python equivalent of Rake appears to be Scons.
The other thing that made me rethink Python lately was that the Jython project seems to be fairly stalled. I know there was a new grant to get it moving again but the Jython page has no news since 2005. Now Sun is paying people to work on JRuby. That makes me think that Ruby may be the more promising way to go but JRuby is still not finished (by it's version number.) The perlisms in Ruby bother me but I read somewhere that it's being moved away from that kind of sloppiness now.
|
|
|
Message #221647
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Actually I was replying to John Brand (the thread interface doesn't help much). I had no helpful answer to your original question and that's why I didn't reply to it :)
As for the "working in a vacuum" part, my short (probably too short) answer was with a "you" meaning every single person on your team.
Another point is that knowing Java doesn't bring you much in learning how to use Maven. So if you start a new project I think that learning Raven is much easier than learning Maven (but obviously I'm biased). You don't need much knowledge of Ruby for it.
|
|
|
Message #221663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Say it takes you a day to learn how to use a new tool which can save you many days of work later on because it's a better fit for what you're trying to do. You'd still ignore it just because it's not in the "right" language?
I guess others have already said this, but for me the big deal isnt me, today. During a 10-20 year product cycle, 30-50 developers might be involved in a particular software product. If I picked Java, I did so because I believed that the language has a chance to "last that long". Thats a risk, and I am unlikely to increase it by betting on one more language.
It has nothing to do with "right" or "wrong" language.
|
|
|
Message #221676
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Actually I was replying to John Brand (the thread interface doesn't help much).
I apologize, the answer was adjacent and made sense in the context of my post. I should just assume that you replied to the post you meant to reply to (although, a quote in your reply would help.)
I had no helpful answer to your original question and that's why I didn't reply to it :)
As for the "working in a vacuum" part, my short (probably too short) answer was with a "you" meaning every single person on your team.
My team is filled with RPG and COBOL programmers. Java is crazy new technology to them. It makes me chuckle to think about trying to sell them Python or Ruby. Not that I won't. It'll just be later. Also, given that the primary platform at this time is the AS400, Java is very doable but Python and Ruby are not. JRuby and Jython could work, though.
Another point is that knowing Java doesn't bring you much in learning how to use Maven. So if you start a new project I think that learning Raven is much easier than learning Maven (but obviously I'm biased). You don't need much knowledge of Ruby for it.
I've never really been sold on Maven. I think I just don't have a need for what it does.
I kind of jumped in this discussion because using a scripting language instead of ant XML files is an attractibve option and a good way to introduce scripting languages.
|
|
|
Message #221683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
I kind of jumped in this discussion because using a scripting language instead of ant XML files is an attractibve option and a good way to introduce scripting languages.
I dont know, I have used MQSC and wasadmin tcl extensively, and I cant really see that there is much advantage in scripting for configuration compared to a xml config file with schema validation etc.
Maybe I am just so used to them that they dont bother mer anymore, but I am always surprised that people think of them as such a problem.
|
|
|
Message #221693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
I kind of jumped in this discussion because using a scripting language instead of ant XML files is an attractibve option and a good way to introduce scripting languages.
I dont know, I have used MQSC and wasadmin tcl extensively, and I cant really see that there is much advantage in scripting for configuration compared to a xml config file with schema validation etc.
Maybe I am just so used to them that they dont bother mer anymore, but I am always surprised that people think of them as such a problem.
I used to be quite fluent in the ant language. I've not had to do much with it for a few years and now when I look at it I just think that I don't want to eat that elephant again. As far as I am concerned the schema validation is pretty useless as I've never had a serious issue with the syntax. The point here is that XML in Ant is being used as a framework for creating a DSL and it's not really good at that. I read somewhere that the original author of Ant even made a mea culpa for using xml. If I can find the quote I'll post it.
|
|
|
Message #221703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
"...just ask James Duncan Davidson, the original creator of Ant, who later came to admit that
1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
2. He really regrets it and apologizes to the Java community at large for it."
http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+Again.aspx
OK, I guess JDD should know, so if he says that xml was wrong for ant, then I guess hes right.
I would have believed that xml was one of the principal reasons for why ant was as quickly and as widelly adopted as *the* java build system once upon a time, but I guess not.
Anyhow, he doesnt have to apologize to me, because I sure havent suffered, even though I have used ant quite a lot in the past.
|
|
|
Message #221704
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
"...just ask James Duncan Davidson, the original creator of Ant, who later came to admit that
1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
2. He really regrets it and apologizes to the Java community at large for it."
http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+Again.aspx
I am afraid I still don't get the considerable and, it seems, increasing hostility towards XML.
Better XML than an increasing range of potentially incomprehensible DSLs. Sure, you can write meaningless stuff in XML, but at least you can validate, parse and transform it, and pretty much guarantee that it will be readable in future.
Those who complain too vigorously about XML should be forced to deal with the results of those who have actually gone ahead and written their own data parsers; only perhaps with somewhat out-of-date documentation, and with the parser written in a language or dialect that is no longer used. I have had too much experience of that to support the DIY approach.
|
|
|
Message #221709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
< guess JDD should know, so if he says that xml was wrong for ant, then I guess hes right.
I would have believed that xml was one of the principal reasons for why ant was as quickly and as widelly adopted as *the* java build system once upon a time, but I guess not.
Technologies become de facto standard for a variety of reasons, the principal one usually being that there is a big void that needs to be filled.
The sad thing about this is that whenever a product takes the world by storm because it's filling a unique need, there is a high likeliness that this tool will not be of very high quality (JUnit comes to mind as another example of this phenomenon :-)).
Personally, I don't feel that the XML persona of ant gets in my way that much, but its lack of dynamicity certainly does (I want if/then/else, while and inheritance!).
--
Cedric
|
|
|
Message #221713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
JUnit comes to mind as another example of this phenomenon :-)
--
Cedric
Nice unbiased comment. LOL.
|
|
|
Message #221714
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Personally, I don't feel that the XML persona of ant gets in my way that much, but its lack of dynamicity certainly does (I want if/then/else, while and inheritance!).
Use XSLT to transform the build.xml. Extra points for initiating the transformation from ant.
=)
|
|
|
Message #221724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
I am afraid I still don't get the considerable and, it seems, increasing hostility towards XML.
I'm not hostile towards it. I actually have used XML quite extensively and along the way, I figured out that there are things it is good for and things it is not so good for.
It's a good way to specify data.
It's a bad platform for writing code.
Better XML than an increasing range of potentially incomprehensible DSLs.
I don't want a DSL either. I want a tool that makes use of a well-worn scripting language like Python or Ruby. Happily such tools already exist.
Sure, you can write meaningless stuff in XML, but at least you can validate, parse and transform it, and pretty much guarantee that it will be readable in future.
If it's not readable now, how will it be readable in the future? ;)
Those who complain too vigorously about XML should be forced to deal with the results of those who have actually gone ahead and written their own data parsers; only perhaps with somewhat out-of-date documentation, and with the parser written in a language or dialect that is no longer used. I have had too much experience of that to support the DIY approach.
I agree with you but where I stand, the XML approach is hardly better than the DIY approach. Yeah, you don't have to write your own parser but that only gets you so far.
One thing I've thought about is a simplified syntax that's structurally equivalent to the way that most people use XML that can easily be transformed into XML and therefore making use of all the tools that exist for it. Perhaps more than one such syntax could be defined. Then we might have our cake and eat it too.
|
|
|
Message #221725
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
JUnit comes to mind as another example of this phenomenon :-)
--
Cedric
Nice unbiased comment. LOL.
Biased or not, it's undoubtedly true.
|
|
|
Message #221727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
One thing I've thought about is a simplified syntax that's structurally equivalent to the way that most people use XML that can easily be transformed into XML and therefore making use of all the tools that exist for it. Perhaps more than one such syntax could be defined. Then we might have our cake and eat it too.
Check out YAML:
http://www.yaml.org
|
|
|
Message #221728
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
One thing I've thought about is a simplified syntax that's structurally equivalent to the way that most people use XML that can easily be transformed into XML and therefore making use of all the tools that exist for it. Perhaps more than one such syntax could be defined. Then we might have our cake and eat it too.
Check out YAML:
http://www.yaml.org
Damn, that's pretty much exactly what I was thinking. Too slow I guess (with some filled in blanks of course).
|
|
|
Message #221729
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
Damn, that's pretty much exactly what I was thinking. Too slow I guess (with some filled in blanks of course).
Actually, it's not exactly. It's a separate spec. I was more thinking of a pseudo XML. According to the spec:
"Newcomers to YAML often search for its correlation to the eXtensible Markup Language (XML). While the two languages may actually compete in several application domains, there is no direct correlation between them."
Not that YAML isn't great. I just have a ton of tools at hand that work with XML. Anyway, what I was thinking would look similar to YAML, i.e. with indention that is syntactically significant ala Python.
|
|
|
Message #221731
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
I am afraid I still don't get the considerable and, it seems, increasing hostility towards XML.
I'm not hostile towards it.
Sorry, didn't mean to indicate you were. I was responding to the link, and vaguely commenting in general, and somewhat off-topic.
I actually have used XML quite extensively and along the way, I figured out that there are things it is good for and things it is not so good for.
It's a good way to specify data.
It's a bad platform for writing code.
Absolutely. But I find things like build 'scripts' ambiguous, as they combine features of configuration data and code.
Sure, you can write meaningless stuff in XML, but at least you can validate, parse and transform it, and pretty much guarantee that it will be readable in future.
If it's not readable now, how will it be readable in the future? ;)
Ah - by 'readable' I mean easily parsable and transformable: machine-readable.
|
|
|
Message #221771
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Raven 1.1: Build Java with Ruby
But I find things like build 'scripts' ambiguous, as they combine features of configuration data and code.
I can see your point. And ant does a good job at what it was designed to do. I just want something a little more powerful and easier to customize. I also find maintaining ant files to be a pain, although a good editor would help.
Ah - by 'readable' I mean easily parsable and transformable: machine-readable.
It was a poor attempt at a joke. It didn't really merit a response. I pretty much knew what you meant. I can't pass up an oppurtunity to get a cheap shot in. This is the year 2006.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
