From buzdin at gmail.com Tue Jul 15 19:47:57 2014 From: buzdin at gmail.com (Dmitry Buzdin) Date: Tue, 15 Jul 2014 22:47:57 +0300 Subject: SigTest Tool Message-ID: Hello, I am looking for a right person to get in touch with regards to SigTest tool development? https://wiki.openjdk.java.net/display/CodeTools/sigtest The project I am working on would benefit greatly from that, but there are certain API extensibility issues and the whole build process and publishing to Maven Central is basically absent. After move to Mercurial Jenkins was not reconfigured etc. etc. I have possibility to contribute, but need help from someone with commit rights and idea of what is going on. Suggestions are: - start publishing to Maven Central (via Bintray or directly) - Work on API to ensure violation levels are configurable (so error could be substituted by warning in some projects via configuration file or system property) - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo ( https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) The ultimate goal is to treat SigTest as a low-level core library and start building proper maven plugins, which would analyse API changes, but only in certain packages and classes annotated as @Stable. This would be quite a convenient tool for any build pipeline of mature framework. I can share more details about the approach, but the first thing is to help getting it to Maven repo and fix closed API restriction. Regards, Dmitry Buzdin JUG Latvia Lead From kevin.looney at oracle.com Tue Jul 15 21:20:22 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Tue, 15 Jul 2014 14:20:22 -0700 Subject: SigTest Tool In-Reply-To: References: Message-ID: <53C59B16.30801@oracle.com> Hello Dima, Your idea of 'maven plugins checking @stable annotated APIs' sounds really cool! SigTest may be a good basis for doing such a thing. I am the development manager for the group that contributed SigTest into OpenJDK/CodeTools. I've sent out inquiries to the engineer that develops SigTest, and someone in LUG associated with adopt-openjdk - we'll get a few answers for you soon. I just wanted to point your attention to a couple of things. It might be possible to override SigTest logic to do what you wish - without changing the OS source. SigTest is designed in a way such that users can write 'plugins' that may implement and report incompatibilities according to their own logic. The SigTest User Guide is posted online: (http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/toc.htm) Please refer to these appendices: Appendix C http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_compat.htm#Z4000c521043455 These are the rules by which SigTest currently operates, according to the Java compatibility rules defined by the JLS (chapter 3). Appendix G http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_serialization_example.htm#CIABEGJC This is a custom-tool written using SigTest as a framework. There is example code in the SigTest distribution that implements this tool example. This might be a good starting point for implementing your own logic. I hope this helps. More answers on your direct requests soon. Thanks, Kevin L On 7/15/14, 12:47 PM, Dmitry Buzdin wrote: > Hello, > > I am looking for a right person to get in touch with regards to SigTest > tool development? > > https://wiki.openjdk.java.net/display/CodeTools/sigtest > > The project I am working on would benefit greatly from that, but there are > certain API extensibility issues and the whole build process and publishing > to Maven Central is basically absent. > After move to Mercurial Jenkins was not reconfigured etc. etc. > > I have possibility to contribute, but need help from someone with commit > rights and idea of what is going on. > > Suggestions are: > - start publishing to Maven Central (via Bintray or directly) > - Work on API to ensure violation levels are configurable (so error could > be substituted by warning in some projects via configuration file or system > property) > - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo ( > https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) > > The ultimate goal is to treat SigTest as a low-level core library and start > building proper maven plugins, which would analyse API changes, but only in > certain packages and classes annotated as @Stable. This would be quite a > convenient tool for any build pipeline of mature framework. > > I can share more details about the approach, but the first thing is to help > getting it to Maven repo and fix closed API restriction. > > Regards, > Dmitry Buzdin > JUG Latvia Lead -- kevin.looney at oracle.com From martijnverburg at gmail.com Wed Jul 16 08:07:38 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 16 Jul 2014 09:07:38 +0100 Subject: SigTest Tool In-Reply-To: <53C59B16.30801@oracle.com> References: <53C59B16.30801@oracle.com> Message-ID: Hi Kevin/All, CCing in the Adoption Group as there's possibly other folks interested in this area. @Dmitry - Feel free to use the AdoptOpenJDK GitHub site to start a repo with code changes until the area around licensing / contributions can be cleared up. Just license it with GPLv2 with Classpath exception so it'll be easy to merge into OpenJDK proper (if allowed etc). Cheers, Martijn On 15 July 2014 22:20, Kevin Looney wrote: > Hello Dima, > > Your idea of 'maven plugins checking @stable annotated APIs' sounds > really cool! SigTest may be a good basis for doing such a thing. > > I am the development manager for the group that contributed SigTest into > OpenJDK/CodeTools. I've sent out inquiries to the engineer that develops > SigTest, and someone in LUG associated with adopt-openjdk - we'll get a > few answers for you soon. > > I just wanted to point your attention to a couple of things. It might be > possible to override SigTest logic to do what you wish - without changing > the OS source. SigTest is designed in a way such that users can write > 'plugins' that may implement and report incompatibilities according to > their own logic. > > The SigTest User Guide is posted online: (http://docs.oracle.com/ > javame/test-tools/sigtest/3_0/html/toc.htm) > > Please refer to these appendices: > > Appendix C > http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ > compat.htm#Z4000c521043455 > > These are the rules by which SigTest currently operates, according to the > Java compatibility rules defined by the JLS (chapter 3). > > Appendix G > > http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ > serialization_example.htm#CIABEGJC > > This is a custom-tool written using SigTest as a framework. There is > example code in the SigTest distribution that implements this tool example. > This might be a good starting point for implementing your own logic. > > > I hope this helps. More answers on your direct requests soon. > > Thanks, > Kevin L > > > > > On 7/15/14, 12:47 PM, Dmitry Buzdin wrote: > >> Hello, >> >> I am looking for a right person to get in touch with regards to SigTest >> tool development? >> >> https://wiki.openjdk.java.net/display/CodeTools/sigtest >> >> The project I am working on would benefit greatly from that, but there are >> certain API extensibility issues and the whole build process and >> publishing >> to Maven Central is basically absent. >> After move to Mercurial Jenkins was not reconfigured etc. etc. >> >> I have possibility to contribute, but need help from someone with commit >> rights and idea of what is going on. >> >> Suggestions are: >> - start publishing to Maven Central (via Bintray or directly) >> - Work on API to ensure violation levels are configurable (so error could >> be substituted by warning in some projects via configuration file or >> system >> property) >> - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo ( >> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) >> >> The ultimate goal is to treat SigTest as a low-level core library and >> start >> building proper maven plugins, which would analyse API changes, but only >> in >> certain packages and classes annotated as @Stable. This would be quite a >> convenient tool for any build pipeline of mature framework. >> >> I can share more details about the approach, but the first thing is to >> help >> getting it to Maven repo and fix closed API restriction. >> >> Regards, >> Dmitry Buzdin >> JUG Latvia Lead >> > > > -- > kevin.looney at oracle.com > > From buzdin at gmail.com Wed Jul 16 08:46:37 2014 From: buzdin at gmail.com (Dmitry Buzdin) Date: Wed, 16 Jul 2014 11:46:37 +0300 Subject: SigTest Tool In-Reply-To: References: <53C59B16.30801@oracle.com> Message-ID: Hi Martijn, I am fine with that. Could you please add me to AdoptOpenJDK GitHub group. My account is 'buzdin'. Access to CloubBees Jenkins is also required. Also, could someone confirm that the up to date location of SigTest sources is this one http://hg.openjdk.java.net/code-tools/sigtest So the main ideas are working on build scripts and API of existing code with the goal to author a custom SigTest based tool in a separate repository. Will also send more detailed description of the concept tonight. Regards, Dmitry On Wed, Jul 16, 2014 at 11:07 AM, Martijn Verburg wrote: > Hi Kevin/All, > > CCing in the Adoption Group as there's possibly other folks interested in > this area. > > @Dmitry - Feel free to use the AdoptOpenJDK GitHub site to start a repo > with code changes until the area around licensing / contributions can be > cleared up. Just license it with GPLv2 with Classpath exception so it'll > be easy to merge into OpenJDK proper (if allowed etc). > > Cheers, > Martijn > > > On 15 July 2014 22:20, Kevin Looney wrote: > >> Hello Dima, >> >> Your idea of 'maven plugins checking @stable annotated APIs' sounds >> really cool! SigTest may be a good basis for doing such a thing. >> >> I am the development manager for the group that contributed SigTest into >> OpenJDK/CodeTools. I've sent out inquiries to the engineer that develops >> SigTest, and someone in LUG associated with adopt-openjdk - we'll get a >> few answers for you soon. >> >> I just wanted to point your attention to a couple of things. It might be >> possible to override SigTest logic to do what you wish - without changing >> the OS source. SigTest is designed in a way such that users can write >> 'plugins' that may implement and report incompatibilities according to >> their own logic. >> >> The SigTest User Guide is posted online: (http://docs.oracle.com/ >> javame/test-tools/sigtest/3_0/html/toc.htm) >> >> Please refer to these appendices: >> >> Appendix C >> http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ >> compat.htm#Z4000c521043455 >> >> These are the rules by which SigTest currently operates, according to the >> Java compatibility rules defined by the JLS (chapter 3). >> >> Appendix G >> >> http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ >> serialization_example.htm#CIABEGJC >> >> This is a custom-tool written using SigTest as a framework. There is >> example code in the SigTest distribution that implements this tool example. >> This might be a good starting point for implementing your own logic. >> >> >> I hope this helps. More answers on your direct requests soon. >> >> Thanks, >> Kevin L >> >> >> >> >> On 7/15/14, 12:47 PM, Dmitry Buzdin wrote: >> >>> Hello, >>> >>> I am looking for a right person to get in touch with regards to SigTest >>> tool development? >>> >>> https://wiki.openjdk.java.net/display/CodeTools/sigtest >>> >>> The project I am working on would benefit greatly from that, but there >>> are >>> certain API extensibility issues and the whole build process and >>> publishing >>> to Maven Central is basically absent. >>> After move to Mercurial Jenkins was not reconfigured etc. etc. >>> >>> I have possibility to contribute, but need help from someone with commit >>> rights and idea of what is going on. >>> >>> Suggestions are: >>> - start publishing to Maven Central (via Bintray or directly) >>> - Work on API to ensure violation levels are configurable (so error could >>> be substituted by warning in some projects via configuration file or >>> system >>> property) >>> - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo >>> ( >>> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) >>> >>> The ultimate goal is to treat SigTest as a low-level core library and >>> start >>> building proper maven plugins, which would analyse API changes, but only >>> in >>> certain packages and classes annotated as @Stable. This would be quite a >>> convenient tool for any build pipeline of mature framework. >>> >>> I can share more details about the approach, but the first thing is to >>> help >>> getting it to Maven repo and fix closed API restriction. >>> >>> Regards, >>> Dmitry Buzdin >>> JUG Latvia Lead >>> >> >> >> -- >> kevin.looney at oracle.com >> >> > From martijnverburg at gmail.com Wed Jul 16 08:53:09 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 16 Jul 2014 09:53:09 +0100 Subject: SigTest Tool In-Reply-To: References: <53C59B16.30801@oracle.com> Message-ID: Hi Dmitry, I've added you to both, GitHub permissions may not let you create a repo - if you get blocked, let me know! Cheers, Martijn On 16 July 2014 09:46, Dmitry Buzdin wrote: > Hi Martijn, > > I am fine with that. > > Could you please add me to AdoptOpenJDK GitHub group. My account is > 'buzdin'. Access to CloubBees Jenkins is also required. > Also, could someone confirm that the up to date location of SigTest > sources is this one http://hg.openjdk.java.net/code-tools/sigtest > > So the main ideas are working on build scripts and API of existing code > with the goal to author a custom SigTest based tool in a separate > repository. > > Will also send more detailed description of the concept tonight. > > Regards, > Dmitry > > > On Wed, Jul 16, 2014 at 11:07 AM, Martijn Verburg < > martijnverburg at gmail.com> wrote: > >> Hi Kevin/All, >> >> CCing in the Adoption Group as there's possibly other folks interested in >> this area. >> >> @Dmitry - Feel free to use the AdoptOpenJDK GitHub site to start a repo >> with code changes until the area around licensing / contributions can be >> cleared up. Just license it with GPLv2 with Classpath exception so it'll >> be easy to merge into OpenJDK proper (if allowed etc). >> >> Cheers, >> Martijn >> >> >> On 15 July 2014 22:20, Kevin Looney wrote: >> >>> Hello Dima, >>> >>> Your idea of 'maven plugins checking @stable annotated APIs' sounds >>> really cool! SigTest may be a good basis for doing such a thing. >>> >>> I am the development manager for the group that contributed SigTest into >>> OpenJDK/CodeTools. I've sent out inquiries to the engineer that develops >>> SigTest, and someone in LUG associated with adopt-openjdk - we'll get a >>> few answers for you soon. >>> >>> I just wanted to point your attention to a couple of things. It might be >>> possible to override SigTest logic to do what you wish - without changing >>> the OS source. SigTest is designed in a way such that users can write >>> 'plugins' that may implement and report incompatibilities according to >>> their own logic. >>> >>> The SigTest User Guide is posted online: (http://docs.oracle.com/ >>> javame/test-tools/sigtest/3_0/html/toc.htm) >>> >>> Please refer to these appendices: >>> >>> Appendix C >>> http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ >>> compat.htm#Z4000c521043455 >>> >>> These are the rules by which SigTest currently operates, according to >>> the Java compatibility rules defined by the JLS (chapter 3). >>> >>> Appendix G >>> >>> http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ >>> serialization_example.htm#CIABEGJC >>> >>> This is a custom-tool written using SigTest as a framework. There is >>> example code in the SigTest distribution that implements this tool example. >>> This might be a good starting point for implementing your own logic. >>> >>> >>> I hope this helps. More answers on your direct requests soon. >>> >>> Thanks, >>> Kevin L >>> >>> >>> >>> >>> On 7/15/14, 12:47 PM, Dmitry Buzdin wrote: >>> >>>> Hello, >>>> >>>> I am looking for a right person to get in touch with regards to SigTest >>>> tool development? >>>> >>>> https://wiki.openjdk.java.net/display/CodeTools/sigtest >>>> >>>> The project I am working on would benefit greatly from that, but there >>>> are >>>> certain API extensibility issues and the whole build process and >>>> publishing >>>> to Maven Central is basically absent. >>>> After move to Mercurial Jenkins was not reconfigured etc. etc. >>>> >>>> I have possibility to contribute, but need help from someone with commit >>>> rights and idea of what is going on. >>>> >>>> Suggestions are: >>>> - start publishing to Maven Central (via Bintray or directly) >>>> - Work on API to ensure violation levels are configurable (so error >>>> could >>>> be substituted by warning in some projects via configuration file or >>>> system >>>> property) >>>> - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new >>>> repo ( >>>> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) >>>> >>>> The ultimate goal is to treat SigTest as a low-level core library and >>>> start >>>> building proper maven plugins, which would analyse API changes, but >>>> only in >>>> certain packages and classes annotated as @Stable. This would be quite a >>>> convenient tool for any build pipeline of mature framework. >>>> >>>> I can share more details about the approach, but the first thing is to >>>> help >>>> getting it to Maven repo and fix closed API restriction. >>>> >>>> Regards, >>>> Dmitry Buzdin >>>> JUG Latvia Lead >>>> >>> >>> >>> -- >>> kevin.looney at oracle.com >>> >>> >> > From Mikhail.Ershov at oracle.com Wed Jul 16 10:02:04 2014 From: Mikhail.Ershov at oracle.com (Mikhail Ershov) Date: Wed, 16 Jul 2014 14:02:04 +0400 Subject: SigTest Tool In-Reply-To: References: <53C59B16.30801@oracle.com> Message-ID: <53C64D9C.4030707@oracle.com> Hi Dmitry, Feel free to ask any technical questions, I'll try to help. Mike Ershov, Sigtest tool engineering lead On 07/16/2014 12:46 PM, Dmitry Buzdin wrote: > Hi Martijn, > > I am fine with that. > > Could you please add me to AdoptOpenJDK GitHub group. My account is > 'buzdin'. Access to CloubBees Jenkins is also required. > Also, could someone confirm that the up to date location of SigTest sources > is this one http://hg.openjdk.java.net/code-tools/sigtest > > So the main ideas are working on build scripts and API of existing code > with the goal to author a custom SigTest based tool in a separate > repository. > > Will also send more detailed description of the concept tonight. > > Regards, > Dmitry > > > On Wed, Jul 16, 2014 at 11:07 AM, Martijn Verburg > wrote: > >> Hi Kevin/All, >> >> CCing in the Adoption Group as there's possibly other folks interested in >> this area. >> >> @Dmitry - Feel free to use the AdoptOpenJDK GitHub site to start a repo >> with code changes until the area around licensing / contributions can be >> cleared up. Just license it with GPLv2 with Classpath exception so it'll >> be easy to merge into OpenJDK proper (if allowed etc). >> >> Cheers, >> Martijn >> >> >> On 15 July 2014 22:20, Kevin Looney wrote: >> >>> Hello Dima, >>> >>> Your idea of 'maven plugins checking @stable annotated APIs' sounds >>> really cool! SigTest may be a good basis for doing such a thing. >>> >>> I am the development manager for the group that contributed SigTest into >>> OpenJDK/CodeTools. I've sent out inquiries to the engineer that develops >>> SigTest, and someone in LUG associated with adopt-openjdk - we'll get a >>> few answers for you soon. >>> >>> I just wanted to point your attention to a couple of things. It might be >>> possible to override SigTest logic to do what you wish - without changing >>> the OS source. SigTest is designed in a way such that users can write >>> 'plugins' that may implement and report incompatibilities according to >>> their own logic. >>> >>> The SigTest User Guide is posted online: (http://docs.oracle.com/ >>> javame/test-tools/sigtest/3_0/html/toc.htm) >>> >>> Please refer to these appendices: >>> >>> Appendix C >>> http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ >>> compat.htm#Z4000c521043455 >>> >>> These are the rules by which SigTest currently operates, according to the >>> Java compatibility rules defined by the JLS (chapter 3). >>> >>> Appendix G >>> >>> http://docs.oracle.com/javame/test-tools/sigtest/3_0/html/a_ >>> serialization_example.htm#CIABEGJC >>> >>> This is a custom-tool written using SigTest as a framework. There is >>> example code in the SigTest distribution that implements this tool example. >>> This might be a good starting point for implementing your own logic. >>> >>> >>> I hope this helps. More answers on your direct requests soon. >>> >>> Thanks, >>> Kevin L >>> >>> >>> >>> >>> On 7/15/14, 12:47 PM, Dmitry Buzdin wrote: >>> >>>> Hello, >>>> >>>> I am looking for a right person to get in touch with regards to SigTest >>>> tool development? >>>> >>>> https://wiki.openjdk.java.net/display/CodeTools/sigtest >>>> >>>> The project I am working on would benefit greatly from that, but there >>>> are >>>> certain API extensibility issues and the whole build process and >>>> publishing >>>> to Maven Central is basically absent. >>>> After move to Mercurial Jenkins was not reconfigured etc. etc. >>>> >>>> I have possibility to contribute, but need help from someone with commit >>>> rights and idea of what is going on. >>>> >>>> Suggestions are: >>>> - start publishing to Maven Central (via Bintray or directly) >>>> - Work on API to ensure violation levels are configurable (so error could >>>> be substituted by warning in some projects via configuration file or >>>> system >>>> property) >>>> - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo >>>> ( >>>> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) >>>> >>>> The ultimate goal is to treat SigTest as a low-level core library and >>>> start >>>> building proper maven plugins, which would analyse API changes, but only >>>> in >>>> certain packages and classes annotated as @Stable. This would be quite a >>>> convenient tool for any build pipeline of mature framework. >>>> >>>> I can share more details about the approach, but the first thing is to >>>> help >>>> getting it to Maven repo and fix closed API restriction. >>>> >>>> Regards, >>>> Dmitry Buzdin >>>> JUG Latvia Lead >>>> >>> >>> -- >>> kevin.looney at oracle.com >>> >>> From sadhak001 at gmail.com Thu Jul 17 21:56:05 2014 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 17 Jul 2014 22:56:05 +0100 Subject: SigTest Tool Message-ID: Hi Dmitry, Thanks for letting us know about the build, it fixed and running fine again - do you have another repo in mind when you say new repo in your message? Maven plugin would be interesting to see coming out it of this tool. From other messages I see Martijn has already given you access to the github repo to make your contributions - looking forward to it. About publishing artefacts of SigTest to Maven central - I would leave this question open to discussion - @Martijn, @Kevin, @Jonathan - what do you have in mind about this, Maven Central has a set of rules that we must comply to in order to publish artefacts (see http://maven.apache.org/guides/mini/guide-central-repository-upload.html), including changing the format of the artefact name. If we go that route for SigTest should we also do it for other opensource code-tool projects like jtreg, jtharness and jcov? Cheers, Mani ------------------------------ > > Message: 6 > Date: Tue, 15 Jul 2014 22:47:57 +0300 > From: Dmitry Buzdin > To: code-tools-dev at openjdk.java.net > Subject: SigTest Tool > Message-ID: > < > CAEwpzzwWhMgWx+p1-CB3ffC72hK1debejyqs8Mz1dNHi6Ye1Zg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello, > > I am looking for a right person to get in touch with regards to SigTest > tool development? > > https://wiki.openjdk.java.net/display/CodeTools/sigtest > > The project I am working on would benefit greatly from that, but there are > certain API extensibility issues and the whole build process and publishing > to Maven Central is basically absent. > After move to Mercurial Jenkins was not reconfigured etc. etc. > > I have possibility to contribute, but need help from someone with commit > rights and idea of what is going on. > > Suggestions are: > - start publishing to Maven Central (via Bintray or directly) > - Work on API to ensure violation levels are configurable (so error could > be substituted by warning in some projects via configuration file or system > property) > - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo ( > https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) > > The ultimate goal is to treat SigTest as a low-level core library and start > building proper maven plugins, which would analyse API changes, but only in > certain packages and classes annotated as @Stable. This would be quite a > convenient tool for any build pipeline of mature framework. > > I can share more details about the approach, but the first thing is to help > getting it to Maven repo and fix closed API restriction. > > Regards, > Dmitry Buzdin > JUG Latvia Lead > > > ------------------------------ > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From martijnverburg at gmail.com Fri Jul 18 09:18:44 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 18 Jul 2014 10:18:44 +0100 Subject: SigTest Tool In-Reply-To: References: Message-ID: Hi Mani, I think the Maven thing will be find. Initially we're using org.adoptopenjdk - but *if* and when projects migrate to OpenJDK proper I assume some sort of official naming structure will be used, probably taking guidance from Jigsaw. Cheers, Martijn On 17 July 2014 22:56, Mani Sarkar wrote: > Hi Dmitry, > > Thanks for letting us know about the build, it fixed and running fine again > - do you have another repo in mind when you say new repo in your message? > > Maven plugin would be interesting to see coming out it of this tool. From > other messages I see Martijn has already given you access to the github > repo to make your contributions - looking forward to it. > > About publishing artefacts of SigTest to Maven central - I would leave this > question open to discussion - @Martijn, @Kevin, @Jonathan - what do you > have in mind about this, Maven Central has a set of rules that we must > comply to in order to publish artefacts (see > http://maven.apache.org/guides/mini/guide-central-repository-upload.html), > including changing the format of the artefact name. > > If we go that route for SigTest should we also do it for other opensource > code-tool projects like jtreg, jtharness and jcov? > > Cheers, > Mani > > ------------------------------ > > > > Message: 6 > > Date: Tue, 15 Jul 2014 22:47:57 +0300 > > From: Dmitry Buzdin > > To: code-tools-dev at openjdk.java.net > > Subject: SigTest Tool > > Message-ID: > > < > > CAEwpzzwWhMgWx+p1-CB3ffC72hK1debejyqs8Mz1dNHi6Ye1Zg at mail.gmail.com> > > Content-Type: text/plain; charset=UTF-8 > > > > Hello, > > > > I am looking for a right person to get in touch with regards to SigTest > > tool development? > > > > https://wiki.openjdk.java.net/display/CodeTools/sigtest > > > > The project I am working on would benefit greatly from that, but there > are > > certain API extensibility issues and the whole build process and > publishing > > to Maven Central is basically absent. > > After move to Mercurial Jenkins was not reconfigured etc. etc. > > > > I have possibility to contribute, but need help from someone with commit > > rights and idea of what is going on. > > > > Suggestions are: > > - start publishing to Maven Central (via Bintray or directly) > > - Work on API to ensure violation levels are configurable (so error could > > be substituted by warning in some projects via configuration file or > system > > property) > > - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new repo > ( > > https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) > > > > The ultimate goal is to treat SigTest as a low-level core library and > start > > building proper maven plugins, which would analyse API changes, but only > in > > certain packages and classes annotated as @Stable. This would be quite a > > convenient tool for any build pipeline of mature framework. > > > > I can share more details about the approach, but the first thing is to > help > > getting it to Maven repo and fix closed API restriction. > > > > Regards, > > Dmitry Buzdin > > JUG Latvia Lead > > > > > > ------------------------------ > > > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > From buzdin at gmail.com Fri Jul 18 10:40:29 2014 From: buzdin at gmail.com (Dmitry Buzdin) Date: Fri, 18 Jul 2014 13:40:29 +0300 Subject: SigTest Tool In-Reply-To: References: Message-ID: Hi, We are in touch with Mikhail to prototype the maven plugin and see if any modifications needed on SigTest side. Once the prototype is there we could publish it under AdoptOpenJDK brand if everybody is ok with that. I will let you know about the progress soon enough. Regards, Dmitry On Fri, Jul 18, 2014 at 12:18 PM, Martijn Verburg wrote: > Hi Mani, > > I think the Maven thing will be find. Initially we're using > org.adoptopenjdk - but *if* and when projects migrate to OpenJDK proper I > assume some sort of official naming structure will be used, probably taking > guidance from Jigsaw. > > Cheers, > Martijn > > > On 17 July 2014 22:56, Mani Sarkar wrote: > > > Hi Dmitry, > > > > Thanks for letting us know about the build, it fixed and running fine > again > > - do you have another repo in mind when you say new repo in your message? > > > > Maven plugin would be interesting to see coming out it of this tool. From > > other messages I see Martijn has already given you access to the github > > repo to make your contributions - looking forward to it. > > > > About publishing artefacts of SigTest to Maven central - I would leave > this > > question open to discussion - @Martijn, @Kevin, @Jonathan - what do you > > have in mind about this, Maven Central has a set of rules that we must > > comply to in order to publish artefacts (see > > http://maven.apache.org/guides/mini/guide-central-repository-upload.html > ), > > including changing the format of the artefact name. > > > > If we go that route for SigTest should we also do it for other opensource > > code-tool projects like jtreg, jtharness and jcov? > > > > Cheers, > > Mani > > > > ------------------------------ > > > > > > Message: 6 > > > Date: Tue, 15 Jul 2014 22:47:57 +0300 > > > From: Dmitry Buzdin > > > To: code-tools-dev at openjdk.java.net > > > Subject: SigTest Tool > > > Message-ID: > > > < > > > CAEwpzzwWhMgWx+p1-CB3ffC72hK1debejyqs8Mz1dNHi6Ye1Zg at mail.gmail.com> > > > Content-Type: text/plain; charset=UTF-8 > > > > > > Hello, > > > > > > I am looking for a right person to get in touch with regards to SigTest > > > tool development? > > > > > > https://wiki.openjdk.java.net/display/CodeTools/sigtest > > > > > > The project I am working on would benefit greatly from that, but there > > are > > > certain API extensibility issues and the whole build process and > > publishing > > > to Maven Central is basically absent. > > > After move to Mercurial Jenkins was not reconfigured etc. etc. > > > > > > I have possibility to contribute, but need help from someone with > commit > > > rights and idea of what is going on. > > > > > > Suggestions are: > > > - start publishing to Maven Central (via Bintray or directly) > > > - Work on API to ensure violation levels are configurable (so error > could > > > be substituted by warning in some projects via configuration file or > > system > > > property) > > > - Reconfigure Jenkins Job on cloudbees so it runs smoothly from new > repo > > ( > > > https://adopt-openjdk.ci.cloudbees.com/job/sigtest/) > > > > > > The ultimate goal is to treat SigTest as a low-level core library and > > start > > > building proper maven plugins, which would analyse API changes, but > only > > in > > > certain packages and classes annotated as @Stable. This would be quite > a > > > convenient tool for any build pipeline of mature framework. > > > > > > I can share more details about the approach, but the first thing is to > > help > > > getting it to Maven repo and fix closed API restriction. > > > > > > Regards, > > > Dmitry Buzdin > > > JUG Latvia Lead > > > > > > > > > ------------------------------ > > > > > > > -- > > @theNeomatrix369 * | **Blog > > ** | *LJC Associate & LJC Advocate > > (@adoptopenjdk & @adoptajsr programs) > > *Meet-a-Project - *MutabilityDetector > > * | **Bitbucket > > * * | **Github > > * * | **LinkedIn > > * > > *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ > > > > *Don't chase success, rather aim for "Excellence", and success will come > > chasing after you!* > > > From eric.mccorkle at oracle.com Tue Jul 22 17:51:39 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 22 Jul 2014 13:51:39 -0400 Subject: Proposal for a code-tools project: spec description DSL and test case generation tool Message-ID: <53CEA4AB.9000301@oracle.com> I would like to propose the creation of a repository in which I (and possibly others) will work on a tool that provides a DSL for denoting language and execution specifications. This tool will also provide the ability to generate code that enumerates test cases from a spec, allowing for specification-driven testing. The tentative title for the repository (and the language) is "lsl", a shortening of "logical specification language"; however, I am open to suggestions for a better name. The repository will be open, and all code will be licensed under the appropriate version of the GPL. Details about the proposed LSL language and tools follow: * The LSL language should allow users to write language specifications in a syntax that can be parsed and operated on by tools. The language will be based on Gentzen-style inference rules, which are the generally-accepted standard for writing language and type system specifications in programming language literature. Rules in this style amount to logical "implies" statements, with a single conclusion and possibly multiple premises. Additionally, the language needs to allow users to define abstract syntax structures, as well as maps, sequences, sets, and other structures that are common in programming language specifications. * It should be possible to use LSL to formally describe important parts of the JLS and JVMS, such as the grammar, the type system, the selection/resolution logic for method invocation, and others. * There will be a tool, tentatively named "lslproc", which will parse specifications written using the DSL. The tool will have two builtin backends, and will support a pluggable backend architecture, allowing additional backends to be written in the future. * The first backend will generate code that enumerates the characteristic cases for a given spec. The primary use case for this is testing problems where the following exist: 1) highly recursive structure, 2) very difficult to determine expected results (ie. truth tables lack large "blocks"), 3) very large sample spaces, with large equivalence classes that are not easy to compute (related to (2)). The specnote tool will act similarly to a lex/yacc style tool, generating test case enumeration code, which is then combined with a test harness to create an enumeration test. * The second backend will generate documentation in several formats (docbook, LaTeX, etc) that renders as an abstract syntax definition, and a set of inference rules in the standard Gentzen-style notation. * The repository will also contain a library that will be used to support the code generated by the first backend. This library will provide a framework for implementing enumeration procedures. Should components of this library prove to be generally useful, they may be considered for addition to the core libraries. General notes: * The details of the spec DSL beyond the simple statement of its goals are at this point undetermined. The design of the DSL should consider similar languages and tools already in existence. * The DSL and tools should be sufficiently powerful to denote a specification for a real programming language (ie. Java); however, they should avoid additional complexity beyond that. * The DSL and tools should be "industrial-grade" software. They should be usable, robust, and provide features suitable for production use (ie. beyond a few toy examples). From eric.mccorkle at oracle.com Wed Jul 23 10:49:17 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 23 Jul 2014 06:49:17 -0400 Subject: Proposal for a code-tools project: spec description DSL and test case generation tool In-Reply-To: <53CEA4AB.9000301@oracle.com> References: <53CEA4AB.9000301@oracle.com> Message-ID: <53CF932D.8030904@oracle.com> Minor issue, but a possible better name occurred to me: Logic, Abstract Syntax, and Enumeration Representation (laser) On 07/22/14 13:51, Eric McCorkle wrote: > I would like to propose the creation of a repository in which I (and > possibly others) will work on a tool that provides a DSL for denoting > language and execution specifications. This tool will also provide the > ability to generate code that enumerates test cases from a spec, > allowing for specification-driven testing. > > The tentative title for the repository (and the language) is "lsl", a > shortening of "logical specification language"; however, I am open to > suggestions for a better name. > > The repository will be open, and all code will be licensed under the > appropriate version of the GPL. > > > Details about the proposed LSL language and tools follow: > > * The LSL language should allow users to write language specifications > in a syntax that can be parsed and operated on by tools. The language > will be based on Gentzen-style inference rules, which are the > generally-accepted standard for writing language and type system > specifications in programming language literature. Rules in this style > amount to logical "implies" statements, with a single conclusion and > possibly multiple premises. Additionally, the language needs to allow > users to define abstract syntax structures, as well as maps, sequences, > sets, and other structures that are common in programming language > specifications. > > * It should be possible to use LSL to formally describe important parts > of the JLS and JVMS, such as the grammar, the type system, the > selection/resolution logic for method invocation, and others. > > * There will be a tool, tentatively named "lslproc", which will parse > specifications written using the DSL. The tool will have two builtin > backends, and will support a pluggable backend architecture, allowing > additional backends to be written in the future. > > * The first backend will generate code that enumerates the > characteristic cases for a given spec. The primary use case for this is > testing problems where the following exist: 1) highly recursive > structure, 2) very difficult to determine expected results (ie. truth > tables lack large "blocks"), 3) very large sample spaces, with large > equivalence classes that are not easy to compute (related to (2)). The > specnote tool will act similarly to a lex/yacc style tool, generating > test case enumeration code, which is then combined with a test harness > to create an enumeration test. > > * The second backend will generate documentation in several formats > (docbook, LaTeX, etc) that renders as an abstract syntax definition, and > a set of inference rules in the standard Gentzen-style notation. > > * The repository will also contain a library that will be used to > support the code generated by the first backend. This library will > provide a framework for implementing enumeration procedures. Should > components of this library prove to be generally useful, they may be > considered for addition to the core libraries. > > > General notes: > > * The details of the spec DSL beyond the simple statement of its goals > are at this point undetermined. The design of the DSL should consider > similar languages and tools already in existence. > > * The DSL and tools should be sufficiently powerful to denote a > specification for a real programming language (ie. Java); however, they > should avoid additional complexity beyond that. > > * The DSL and tools should be "industrial-grade" software. They should > be usable, robust, and provide features suitable for production use (ie. > beyond a few toy examples). >