Re: [VOTE] Retire AltRMI
The AltRMI podling, http://incubator.apache.org/projects/ altrmi.html has become stagnant. Here is a vote to move it into retirement. [ ] -1 : It lives on, you someone missed my recent commits on it last week [ ] 0 : I don't do fall cleansing [ ] +1 : Move to retirement +1 -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Retire AltRMI
The mentor and lead (cough) I mean person who made most commits. I've also voted +1 for retirement@ Apache. There are tons of things wrong with AltRMI that precluded a 1.0 release. That notwithstanding the fact that it went out in a couple of releases of http://enterpriseobjectbroker.org/ * the callback side of it (duplex if you like) had some flaws in that it would not scale very well and would create problems in the attempt to recover a connection * there are some logical holes in the client/server communication ... handshaking if you will * nothing about it is robust or hardened against hackers. * its Stub generator (Javac based) was well past in sell by date, and one could suggest in the age of dynamic proxies is not needed * 20% of its code was bound to Avalon which just ain't needed these days. * coverage was pretty low. no unit tests, although many integration tests * arcane naming of classes, methods and concepts. * I could go on.. As it happens a massively reworked version lives at Codehaus - http://svn.jremoting.codehaus.org/ (no site) with many features deleted. It is a fork yes. Most of the code that survives has a copyright statement crediting Apache - like http:// svn.jremoting.codehaus.org/browse/jremoting/jremoting/trunk/api/src/ java/org/codehaus/jremoting/server/StubRetriever.java A much smaller number of genuinely new classes are copyrighted to just The JRemoting Committers - http://svn.jremoting.codehaus.org/browse/ jremoting/jremoting/trunk/server/src/java/org/codehaus/jremoting/ server/transports/ServerXStreamDriver.java All is Apache licensed of course rather than my more usual BSD Regards, - Paul On Nov 6, 2006, at 10:06 PM, Leo Simons wrote: On Nov 6, 2006, at 9:01 PM, peter royal wrote: The AltRMI podling, http://incubator.apache.org/projects/ altrmi.html has become stagnant. Here is a vote to move it into retirement. [ ] -1 : It lives on, you someone missed my recent commits on it last week [ ] 0 : I don't do fall cleansing [ ] +1 : Move to retirement Here's my +1 +1. Shame though. Such a great codebase it is. So much just works feeling attached to it no-one needs to work on it. Heh. Perhaps we can prod some of its contributors (who moved on to bigger and greater things long ago as far as I know) to contribute some of the good bits as a replacement RMI module to Harmony, and have AltRMI eclipse RMI many years after it was first envisioned. Or maybe not :) cheers, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts
key ID 96324791 used to sign releases is not available from the usual public key server networks. please upload to pgp.mit.edu (web interface) or use gpg (to upload to any well known pubilc keyserver). I had lodged this key at http://keyserver.veridis.com, but wasn't sure if this would be widely available. I'm a novice in this field. I have now uploaded the key to pgp.mit.edo and I see C:\ gpg --search-keys goodson gpg: searching for goodson from hkp server pgp.mit.edu (1) Kelvin Goodson [EMAIL PROTECTED] 1024 bit DSA key 96324791, created: 2006-10-17 Regards, Kelvin. On 07/11/06, Luciano Resende [EMAIL PROTECTED] wrote: One more thing, about the signatures,the public key for verifying the signatures may be found in : https://svn.apache.org/repos/asf/incubator/tuscany/KEYS - Luciano Resende On 11/6/06, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Robert for looking into this, more comments inline... Please let me know if you have any further questions. On 11/6/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 11/5/06, Luciano Resende [EMAIL PROTECTED] wrote: The Tuscany PPMC has voted to Release DAS for Java API Implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. +0 (a couple of questions which i'd like answering before i can +1) please fix: md5 sums are not in the correct format. please delete all but the last line. (AIUI they are read automatically by some scripts.) this does not require a rebuild. The files should be in the right format now. questions sample-companyweb-1.0-incubator-M2.war lacks LICENSE and NOTICE files. this means that it cannot be distributed as a raw artifact. is the intention to ban this artifact from distribution via maven? LICENSE and NOTICE are available inside the war file at WEB-INF\classes\META-INF, please let me know if they are in the wrong place. RAT: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/samples/testing/tomcat/datasource.xsl lacks a license header. is there a reason (for example, is it generated) or is it just an oversight? This was an oversight on my part, I have created a JIRA and a patch was applied to the trunk. http://issues.apache.org/jira/browse/TUSCANY-900 Would this be enough ? important (but can be fixed for next release) - key ID 96324791 used to sign releases is not available from the usual public key server networks. please upload to pgp.mit.edu (web interface) or use gpg (to upload to any well known pubilc keyserver). Sure, the key is from kgoodson, that was of great help signing and uploading the DAS artifacts. I have forwarded this comment to him. stylistic (best practice) --- release names can be a form of advertising and can also allow the trademark to be used to prevent unauthorised jars being distributed with similar names. so, i'd recommend ensuing all releases are prefixed with 'apache-tuscany' when tuscany graduates. i have no objection to using this naming in the incubator (though some people may). the compressed archives unpack into the current directory. this is a real PITA for most users and a bad practice. there are two good approaches: either structure the release so that all duistributions unpack into the same directory (with name based on the release) in a way that elegantly combines or have each unpack distribution into a separate, meaningfully but uniquely named directory. I'm aware of this, and have submitted a patch to fix this in the trunk, but unfortunately it is not available in this release. http://issues.apache.org/jira/browse/TUSCANY-886 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Retire AltRMI
On Nov 6, 2006, at 5:06 PM, Leo Simons wrote: On Nov 6, 2006, at 9:01 PM, peter royal wrote: The AltRMI podling, http://incubator.apache.org/projects/ altrmi.html has become stagnant. Here is a vote to move it into retirement. [ ] -1 : It lives on, you someone missed my recent commits on it last week [ ] 0 : I don't do fall cleansing [ ] +1 : Move to retirement Here's my +1 +1. Shame though. Such a great codebase it is. So much just works feeling attached to it no-one needs to work on it. +1 all the way around. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts
i'm now +1 (more inline) On 11/7/06, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Robert for looking into this, more comments inline... Please let me know if you have any further questions. On 11/6/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 11/5/06, Luciano Resende [EMAIL PROTECTED] wrote: The Tuscany PPMC has voted to Release DAS for Java API Implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. +0 (a couple of questions which i'd like answering before i can +1) please fix: md5 sums are not in the correct format. please delete all but the last line. (AIUI they are read automatically by some scripts.) this does not require a rebuild. The files should be in the right format now. look good to me questions sample-companyweb-1.0-incubator-M2.war lacks LICENSE and NOTICE files. this means that it cannot be distributed as a raw artifact. is the intention to ban this artifact from distribution via maven? LICENSE and NOTICE are available inside the war file at WEB-INF\classes\META-INF, please let me know if they are in the wrong place. thanks (missed them) RAT: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/samples/testing/tomcat/datasource.xsl lacks a license header. is there a reason (for example, is it generated) or is it just an oversight? This was an oversight on my part, I have created a JIRA and a patch was applied to the trunk. http://issues.apache.org/jira/browse/TUSCANY-900 Would this be enough ? it's the provinence that's most important. since there's only one, i'm happy to see this fixed in head and the release cut. important (but can be fixed for next release) - key ID 96324791 used to sign releases is not available from the usual public key server networks. please upload to pgp.mit.edu (web interface) or use gpg (to upload to any well known pubilc keyserver). Sure, the key is from kgoodson, that was of great help signing and uploading the DAS artifacts. I have forwarded this comment to him. i have CAB30DDC from kgoodson. not sure why the artifacts are signed by 96324791. consider generating your own key and adding an extra signature. stylistic (best practice) --- release names can be a form of advertising and can also allow the trademark to be used to prevent unauthorised jars being distributed with similar names. so, i'd recommend ensuing all releases are prefixed with 'apache-tuscany' when tuscany graduates. i have no objection to using this naming in the incubator (though some people may). the compressed archives unpack into the current directory. this is a real PITA for most users and a bad practice. there are two good approaches: either structure the release so that all duistributions unpack into the same directory (with name based on the release) in a way that elegantly combines or have each unpack distribution into a separate, meaningfully but uniquely named directory. I'm aware of this, and have submitted a patch to fix this in the trunk, but unfortunately it is not available in this release. http://issues.apache.org/jira/browse/TUSCANY-886 good - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts
On 11/7/06, kelvin goodson [EMAIL PROTECTED] wrote: key ID 96324791 used to sign releases is not available from the usual public key server networks. please upload to pgp.mit.edu (web interface) or use gpg (to upload to any well known pubilc keyserver). I had lodged this key at http://keyserver.veridis.com, but wasn't sure if this would be widely available. I'm a novice in this field. I have now uploaded the key to pgp.mit.edo and I see C:\ gpg --search-keys goodson gpg: searching for goodson from hkp server pgp.mit.edu (1) Kelvin Goodson [EMAIL PROTECTED] 1024 bit DSA key 96324791, created: 2006-10-17 yeh - it is now on the major networks. sometimes it takes a while to sync or it's possible that i made mistake in the cut and paste :-/ but all's well now - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
On 11/7/06, David E Jones [EMAIL PROTECTED] wrote: On Nov 5, 2006, at 3:52 AM, robert burrell donkin wrote: On 11/2/06, David E Jones [EMAIL PROTECTED] wrote: The OFBiz podling (PPMC and community) has reached a consensus internally approving the 4.0.0 TS5 test snapshot release. We are now requesting a vote for review and approval from the general Incubator group and the Incubator PMC. +0 ATM (i have a couple of questions) i'm now (reluctantly) +1 (see comments below) snip http://svn.apache.org/repos/asf/incubator/ofbiz/trunk/framework/ workflow/dtd/xpdl.dtd may not be under an open source compatible license (note that modification is not explicitly allowed but all rights are not restricted). standard DTDs are a difficult subject: many licenses used are not open source compatible. may need to ask on legal. i think that a clean room implementation of the DTD from the specification under the apache license (if that is possible) may be easier and quicker than untangling the legal issues. same goes for http://svn.apache.org/repos/asf/incubator/ofbiz/trunk/framework/ workflow/dtd/xpdl.xsd and http://svn.apache.org/repos/asf/incubator/ofbiz/trunk/framework/ shark/dtd/TC-1025_schema_10_xpdl.xsd would this be possible? I read through the stuff on the 3party.html page you referenced and I think if this does become the case there is an easy way we can handle it. While it may be a little inconvenient we can remove these files and refer to them in locations publicly available via the internet. This way we can refer to them, but not include them. Would that solve the problem? probably IMHO it's worth considering creating clean room implementations in the medium term (or lobbying for an open source compatible license) ofbiz.jar does not contain LICENSE and NOTICE in it's META-INF. so this jar cannot be distributed as a bare artifact. for example, this means that it cannot be distributed through the maven repository. do you intend to ban distribution by maven? I'm not sure what this would/should look like, and honestly hadn't considered the distribution of these jars through a Maven repository/ server. The ofbiz.jar isn't really of any use on its own and is just an executable place holder that loads other stuff in OFBiz. For distribution in Maven would every jar in OFBiz have to include the NOTICE and LICENSE files? We could certainly do this by just changing the ant scripts. yes - every apache jar that is released by itself would need NOTICE and LICENSE files On a side note, is this getting in the way of the voting process for this Test Snapshot release? possibly AFAIC the substantive issue is the xsd's without open source licenses but IMHO this is a marginal case. the license is missing from the LICENSE file. apache has traditionally issued aggregate binary releases containing redistributable binary components which are not open source but does not include source under restrictive licenses. xsd's are a difficult corner case. much better to create clean room implementations. since this is an incubator release and there seems no substantial legal risk i'm going to +1 but i trust that the mentors will see that this issue is resolved before graduation. I've notice that no one else has really voted on it yet. that's not unusual. unfortunately, checking releases takes IPMC energy which is in limited supply. i run RAT (which is quicker) but there's still quite a deal of time talen by offering explanations. mentors really need to cast their votes - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
Hi, On 11/7/06, robert burrell donkin [EMAIL PROTECTED] wrote: The OFBiz podling (PPMC and community) has reached a consensus internally approving the 4.0.0 TS5 test snapshot release. We are now requesting a vote for review and approval from the general Incubator group and the Incubator PMC. +1 from me. AFAIC the substantive issue is the xsd's without open source licenses but IMHO this is a marginal case. the license is missing from the LICENSE file. apache has traditionally issued aggregate binary releases containing redistributable binary components which are not open source but does not include source under restrictive licenses. xsd's are a difficult corner case. much better to create clean room implementations. So would you recommend OFBiz copy the XSD and relicense it to ASL 2.0? since this is an incubator release and there seems no substantial legal risk i'm going to +1 but i trust that the mentors will see that this issue is resolved before graduation. It's on my (very) short list of remaining OFBiz issues to handle before calling a graduation vote. mentors really need to cast their votes - robert Mine was cast on [EMAIL PROTECTED], casting here again for clarity and ease of IPMC viewing. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Retire AltRMI
+1 Move to retirement --- Noel smime.p7s Description: S/MIME cryptographic signature
RE: [VOTE] Retire AltRMI
Yoav Shapira wrote: am in favor of fall/spring/periodic cleanups in general. +1 Would be happy if people would help select some other candidates. I would not be at ease retiring a project without hearing from its mentor, who's yet to vote on this thread. It is such an old project it predates the notion, but Paul has several times suggested retirement. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Retire AltRMI
Hi, On 11/7/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Yoav Shapira wrote: am in favor of fall/spring/periodic cleanups in general. +1 Would be happy if people would help select some other candidates. I would not be at ease retiring a project without hearing from its mentor, who's yet to vote on this thread. It is such an old project it predates the notion, but Paul has several times suggested retirement. Great. Thank you Noel for clarifying, and thanks Paul for explaining much the same in your vote post. +1 from me now. As for suggesting other retirement candidates, I'll take a look. How's WSRP4J going? Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarification on SF license and sandboxes
On 11/6/06, Henri Yandell [EMAIL PROTECTED] wrote: On 11/6/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 11/6/06, Henri Yandell [EMAIL PROTECTED] wrote: I'm still confused - why do we allow people to upload attachments that are not intended for inclusion? I can see one very reasonable reason from a user point of view - the example they want to upload is business related and so they want to do their best to explain the problem to us, but not to have us publish those details any further. However that reason doesn't hold up as it's public if it's in our JIRA and if we don't know the license on it, then can we even use it to resolve the issue? What makes an attachment special? Why don't we have to do this for comments and the jira issue itself? Not seeing why we don't just say: All issues + attachments are intended for inclusion. There's a difference between I don't want to contribute this code to the project code base versus I don't want my code published. The no option means the code is not for inclusion into the project. It doesn't necessarily mean that the code is confidential. What does 'not for inclusion' mean though? It's probably better to ask this question on the infra@ list, since it's a lot more likely that the discussion surrounding the explicit addition of this checkbox happened there rather than here. I'm sure you'd rather have a definitive answer rather than lots of pure speculation. ;-) -- Martin Cooper If it's marked that way, can I take bits of the code out of it? Do I have to worry about looking at that code and then implementing something in the apache code that does the same thing and getting sued? For example, what if someone posts a bit of Sun's Java source to the Harmony JIRA and marks it 'not for inclusion'. There's a world of meaning in that not for inclusion flag. What's in it for the ASF to have a not for inclusion option? I'm not seeing why we allow it - better to say Anything here is for inclusion. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
