harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][jmx] Options for going forward w/ MX4J
Date Tue, 26 Sep 2006 16:41:34 GMT
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.



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message