Geir Magnusson Jr. wrote: > I've been talking with Simone Bordet about how we might bring MX4J into > Harmony. I think it's a good code base to build our JMX implementation > on, as it's well tested and has been used in implementations that have > been tested with the JMX TCK. (We can't say that MX4J passes, as I > don't believe the project has a TCK). MX4J has served many people over > many years, and it's a shame that the addition of JMX into the SE > platform has sent this project into it's "golden years".
I see it a bit differently -- it is a testament to the quality and broad use of MX4J that has helped make JMX a compelling addition to Java SE. I join you in commending Simone and the other contributors for their work. > There were a lot of issues discussed, mainly about user support, time > Simone could commit to help us, etc , and in summary, it boils down to > this : > > Simone has no problem with us doing a "gentle fork" (in his words) of > the code to build on. By this, we are simply taking a snapshot of the > project codebase, and building upon it. This is not a hostile, > anti-community act, but simply a recognition that it's useful code for > us, we want to keep building on the code base, but need to make > modifications for java SE 5 that are incompatible with the needs of the > pre-Java 5 users that the MX4J project support. I read this as an indication that MX4J has no interest in pursuing a 5.0 compatible implementation? Likewise we have no interest in distributing a 1.4 version. > We are not becoming "MX4J", although I'd like to do whatever we can > to leave that door open - how we can structure the code in SVN so > that in the future, if Simone has some time and wishes to move his > user base over here, we can easily welcome that community. > > Anyway, that's the long and the short of it. > > if people like this, I suggest that we put in "standard" SVN repository > in the same way we do java.util.concurrent. Given the history of the > code, I'm very doubtful we can find full paperwork to get into > "enhanced". The difference is that we'd be modifying it (although if > possible, it would be nice to have a clear boundary between the "old > mx4j code" and our new enhancements, in the event that the mx4j > community comes over...) Presumably all the enhancements that are made in the Harmony SVN tree are 'our new enhancements', so identifying them will not be a problem. Putting the code into standard sounds like the right answer. I assume that in this scenario, and unlike concurrent, we do not attempt to keep the two sites in sync. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
