The gitweb is available here: http://stackworks.net/cgi-bin/gitweb.cgi?p=girm.git;a=summary

and cloning is available at

git://stackworks.net/girm.git/

Firstly, while EJB 3.0 is miles better than EJB 2.1, it doesn’t match up to a proper IoC container. By IoC, I am talking both about the Tapestry 5 IoC container, and the Spring IoC container. I find that with writing service methods with EJB, I spend far too much time both massaging domain objects between the EJB layer and the Tapestry layer – the Hibernate/JPA session is no longer valid outside of the EJB layer, so forget about all the “cool” stuff it does, such as lazy fetching, and wallow in pain replicating that functionality.

Second, component based view models are powerful, but not quick to grasp. I grew up (shame shame) on PHP, doing in-line HTML output. I know, this is bad, and I know better. I’ve grown accustomed to other view technologies such as templates (Smarty, Cheetah-Template, Velocity, etc), but still find myself taking a long time developing a workable component based model. This may be a shortcoming in Tapestry, but its taken me far longer to develop views than I would like. I will say that the component model is stronger than JSPs, but sometimes quick & dirty JSP gets you there faster. Some of this may be my experiences with Tapestry 5 talking, which I will discuss further below.

Third, Hibernate is amongst the best ORM wrappers available and a major time saver. Compared to other ORM wrappers out there (like ActiveRecord), it has an unmatched feature set, often backed by very mature Java technologies and libraries.

Java is a good language, and a fantastic environment. Yes, the language isn’t that great – overly verbose, no closure, a little too static. But the Java libraries available, especially on the server-side are un-matched from other web-development languages, including my favorite language, Python.

Groovy is a very promising language. Closures, duck-typing, first class JVM language, and more. Libraries that should have existed ages ago (XmlSlurper comes to mind). If you’re going to do quick development in a Java environment, or looking at a scripting solution in Java, give Groovy a strong look.

Whatever you do, avoid the creation of your own GWF. Also known as the Ghetto Web Framework. We’ve all seem them – you started out with some servlets, and went from there, making half-baked utility functions, some copy and pasting, etc. You get a maintenance nightmare – changes which should simply be a two-liner end up being propagated in odd places in your GWF, requiring exponential time to change. Plus your GWF is so tightly coupled to your application,  you can’t use it for the next application. There are so many web frameworks out there – please use one

Groovy on Grails makes an incredible rapid development environment. Coupled with Groovy, and with idea taken from  Ruby on Rails amongst other systems, you get an incredible Java development environment which is more productive and quicker to develop in than EJB, Tapestry, and maybe even the venerable RoR. Plus, its pure Java nature coupled with libraries such as Hibernate and Spring, you gain all the advantages of scalability and support that you just don’t get in RoR.

Wicket and Tapestry are very well organized frameworks. While I talked somewhat negatively about component based frameworks above, I would like to mention that both of these frameworks are fantastic in their own right. Wicket seems to be gaining a lot of momentum as well. But, on a negative note, Tapestry 5 needs more documentation. You can buy 200 books on Struts (though why you’d want to use it is beyond me), 3 on Grails, 1 (and soon 2) on Wicket, and 0 on Tapestry 5. Tapestry 5 really needs more developer momentum and support to come to fruition. Howard Lewis Ship is doing a fantastic job on being very careful and deliberate in his design and crafting of Tapestry, but he is after all one person, and can not do it all.

So, you may ask,  what does this have to do with IRM 2?

Well, I’ve been once again at the crank. I’ve realized that the code I wanted to avoid writing (simple CRUD), I am writing again, primarily through my mis-choice of EJB3. Partly contributing to this is Tapestry -  I’m writing a fair number of CRUD views – none of which are in any way exciting.

I’ve been converting the existing code from Tapestry/EJB to the Groovy on Grails framework.  Its been amazing easy to accomplish, and the Grails scaffolding support has been an amazing productivity boost.

Look for a developer’s release by the end of the year .

Till then

-Yann

This quick little component can solve all those problems. I present you Render.java. This incredible class is appearing in IRM 2.

Update: You can also use the builtin Tapestry component named Delegate.

<t:delegate to="block:foo"/>

But if you still prefer, you can use this Component:

package net.stackworks.irm.web.components;
import org.apache.tapestry.annotations.Parameter;



/**
 * Simple component which will render a Block in a page.
 * To use: - Make sure your Block has a defined getter method (getSidebar()) which returns the Block
 *         - Do a <t:render value="sidebar"/> <!-- this calls getSidebar() -->
 *         - Enjoy your rendered Block
 * @author Yann Ramin
 *
 */
public class Render {
	@Parameter(required = true)
	private Object _value;

	/**
	 * Returns the Object, which allows another object (presumably, a block) to render
	 * first.
	 *
	 * @return Object to render
	 */
	Object beginRender() {
		return _value;
	}
}

I have a full Tapestry 5 based web framework, which currently supports abstract templating and other functionality with Tapestry components. I also have a full Tapestry->EJB3.0 call system developed (just need to actually go write the Beans now ), and have started mapping the data model for Users, CRI (Cross Reference Identifier, the new name of the IRM2Python GUID, more on this later), and Schemas.

One tricky part is developing the JAAS authentication scheme. I’m working through some substitutes, but also expect to support non-JAAS simple database authentication (at least for now).

I also had a chance to do a little work in Illustrator on the visual front, developing a new logo for IRM2. See below for an idea of what it looks like. Its designed to emphasize the connected nature of IRM, from the trouble tickets to the AssetMesh. Feel free to leave comments.

More later!

I’ll get into all the details of what IRM 2 is going to do for you, but I’d first like to share some history with you about where IRM has come from, the previous short attempts at IRM 2, and how its influenced my current direction.

In the beginning was the command line.

Then came IRM. It was quite literally the second piece of software I wrote as a web application. It used the trendy new (well at the time) PHP 3.0. MySQL 3.22 was the in thing. The whole LAMP architecture was just in its infancy.IRM was created way back when (1999 for those keeping score) for my high school. It allowed people to post problems (using the odd nomenclature “Tracking”) about computers that were in its database. The database seed script that comes with IRM reflects these early beginnings, including the computer named Ants and the Library Back Room.IRM went through several versions, 0.5, 0.9, 0.9b, 0.9c, etc. Around the 1.0 release, a really great guy from the University of Tulsa , Keith Schoenefeld started contributing to IRM. He cleaned up a ton of my early major misguided attempts at software development (turns out ENDIF; is kinda not cool), and over time provided new functionality such as the FAQ and Knowledgebase system.

IRM grew in leaps and bounds, adding the Software subsystem, the Reports subsystem, and then Networking. Patch submissions from Mica Curie also started, and some key features were added to the project.
In 2004-2005 another contributer joined the project, Matt Palmer. Not only did he make a nice Debian package for IRM (apt-get install irm is so much easier ), he allowed for the full translation of the IRM source. Version 1.4 and then 1.5 were released under his guidance. By that time I had started full time at UC Davis, so my time was becoming slim catching up with all those college things. Matt graciously took up the maintainer role for IRM 1.5 and released several versions, culminating in 1.5.8-dev, the current recommended version (or 1.5.7 for the squeemish).

During all of those time, I became increasingly dissatisfied with the PHP structure that IRM was running on. Its underpinnings were still dating back from 1999, PHP 3.0 code, strange code reuse, no abstract templating, and a fixed database structure. In 2002 I attempted a partial rewrite of IRM called IRT (Information Resource Tracker) in a custom mod_perl framework (the job I had at the time was developing a custom mod_perl application for footagesearch.com – still used to this day, though its had numerous updates). It failed miserably. I can’t even find the source code.

Next up was IRM 2.0 in Python. It included some new ideas for abstract schemas and relational linking. Its asset manager actually worked. It was developed in a custom Python application server Cymbeline, which was probably a bad move as I was spending more time developing Cymbeline than IRM 2. This also fell by the wayside during those college years. But it was a great learning exercise in what worked and what didn’t.

And thats the history in a summary. If you were a contributor (I know I left a bunch out, especially when I was not active maintainer ), let me know and I’ll add you to the history

Since working on IRM, my life has changed a lot. I graduated high school (yes, IRM is that old), graduated college, and got a good “real job.” More importantly, I’ve built lots of real software in between, for personal use, research work, as well as commercial contract work. I’ve been around the block a few times, and tried on a large number of hats, all of which will reflect themselves in the design and implementation of IRM 2.

So, that gives us IRM 2, Mk III. The third incarnation of IRM2. And better, more powerful, and very different from the rest. Read on.

To begin, its still a web application. IRM is never going to be solely a desktop application, though the line between web application and desktop application is really blurring these days.

It utilizes Java. I can already hear the complaints trickling in. I’ve grown quite fond of Java at my day job, and really recognized what strengths it brings to the enterprise web application front. The Sun Java VM is now also Open Source, with the rest of the classpath libraries becoming Open Source in the near future. There are multiple Java vendors, and Java does really run everywhere these days. Java is also very quick, and the framework provided with it are top-notch. A considerably worse choice would be to move to .NET and ASP.NET.

It utilizes Enterprise JavaBeans 3.0 . These are not the EJBs of 2.0 and 1.0 days, which were, to put it mildly, horrible. EJB3.0 is actually a joy to work with, and brings with it an amazing amount of functionality, such as transactional support, security, and scalability.

It utilizes the Java Persistence API 1.0, along with Hibernate when the JPA doesn’t go far enough. Both of these technologies are wonderful to use, and greatly speed development (and makes maintenance much easier).

For the presentation layer, Apache Tapestry won out over other packages such as Struts2, JSF, and Spring. While I prefer to use Java Community standards whenever possible, I compromised for Tapestry as it is a wonderful (though not well known) package.

All of this can successfully run in the JBoss Application Server, making deployment a snap on any platform. It can also be run in any mostly-EJB3.0 compliant container, though drop-in portability will not be a focus of the first releases. By utilizing Java Persistence, we will automatically support any JDBC compliant database server, from good old MySQL, Oracle, PostgreSQL, Microsoft SQL, DB2, to the built in HSQLDB.

I am working on a master roadmap which lays out our development cycles and sets goals. Look here in the next few days for updates on how its going to look.

In short, IRM 2 will feature:

• The asset manager interface from PythonIRM2. User definable schemas for any device, item, location, or thought you can think of. Fully linkable schemas let you associate users, software, locations, peripherals, and potted plants together into an AssetMesh^tm. Since everything is associated in real life, why not let your asset manager let you express that?
• Trouble ticket system to manage user problems, your own problems, and let you keep your head on straight. Includes both user ticketing, technician ticketing, and phone support ticketing.
• User self help system, bringing back the FAQ, user trouble reporting, and other features which made IRM into such a successful integrated application for the IT helpdesk.
• And more!

To bright futures ahead, but remembering the beginnings…