You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/09/26 16:17:11 UTC
[classlib][jmx] Options for going forward w/ MX4J
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".
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. 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...)
comments?
geir
---------------------------------------------------------------------
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
Re: [classlib][jmx] Options for going forward w/ MX4J
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 26, 2006, at 12:41 PM, Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> 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?
None - there'd be no point.
> Likewise we have no interest in distributing
> a 1.4 version.
Well, I have no burning interest, but if it meant that we could move
the MX4J community here, I'd have no problem making the "legacy"
builds available for those still using pre Java 5.
>
>> 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.
Yes, on the last bit, and I think so on everything else - this is a
first for us, so I expect we make a few laps around this particular
rabbit hole in how to work with this. I think that we'll have to
make changes in the "standard" codebase - this would be ours, hence
the honesty in labeling it a fork.
geir
>
> Regards,
> Tim
>
> --
>
> 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
>
---------------------------------------------------------------------
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
Re: [classlib][jmx] Options for going forward w/ MX4J
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Thanks for the comments, Simone. I'm hoping that at some point in the
near future, we can think about doing other things that bring the
communities closer together, but this is a great first step.
geir
Simone Bordet wrote:
> Hi,
>
> On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
>> 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.
>
> Thanks for the kind words.
>
>> > 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.
>
> Correct. My take on the issue is that there is no point for MX4J to
> implement JMX 1.3 (shipped in JDK 5), since it will be very rare that
> people will put such an alternative implementation in the boot
> classpath before the JDK classes.
> I think implementing JMX 1.3 belongs more to an effort such as
> Harmony, or such as Application Servers heavily based on JMX that
> support J2EE 5.
>
>> 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.
>
> This is also my thinking. We can agree on a best effort communication
> where mx4j notifies harmony-dev of bugs discovered in mx4j, or of new
> releases, and harmony can communicate bugs to mx4j, with the goal of
> saving time and energy, but not with the goal of keeping the codebases
> in sync.
>
> Regards,
>
> Simon
---------------------------------------------------------------------
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
Re: [classlib][jmx] Options for going forward w/ MX4J
Posted by Simone Bordet <si...@gmail.com>.
Hi,
On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> 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.
Thanks for the kind words.
> > 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.
Correct. My take on the issue is that there is no point for MX4J to
implement JMX 1.3 (shipped in JDK 5), since it will be very rare that
people will put such an alternative implementation in the boot
classpath before the JDK classes.
I think implementing JMX 1.3 belongs more to an effort such as
Harmony, or such as Application Servers heavily based on JMX that
support J2EE 5.
> 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.
This is also my thinking. We can agree on a best effort communication
where mx4j notifies harmony-dev of bugs discovered in mx4j, or of new
releases, and harmony can communicate bugs to mx4j, with the goal of
saving time and energy, but not with the goal of keeping the codebases
in sync.
Regards,
Simon
--
http://bordet.blogspot.com
---------------------------------------------------------------------
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
Re: [classlib][jmx] Options for going forward w/ MX4J
Posted by Tim Ellison <t....@gmail.com>.
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 (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