Rob Stryker
added a comment - 02/Apr/09 11:38 PM Better yet, what exactly is preventing you from making a runtime for the latest 5.1? What's it say?
In my workspace it says " This server type expects a version of 5.0 but the server directory is of version 5.1.0.CR1." as a warning but completing the wizard still works.
Any more details?

I checked out the source, built the AS, and it seems to work with the 5.0 server type. Wizard can finish, server can start. If there are no severe structural changes, then for now I'll say a new servertype is not necessary.

Rob Stryker
added a comment - 03/Apr/09 2:32 AM I checked out the source, built the AS, and it seems to work with the 5.0 server type. Wizard can finish, server can start. If there are no severe structural changes, then for now I'll say a new servertype is not necessary.

Galder Zamarreño
added a comment - 03/Apr/09 3:59 AM Hmmm, I still can't. I keep getting this message when trying to create the runtime:
"The home directory does not exist, is missing key files, or is of the incorrect version."
I'm running Tools 3.0.GA. Rob, did you verify this with GA or some other branch?

Sorry Galder. I didn't read the issue thoroughly. It should be committed to both 3.0.1 and 3.1.0 streams already. And the messages have already been clarified.

@Max: While you're right that new API's are a difference, the problem is that they've backported the fixes to 5.0.x stream, which means that if they do come out with a 5.0.2 or 5.0.3 stream, the new API's will still be there.

In all honesty, If I were ever to rewrite this stuff entirely, I could probably have only 1 server type and make everything absolutely dynamic, reading the server's version from the installation folder and then calculate everything from classpath container information to startup information to deployment stuff. The need for a new "Server Type" really is not great at all. The only primary difference here is whether the server starts with "deploy to the server area" or "deploy to metadata". That's basically all that changes. And the user can adjust that at his will in the server editor.

Rob Stryker
added a comment - 03/Apr/09 4:40 AM Sorry Galder. I didn't read the issue thoroughly. It should be committed to both 3.0.1 and 3.1.0 streams already. And the messages have already been clarified.
@Max: While you're right that new API's are a difference, the problem is that they've backported the fixes to 5.0.x stream, which means that if they do come out with a 5.0.2 or 5.0.3 stream, the new API's will still be there.
In all honesty, If I were ever to rewrite this stuff entirely, I could probably have only 1 server type and make everything absolutely dynamic, reading the server's version from the installation folder and then calculate everything from classpath container information to startup information to deployment stuff. The need for a new "Server Type" really is not great at all. The only primary difference here is whether the server starts with "deploy to the server area" or "deploy to metadata". That's basically all that changes. And the user can adjust that at his will in the server editor.

Rob Stryker
added a comment - 07/Apr/09 4:17 AM Galder:
This was verified in 3.0.GA and was fixed in both 3.0.1 maintenance and 3.1 trunk a while ago. No commits were made on this JIRA as they were made in a previous commit. (commits 14204 and 14251)

Rob, as a comment to "make everything absolutely dynamic, reading the servers version from the installation folder" would not be the solution - having a static version is relevant in context of runtime components i believe.

Removing some of the static types does make sense though since they should just be a configuration option IMO (i.e. "deploy only server")

Max Rydahl Andersen
added a comment - 07/Apr/09 8:17 AM Rob, as a comment to "make everything absolutely dynamic, reading the servers version from the installation folder" would not be the solution - having a static version is relevant in context of runtime components i believe.
Removing some of the static types does make sense though since they should just be a configuration option IMO (i.e. "deploy only server")