harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][jmx] Options for going forward w/ MX4J
Date Tue, 26 Sep 2006 19:07:48 GMT

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


Mime
View raw message