|
Andreas, could you also test the JRockit 5/Linux combination (or was it on linux initially in your case?
Also, check my code review questions in the dev list, please. Yes, this was tested on Fedora 7 using JRockit.. I'll take a look at the dev comments.
module-boot should not depend on core and currently does not - classpath implications.
Holger,
Can you please be more specific on why module-boot shouldn't depend on core? I don't understand the classpath implications you are referring to. Besides, module-boot currently does depend on core. Just take a look at ModuleBootstrap.java and ReflectionHelper.java. Unless you don't count core imports as dependencies -Andreas I only looked at the immediate dependencies and core wasn't in there (which just proves that implicit dependencies via the parent pom are evil..Dirk is removing them as we speak). As for the dependency itself, all I know is that when the boot module was created, we tried to avoid the dependency on core for some important reasons. Might have been classpath trouble, might have been cyclic build problem - I don't know since I didn't write any of that.
On the other hand as a general rule core should not become a dumping ground for code that is only used once. Over the last year we have tried very hard to reduce unnecessary coupling across all modules. Changed summary and description to reflect reality on what's being worked on now.
Hi Andreas
I was seeing the changes you made to the LicenseHandler and there is a problem with its usage with the GUI Installer. The problem is that due to a limitation in the installer we are currently using, we can't execute a class that uses other jar files.... meaning that the usage of the commons logging will blow everything up in the GUI Installer. Is there anything you can do about this? Marie,
Yes, I am aware of this and took this into account. I even have a patch for the GUI installer to address that, which actually is a bug Thanks for pointing this out, though. -Andreas Committed changes in two parts to make upcoming 2.x port a bit easier:
r8501
r8502
Ported first part r8501 to 2.x, committed as r8504.
Comitted 2nd part from r8502 to 2.x as r8505. Note that this was not an actual merge because of the difference on how this needed to be ported to 2.x.
Tested against Sun's VM and BEA's JRockit.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Mule bootstrap code refactoring (was license refactoring)
>>>
License code refactoring, mainly moving code out into separate util classes. These util classes should eventually go into the core. I tested these changes with JRockit 5.0 and SunJDK1.4.2.