Re: [VOTE] Approve the 1.1 release of Tuscany SDO
On Fri, Apr 11, 2008 at 2:08 AM, Kevan Miller [EMAIL PROTECTED] wrote: snip For files without src license headers, I was referring to files like: ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/impl/model/SDO.mdl ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/impl/src/test/resources/customer1.xml ... Looks like most are test files. I won't quibble much about the test files. Easiest (in the long run) to add license headers, IMO. Not sure what to make of the SDO.mdl file. For the .mdl one I believe it has not yet been found how to generate it including the header, the few test files that don't include it i think may need the files without header for the tests, either way, I don't think its a blocking problem for those test files and they're covered by the top level LICENSE and don't contain much much IP, eg: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/impl/src/test/resources/customer1.xml ...ant
Re: [VOTE] Approve the 1.1 release of Tuscany SDO
On Fri, Apr 11, 2008 at 2:35 AM, sebb [EMAIL PROTECTED] wrote: On 11/04/2008, Kevan Miller [EMAIL PROTECTED] wrote: On Apr 10, 2008, at 8:42 PM, Luciano Resende wrote: The files that have this license are listed in the LICENSE [1] file (search for Apache Tuscany SDO for Java Subcomponents) and I also see a mention of osoa.org in the NOTICE [2]. Is this what you were looking for ? For files without src license headers, I was referring to files like: ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/impl/model/SDO.mdl ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/impl/src/test/resources/customer1.xml ... Looks like most are test files. I won't quibble much about the test files. Easiest (in the long run) to add license headers, IMO. Not sure what to make of the SDO.mdl file. Yes, I saw the simple osoa.org attribution in the notice file. However, IMO that is not sufficient. I think the NOTICE should contain the copyright info and I believe the OSOA license requires it. From the OSOA license: 1.A link or URL to the Artifacts at this location: http://www.osoa.org/display/Main/Service+Data+Objects+Specifications 2.The full text of this copyright notice as shown in the Artifacts. I would add both of those to the NOTICE file. The NOTICE file is for attributions only. The rest goes in the LICENSE file, as has already been done This was our understanding too which is why its been changed to be this way. Have these replies clarified things enough, any further comments...or votes? ...ant
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
That seems to be a build issue on my side. I missed a parameter when starting the build - sorry for that. I just created another build from the same SVN tag and replaced the files for the maven repository. Now all seems to be correct! -- Michael Kevan Miller wrote: Sources jars (e.g. http://people.apache.org/~mbaessler/uimaj-2.2.2/05/maven/org/apache/uima/jVinci/2.2.2-incubating/jVinci-2.2.2-incubating-sources.jar) are missing LICENSE/NOTICE files. Beyond this, I didn't see any problems. --kevan On Apr 10, 2008, at 5:44 AM, Michael Baessler wrote: The Apache UIMA committers ask the Apache Incubator PMC for permission to publish a new bug fix release of Apache UIMA version 2.2.2. This release contains bug fixes of for release version 2.2.1 that was published in December 2007. For details about the fixes, please have a look at the release notes. We had a vote on uima-dev that resulted in 6 binding +1s (all the committers) and no 0s or -1s. The vote thread is here: http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200804.mbox/[EMAIL PROTECTED] Please review the release candidate here: http://people.apache.org/~mbaessler/uimaj-2.2.2/05/ There are subdirectories like: /bin - contains the binary distribution files /src - contains the source distribution files /rat - contains the RAT reports (using RAT 0.5.1) with some comments The SVN tag for this release candidate is: https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05 The KEYS file can be found in the SVN at: http://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/uimaj-distr/src/main/readme/KEYS Please vote: [ ] +1 Accept to release Apache UIMA 2.2.2 [ ] -1 No, because Thanks! -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
sebb wrote: On 10/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: The Apache UIMA committers ask the Apache Incubator PMC for permission to publish a new bug fix release of Apache UIMA version 2.2.2. This release contains bug fixes of for release version 2.2.1 that was published in December 2007. For details about the fixes, please have a look at the release notes. We had a vote on uima-dev that resulted in 6 binding +1s (all the committers) and no 0s or -1s. The vote thread is here: http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200804.mbox/[EMAIL PROTECTED] Please review the release candidate here: http://people.apache.org/~mbaessler/uimaj-2.2.2/05/ There are subdirectories like: /bin - contains the binary distribution files /src - contains the source distribution files /rat - contains the RAT reports (using RAT 0.5.1) with some comments Not sure I agree that RELEASE_NOTES don't require an AL header. It would not do any harm to add the header. Most parts of the RELEASE_NOTES are generated using JIRA, so I thought we can apply the rule mentioned on at http://www.apache.org/legal/src-headers.html. But if you think it would be better to have one, we will add a header next time. Hope that this is not a release stopper. Problem building uimaj: 1) javax.activation:activation:jar:1.0.2 ... Path to dependency: 1) org.apache.uima:uimaj-adapter-soap:jar:2.2.2-incubating 2) javax.activation:activation:jar:1.0.2 Should it not be using a more recent version, e.g. 1.1 ? When I remember correctly, I think we explicitly use this version because of some license changes for in the latter versions. Maybe some other UIMA committer can explain more detailed. The SVN tag for this release candidate is: https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05 The KEYS file can be found in the SVN at: http://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/uimaj-distr/src/main/readme/KEYS See separate e-mail regarding eol-style settings. Also, there are 3 .GIF files - the rest are all .gif. Could these be mistakes? We don't see any issues during our testing of this components (CDE plugin) but we will change it for the next release to lower case. Thanks for checking our release! -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: sebb wrote: The SVN tag https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05 has lots of missing SVN eol-style settings. See the file uimaj-2.2.2-05.sh in http://people.apache.org/~sebb/SVNfixes/ This should probably be applied to trunk as well ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebb, thanks for looking over our release. There are a lot of files in your list where not setting the eol-style property is intentional: all our test files. Which extensions are these? I can change my script to treat these differently. Setting eol-style:native would make our tests fail on one platform or another as they're usually compared to some expected output, which in turn depends on the exact byte content of the files. Unfortunately, there is no (valid) eol-style:none or such that allows us to make this intention explicit. In which case, the tests may fail to work on OSes with a different line ending, unless you set the mime-type to binary. For the java code we could set it to native. We just never felt the need. Since we need to be careful with our test files, we don't follow the automatic eol-style client setup as recommended. AFAIK, all UIMA developers use Eclipse for their development, and Eclipse doesn't care about eol style (or not that I noticed anyway). No it doesn't mind. But SVN does. If you edit a Java file on Unix and commit to SVN, then someone who edits it on Mac or Windows and commits to SVN will generate an SVN diff which shows the whole file has been changed. Makes it very difficult to see what has actually changed. Likewise for pom.xml etc. I hope you'll agree that it's up to the project to set an eol-style policy. Our policy is not to set the property unless it's required (e.g., for .sh or .bat files). Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
On Friday 11 April 2008, Thilo Goetz wrote: For the java code we could set it to native. We just never felt the need. Since we need to be careful with our test files, we don't follow the automatic eol-style client setup as recommended. AFAIK, all UIMA developers use Eclipse for their development, and Eclipse doesn't care about eol style (or not that I noticed anyway). I just want to say that this is a fairly short sighted view. CURRENTLY, all your developers use Eclipse, but if eol-style is not set properly on the files, it makes it much harder for other people that don't use eclipse to jump in and look at code and help. For example, without eol-style, a unix committed file loaded into notepad ends up all on one line. (not that anyone in their right mind would use notepad) It's probably not in the projects best interest to intentional exclude folks by making it harder for them to look at the code. Thus, you then only attract the folks that use eclipse making it self-fullfilling that all the developers use eclipse. As sebb pointed out, there are issues with svn diff and change tracking as well. Without eol-style set, a one line change can actually result in the ENTIRE file being marked changed. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
On Fri, Apr 11, 2008 at 9:10 AM, sebb [EMAIL PROTECTED] wrote: On 11/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: sebb wrote: Problem building uimaj: 1) javax.activation:activation:jar:1.0.2 Unfortunately only the POM and metadata are present in the M2 repo for that version - the jar is not present. I raised a JIRA issue for this: http://jira.codehaus.org/browse/MAVENUPLOAD-2014 This is because Sun's license prevents this jar from being redistributed from the central Maven repository: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html In the build instructions on the UIMA website, we describe how to obtain the jar yourself and add it to your local Maven repo: http://incubator.apache.org/uima/svn.html#building.command.line -Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
On Friday 11 April 2008, Adam Lally wrote: On Fri, Apr 11, 2008 at 9:10 AM, sebb [EMAIL PROTECTED] wrote: On 11/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: sebb wrote: Problem building uimaj: 1) javax.activation:activation:jar:1.0.2 Unfortunately only the POM and metadata are present in the M2 repo for that version - the jar is not present. I raised a JIRA issue for this: http://jira.codehaus.org/browse/MAVENUPLOAD-2014 This is because Sun's license prevents this jar from being redistributed from the central Maven repository: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html In the build instructions on the UIMA website, we describe how to obtain the jar yourself and add it to your local Maven repo: http://incubator.apache.org/uima/svn.html#building.command.line Any particular reason you don't exclude this dependency in you poms and then pull in a version that IS available. Either the 1.1 version from java.net: http://download.java.net/maven/1/javax.activation/jars/ or the geronimo-specs version available at central: http://repo1.maven.org/maven2/org/apache/geronimo/specs/ (In general, I prefer the geronimo specs versions, but it doesn't really matter) -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
sebb wrote: On 11/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: sebb wrote: On 10/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: The Apache UIMA committers ask the Apache Incubator PMC for permission to publish a new bug fix release of Apache UIMA version 2.2.2. This release contains bug fixes of for release version 2.2.1 that was published in December 2007. For details about the fixes, please have a look at the release notes. We had a vote on uima-dev that resulted in 6 binding +1s (all the committers) and no 0s or -1s. The vote thread is here: http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200804.mbox/[EMAIL PROTECTED] Please review the release candidate here: http://people.apache.org/~mbaessler/uimaj-2.2.2/05/ There are subdirectories like: /bin - contains the binary distribution files /src - contains the source distribution files /rat - contains the RAT reports (using RAT 0.5.1) with some comments Not sure I agree that RELEASE_NOTES don't require an AL header. It would not do any harm to add the header. Most parts of the RELEASE_NOTES are generated using JIRA, so I thought we can apply the rule Which rule? What files in an Apache release do not require a license header? A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header. If in doubt about the extent of the file's creativity, add the license header to the file. mentioned on at http://www.apache.org/legal/src-headers.html. But if you think it would be better to have one, we will add a header next time. Hope that this is not a release stopper. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
sebb wrote: On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: sebb wrote: The SVN tag https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05 has lots of missing SVN eol-style settings. See the file uimaj-2.2.2-05.sh in http://people.apache.org/~sebb/SVNfixes/ This should probably be applied to trunk as well ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebb, thanks for looking over our release. There are a lot of files in your list where not setting the eol-style property is intentional: all our test files. Which extensions are these? I can change my script to treat these differently. .txt mostly, some .xml. So I think one needs to handle this on an individual file level. Setting eol-style:native would make our tests fail on one platform or another as they're usually compared to some expected output, which in turn depends on the exact byte content of the files. Unfortunately, there is no (valid) eol-style:none or such that allows us to make this intention explicit. In which case, the tests may fail to work on OSes with a different line ending, unless you set the mime-type to binary. I don't understand that remark. For the java code we could set it to native. We just never felt the need. Since we need to be careful with our test files, we don't follow the automatic eol-style client setup as recommended. AFAIK, all UIMA developers use Eclipse for their development, and Eclipse doesn't care about eol style (or not that I noticed anyway). No it doesn't mind. But SVN does. If you edit a Java file on Unix and commit to SVN, then someone who edits it on Mac or Windows and commits to SVN will generate an SVN diff which shows the whole file has been changed. Makes it very difficult to see what has actually changed. Likewise for pom.xml etc. True. We try to avoid that ;-). Although most of us work on windows, we use unix style eol chars for all source code. I hope you'll agree that it's up to the project to set an eol-style policy. Our policy is not to set the property unless it's required (e.g., for .sh or .bat files). Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? So how do you create a distribution? To my mind, it shouldn't matter if you extracted the code on linux or windows. The distribution should come out the same and work on both platforms. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
Daniel Kulp wrote: On Friday 11 April 2008, Adam Lally wrote: On Fri, Apr 11, 2008 at 9:10 AM, sebb [EMAIL PROTECTED] wrote: On 11/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: sebb wrote: Problem building uimaj: 1) javax.activation:activation:jar:1.0.2 Unfortunately only the POM and metadata are present in the M2 repo for that version - the jar is not present. I raised a JIRA issue for this: http://jira.codehaus.org/browse/MAVENUPLOAD-2014 This is because Sun's license prevents this jar from being redistributed from the central Maven repository: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html In the build instructions on the UIMA website, we describe how to obtain the jar yourself and add it to your local Maven repo: http://incubator.apache.org/uima/svn.html#building.command.line Any particular reason you don't exclude this dependency in you poms and then pull in a version that IS available. Either the 1.1 version from java.net: http://download.java.net/maven/1/javax.activation/jars/ or the geronimo-specs version available at central: http://repo1.maven.org/maven2/org/apache/geronimo/specs/ (In general, I prefer the geronimo specs versions, but it doesn't really matter) If that works, it'll be vastly preferable to the manual do-hicky we have now. We'll follow up on uima-dev. Thanks, Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
On Friday 11 April 2008, Thilo Goetz wrote: Daniel Kulp wrote: On Friday 11 April 2008, Thilo Goetz wrote: For the java code we could set it to native. We just never felt the need. Since we need to be careful with our test files, we don't follow the automatic eol-style client setup as recommended. AFAIK, all UIMA developers use Eclipse for their development, and Eclipse doesn't care about eol style (or not that I noticed anyway). I just want to say that this is a fairly short sighted view. CURRENTLY, all your developers use Eclipse, but if eol-style is not set properly on the files, it makes it much harder for other people that don't use eclipse to jump in and look at code and help. For example, without eol-style, a unix committed file loaded into notepad ends up all on one line. (not that anyone in their right mind would use notepad) It's That's a pretty hypothetical scenario. What editors that a programmer would use are there on windows that don't handle unix eol chars? Um... well. If I just need to make a real quick edit (like fix a typo in a string), I may startup anything that starts up real quick, like notepad. Eclipse takes too long. Even on Linux, I use eclipse for most stuff, but if I need to make a quick pom edit or fix a checkstyle error after cruisecontrol emails me a build failure or something, I'll just use vim or something. In anycase, there are a bunch of editors on windows that by default will create files with DOS eol style. I think even eclipse might. If you edit an EXISTING file that is unix, they keep it that way, but creating a new file defaults ot DOS style. If a Unix person using an older version of emacs or vim or something loads that file, they see ^M things all over the place. You call it short-sighted, I call it on-demand. If somebody comes along and says I would like to help with UIMA but I can't because of your stupid unix eol settings, then we'll certainly reconsider. In the mean time, we're just saving ourselves some trouble. The main issue is that adding the svn:eol-style CAN be hugely disruptive later. If a file has mixed styles (some lines unix, some lines windows), you have to fix it. Which can create HUGE diffs and disrupts history, branch merges, etc... Getting it setup properly at the start prevents a large amount of pain later. Example: in general, the cxf devs are pretty good about it. (I used to run a script once a month or so to double check, but haven't in a while). sebb's script for cxf still resulted in a commit email broken into about 10 parts. The larger a project gets, the harder and more painful it is to fix later. In anycase, not a concern for the release vote, but IMO, something that should be STRONGLY considered. Dan But I certainly get your point. I recently offered to help on a project, but decided not to when the developers refused to make a small change that would have allowed me to work in Eclipse. probably not in the projects best interest to intentional exclude folks by making it harder for them to look at the code. Thus, you then only attract the folks that use eclipse making it self-fullfilling that all the developers use eclipse. I agree with you in principle, see above. Just not sure this is really a concern. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
On Friday 11 April 2008, Thilo Goetz wrote: Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? So a unix person can edit it without leaving lines that don't have the cr/lf (or have to see ^M marks all over the place). I do all kinds of edits to bat files from my Linux box. However, if they get committed with mixed styles, some versions of windows complain loudly when you try to run them. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 1.1 release of Tuscany SDO
On 4/9/08, ant elder [EMAIL PROTECTED] wrote: Should have voted myself, so +1. Anyone else able to review and vote on this? No blockers, +1 from me. Matthieu ...ant On Mon, Apr 7, 2008 at 12:10 AM, ant elder [EMAIL PROTECTED] wrote: Please vote to approve the 1.1 release of Tuscany SDO. This is RC4 fixing the issues found in the previous RC2. The release artifacts including source and binary distributions, maven staging repository, and RAT report are at: http://people.apache.org/~antelder/tuscany/sdo/1.1-rc4a http://people.apache.org/%7Eantelder/tuscany/sdo/1.1-rc4a The tag for the release is at: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/ KEYS file is at: https://svn.apache.org/repos/asf/incubator/tuscany/KEYS The tuscany-dev list vote thread is at: http://apache.markmail.org/message/xgaeb7klnsfdkrmx Many thanks, ...ant
Re: UIMA release - lots of missing SVN eol-style property settings
Daniel Kulp wrote: On Friday 11 April 2008, Thilo Goetz wrote: Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? So a unix person can edit it without leaving lines that don't have the cr/lf (or have to see ^M marks all over the place). I do all kinds of edits to bat files from my Linux box. However, if they get committed with mixed styles, some versions of windows complain loudly when you try to run them. Ok, I'll take your word for it ;-) So how do you handle releases, as I asked in a different mail in this thread? If you now extract the code on unix, you have .bat files with unix eol chars. I don't think the windows shell handles that. Same for .sh files, just the other way around. I'm sure people have a solution for that, but I don't see it. [In case this is not clear: we create one distribution with both .sh files and .bat files. The distro should work correctly on unix and windows. Just so we're all on the same page.] --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: sebb wrote: On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: sebb wrote: The SVN tag https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.2/uimaj-2.2.2-05 has lots of missing SVN eol-style settings. See the file uimaj-2.2.2-05.sh in http://people.apache.org/~sebb/SVNfixes/ This should probably be applied to trunk as well ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebb, thanks for looking over our release. There are a lot of files in your list where not setting the eol-style property is intentional: all our test files. Which extensions are these? I can change my script to treat these differently. .txt mostly, some .xml. So I think one needs to handle this on an individual file level. My script can be set up to allow optional values, e.g. at present pdf files can have a mime-type of either 'application/octet-stream' or 'application/pdf' Setting eol-style:native would make our tests fail on one platform or another as they're usually compared to some expected output, which in turn depends on the exact byte content of the files. Unfortunately, there is no (valid) eol-style:none or such that allows us to make this intention explicit. In which case, the tests may fail to work on OSes with a different line ending, unless you set the mime-type to binary. I don't understand that remark. For the java code we could set it to native. We just never felt the need. Since we need to be careful with our test files, we don't follow the automatic eol-style client setup as recommended. AFAIK, all UIMA developers use Eclipse for their development, and Eclipse doesn't care about eol style (or not that I noticed anyway). No it doesn't mind. But SVN does. If you edit a Java file on Unix and commit to SVN, then someone who edits it on Mac or Windows and commits to SVN will generate an SVN diff which shows the whole file has been changed. Makes it very difficult to see what has actually changed. Likewise for pom.xml etc. True. We try to avoid that ;-). Although most of us work on windows, we use unix style eol chars for all source code. That probably annoys the Mac Users... I hope you'll agree that it's up to the project to set an eol-style policy. Our policy is not to set the property unless it's required (e.g., for .sh or .bat files). Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? No idea - I would have thought CRLF would be more appropriate. So how do you create a distribution? To my mind, it shouldn't matter if you extracted the code on linux or windows. The distribution should come out the same and work on both platforms. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 1.1 release of Tuscany SDO
On Apr 11, 2008, at 3:47 AM, ant elder wrote: On Fri, Apr 11, 2008 at 2:08 AM, Kevan Miller [EMAIL PROTECTED] wrote: snip For files without src license headers, I was referring to files like: ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/ impl/model/SDO.mdl ==C:/Tuscany/Distros/SDO/1.1-rc4a/tuscany-sdo-1.1-incubating-src/ impl/src/test/resources/customer1.xml ... Looks like most are test files. I won't quibble much about the test files. Easiest (in the long run) to add license headers, IMO. Not sure what to make of the SDO.mdl file. For the .mdl one I believe it has not yet been found how to generate it including the header, the few test files that don't include it i think may need the files without header for the tests, either way, I don't think its a blocking problem for those test files and they're covered by the top level LICENSE and don't contain much much IP, eg: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1/impl/src/test/resources/customer1.xml K. If .mdl is generated, it need not include a header. --kevan
Re: UIMA release - lots of missing SVN eol-style property settings
On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: Daniel Kulp wrote: On Friday 11 April 2008, Thilo Goetz wrote: Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? So a unix person can edit it without leaving lines that don't have the cr/lf (or have to see ^M marks all over the place). I do all kinds of edits to bat files from my Linux box. However, if they get committed with mixed styles, some versions of windows complain loudly when you try to run them. Ok, I'll take your word for it ;-) So how do you handle releases, as I asked in a different mail in this thread? If you now extract the code on unix, you have .bat files with unix eol chars. I don't think the windows shell handles that. Same for .sh files, just the other way around. I'm sure people have a solution for that, but I don't see it. use eol-style: LF for .sh and CRLF for .bat/.cmd [In case this is not clear: we create one distribution with both .sh files and .bat files. The distro should work correctly on unix and windows. Just so we're all on the same page.] --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: Daniel Kulp wrote: On Friday 11 April 2008, Adam Lally wrote: On Fri, Apr 11, 2008 at 9:10 AM, sebb [EMAIL PROTECTED] wrote: On 11/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: sebb wrote: Problem building uimaj: 1) javax.activation:activation:jar:1.0.2 Unfortunately only the POM and metadata are present in the M2 repo for that version - the jar is not present. I raised a JIRA issue for this: http://jira.codehaus.org/browse/MAVENUPLOAD-2014 This is because Sun's license prevents this jar from being redistributed from the central Maven repository: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html In the build instructions on the UIMA website, we describe how to obtain the jar yourself and add it to your local Maven repo: http://incubator.apache.org/uima/svn.html#building.command.line Any particular reason you don't exclude this dependency in you poms and then pull in a version that IS available. Either the 1.1 version from java.net: http://download.java.net/maven/1/javax.activation/jars/ or the geronimo-specs version available at central: http://repo1.maven.org/maven2/org/apache/geronimo/specs/ (In general, I prefer the geronimo specs versions, but it doesn't really matter) If that works, it'll be vastly preferable to the manual do-hicky we have now. We'll follow up on uima-dev. FYI: the Geronimo-specs approach works fine for building JMeter. Thanks, Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
sebb wrote: On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: [...] True. We try to avoid that ;-). Although most of us work on windows, we use unix style eol chars for all source code. That probably annoys the Mac Users... We have Mac users (and developers), and they haven't complained yet. Maybe they're used to trouble, I don't know. Unfortunately, I don't own a Mac :-( --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
Actually, there is a reverse issue It also makes it quite difficult for people to help with UIMA if they are also contributors to other projects that DO use the normal svn settings, Eclipse or not. For example, lets pretend for a moment that I'm a Windows user that uses eclipse and contributes to several Apache projects. My svn is setup properly so any .java files I add are eol-style:native, etc... I then am voted in as a committer to UIMA due to some awesome work I've done. Do I need to maintain completely different svn settings when working on UIMA so that I don't add files in windows format? Dan On Friday 11 April 2008, Thilo Goetz wrote: Daniel Kulp wrote: On Friday 11 April 2008, Thilo Goetz wrote: For the java code we could set it to native. We just never felt the need. Since we need to be careful with our test files, we don't follow the automatic eol-style client setup as recommended. AFAIK, all UIMA developers use Eclipse for their development, and Eclipse doesn't care about eol style (or not that I noticed anyway). I just want to say that this is a fairly short sighted view. CURRENTLY, all your developers use Eclipse, but if eol-style is not set properly on the files, it makes it much harder for other people that don't use eclipse to jump in and look at code and help. For example, without eol-style, a unix committed file loaded into notepad ends up all on one line. (not that anyone in their right mind would use notepad) It's That's a pretty hypothetical scenario. What editors that a programmer would use are there on windows that don't handle unix eol chars? You call it short-sighted, I call it on-demand. If somebody comes along and says I would like to help with UIMA but I can't because of your stupid unix eol settings, then we'll certainly reconsider. In the mean time, we're just saving ourselves some trouble. But I certainly get your point. I recently offered to help on a project, but decided not to when the developers refused to make a small change that would have allowed me to work in Eclipse. probably not in the projects best interest to intentional exclude folks by making it harder for them to look at the code. Thus, you then only attract the folks that use eclipse making it self-fullfilling that all the developers use eclipse. I agree with you in principle, see above. Just not sure this is really a concern. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
sebb wrote: On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: Daniel Kulp wrote: On Friday 11 April 2008, Thilo Goetz wrote: Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? So a unix person can edit it without leaving lines that don't have the cr/lf (or have to see ^M marks all over the place). I do all kinds of edits to bat files from my Linux box. However, if they get committed with mixed styles, some versions of windows complain loudly when you try to run them. Ok, I'll take your word for it ;-) So how do you handle releases, as I asked in a different mail in this thread? If you now extract the code on unix, you have .bat files with unix eol chars. I don't think the windows shell handles that. Same for .sh files, just the other way around. I'm sure people have a solution for that, but I don't see it. use eol-style: LF for .sh and CRLF for .bat/.cmd Right, that's what we're doing. Dan on the other hand is recommending using eol-style:native, because he wants to edit .bat files on unix. And this is also the setting in svn config that you pointed to above, btw. We may have entered a loop here, not quite sure yet. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
Daniel Kulp wrote: Actually, there is a reverse issue It also makes it quite difficult for people to help with UIMA if they are also contributors to other projects that DO use the normal svn settings, Eclipse or not. For example, lets pretend for a moment that I'm a Windows user that uses eclipse and contributes to several Apache projects. My svn is setup properly so any .java files I add are eol-style:native, etc... I then am voted in as a committer to UIMA due to some awesome work I've done. Do I need to maintain completely different svn settings when working on UIMA so that I don't add files in windows format? Dan Dan, you've got me on the .java files, but you'll never convince me that the default settings for .bat and .sh files are a good idea. Nor for .txt, for that matter. This is all very well for some English readme files, but if you work with text as data, and exotic code pages, you don't want your data repository to go in and manipulate your data. All hell breaks loose, I've been there. Anyway, as I said, if your hypothetical developer becomes real, we can work this out I'm sure. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UIMA release - lots of missing SVN eol-style property settings
On Friday 11 April 2008, Thilo Goetz wrote: sebb wrote: On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: Daniel Kulp wrote: On Friday 11 April 2008, Thilo Goetz wrote: Indeed, but see also: http://www.apache.org/dev/version-control.html#https-svn-config These conventions are generally used by Java projects, e.g. all of Commons. Yes, and they don't work for us, as I pointed out earlier. There are also settings in there that I find rather doubtful. What is the point of having eol-style for .bat files set to native? So a unix person can edit it without leaving lines that don't have the cr/lf (or have to see ^M marks all over the place). I do all kinds of edits to bat files from my Linux box. However, if they get committed with mixed styles, some versions of windows complain loudly when you try to run them. Ok, I'll take your word for it ;-) So how do you handle releases, as I asked in a different mail in this thread? If you now extract the code on unix, you have .bat files with unix eol chars. I don't think the windows shell handles that. Same for .sh files, just the other way around. I'm sure people have a solution for that, but I don't see it. use eol-style: LF for .sh and CRLF for .bat/.cmd Right, that's what we're doing. Dan on the other hand is recommending using eol-style:native, because he wants to edit .bat files on unix. And this is also the setting in svn config that you pointed to above, btw. We may have entered a loop here, not quite sure yet. Yea. This is an interesting one. It might work for CRLF. I think svn may then prevent the commit on unix if they are inconsistent. I know you cannot svn add a file if the eol styles are inconsistent. Not sure about an commit. In anycase, ANY setting is better than no setting. It at least keeps the file in a consistent shape. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.2-incubating
sebb wrote: On 11/04/2008, Thilo Goetz [EMAIL PROTECTED] wrote: Daniel Kulp wrote: On Friday 11 April 2008, Adam Lally wrote: On Fri, Apr 11, 2008 at 9:10 AM, sebb [EMAIL PROTECTED] wrote: On 11/04/2008, Michael Baessler [EMAIL PROTECTED] wrote: sebb wrote: Problem building uimaj: 1) javax.activation:activation:jar:1.0.2 Unfortunately only the POM and metadata are present in the M2 repo for that version - the jar is not present. I raised a JIRA issue for this: http://jira.codehaus.org/browse/MAVENUPLOAD-2014 This is because Sun's license prevents this jar from being redistributed from the central Maven repository: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html In the build instructions on the UIMA website, we describe how to obtain the jar yourself and add it to your local Maven repo: http://incubator.apache.org/uima/svn.html#building.command.line Any particular reason you don't exclude this dependency in you poms and then pull in a version that IS available. Either the 1.1 version from java.net: http://download.java.net/maven/1/javax.activation/jars/ or the geronimo-specs version available at central: http://repo1.maven.org/maven2/org/apache/geronimo/specs/ (In general, I prefer the geronimo specs versions, but it doesn't really matter) If that works, it'll be vastly preferable to the manual do-hicky we have now. We'll follow up on uima-dev. FYI: the Geronimo-specs approach works fine for building JMeter. I changed the POM in the one project that references the javax.activation, changing the dependency to dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-activation_1.0.2_spec/artifactId version1.2/version scopecompile/scope /dependency This seems to have done the trick - is that all that we need to do? This artifact appears to be Apache v2 licensed. -Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
An update on Apache Tuscany
I'd like to take this opportunity to share information about how Apache Tuscany project has positively moved forward to build a larger community that is more integrated within the Apache ecosystem. I would make the following bullets so they stand out - We have welcomed 3 new committers, and have a new one being voted. - And added new PPMC members. - We have also experienced an increase in the number of user generated patches, from an average of 4 in the last months of 2007 to 7 in March, and other 7 only on the first days of current month. - We have welcomed many new community members who are beginning to learn Tuscany or are at a point of wanting to contribute - We also noticed traction from China and would like to thank the Tuscany contributors who have been instrumental for creating that awareness. This effort includes contribution of a Chinese version of the Tuscany website. - Actively participated in GSOC and mentored students and we have 8 good proposals being evaluated at the moment. - We have enhanced our website and user documentation, and this has paid off with great feedback from the community [1], here is what J Aaron Farr posted in his blog : ... One interesting observation was that the Tuscany team got started faster thanks to good project documentation and fewer software prerequisites - And some of the Tuscany Users have also been providing us with great feedback of their success using Tuscany in their first try [2]. The Tuscany community also spent great amount of time extending Tuscany to integrate with other Apache projects: - Apache Abdera for our Atom binding support - Apache ActiveMQ - Apache Axis2 for WebServices biding - Apache Derby - Apache Felix for OSGI runtime support - Apache Geronimo as a first-class integrated hosting platform for Tuscany - Apache ODE for BPEL engine integration - Apache OpenJPA - Apache Tomcat as hosting platform - etc And we have also noticed interest from other open source projects: - Eclipse STP for SCA Tooling is available for Tuscany SCA release 1.1 [3] - Also the Eclipse ELIF project has been integrating with Tuscany SCA [4] Tuscany community participated in many conferences and wrote journal articles to create awareness around Tuscany and help expand the community: - ApacheCon - JavaOne 2007 and 2008 - OASIS Symposium - SOA World - Asia Open Source Symposium Asia Open Source Symposium Code Fest - Presentations at Universities in (China, US, UK, Brazil) - Articles in Brazilian Magazines, Java Developer Journal and Chinese technical magazine - PyCon Italia Due Conference (Italy) And also, we have continued to deliver various Tuscany releases. We would like to thank our mentors and the community as a whole for the tremendous effort that has been put into creating the open and growing community that we are experiencing today. Further information is also available in the Tuscany Incubator Status page [5] [1] http://cubiclemuses.com/cm/blog/2008/codefest.html [2] http://incubator.apache.org/tuscany/projects-using-tuscany.html [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg29815.html [4] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg02643.html [5] http://incubator.apache.org/projects/tuscany.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache Abdera 0.4.0-incubating
The Apache Abdera community is pleased to announce the 0.4.0-incubating release. You can download binary and source distributions from: http://incubator.apache.org/abdera Introduction The goal of the Apache Abdera project is to build a functionally-complete, high-performance implementation of the IETF Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) specifications. Abdera is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. Release Summary === * A simplified server side framework and API for implementing services. * Server side filter API for intercepting requests and implementing concerns such as security. * A collection of pre-bundled Atom Publishing Protocol adapters for JDBC, JCR, filesystems, and CouchDB. * An improved JSON serialization mechanism. * New extensions such as OAuth support. * New StreamWriter interface for fast Atom document serialization * Improved Unicode performance for IRI implementation * URI Template Support * HTML Parser * Many API improvements and bug fixes! Please feel free to send any feedback to our mailing lists: [EMAIL PROTECTED] [EMAIL PROTECTED] Any contribution in the form of coding, testing, improving the documentation, and reporting bugs is always welcome. For more information on how to get involved with the development of Abdera, visit our website at: http://incubator.apache.org/abdera Thank you for your interest in Apache Abdera! - Apache Abdera Project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
