Wayne, Everything that you say about dependencies is true in general, and I do not wish to diminish your point, as it is an important one. On the other hand, there is a feature of Java, and J2EE in particular, which helps to solve this problem. The Java VM Classloader has the capability of running on multiple threads many different versions of the same modules. For example, if you have two applications in .war files, and they contain different versions of the same .jar file, both applications can run on the same server, in the same VM, peacefully, without hurting each other. This feature of Java greatly reduces the dependency problem. This is why the OpenHRE .war contains all the modules that you need to run, as long as they do not conflict with modules "hard-wired" into the J2EE server, which is where the problems often arise, because "hard-wired" modules can often not be overridden.
We can certainly supply you with whatever level of integration that you desire. We can send you a .zip or .tar that includes the J2EE server and application pre-integrated. We can even sell you a complete server, already loaded up, including LAMP and/or LAMJ or whatever else, and supported. - Don ----- Original Message ----- From: "Wayne Wilson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 10, 2004 7:47 AM Subject: Re: OpenHRE software available Let me try another stab at clarification: If you write just one application and run it on just one application server things are very peachy. As Dave say's an 'environment' builds up around your work as you use bits and pieces from other projects. This is sort of like a linux distribution. The external components were built with their authors 'environment' in mind. You end up having a chain of dependencies. Moving your 'project' to another J2EE environment easily depends upon you being self-contained within the J2EE specification and not having external dependencies. Anyone who has used linux for a few years must be familiar with this story about keeping all your dependencies in order. Most distributions have an elaborate mechanism for checking dependencies and automatically attempting to fix them. Here is an example: Recently, I decided to upgrade to Evolution 2. I started looking for the components for my relatively recent Fedora Core 2 distro. Well, in a very little time I discovered that Evolution 2 needed a more recent Gnome then I had. I looked into what that would take and the simplest path was to wait and upgrade to Fedora Core 3 which has all these parts integrated in. Such a massive upgrade of components within my working distribution as it was running was something I did not wish to undertake. So, what happens in a 'server farm' that services several developer groups and commercial applications? Well, each of them has made assumptions about the 'environment' that surrounds their execution environment. Some of these assumptions are incompatible with each other. Others are just different, i.e. they could be made compatible, but that requires some work on out part, which we find is not warranted for these applications. Why is that work not warranted? Because every time you go back to the vendor for support, you have to waste effort explaining and proving that your deviation from their 'environment' is not the cause of the problem! And so I come back to my initial assertion: It is the distribution of all components, integrated by a vendor, needed to support an application that someone has written, which is an essential part of paid for support. The concept of support for LAMP and LAMJ is based around this concept, I believe.
