Re: status of PGP support in Maven
On Mon, Oct 6, 2008 at 10:45 AM, Henning Schmiedehausen [EMAIL PROTECTED] wrote: On Fri, 2008-10-03 at 12:31 -0400, Noel J. Bergman wrote: We don't have to. We can simply mandate that every ASF project sign their artifacts and charge the Maven PMC with enforcing it. No. The Maven PMC is charged with developing software for the Apache Maven project. If we really want to put a distribution policy in place and enforce it, I can see us creating a repository PMC which does this (and talk to Maven about the features that they would like to see or (gasp!) implement them and contribute them back to Maven. I would see such a PMC as part of or collaborating with Infrastructure. I thought this effort was started years and years ago... Maven is a piece of software, not a distribution mechanism. They just happen to build it because no one else did. And perhaps now you start to gain a glimer of the depth of the problem created by Maven's irresponsible, unconscionable, lackadaisical, attitude towards security, despite other repository exemplars (e.g., linux distributions), having had security in place for years. Yes, it may be a Please stop it, Noel. This is not constructive. Being in the camp I hate Maven too, I must say I agree with Henning that the language used was inappropriate. I would like to swap Noel's statement around and ask; Why doesn't security concerned individuals participate in the Maven effort? Lead by example and not by bashing... Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allow incubator releases? [was: way too wordy]
On Mon, Oct 6, 2008 at 10:21 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Drop any pretense that the incubator has a say over the already-done code releases, and we can seriously start the real discussion, which would have been motivating projects to graduate if we hadn't wasted several hundred posts on a silly topic. Uhhh... I might misunderstand your English here (mine ain't that refined); Are you suggesting that the Incubator PMC has no say over code releases of podlings? My stance is still; Releases from the Incubator are ASF releases of code, no different than another PMC. IMHO, the disclaimers are not helping anyone, not the podling, not the IPMC, not the downstream projects, not the public, not the repository management, not the tool chain... So, I still think; WTFing Point? Now, we can deal with such situation in two possible ways; * Accept that projects eventually dies, and that everyone downstream needs to deal with that, and that downstream users are capable of basic SWOT analysis and let podlings release as much as they want. I would like (as a Maven user) the groupId in Maven artifacts to be org.apache.incubator.podling until the graduation occurs. * Not accept podlings to release code. Possibly having the final act of the podling to do a release, which effectuates the graduation. I am Ok with either of these, since I think that downstream users ain't stupid and more capable than I think we give them credit for. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allow incubator releases?
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Niclas Hedhman wrote: I will support the initial intent of no releases out of Incubator. Which would work, except for the fact that the incubator decided it's a good idea to have podlings demonstrate how releases work in a meritocracy. Sure they've grokked vetoes over code, but the majority-vote release schema is nearly at odds with that. It's good that they demonstrate the entire cycle of envisioning ... creating ... collecting ... releasing code as a community. +1 So this is a better schema. Drop any pretense that the incubator has a say over the already-done code releases, and we can seriously start the real discussion, which would have been motivating projects to graduate if we hadn't wasted several hundred posts on a silly topic. This is simple, people. This is what mentors are for. When the PMC submits the board report, someone should mark the ones that need motivating and task the mentors with doing so. If the mentors can't (which is fine, we're all volunteers here), then delegate to someone who can. As for motivation, escaping the neverending threads on this mailing list should be encouragement enough. -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] accept Droids into incubation
Thorsten Scherler [EMAIL PROTECTED] writes: Please vote on accepting Droids into incubation. +1 -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL - OpenWebBeans Project Proposal]
On Oct 3, 2008, at 4:48 PM, Gurkan Erdogdu wrote: Hi to all; I have posted a proposal about the project, named OpenWebBeans. It is in the WIKI, its address is http://wiki.apache.org/incubator/OpenWebBeansProposal I made a few minor editorial updates (spelling/grammar) and one wording change Geronimo will include == Geronimo may include. Can you point us to the current project? I couldn't find it on sourceforge. Last I recall Guice was planning on an Apache licensed WebBeans implementation. Is that still their plan? Any discussions with their project? --kevan
Re: status of PGP support in Maven
On Fri, Oct 3, 2008 at 8:01 PM, Henning Schmiedehausen [EMAIL PROTECTED] wrote: On Fri, 2008-10-03 at 11:20 -0400, Noel J. Bergman wrote: Henning Schmiedehausen wrote: There is a pretty nice proposal on http://people.apache.org/~henkp/trust/, however this will again take a piece of freedom of doing software at Apache away and introduce some administrative overhead that all projects must implement and manage. But, as you say, it is worth doing something, whether exactly that or not, because Formalizing the signing of our releases would be a huge step towards a reliable validation for the Apache software releases. It still does not help you with third-party releases, though. Is it our problem if you mean a third party, e.g., IBM, releasing our code as part of their own commercial product? Actually I meant verifying/validating the third party dependencies that Apache projects *use*. So even if we go through all the pains of making sure that our users really get apache-baz-1.0, it might just pull in some-random-dependency-from-sourceforge-1.0 which can not be validated. Ciao Henning There are maven plugins that can validate the checksums of 3rd party dependencies. Works well as long as: A) You can trust that your apache-baz-1.0 source has not been tampered with. B) The dependency had not been tampered with at the time that the dependency was first added to the build. (Since that's when the expected checksum is calculated) Problem A: is universal to all builds at apache even if it's a maven based or make based build. I guess this is what the GPG discussion is about. Problem B: Could be further reduced if the 3rd party used some type signing to help the apache developers validate that the 3rd party artifact is indeed authentic. If dependency checksum validation was encouraged by all our source builds, I think Problem B would become even less of a problem because you would get a network effect between all the source builds. As more more projects add a 3rd party dependency validated by a checksum, it becomes harder to exploit that 3rd party dependency as the artifact checksum gets checked by more and more builds. Tampering with the artifact would result some builds builds breaking and folks investigating the tampering. Therefore the most effective way to tamper with a 3rd party artifact would be to do it when the 3rd party artifact first gets deployed. So in effect we reduce the vulnerability window that exploits are effective in, which I think helps. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: status of PGP support in Maven
Niclas Hedhman wrote: Being in the camp I hate Maven too I hate Maven's lack of authentication, the potential for widespread damage, and am immensely frustrated by their *years* of willfully negligent handling thereof. I would like to swap Noel's statement around and ask; Why doesn't security concerned individuals participate in the Maven effort? Lead by example and not by bashing... They have received constructive input for years. They continue to do so. Jason's comments appear to echo the old-school negligence that I'd hoped the Maven PMC was at long last starting to be cured of. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of PGP support in Maven
Note that problem A and B both occur at manual steps in the build/development process. Just wanted to point that out to folks who complain that maven is insecure because it downloads stuff automatically. With checksums, as long as the manual steps are secure, automated bits should be secure too. Regards, Hiram There are maven plugins that can validate the checksums of 3rd party dependencies. Works well as long as: A) You can trust that your apache-baz-1.0 source has not been tampered with. B) The dependency had not been tampered with at the time that the dependency was first added to the build. (Since that's when the expected checksum is calculated) Problem A: is universal to all builds at apache even if it's a maven based or make based build. I guess this is what the GPG discussion is about. Problem B: Could be further reduced if the 3rd party used some type signing to help the apache developers validate that the 3rd party artifact is indeed authentic. If dependency checksum validation was encouraged by all our source builds, I think Problem B would become even less of a problem because you would get a network effect between all the source builds. As more more projects add a 3rd party dependency validated by a checksum, it becomes harder to exploit that 3rd party dependency as the artifact checksum gets checked by more and more builds. Tampering with the artifact would result some builds builds breaking and folks investigating the tampering. Therefore the most effective way to tamper with a 3rd party artifact would be to do it when the 3rd party artifact first gets deployed. So in effect we reduce the vulnerability window that exploits are effective in, which I think helps. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL - OpenWebBeans Project Proposal]
Hi Kevan, Matthias; The project current code base is in the sourceforge -- http://bigfaces.svn.sourceforge.net/viewvc/bigfaces/webbeansimpl/. I am developing the remaining pieces of the specification continuously. About Implementation : So far, only Web Beans specification that is published is EDR-1, in this EDR-1 there is no API contract of the specification. So when I started to implement the specification, I created my own API. But now, I looked at the http://seamframework.org/WebBeans address and it defines the API contracts and some of the concerns explained in the EDR-1 are changed. I am trying to adapted my implemented API contracts with this unpublished API. I explicitly commented on these changes in the source code. I think there is no so much differences. There are two folder in the implementation, webbeans-api is the API and webbeans-impl is the implementation. All the unit test are contained in the webbeans-impl folder. Thanks; Gurkan - Original Message From: Matthias Wessendorf [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Monday, October 6, 2008 3:34:34 PM Subject: Re: [PROPOSAL - OpenWebBeans Project Proposal] On Mon, Oct 6, 2008 at 2:30 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 4:48 PM, Gurkan Erdogdu wrote: Hi to all; I have posted a proposal about the project, named OpenWebBeans. It is in the WIKI, its address is http://wiki.apache.org/incubator/OpenWebBeansProposal I made a few minor editorial updates (spelling/grammar) and one wording change Geronimo will include == Geronimo may include. Can you point us to the current project? I couldn't find it on sourceforge. Last I recall Guice was planning on an Apache licensed WebBeans implementation. Is that still their plan? Any discussions with their project? really ? Interesting. The JBoss WebBeans RI is Apache 2.0 licensed as well (and it looks like their TCK will be as well) See here: http://seamframework.org/WebBeans -Matthias --kevan -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: status of PGP support in Maven
On Mon, 2008-10-06 at 10:21 -0400, Noel J. Bergman wrote: Henning Schmiedehausen wrote: Noel J. Bergman wrote: We don't have to. We can simply mandate that every ASF project sign their artifacts and charge the Maven PMC with enforcing it. No. The Maven PMC is charged with developing software for the Apache Maven project. You misunderstand. I mean that the Maven code should enforce authentication, not that the Maven PMC must police the repository. Maven is a modular framework. If you want to enforce such policy, it should be possible to write plugins to do so. All that is needed is someone to write them or fund writing. The current Maven group seems to feel that they don't need them or they are not high on the prio list. So someone else must do it. This is a do-ocracy. :-) If we really want to put a distribution policy in place and enforce it, I can see us creating a repository PMC which does this We already have that as a subgroup of Infrastructure. The [EMAIL PROTECTED] list has existed for *years*. I know. So why are you bashing the Maven PMC when you mean the repository management group? Ciao Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] accept Droids into incubation
+1 On Thu, 2008-10-02 at 22:00 +0200, Thorsten Scherler wrote: Please vote on accepting Droids into incubation. The proposal can be found at: http://wiki.apache.org/incubator/DroidsProposal The text of the proposal = Droids, an intelligent standalone robot framework = === Abstract === Droids aims to be an intelligent standalone robot framework that allows to create and extend existing droids (robots). === Proposal === As a standalone robot framework Droids will offer infrastructure code to create and extend existing robots. In the future it will offer as well a web based administration application to manage and controll the different droids which will communicate with this app. Droids makes it very easy to extend existing robots or write a new one from scratch, which can automatically seek out relevant online information based on the user's specifications. Since the flexible design it can reuse directly all custom business logic that are written in java. In the long run it should become umbrella for specialized droids that are hosted as sub-projects. Where an ultimate goal is to integrate an artificial intelligence that can control a swarm of droids and actively plan/react on different tasks. === Background === The initial idea for the Droids project was voiced in February 2007 from Thorsten Scherler mainly because of personal curiosity and developed as a labs project. The background of his work was that Cocoon trunk (2.2) did not provide a crawler anymore and Forrest was based on it, meaning we could not update anymore till we found a crawler replacement. Getting more involved in Solr and Nutch he saw the request for a generic standalone crawler. For the first version he took nutch, ripped out and modified the plugin/extension framework. However the second version were not based on it anymore but was using Spring instead. The main reason was that Spring has become a standard and helped to make Droids as extensible as possible. Soon the first plugins and sample droids had been added to the code based. === Rationale === There is ever more demand for tools that automatically do determinate tasks. Search engines such as Nuts are normally very focused on a specific functionality and are not focused on extensibility. Furthermore there are manly focused on crawling, requesting certain pages and extract links to other pages, which in our opinion is only one small area for automated robots. While there are a number of existing crawler libraries for various task, each of them comes with a custom API and there are no generic interface for automatically determining which crawler (droids) to use for a specific task. The Droids project attempts to remove this duplication of efforts. We believe that by pooling the efforts of multiple projects we will be able to create a generic robot framework that exceeds the capabilities and quality of the custom solutions of any single project. The focus of Droids is not a single crawler but more to offer different reusable components that custom droids (robots) can use to automate certain tasks. An intelligent standalone robot framework project will not only provide common ground for the developers of crawler but as well for any other automated application (robots) libraries. === Initial Goals === The initial goals of the proposed project are: * Viable community around the Droids codebase * Active relationships and possible cooperation with related projects and communities (e.g. reusing Tika for text extraction) * Generic robot API for crawling, extracting structured text content and/or new task, filtering task and handle the content * Flexible extension and plugin development to create a wide range of functionality * Fuel develop of various droids and bring the current wget style crawler to state-of-the-art level == Current Status == === Meritocracy === All the initial committers are familiar with the meritocracy principles of Apache, and have already worked on the various source codebases. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is not yet a clear Droids community. Instead we have a number of people and related projects with an understanding that an intelligent standalone robot framework project would best serve everyone's interests. The primary goal of the incubating project is to build a self-sustaining community around this shared vision. === Core Developers === The initial set of developers comes from various backgrounds, with different but compatible needs for the proposed project. === Alignment === As a generic robot framework Droids will likely be widely used by various open source and commercial projects both together with and independent of other Apache tools. Apache projects like Cocoon, Lenya and Forrest are potential candidates for using different
Fw: OpenWebBeans
Hi Conny, Its great, and thanks for interesting about the proposal. I have just sent the source code of the implementation sourceforge addresses to the this group (It is http://bigfaces.svn.sourceforge.net/viewvc/bigfaces/webbeansimpl/). Lets discuss the things about the implementation and spec here. If you have any questions about the source code or any other, I would like to answer happily. Cheers; Gurkan - Forwarded Message From: Conny Lundgren [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 6, 2008 8:21:53 PM Subject: OpenWebBeans Hi My name is Conny, and I currently serve on the EG for JSR299. I think your proposal is interesting, and if needed I could possibly contribute to the development of the implementation. Regards, Conny
Re: Allow incubator releases? [was: way too wordy]
Niclas Hedhman wrote: On Mon, Oct 6, 2008 at 10:21 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Drop any pretense that the incubator has a say over the already-done code releases, and we can seriously start the real discussion, which would have been motivating projects to graduate if we hadn't wasted several hundred posts on a silly topic. Uhhh... I might misunderstand your English here (mine ain't that refined); Are you suggesting that the Incubator PMC has no say over code releases of podlings? Pretty much, that's it. The code is voted released by the Incubator PMC under the Apache License. The ASF places exactly those AL limits on the code (very few) and enforces those limits, alone. To have a successful release vote, we have lots of extra rules, such as how the Podling vote happens, the IPMC vote ratifies it, rat and other methods validate that the copyrights, licenses and such line up, that there is a DISCLAIMER in the package, etc. If preconditions don't happen they won't have the successful release vote they wanted. The Incubator PMC has a strong say over what appears on incubator.a.o/* pages, what is added to or revoked from www.a.o/dist/incubator/*, and so forth and so on. But that's the extent. Postconditions that aren't in the license don't exist. You can't say Commercial use is disallowed, and so forth. My stance is still; Releases from the Incubator are ASF releases of code, no different than another PMC. IMHO, the disclaimers are not helping anyone, not the podling, not the IPMC, not the downstream projects, not the public, not the repository management, not the tool chain... So, I still think; WTFing Point? Well we could drop the DISCLAIMER requirement, that's another thread entirely :) Now, we can deal with such situation in two possible ways; * Accept that projects eventually dies, and that everyone downstream needs to deal with that, and that downstream users are capable of basic SWOT analysis and let podlings release as much as they want. I would like (as a Maven user) the groupId in Maven artifacts to be org.apache.incubator.podling until the graduation occurs. * Not accept podlings to release code. Possibly having the final act of the podling to do a release, which effectuates the graduation. I am Ok with either of these, since I think that downstream users ain't stupid and more capable than I think we give them credit for. How about a brand new idea? Lay down a Milestone-style chart of what it takes to operate as an ASF project. Demonstrate community of meritocracy, add committers or ppmc members based on contributions, complete IP review, and then... and only then... they hit the release milestone. One or two releases later, they are ejected from the Incubator - either to the target PMC or as a TLP. So releases would reflect the project is probably ready to graduate, the only difference would be that the incubator PMC wants to see this done right before calling the podling baked. WDYT? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL - OpenWebBeans Project Proposal]
I am part of the EG, but I can't share the draft PDFs. You need a NDA for that. -M On Mon, Oct 6, 2008 at 8:27 PM, Gurkan Erdogdu [EMAIL PROTECTED] wrote: Hi Kevan, Matthias; The project current code base is in the sourceforge -- http://bigfaces.svn.sourceforge.net/viewvc/bigfaces/webbeansimpl/. I am developing the remaining pieces of the specification continuously. About Implementation : So far, only Web Beans specification that is published is EDR-1, in this EDR-1 there is no API contract of the specification. So when I started to implement the specification, I created my own API. But now, I looked at the http://seamframework.org/WebBeans address and it defines the API contracts and some of the concerns explained in the EDR-1 are changed. I am trying to adapted my implemented API contracts with this unpublished API. I explicitly commented on these changes in the source code. I think there is no so much differences. There are two folder in the implementation, webbeans-api is the API and webbeans-impl is the implementation. All the unit test are contained in the webbeans-impl folder. Thanks; Gurkan - Original Message From: Matthias Wessendorf [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Monday, October 6, 2008 3:34:34 PM Subject: Re: [PROPOSAL - OpenWebBeans Project Proposal] On Mon, Oct 6, 2008 at 2:30 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 4:48 PM, Gurkan Erdogdu wrote: Hi to all; I have posted a proposal about the project, named OpenWebBeans. It is in the WIKI, its address is http://wiki.apache.org/incubator/OpenWebBeansProposal I made a few minor editorial updates (spelling/grammar) and one wording change Geronimo will include == Geronimo may include. Can you point us to the current project? I couldn't find it on sourceforge. Last I recall Guice was planning on an Apache licensed WebBeans implementation. Is that still their plan? Any discussions with their project? really ? Interesting. The JBoss WebBeans RI is Apache 2.0 licensed as well (and it looks like their TCK will be as well) See here: http://seamframework.org/WebBeans -Matthias --kevan -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenWebBeans
Hi Bill; Thanks for considering about the proposal. This is the seperate effort from the Gavin King. Actually, I have requested from the Gavin to add me as an observer to the working group, I haven't received any response. I changed the wrong term *JEE* from the proposal. Sincerely; Gurkan - Original Message From: Bill Shannon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 6, 2008 9:57:15 PM Subject: OpenWebBeans Hi Gurkan. I saw your proposal at Apache: http://wiki.apache.org/incubator/OpenWebBeansProposal Are you working with Gavin King on this, or is this a completely separate effort? Also, please do me a favor and fix the JEE references. There is no JEE. *Never* use that name. JEE 6.0 should be Java EE 6, and JEE should be Java EE everywhere. http://www.java.com/en/about/brand/naming.jsp http://www.theserverside.com/news/thread.tss?thread_id=35561 Thanks. Bill Shannon Java EE Spec Lead
Re: [Vote] accept Droids into incubation
+1 Regards, Alan On Oct 2, 2008, at 1:00 PM, Thorsten Scherler wrote: Please vote on accepting Droids into incubation. The proposal can be found at: http://wiki.apache.org/incubator/DroidsProposal The text of the proposal = Droids, an intelligent standalone robot framework = === Abstract === Droids aims to be an intelligent standalone robot framework that allows to create and extend existing droids (robots). === Proposal === As a standalone robot framework Droids will offer infrastructure code to create and extend existing robots. In the future it will offer as well a web based administration application to manage and controll the different droids which will communicate with this app. Droids makes it very easy to extend existing robots or write a new one from scratch, which can automatically seek out relevant online information based on the user's specifications. Since the flexible design it can reuse directly all custom business logic that are written in java. In the long run it should become umbrella for specialized droids that are hosted as sub-projects. Where an ultimate goal is to integrate an artificial intelligence that can control a swarm of droids and actively plan/react on different tasks. === Background === The initial idea for the Droids project was voiced in February 2007 from Thorsten Scherler mainly because of personal curiosity and developed as a labs project. The background of his work was that Cocoon trunk (2.2) did not provide a crawler anymore and Forrest was based on it, meaning we could not update anymore till we found a crawler replacement. Getting more involved in Solr and Nutch he saw the request for a generic standalone crawler. For the first version he took nutch, ripped out and modified the plugin/extension framework. However the second version were not based on it anymore but was using Spring instead. The main reason was that Spring has become a standard and helped to make Droids as extensible as possible. Soon the first plugins and sample droids had been added to the code based. === Rationale === There is ever more demand for tools that automatically do determinate tasks. Search engines such as Nuts are normally very focused on a specific functionality and are not focused on extensibility. Furthermore there are manly focused on crawling, requesting certain pages and extract links to other pages, which in our opinion is only one small area for automated robots. While there are a number of existing crawler libraries for various task, each of them comes with a custom API and there are no generic interface for automatically determining which crawler (droids) to use for a specific task. The Droids project attempts to remove this duplication of efforts. We believe that by pooling the efforts of multiple projects we will be able to create a generic robot framework that exceeds the capabilities and quality of the custom solutions of any single project. The focus of Droids is not a single crawler but more to offer different reusable components that custom droids (robots) can use to automate certain tasks. An intelligent standalone robot framework project will not only provide common ground for the developers of crawler but as well for any other automated application (robots) libraries. === Initial Goals === The initial goals of the proposed project are: * Viable community around the Droids codebase * Active relationships and possible cooperation with related projects and communities (e.g. reusing Tika for text extraction) * Generic robot API for crawling, extracting structured text content and/or new task, filtering task and handle the content * Flexible extension and plugin development to create a wide range of functionality * Fuel develop of various droids and bring the current wget style crawler to state-of-the-art level == Current Status == === Meritocracy === All the initial committers are familiar with the meritocracy principles of Apache, and have already worked on the various source codebases. We will follow the normal meritocracy rules also with other potential contributors. === Community === There is not yet a clear Droids community. Instead we have a number of people and related projects with an understanding that an intelligent standalone robot framework project would best serve everyone's interests. The primary goal of the incubating project is to build a self-sustaining community around this shared vision. === Core Developers === The initial set of developers comes from various backgrounds, with different but compatible needs for the proposed project. === Alignment === As a generic robot framework Droids will likely be widely used by various open source and commercial projects both together with and independent of other Apache tools. Apache projects like Cocoon, Lenya and Forrest are potential candidates for using different droids as an embedded component. == Known Risks == === Orphaned
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Wed, Sep 24, 2008 at 3:40 PM, Jukka Zitting [EMAIL PROTECTED] wrote: This is a slight majority (of binding votes) for accepting the proposed change, but given the clear lack of consensus and the concerns voiced about that, I unfortunately need to conclude that this issue should be tabled until better consensus is reached. The followup discussion seems to be running in circles, with no clear compromises or alternative solutions being presented. Meanwhile a few opponents of this proposal have mentioned that their opinion has changed and a few others that they'd accept the majority decision and that we should move on. So, unless within a week from now we start seeing constructive efforts at forming an alternative policy (or clarifying the current undocumented policy) that we could vote on, I will declare this vote as passing and implement the proposed change based on the measured majority. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenWebBeans
Gurkan Erdogdu wrote: Hi Bill; Thanks for considering about the proposal. This is the seperate effort from the Gavin King. Actually, I have requested from the Gavin to add me as an observer to the working group, I haven't received any response. I changed the wrong term *JEE* from the proposal. Thanks! It's always good to have multiple implementations of a spec so I'll be interested to see how this progresses. Note that Gavin has been doing significant work on the Web Beans spec recently and a new draft should be available soon. You might want to update the text of your proposal to align with the new draft once it's available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenWebBeans
unfortunately the complete java *community* process isn't that open. So, the update of the proposal needs to wait a bit... until the spec draft is accessible for common people. IMO the update isn't really required at all. We just discuss here if such a project is interesting in Apache land or not. IMO that proposal doesn't need to match 100% of the latest (un-published) spec drafts :-) -M On Mon, Oct 6, 2008 at 9:46 PM, Bill Shannon [EMAIL PROTECTED] wrote: Gurkan Erdogdu wrote: Hi Bill; Thanks for considering about the proposal. This is the seperate effort from the Gavin King. Actually, I have requested from the Gavin to add me as an observer to the working group, I haven't received any response. I changed the wrong term *JEE* from the proposal. Thanks! It's always good to have multiple implementations of a spec so I'll be interested to see how this progresses. Note that Gavin has been doing significant work on the Web Beans spec recently and a new draft should be available soon. You might want to update the text of your proposal to align with the new draft once it's available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] apache-empire-db-2.0.4-incubating and apache-empire-struts2-ext-1.0.4-incubating release, 2nd round
On Fri, Oct 3, 2008 at 1:27 PM, sebb [EMAIL PROTECTED] wrote: Wherever the additional license files are placed, they need to be referenced from the main LICENSE file. I'm not sure where you get this from. This is the first time I hear this requirement. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] apache-empire-db-2.0.4-incubating and apache-empire-struts2-ext-1.0.4-incubating release, 2nd round
Martijn Dashorst wrote: On Fri, Oct 3, 2008 at 1:27 PM, sebb [EMAIL PROTECTED] wrote: Wherever the additional license files are placed, they need to be referenced from the main LICENSE file. I'm not sure where you get this from. This is the first time I hear this requirement. there : http://www.apache.org/dev/release.html#distributing-code-under-several-licenses -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Pig graduation to hadoop subproject
Pig Developers and Mentors, Pig has been incubating for over a year now. In this period of time, we had extended our community with 2 new committers, had a release, resolved 300 issues. We have made some significant code improvements including pipeline redesign, addition of streaming and limit functionality, grunt shell improvements and significant performance speedup. We have a constant traffic and lively discussions on both pig-dev and pig-user mailing lists and we conduct our business in the open by publishing proposals and discussing them in the mailing lists. As of now, we have completed graduation requirements as described in http://incubator.apache.org/guides/graduation.html. I would like to call for a graduation vote at this time. I would also propose that we graduate as a subproject of Hadoop. There are several advantages to this approach. First, this would allow us to extend both our user and developer base. Second, it would bring benefits to the Hadoop community by providing a higher level interface and easier entry point for new users. Third, having an established project to provide guidance, would help Pig to become a mature participant in the open source community. Please, vote by the end of the day on Thursday, 10/9. Thanks, Olga PS: I am ccing hadoop and incubator general mailing lists; however, no action is required from them at this time. This step is for Pig community only.
Graduation Checklist , was Re: [VOTE] Pig graduation to hadoop subproject
On Mon, Oct 6, 2008 at 3:32 PM, Olga Natkovich [EMAIL PROTECTED] wrote: Pig Developers and Mentors, Pig has been incubating for over a year now. In this period of time, we had extended our community with 2 new committers, Has this list been updated recently ? Does it reflect the current list of committers ? [1] http://incubator.apache.org/pig/whoweare.html As of now, we have completed graduation requirements as described in http://incubator.apache.org/guides/graduation.html. Have you guys looked at the Creating an Open and Diverse community section on the graduation checklist ? -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Graduation Checklist , was Re: [VOTE] Pig graduation to hadoop subproject
-Original Message- From: Luciano Resende [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2008 4:11 PM To: general@incubator.apache.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Graduation Checklist , was Re: [VOTE] Pig graduation to hadoop subproject On Mon, Oct 6, 2008 at 3:32 PM, Olga Natkovich [EMAIL PROTECTED] wrote: Pig Developers and Mentors, Pig has been incubating for over a year now. In this period of time, we had extended our community with 2 new committers, Has this list been updated recently ? Does it reflect the current list of committers ? [1] http://incubator.apache.org/pig/whoweare.html Yes, the document is up-to-date. As of now, we have completed graduation requirements as described in http://incubator.apache.org/guides/graduation.html. Have you guys looked at the Creating an Open and Diverse community section on the graduation checklist ? Yes, and I think we satisfied these requirements. -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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: status of PGP support in Maven
On Mon, Oct 6, 2008 at 10:08 PM, Hiram Chirino [EMAIL PROTECTED] wrote: There are maven plugins that can validate the checksums of 3rd party dependencies. Uhhh... Call me stupid, but how can checksum solve anything other than assuring that the download worked?? AFAIK, Maven does not pick up the checksums from the authorative server and validates it against the mirrored one. Perhaps that has changed since back then... And even then, how hard can it be to get the same 1024/2048/65536/... bit checksum by modifying that many 'extra' or 'unused' bits? Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of PGP support in Maven
On 6-Oct-08, at 10:21 AM, Noel J. Bergman wrote: Niclas Hedhman wrote: Being in the camp I hate Maven too I hate Maven's lack of authentication, the potential for widespread damage, and am immensely frustrated by their *years* of willfully negligent handling thereof. I would like to swap Noel's statement around and ask; Why doesn't security concerned individuals participate in the Maven effort? Lead by example and not by bashing... They have received constructive input for years. They continue to do so. Jason's comments appear to echo the old-school negligence that I'd hoped the Maven PMC was at long last starting to be cured of. Noel, your comments are completely out of whack with reality. You are asking Maven to enforce something that no one does. Pretty much almost no one. Downloads from our own servers: 57.47% archive.apache.org 40.72% www.apache.org ... almost all are zip's and [.tar].gz's (see extensions report) 92.72% .zip [Zip archives] 2.10% .gz [Gzip compressed files] 2.05% .tar.gz [Compressed archives] 0.1% .asc (not even listed) Almost no one is validating PGP signatures. It's not that we couldn't in the past, we just had to choose to implement features that delivered what our users wanted. Checking PGP signatures is obviously not something the vast majority of people do. So pointing your finger at us and calling it negligence is not even remotely correct. The same goes the checksums which people also don't check but Maven does this automatically so we are, in fact, providing a greater degree of security to the average user. By default as a big warning message appears and you can optionally fail builds if the checksum fails. After having a discussion with Henk about the nature of PGP usage and checksums I share his sentiments which he has allowed me to quote: -- In the past I have maintained that the most important reason to sign stuff is to protect the /ASF/ (as opposed to downloaders). People trust the ASF to detect malware (trojans etc) and react upon detection. For downloaders, a simple md5 check should be sufficient. The ASF should be as cautious/suspicious as the most cautious/suspicious downloader imaginable. Are we ? -- Another reason: one day some computer science class is going to compare various open-software centers (like the ASF) on how well such centers protect themselves against malware. The ASF should be examplary. Are we ? When Mercury is integrated into Maven and people can optionally fail builds on failed PGP sig validation Maven will again provide a greater degree of security given that the practice of validating sigs is pretty much non-existent. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Allow incubator releases? [was: way too wordy]
On Tue, Oct 7, 2008 at 2:45 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: How about a brand new idea? Lay down a Milestone-style chart of what it takes to operate as an ASF project. Demonstrate community of meritocracy, add committers or ppmc members based on contributions, complete IP review, and then... and only then... they hit the release milestone. One or two releases later, they are ejected from the Incubator - either to the target PMC or as a TLP. So releases would reflect the project is probably ready to graduate, the only difference would be that the incubator PMC wants to see this done right before calling the podling baked. Works for me, although you say nothing about whether that release is an ASF release or not. IMHO, it is an Incubator PMC release, just like any other PMC operated umbrella project. ;-) Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. On 6-Oct-08, at 10:22 AM, Noel J. Bergman wrote: Jason van Zyl wrote: The discussions are taking place on the Maven PMC list. If you are a member you can join the list. Why are those discussions taking place on a private, closed, list instead of an open one? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl [EMAIL PROTECTED] wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. Yes, although the PMC is expected to do all non-sensitive discussion on the public dev@ list. But, so far I think the central repo has served the Java communities (not only Apache) very well. It allows sync'ing from other repository hosts, which has made life a lot easier for smaller projects. That said, I think that Maven should move away from a central repository, and instead go with distributed ones and possibly harness the power of search engines (Yahoo RDF?) to locate stuff everywhere. To be able to do that securely, some clever security mechanisms must first be developed, and since that is in line with security-concerned people, I think it is a good thing to do so. How hard can it be?, considering the expertise around detailing the requirements almost at code level, right ;-) ? Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 7-Oct-08, at 12:02 AM, Niclas Hedhman wrote: On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl [EMAIL PROTECTED] wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. Yes, although the PMC is expected to do all non-sensitive discussion on the public dev@ list. But, so far I think the central repo has served the Java communities (not only Apache) very well. It allows sync'ing from other repository hosts, which has made life a lot easier for smaller projects. That said, I think that Maven should move away from a central repository, and instead go with distributed ones and possibly harness the power of search engines (Yahoo RDF?) to locate stuff everywhere. This is already possible with Nexus (http://nexus.sonatype.org). Nexus, or the Nexus CLI tool, produces a Lucene index which Nexus uses to create a federated searching and retrieval mechanism. One instance of Nexus can proxy any other Maven repository -- a repository manager or normal webserver -- and with the presence of the Nexus index allows federated searching and retrieval of artifacts through that single instance. Some groups are already starting to provide Nexus indices: http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexed+Maven+Repositories This means you as a user can setup Nexus locally, create proxied repositories and get access to the contents of those repositories. So if everyone did this we could federate all the repositories around the world and then central just becomes a switchboard. This would be great as it would distribute the load around, but I think we still might want to collect everything in one place for safety. To be able to do that securely, some clever security mechanisms must first be developed, and since that is in line with security-concerned people, I think it is a good thing to do so. How hard can it be?, considering the expertise around detailing the requirements almost at code level, right ;-) ? Mercury will support PGP validation, and we are building support for PGP into Nexus so the indices could be retrieved and validated, and subsequent retrieval of artifacts could then also be validated. The technology is pretty much there to do what you're asking for but producing the indices in all the repositories will take time. But people are doing because it also provides value in the IDEs. m2eclipse, Netbeans, and IDEA are already integrating Nexus index technology to provide full POM auto-completion support, and we also use the index to find Maven plugins, Maven archetypes, and flag artifacts as having sources, javadocs, and valid checksums and signatures. So people will create indices to get the value in IDEs and as a consequence federating everything is possible. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
