http://chaupal.github.io/
————————————————————————————————————————————————————————————————————
至少两个月没更新了，不会又是雷声大雨点小吧！！！###################################
捡到宝了， 偶然浏览邮件列表，发现老外改过的一版:
https://java.net/nonav/projects/jxta/lists/announce/archive/2013-10/message/0
https://java.net/nonav/projects/jxta/lists/announce/archive/2013-10/thread/1#00009
https://java.net/nonav/projects/jxta/lists
见Bruno Grieder的回复。还好链接没有失效，赶紧留一个备份。
Amalto modified JXTA version available for checkout
Kees,
This went faster than anticipated.
I have uploaded the Amalto modified version on Assembla.
The "project" is at https://www.assembla.com/spaces/jxta-amalto/wiki ;
The code can be checked out using subversion (1.6) at
https://subversion.assembla.com/svn/jxta-amalto/trunk/jxta-amalto-contributed/
This project was 'mavenized': to build it, install Maven, cd to the project
directory and simply run 'mvn clean install'. This should compile the code,
run the tests, build a jar and install it in your local m2 repository.
Any issue, let me know.
Bruno
On 10 oct. 2013, at 09:53, Bruno Grieder <bruno.grieder@...> wrote:
> Jérôme, Kees,
>
> I recall the hard time Oracle gave us on modifying the licensing terms but
> I just re-read the JXTA license and my take is that we can do whatever we
> want with the code as long as we keep a copy of the JXTA license somewhere
> in the source tree and in the binary (jar) along with the new license. The
> new license should just clearly state that some original parts of the code
> have been contributed under the provided JXTA license.
> Regarding the 'JXTA' acronym, Oracle made it unfortunately very clear that
> they wanted to keep the property and refused to contribute the name to the
> community.
>
> Should this become a blocker issue, we can check what the guys developing
> Jenkins did vis à vis the Hudson code and name, since they met the exact
> same issue. LibreOffice vs OpenOffice is another likely good example.
>
> On that matter, I believe that one of the first thing to do is to engage in
> some large refactoring and remove the JXTA acronym from all possible places
> (licenses excluded) and replace all the copyright notices at the top of
> every class and every interface with the new licensing terms. This should
> already clear the air quite a bit on the use of 'JXTA' itself.
>
> As soon as I have a little time, I will upload the Amalto modified code to
> some public repository. Since it would be too hard to clearly distinguish
> what contributions Amalto made, I will simply add a small text note saying
> that our contributions are made under the Public Domain (it can also be
> under the Apache 2.0 or BSD if you have already elected one of those - let
> me know).
>
> Bruno
>
> On 10 oct. 2013, at 09:17, JVerstry <jverstry@...> wrote:
>
>> On 9/10/2013 23:13, Bruno Grieder wrote:
>>> I would be happy to contribute that code if you are interested.
>>
>> Hi Bruno,
>>
>> I remember we had discussion about licensing in the past. I have been
>> discussing this with Kees too.
>>
>> The bottom line is the following:
>>
>> - When we considered moving to the Apache Foundation, they confirmed:
>> a) That we had to change the license to version 2.0
>> b) That we could not modify the license if we were not the owner of the
>> code
>>
>> - I never got approval from Oracle to do this (they never gave a final
>> answer)
>>
>> The only option we have is:
>> - Keep existing code under the current license
>> - Write new code/contribution under Apache License 2.0 (or whatever other
>> open license we like)
>> - Refactor out existing code under old license progressively
>>
>> If licensing is the only issue, then we don't need to fork the repository
>> right now, if we stick to the above.
>>
>> I totally agree with your analysis of the technical debt and there are
>> good arguments to rewrite a lot (all?)
>> of the code from scratch. However, Kees seems to have a good command of
>> OSGi and it could help us get
>> rid of the classloader API/Impl issues into a cleaner code. It is another
>> option to get out of the mess.
>>
>> Of course, we would still have to find out how and when to integrate your
>> contributions, if possible.
>>
>> Cheers,
>>
>> Jérôme
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
######################This went faster than anticipated.
I have uploaded the Amalto modified version on Assembla.
The "project" is at https://www.assembla.com/spaces/jxta-amalto/wiki ;
The code can be checked out using subversion (1.6) at
https://subversion.assembla.com/svn/jxta-amalto/trunk/jxta-amalto-contributed/
This project was 'mavenized': to build it, install Maven, cd to the project
directory and simply run 'mvn clean install'. This should compile the code,
run the tests, build a jar and install it in your local m2 repository.
Any issue, let me know.
Bruno
On 10 oct. 2013, at 09:53, Bruno Grieder <bruno.grieder@...> wrote:
> Jérôme, Kees,
>
> I recall the hard time Oracle gave us on modifying the licensing terms but
> I just re-read the JXTA license and my take is that we can do whatever we
> want with the code as long as we keep a copy of the JXTA license somewhere
> in the source tree and in the binary (jar) along with the new license. The
> new license should just clearly state that some original parts of the code
> have been contributed under the provided JXTA license.
> Regarding the 'JXTA' acronym, Oracle made it unfortunately very clear that
> they wanted to keep the property and refused to contribute the name to the
> community.
>
> Should this become a blocker issue, we can check what the guys developing
> Jenkins did vis à vis the Hudson code and name, since they met the exact
> same issue. LibreOffice vs OpenOffice is another likely good example.
>
> On that matter, I believe that one of the first thing to do is to engage in
> some large refactoring and remove the JXTA acronym from all possible places
> (licenses excluded) and replace all the copyright notices at the top of
> every class and every interface with the new licensing terms. This should
> already clear the air quite a bit on the use of 'JXTA' itself.
>
> As soon as I have a little time, I will upload the Amalto modified code to
> some public repository. Since it would be too hard to clearly distinguish
> what contributions Amalto made, I will simply add a small text note saying
> that our contributions are made under the Public Domain (it can also be
> under the Apache 2.0 or BSD if you have already elected one of those - let
> me know).
>
> Bruno
>
> On 10 oct. 2013, at 09:17, JVerstry <jverstry@...> wrote:
>
>> On 9/10/2013 23:13, Bruno Grieder wrote:
>>> I would be happy to contribute that code if you are interested.
>>
>> Hi Bruno,
>>
>> I remember we had discussion about licensing in the past. I have been
>> discussing this with Kees too.
>>
>> The bottom line is the following:
>>
>> - When we considered moving to the Apache Foundation, they confirmed:
>> a) That we had to change the license to version 2.0
>> b) That we could not modify the license if we were not the owner of the
>> code
>>
>> - I never got approval from Oracle to do this (they never gave a final
>> answer)
>>
>> The only option we have is:
>> - Keep existing code under the current license
>> - Write new code/contribution under Apache License 2.0 (or whatever other
>> open license we like)
>> - Refactor out existing code under old license progressively
>>
>> If licensing is the only issue, then we don't need to fork the repository
>> right now, if we stick to the above.
>>
>> I totally agree with your analysis of the technical debt and there are
>> good arguments to rewrite a lot (all?)
>> of the code from scratch. However, Kees seems to have a good command of
>> OSGi and it could help us get
>> rid of the classloader API/Impl issues into a cleaner code. It is another
>> option to get out of the mess.
>>
>> Of course, we would still have to find out how and when to integrate your
>> contributions, if possible.
>>
>> Cheers,
>>
>> Jérôme
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Hi,
Resurrecting the "sleeping beauty" sounds interesting, however I share Adrian
concerns and I believe JXTA needs at minimum a serious cleanup before
increasing functionalities.
JXTA scope was too grandiose. A new effort should concentrate on connectivity
first and make it right. The code is cluttered with deprecated features and
features that were never used. It also plays too hard the API vs
Implementation game, leading to complex factories and injection where it does
not need to be. All this makes the code very hard to read.
At Amalto we use a modified 2.6 which incorporates most of the enhancements
of 2.7 plus a few tweaks of our own. Running FindBugs on the bare code
revealed about 450 "issues" from trivial fixes to horrors. We fixed slightly
over 200 of these that look like the most important to us but there is still
a lot of ground to cover.
This code is used in production inside an application run by a few hundred
customers in various network conditions. It is quite stable but from time to
time, the SRDI index seems to get corrupted and the only way to clear the
issue at this stage is a restart (which is not a major issue in our
particular case).
I would be happy to contribute that code if you are interested.
On my own, I tried to perform some redesign and simplification. Quickly this
unfolded into a major rewrite. I have unfortunately no time to work on it and
nothing to show at this stage.
In any case, good luck. I share your view that the JVM needs a good P2P
framework.
Bruno Grieder
Amalto Technologies | CTO
On 9 oct. 2013, at 19:33, Adrian Ivan <adrian@...> wrote:
> Hi,
>
> Sounds interesting ad challenging.
>
> I had a quick read of the document you sent.
>
> I like the ideas, but I have some comments:
> - jxta was a night mare in production
> we tried to make it work until the last moment, but we were forced to dump
> it
> - seems like OSGI is an important topic
> This was not the fundamental issue, I think it was already possible to have
> a wrapper bundle in eclipse around jxta.
>
> The main issues were around connectivity and reliability.
> Our main issue was that that after a while the connection between peers was
> broken and everything was blocking, and did not recover anymore. Even
> worse, it was very hard to debug.
>
> I think Jxta needs Fresh start:
> - Jxta needs to be a framework that allows p2p communication and can be
> integrated software developers
> - clean API without needing to know all internals to write something on top
> of jxta
> - reuse the good ideas around the p2p
> - healthy grand architecture allowing modularity, extensibility
> simple: must solve the communication problem, do not bother about other
> functionality. It must allow fast and reliable communication using the RDV
> and implementing STUN/TURN etc protocols for nat/firewall traversal
> - modern technologies: what about using WebSockets or other current trend?
> the idea would be to take alook at what is happening to the web world
> since jxta went to hibernation. It seems to me that Jxta verlaps the atest
> developments in the web/html5 community
>
> I would recommend to rethink the technology from scratch because just using
> what is in the current code base will be a waste of time. This is coming
> form somebody that had nightmare in production with Jxta.
>
> Looking forward for more news.
>
> Adrian
>
>
> On Wed, Oct 9, 2013 at 1:05 AM, cees_pieters@... <cees_pieters@...> wrote:
> Dear All,
>
> My two posts on JXTA and OSGI that were posted on D-Zone recently
> (http://java.dzone.com/articles/jxse-and-equinox-tutorial-part and ;
> http://java.dzone.com/articles/jxse-and-equinox-tutorial-part-0 , more to ;
> follow) has had the intended effect of reviving some enthusiasm in the
> community on our beloved sleeping beauty called JXTA. The past weeks Matt
> Gumbley and mysellf have worked on the first draft of a roadmap for a 2.8x
> release, under the expert guidance of Jérôme Verstrynge.
> In short, we aim for a two-stage development where the 2.8X release will
> serve a larger effort hosted under Chaupal, which aims to implement an OSGI
> implementation of the JXTA specification. This approach will allow us to
> circumvent the many licensing issues that are currently paralising JXTA
> development, and provide openings for new services and tooling.
>
> We would love to hear the views of the community about ous plans, and we
> welcome ideas and comments.
>
> Kind regards,
>
> Kees Pieters
> Condast
>
>
>
Resurrecting the "sleeping beauty" sounds interesting, however I share Adrian
concerns and I believe JXTA needs at minimum a serious cleanup before
increasing functionalities.
JXTA scope was too grandiose. A new effort should concentrate on connectivity
first and make it right. The code is cluttered with deprecated features and
features that were never used. It also plays too hard the API vs
Implementation game, leading to complex factories and injection where it does
not need to be. All this makes the code very hard to read.
At Amalto we use a modified 2.6 which incorporates most of the enhancements
of 2.7 plus a few tweaks of our own. Running FindBugs on the bare code
revealed about 450 "issues" from trivial fixes to horrors. We fixed slightly
over 200 of these that look like the most important to us but there is still
a lot of ground to cover.
This code is used in production inside an application run by a few hundred
customers in various network conditions. It is quite stable but from time to
time, the SRDI index seems to get corrupted and the only way to clear the
issue at this stage is a restart (which is not a major issue in our
particular case).
I would be happy to contribute that code if you are interested.
On my own, I tried to perform some redesign and simplification. Quickly this
unfolded into a major rewrite. I have unfortunately no time to work on it and
nothing to show at this stage.
In any case, good luck. I share your view that the JVM needs a good P2P
framework.
Bruno Grieder
Amalto Technologies | CTO
On 9 oct. 2013, at 19:33, Adrian Ivan <adrian@...> wrote:
> Hi,
>
> Sounds interesting ad challenging.
>
> I had a quick read of the document you sent.
>
> I like the ideas, but I have some comments:
> - jxta was a night mare in production
> we tried to make it work until the last moment, but we were forced to dump
> it
> - seems like OSGI is an important topic
> This was not the fundamental issue, I think it was already possible to have
> a wrapper bundle in eclipse around jxta.
>
> The main issues were around connectivity and reliability.
> Our main issue was that that after a while the connection between peers was
> broken and everything was blocking, and did not recover anymore. Even
> worse, it was very hard to debug.
>
> I think Jxta needs Fresh start:
> - Jxta needs to be a framework that allows p2p communication and can be
> integrated software developers
> - clean API without needing to know all internals to write something on top
> of jxta
> - reuse the good ideas around the p2p
> - healthy grand architecture allowing modularity, extensibility
> simple: must solve the communication problem, do not bother about other
> functionality. It must allow fast and reliable communication using the RDV
> and implementing STUN/TURN etc protocols for nat/firewall traversal
> - modern technologies: what about using WebSockets or other current trend?
> the idea would be to take alook at what is happening to the web world
> since jxta went to hibernation. It seems to me that Jxta verlaps the atest
> developments in the web/html5 community
>
> I would recommend to rethink the technology from scratch because just using
> what is in the current code base will be a waste of time. This is coming
> form somebody that had nightmare in production with Jxta.
>
> Looking forward for more news.
>
> Adrian
>
>
> On Wed, Oct 9, 2013 at 1:05 AM, cees_pieters@... <cees_pieters@...> wrote:
> Dear All,
>
> My two posts on JXTA and OSGI that were posted on D-Zone recently
> (http://java.dzone.com/articles/jxse-and-equinox-tutorial-part and ;
> http://java.dzone.com/articles/jxse-and-equinox-tutorial-part-0 , more to ;
> follow) has had the intended effect of reviving some enthusiasm in the
> community on our beloved sleeping beauty called JXTA. The past weeks Matt
> Gumbley and mysellf have worked on the first draft of a roadmap for a 2.8x
> release, under the expert guidance of Jérôme Verstrynge.
> In short, we aim for a two-stage development where the 2.8X release will
> serve a larger effort hosted under Chaupal, which aims to implement an OSGI
> implementation of the JXTA specification. This approach will allow us to
> circumvent the many licensing issues that are currently paralising JXTA
> development, and provide openings for new services and tooling.
>
> We would love to hear the views of the community about ous plans, and we
> welcome ideas and comments.
>
> Kind regards,
>
> Kees Pieters
> Condast
>
>
>