Quantcast

Ad upcoming Java 9 ...

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ad upcoming Java 9 ...

Rony G. Flatscher (wu-wien)

Hi there, my original posting did not get through, possibly because I used a wrong e-mail address, therefore retrying. Regards, ---rony

---

Hi there,

one major effort that will materialize with the next version of Java (named Java "9", not "1.9" internally anymore, cf. <http://openjdk.java.net/jeps/223>) is the modularization of the Java runtime environment.

Sloppyly: a "module" defines the packages it consists of and optionally other modules it may require. JSR 376 home-page: <http://openjdk.java.net/projects/jigsaw/spec/>. Some sort of a bird eye's view/introduction at: <http://openjdk.java.net/projects/jigsaw/spec/sotms/>.

Another interesting feature set can be found in the package "java.lang.invoke", cf. <http://download.java.net/java/jdk9/docs/api/java/lang/invoke/package-summary.html>, where the invokedynamic instruction can now be excercised fully from pure Java code.

It is possible to download the "jigsaw" version of Java 9 and to test these features in person. As currently the Java tool communities start to explore the modularity concepts of Java 9, it may be the case that still some details may be changed before it goes GA (cf. <http://openjdk.java.net/projects/jdk9/>, where the release date may be changed depending on the discussions about module implementations; this particular page is also interesting in learning about everything that gets introduced into Java 9, also about various aspects of the new module system).

So this is a bit of preparing "food-for-thoughts" w.r.t. the NetRexx compiler/interpreter, which may elicit the one or the other idea/discussion.

---rony

P.S.: The new Java 9 JavaDocs have a very nice new feature: a search field! Just enter e.g. "compile" and you'll get ajumplist of all JavaDoc entries that contain "compile"!





_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ad upcoming Java 9 ...

rvjansen
Hi Rony,

one of the more acute results of this reworking is that NetRexx is not working at all with Java 9. We have to change the implementation on Java 8 (we need a working compiler to compile NetRexx with itself) to use reflection instead of the reading of all .jar (and .zip) files on the classpath, as it is doing now.  I have cleared trunk some months ago so we can branch off for work on this. Thanks for the links in your email which will save us some time to look up all this. As this is some major restructuring of the translator, it will probably land in version 5 of it; 4 (when it is finished) will be for Java 6-8 and ends there.

During the symposium you mentioned there were fallback api’s defined. I did not find these; and as NetRexx physically opens files to decompress and inspect the classes/method signatures in them, I have great doubts there will be something there that supports our effort.

Kermit, did you have time to look into this? Do we need to schedule a call to divide up the work? The idea would be to change the ‘eager’ and complete looking up of signatures with a ‘lazy’, just-in-time and caching lookup scheme based on the reflection api. So the initial effort would be to trap the ‘signature not found’ exception and retrofit it in the structure it looks for it.

best regards,

René.


On 30 Sep 2016, at 15:43, Rony G. Flatscher (wu-wien) <[hidden email]> wrote:

Hi there, my original posting did not get through, possibly because I used a wrong e-mail address, therefore retrying. Regards, ---rony

---

Hi there,

one major effort that will materialize with the next version of Java (named Java "9", not "1.9" internally anymore, cf. <http://openjdk.java.net/jeps/223>) is the modularization of the Java runtime environment.

Sloppyly: a "module" defines the packages it consists of and optionally other modules it may require. JSR 376 home-page: <http://openjdk.java.net/projects/jigsaw/spec/>. Some sort of a bird eye's view/introduction at: <http://openjdk.java.net/projects/jigsaw/spec/sotms/>.

Another interesting feature set can be found in the package "java.lang.invoke", cf. <http://download.java.net/java/jdk9/docs/api/java/lang/invoke/package-summary.html>, where the invokedynamic instruction can now be excercised fully from pure Java code.

It is possible to download the "jigsaw" version of Java 9 and to test these features in person. As currently the Java tool communities start to explore the modularity concepts of Java 9, it may be the case that still some details may be changed before it goes GA (cf. <http://openjdk.java.net/projects/jdk9/>, where the release date may be changed depending on the discussions about module implementations; this particular page is also interesting in learning about everything that gets introduced into Java 9, also about various aspects of the new module system).

So this is a bit of preparing "food-for-thoughts" w.r.t. the NetRexx compiler/interpreter, which may elicit the one or the other idea/discussion.

---rony

P.S.: The new Java 9 JavaDocs have a very nice new feature: a search field! Just enter e.g. "compile" and you'll get ajumplist of all JavaDoc entries that contain "compile"!




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ad upcoming Java 9 ...

Kermit Kiser

Rony, René -

Yes, I have a plan to fix the jar pre-read issue. I hope to work on that after finishing some changes Google insists are needed right now (they like to change Android in non compatible ways).

I have been worried that we would lose the "branch import" capability (called partial package name in the reference) from NetRexx with Java 9 since that comes from the pre-read of the entire class name space. However on thinking about it now, it occurs to me that the complete namespace for the Java base and library will be documented somewhere and if we capture that data and add it to an internal module of the compiler we can still preserve most of the branch import capability. What do you think?

I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system.

-- Kermit


On 9/30/2016 7:01 AM, René Jansen wrote:
Hi Rony,

one of the more acute results of this reworking is that NetRexx is not working at all with Java 9. We have to change the implementation on Java 8 (we need a working compiler to compile NetRexx with itself) to use reflection instead of the reading of all .jar (and .zip) files on the classpath, as it is doing now.  I have cleared trunk some months ago so we can branch off for work on this. Thanks for the links in your email which will save us some time to look up all this. As this is some major restructuring of the translator, it will probably land in version 5 of it; 4 (when it is finished) will be for Java 6-8 and ends there.

During the symposium you mentioned there were fallback api’s defined. I did not find these; and as NetRexx physically opens files to decompress and inspect the classes/method signatures in them, I have great doubts there will be something there that supports our effort.

Kermit, did you have time to look into this? Do we need to schedule a call to divide up the work? The idea would be to change the ‘eager’ and complete looking up of signatures with a ‘lazy’, just-in-time and caching lookup scheme based on the reflection api. So the initial effort would be to trap the ‘signature not found’ exception and retrofit it in the structure it looks for it.

best regards,

René.


On 30 Sep 2016, at 15:43, Rony G. Flatscher (wu-wien) <[hidden email]> wrote:

Hi there, my original posting did not get through, possibly because I used a wrong e-mail address, therefore retrying. Regards, ---rony

---

Hi there,

one major effort that will materialize with the next version of Java (named Java "9", not "1.9" internally anymore, cf. <http://openjdk.java.net/jeps/223>) is the modularization of the Java runtime environment.

Sloppyly: a "module" defines the packages it consists of and optionally other modules it may require. JSR 376 home-page: <http://openjdk.java.net/projects/jigsaw/spec/>. Some sort of a bird eye's view/introduction at: <http://openjdk.java.net/projects/jigsaw/spec/sotms/>.

Another interesting feature set can be found in the package "java.lang.invoke", cf. <http://download.java.net/java/jdk9/docs/api/java/lang/invoke/package-summary.html>, where the invokedynamic instruction can now be excercised fully from pure Java code.

It is possible to download the "jigsaw" version of Java 9 and to test these features in person. As currently the Java tool communities start to explore the modularity concepts of Java 9, it may be the case that still some details may be changed before it goes GA (cf. <http://openjdk.java.net/projects/jdk9/>, where the release date may be changed depending on the discussions about module implementations; this particular page is also interesting in learning about everything that gets introduced into Java 9, also about various aspects of the new module system).

So this is a bit of preparing "food-for-thoughts" w.r.t. the NetRexx compiler/interpreter, which may elicit the one or the other idea/discussion.

---rony

P.S.: The new Java 9 JavaDocs have a very nice new feature: a search field! Just enter e.g. "compile" and you'll get ajumplist of all JavaDoc entries that contain "compile"!




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ad upcoming Java 9 ...

rvjansen
Kermit,

re: branch imports
I think we should not have to resort to import documentation - and it would not work for own libraries, which are plenty. I have to read more about the module system; my hope is that it will assist.

And yes, migrating the repositories will be next - but that is just work and needs consensus first. I plan to migrate the whole history of the source code repository.  I am not sure we need the whole history of the issue tracker, but I will have a look when we get that dump.

Having worked with sccs, rcs, pvcs, sourcesafe, endevor, svn, rts etc, I am a fulltime Git bigot - that must have been clear from my symposium presentation on how to handle the jGit library with NetRexx. Both SourceForge (where we have other RexxLA code) and Github (duh) support git. I do not want a take a decision that you do not agree with. I think we still have a few months.

 best regards,

René.


On 1 okt. 2016, at 10:42, Kermit Kiser <[hidden email]> wrote:

Rony, René -

Yes, I have a plan to fix the jar pre-read issue. I hope to work on that after finishing some changes Google insists are needed right now (they like to change Android in non compatible ways).

I have been worried that we would lose the "branch import" capability (called partial package name in the reference) from NetRexx with Java 9 since that comes from the pre-read of the entire class name space. However on thinking about it now, it occurs to me that the complete namespace for the Java base and library will be documented somewhere and if we capture that data and add it to an internal module of the compiler we can still preserve most of the branch import capability. What do you think?

I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system.

-- Kermit


On 9/30/2016 7:01 AM, René Jansen wrote:
Hi Rony,

one of the more acute results of this reworking is that NetRexx is not working at all with Java 9. We have to change the implementation on Java 8 (we need a working compiler to compile NetRexx with itself) to use reflection instead of the reading of all .jar (and .zip) files on the classpath, as it is doing now.  I have cleared trunk some months ago so we can branch off for work on this. Thanks for the links in your email which will save us some time to look up all this. As this is some major restructuring of the translator, it will probably land in version 5 of it; 4 (when it is finished) will be for Java 6-8 and ends there.

During the symposium you mentioned there were fallback api’s defined. I did not find these; and as NetRexx physically opens files to decompress and inspect the classes/method signatures in them, I have great doubts there will be something there that supports our effort.

Kermit, did you have time to look into this? Do we need to schedule a call to divide up the work? The idea would be to change the ‘eager’ and complete looking up of signatures with a ‘lazy’, just-in-time and caching lookup scheme based on the reflection api. So the initial effort would be to trap the ‘signature not found’ exception and retrofit it in the structure it looks for it.

best regards,

René.


On 30 Sep 2016, at 15:43, Rony G. Flatscher (wu-wien) <[hidden email]> wrote:

Hi there, my original posting did not get through, possibly because I used a wrong e-mail address, therefore retrying. Regards, ---rony

---

Hi there,

one major effort that will materialize with the next version of Java (named Java "9", not "1.9" internally anymore, cf. <http://openjdk.java.net/jeps/223>) is the modularization of the Java runtime environment.

Sloppyly: a "module" defines the packages it consists of and optionally other modules it may require. JSR 376 home-page: <http://openjdk.java.net/projects/jigsaw/spec/>. Some sort of a bird eye's view/introduction at: <http://openjdk.java.net/projects/jigsaw/spec/sotms/>.

Another interesting feature set can be found in the package "java.lang.invoke", cf. <http://download.java.net/java/jdk9/docs/api/java/lang/invoke/package-summary.html>, where the invokedynamic instruction can now be excercised fully from pure Java code.

It is possible to download the "jigsaw" version of Java 9 and to test these features in person. As currently the Java tool communities start to explore the modularity concepts of Java 9, it may be the case that still some details may be changed before it goes GA (cf. <http://openjdk.java.net/projects/jdk9/>, where the release date may be changed depending on the discussions about module implementations; this particular page is also interesting in learning about everything that gets introduced into Java 9, also about various aspects of the new module system).

So this is a bit of preparing "food-for-thoughts" w.r.t. the NetRexx compiler/interpreter, which may elicit the one or the other idea/discussion.

---rony

P.S.: The new Java 9 JavaDocs have a very nice new feature: a search field! Just enter e.g. "compile" and you'll get ajumplist of all JavaDoc entries that contain "compile"!




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ad upcoming Java 9 ...

Kermit Kiser

René;

Let me know if you find a way to scan the class namespace without reading jar files.

I understand that we have a few months still to migrate the repositories but I don't know how long we will be working on Java9 and other changes before release and I would actually rather be working with the new format/location rather than having to co-ordinate a complicated changeover in the middle of that work. I suggest that we move the repository to GitHub and set up developer accounts there now. We can then take more time to figure out how to move the issue database to another tracker later.

Re Git - I still have no experience with it but I am studying it and I see that there are 4 code levels (remote, local, stage, working) rather than the two (repository and working copy) of SVN and that it requires 3 transactions (add, commit, and push) for a basic Git update equivalent to an SVN commit. I am guessing that Git is about three times as complex as SVN to work with. I trust there are advantages to the added complexity but I will have to learn them over time. I have no problem with switching over and I think most of the other developers already have some Git experience or can grok the switch.

-- Kermit

On 10/1/2016 2:00 AM, René Jansen wrote:
Kermit,

re: branch imports
I think we should not have to resort to import documentation - and it would not work for own libraries, which are plenty. I have to read more about the module system; my hope is that it will assist.

And yes, migrating the repositories will be next - but that is just work and needs consensus first. I plan to migrate the whole history of the source code repository.  I am not sure we need the whole history of the issue tracker, but I will have a look when we get that dump.

Having worked with sccs, rcs, pvcs, sourcesafe, endevor, svn, rts etc, I am a fulltime Git bigot - that must have been clear from my symposium presentation on how to handle the jGit library with NetRexx. Both SourceForge (where we have other RexxLA code) and Github (duh) support git. I do not want a take a decision that you do not agree with. I think we still have a few months.

 best regards,

René.


On 1 okt. 2016, at 10:42, Kermit Kiser <[hidden email]> wrote:

Rony, René -

Yes, I have a plan to fix the jar pre-read issue. I hope to work on that after finishing some changes Google insists are needed right now (they like to change Android in non compatible ways).

I have been worried that we would lose the "branch import" capability (called partial package name in the reference) from NetRexx with Java 9 since that comes from the pre-read of the entire class name space. However on thinking about it now, it occurs to me that the complete namespace for the Java base and library will be documented somewhere and if we capture that data and add it to an internal module of the compiler we can still preserve most of the branch import capability. What do you think?

I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system.

-- Kermit


On 9/30/2016 7:01 AM, René Jansen wrote:
Hi Rony,

one of the more acute results of this reworking is that NetRexx is not working at all with Java 9. We have to change the implementation on Java 8 (we need a working compiler to compile NetRexx with itself) to use reflection instead of the reading of all .jar (and .zip) files on the classpath, as it is doing now.  I have cleared trunk some months ago so we can branch off for work on this. Thanks for the links in your email which will save us some time to look up all this. As this is some major restructuring of the translator, it will probably land in version 5 of it; 4 (when it is finished) will be for Java 6-8 and ends there.

During the symposium you mentioned there were fallback api’s defined. I did not find these; and as NetRexx physically opens files to decompress and inspect the classes/method signatures in them, I have great doubts there will be something there that supports our effort.

Kermit, did you have time to look into this? Do we need to schedule a call to divide up the work? The idea would be to change the ‘eager’ and complete looking up of signatures with a ‘lazy’, just-in-time and caching lookup scheme based on the reflection api. So the initial effort would be to trap the ‘signature not found’ exception and retrofit it in the structure it looks for it.

best regards,

René.


On 30 Sep 2016, at 15:43, Rony G. Flatscher (wu-wien) <[hidden email]> wrote:

Hi there, my original posting did not get through, possibly because I used a wrong e-mail address, therefore retrying. Regards, ---rony

---

Hi there,

one major effort that will materialize with the next version of Java (named Java "9", not "1.9" internally anymore, cf. <http://openjdk.java.net/jeps/223>) is the modularization of the Java runtime environment.

Sloppyly: a "module" defines the packages it consists of and optionally other modules it may require. JSR 376 home-page: <http://openjdk.java.net/projects/jigsaw/spec/>. Some sort of a bird eye's view/introduction at: <http://openjdk.java.net/projects/jigsaw/spec/sotms/>.

Another interesting feature set can be found in the package "java.lang.invoke", cf. <http://download.java.net/java/jdk9/docs/api/java/lang/invoke/package-summary.html>, where the invokedynamic instruction can now be excercised fully from pure Java code.

It is possible to download the "jigsaw" version of Java 9 and to test these features in person. As currently the Java tool communities start to explore the modularity concepts of Java 9, it may be the case that still some details may be changed before it goes GA (cf. <http://openjdk.java.net/projects/jdk9/>, where the release date may be changed depending on the discussions about module implementations; this particular page is also interesting in learning about everything that gets introduced into Java 9, also about various aspects of the new module system).

So this is a bit of preparing "food-for-thoughts" w.r.t. the NetRexx compiler/interpreter, which may elicit the one or the other idea/discussion.

---rony

P.S.: The new Java 9 JavaDocs have a very nice new feature: a search field! Just enter e.g. "compile" and you'll get ajumplist of all JavaDoc entries that contain "compile"!




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ad upcoming Java 9 ...

Fernando Cassia-2
In reply to this post by Kermit Kiser

On Sat, Oct 1, 2016 at 5:42 AM, Kermit Kiser <[hidden email]> wrote:
I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system.

+1 for sourceforge. they are under new management and have got rid of the wrongdoings of the previous owners.

I recently had to report a bug on github as an end user and was astonished to find its very basic issues reporting interface.

https://t.co/Q5yZ2uDCSw

Or perhaps a third option: keeping a presence on both systems? SF.net for downloads, bug triage, and github for CVS?

You know, two windows attract more visitors than a single one...
FC


--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
- George Orwell

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

code repository choice (was: java 9 ...)

rvjansen
If I can summarize the views up until now:

Kermit has no problems switching to Git (thank you!); Fernando prefers SourceForce as its bug reporter is better. I have no preference but note that we have ooRexx at SourceForge. We did decide to move it, but that was under previous SF management and they seem to have played square lately.

I now see a possibility to move to SourceForge and use Git as SCCM. This is also an attractive option for me.
So I have claimed https://sourceforge.net/projects/netrexx/ and have configured it with Git. This is not definitive; Tom already has a NetRexx on Github, and it seems wise to mirror these, at least for the code repository. Thankfully, this is easy and can be automated.

I will share admin of the SF site with chosen RexxLA board members and volunteers. First I will preserve history in an svn-git conversion; after that, I will request a dump from the Kenai metadata and see how much we can convert/import. So for the moment, as the project manager, I have decided to run the project on SourceForge and on GitHub, with a preference of having the bug tracker and other project-meta objects on SourceForge. I will provide a short intro to Git for NetRexx, with the corresponding svn command equivalents. 

best regards,

René.

 



On 6 Oct 2016, at 09:00, Fernando Cassia <[hidden email]> wrote:


On Sat, Oct 1, 2016 at 5:42 AM, Kermit Kiser <[hidden email]> wrote:
I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system.

+1 for sourceforge. they are under new management and have got rid of the wrongdoings of the previous owners.

I recently had to report a bug on github as an end user and was astonished to find its very basic issues reporting interface.

https://t.co/Q5yZ2uDCSw

Or perhaps a third option: keeping a presence on both systems? SF.net for downloads, bug triage, and github for CVS?

You know, two windows attract more visitors than a single one...
FC


--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
- George Orwell
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: code repository choice (was: java 9 ...)

Kermit Kiser
That sounds like a good plan!

Perhaps ooRexx should be mirrored on GitHub also?

-- Kermit

On October 6, 2016 1:20:56 AM PDT, "René Jansen" <[hidden email]> wrote:
If I can summarize the views up until now:

Kermit has no problems switching to Git (thank you!); Fernando prefers SourceForce as its bug reporter is better. I have no preference but note that we have ooRexx at SourceForge. We did decide to move it, but that was under previous SF management and they seem to have played square lately.

I now see a possibility to move to SourceForge and use Git as SCCM. This is also an attractive option for me.
So I have claimed https://sourceforge.net/projects/netrexx/ and have configured it with Git. This is not definitive; Tom already has a NetRexx on Github, and it seems wise to mirror these, at least for the code repository. Thankfully, this is easy and can be automated.

I will share admin of th! e SF site with chosen RexxLA board members and volunteers. First I will preserve history in an svn-git conversion; after that, I will request a dump from the Kenai metadata and see how much we can convert/import. So for the moment, as the project manager, I have decided to run the project on SourceForge and on GitHub, with a preference of having the bug tracker and other project-meta objects on SourceForge. I will provide a short intro to Git for NetRexx, with the corresponding svn command equivalents. 

best regards,

René.

 



On 6 Oct 2016, at 09:00, Fernando Cassia <[hidden email]> wrote:


On Sat, Oct 1, 2016 at 5:42 AM, Kermit Kiser <[hidden email]> wrote:
I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system.

+1 for sourceforge. they are under new management and have got rid of the wrongdoings of the previous owners.

I recently had to report a bug on github as an end user and was astonished to find its very basic issues reporting interface.

https://t.co/Q5yZ2uDCSw

Or perhaps a third option: keeping a presence on both systems? SF.net for downloads, bug triage, and github for CVS?

You know, two windows attract more visitors than a single one...
FC

--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
- George Orwell
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/


--
Sent from my Android device with K-9 Mail.
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: code repository choice (was: java 9 ...)

rvjansen
yes, certainly. but git-git mirroring is easier than svn-git mirroring, so someone should invest some time - it can certainly be done

René.



On 6 Oct 2016, at 10:40, Kermit Kiser <[hidden email]> wrote:

That sounds like a good plan!

Perhaps ooRexx should be mirrored on GitHub also?

-- Kermit

On October 6, 2016 1:20:56 AM PDT, "René Jansen" <[hidden email]> wrote:
If I can summarize the views up until now:

Kermit has no problems switching to Git (thank you!); Fernando prefers SourceForce as its bug reporter is better. I have no preference but note that we have ooRexx at SourceForge. We did decide to move it, but that was under previous SF management and they seem to have played square lately.

I now see a possibility to move to SourceForge and use Git as SCCM. This is also an attractive option for me.
So I have claimed https://sourceforge.net/projects/netrexx/ and have configured it with Git. This is not definitive; Tom already has a NetRexx on Github, and it seems wise to mirror these, at least for the code repository. Thankfully, this is easy and can be automated.



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Loading...