Re: Proposal for a new incubation project: Unstructured Information Management Architecture - UIMA
Yonik Seeley wrote: On 8/26/06, Thilo Goetz [EMAIL PROTECTED] wrote: From an application perspective, we have great hopes for a cooperation with the Lucene project. Great, I think this is something I'd like to get involved in! I've been thinking about how Solr integration could work. You then also need a search engine that can index that extra information and make it available for search. Without getting into too much detail here, some info could be immediately usable by Lucene based apps (like entity extraction, where you can add info via a new field in the document). Parts-of-speech type of stuff is currently more difficult of course. -Yonik I agree (with all of the above ;-). Where it gets really interesting is with queries like show me all documents with book references whose author's last name is Knuth (highlighting the reference in the summary). One might be able to create such a system based on a text search engine with special fields and some sophisticated query expansion, but it would be a lot easier if one had special support for embedded structures in the index -- like you need for XML indexing. I'll be happy to continue this discussion over on solr-dev or wherever is appropriate. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: -1 votes on proposals need no explanation was Re: [VOTE] Accept Wicket into the Incubator
On 8/25/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Upayavira wrote: Justin Erenkrantz wrote: FYI: this is a majority vote not subject to vetos. So, there's no requirement that you provide a reason for voting against it - just like you don't have to provide a reason why you're voting for it. If you want to provide a reason, great, but I could just vote against it without further comment and that's perfectly fine too. -- justin Okay. Thanks for the clarification. I'll try to remember that for the next podling I propose :-) Although... an explanation can go a long way to have other pmc members consider the issues, good and bad, that they might have overlooked. +1 anyone feel like stepping up to add the content of this thread to http://incubator.apache.org/guides/pmc.html...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for a new incubation project: Unstructured Information Management Architecture - UIMA
On 8/27/06, Thilo Goetz [EMAIL PROTECTED] wrote: it would be a lot easier if one had special support for embedded structures in the index -- like you need for XML indexing. Lucene doesn't have embedded structures yet, but it's been discussed. http://www.nabble.com/Flexible-index-format---Payloads-Cont%27d-tf1869946.html -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[policy] incubating projects and maven repositories v1.0
Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: xml - doap + xml - take #1
On 8/26/06, david reid [EMAIL PROTECTED] wrote: Leo Simons wrote: I suggest something like http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/doap-converter Is this really the right place? How do the files get from this set of directories to site-publish? i'm not sure that i understand why the stylesheets need to move anywhere for the generated sitemap over in www.apache.org, the stylesheets are in xdocs/stylesheets/texen. the document is generated in the work directory and then processed. the results are generated into the docs directory. Before I add any files I want to be sure that I won't add a directory that will end up creating a problem. i don't think that there will be a problem (but maybe i'm missing the point...) (but should be easy enough to fix even if there is) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Main page broken links
I updated the page and updated the site. Waiting for the sync. Craig On Aug 27, 2006, at 2:29 AM, robert burrell donkin wrote: On 8/26/06, Craig L Russell [EMAIL PROTECTED] wrote: After the reorganization of the incubator site, the main page has at least three broken links: pThere is a lot more detail available on 1. a href=/resolution.htmlwhat the incubator is responsible for/a and 2. a href=/howwework.htmlhow we do that/a. Please see the menu on the left./p 3. a href=/howtoparticipate.html#Mailing+liststhe [EMAIL PROTECTED] mailing list/a. I'd fix them but I'm not sure what 1. and 2. should point to. 1. Should what the incubator is responsible for point to http://incubator.apache.org/incubation/Incubation_Policy.html http://incubator.apache.org/official/resolution.html the idea is that any documents (for example, board resolutions) that should not be changed by the pmc are kept in there 2. Should how we do that point to http://incubator.apache.org/incubation/Process_Description.html http://incubator.apache.org/incubation/Incubation_Policy.html for consistency with the labels on the sidebar 3. Should the [EMAIL PROTECTED] mailing list point to http://incubator.apache.org/guides/lists.html +1 If so, I can do the update. please do - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [policy] incubating projects and maven repositories v1.0
Hi, On 8/27/06, Jason van Zyl [EMAIL PROTECTED] wrote: There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. [...] Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Me neither. But why do we then need the separate incubator repository if the artifacts get synchronized with the central repository? As I mentioned in the thread before the Incubator Maven repository was created, it makes more sense to enforce an incubator label on the artifact versions than enforcing a specific incubator repository. Especially since there is no way for us to really enforce that repository policy. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On Aug 27, 2006, at 2:22 PM, Jukka Zitting wrote: Hi, On 8/27/06, Jason van Zyl [EMAIL PROTECTED] wrote: There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. [...] Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Me neither. But why do we then need the separate incubator repository if the artifacts get synchronized with the central repository? As I mentioned in the thread before the Incubator Maven repository was created, it makes more sense to enforce an incubator label on the artifact versions than enforcing a specific incubator repository. Especially since there is no way for us to really enforce that repository policy. I agree. I understand that we want users who choose to use an incubating project's artifacts to declaratively state that. If the artifact's name contains incubating then it's pretty clear. The only thing that muddles things for me is when using an m2 repository that contains a non-incubating project with a dependency on an incubating project. Then, a project that depends on the project that is itself not in the incubator might not even know that it's using an incubating project. Can this happen? Is it likely? Is there any policy that we can put into place to avoid that projects with dependencies on projects with incubating projects accidentally have this dependency? Perhaps Maven can help by not allowing the transitive dependency on incubating projects? Just thinking out loud... Craig BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [Fwd: Apache kabuki]
The company behind Kabuki decided to stop (from their side) the incubation process at the ASF - you should go and contact them directly. regards, Martin On 8/26/06, david reid [EMAIL PROTECTED] wrote: From: Jorge Schrauwen [EMAIL PROTECTED] I was browsing incubator today and found: http://incubator.apache.org/projects/kabuki.html Could you get me in touch with them? I have some code they might be interested in. I have a project: http://jorge.hosting-it.be/demo/imageview6/ (It is a Ajax+Php driven image manager) I create more or less a background framework for this jXCore It's a nice base but I personaly don't have time to build on this but a few people who seen and used it where very enthusiastic about it. So maybe there interested in part of it or in the entire thing. jXCore code and documentation is at: http://jorge.hosting-it.be/demo/imageview6/system/javascript/jXCore/ Jorge - 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] Publish Lokahi M01
robert burrell donkin wrote: On 8/11/06, Steve Toback [EMAIL PROTECTED] wrote: The Lokahi community voted on and has approved a proposal to release Lokahi M01. Pursuant to the Releases section of the Incubation Policy we would now like to request the permission of the Incubator PMC to publish the tarball on the Lokahi Download page. there are some files which IMO could and should have license headers but do not: * most of the files in conf * most of the files in database * docs/setup.html Robert, was this an objection to the M01 tarball, or something to address before M02? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 27 Aug 06, at 6:28 PM 27 Aug 06, Craig L Russell wrote: On Aug 27, 2006, at 2:22 PM, Jukka Zitting wrote: Hi, On 8/27/06, Jason van Zyl [EMAIL PROTECTED] wrote: There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. [...] Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Me neither. But why do we then need the separate incubator repository if the artifacts get synchronized with the central repository? As I mentioned in the thread before the Incubator Maven repository was created, it makes more sense to enforce an incubator label on the artifact versions than enforcing a specific incubator repository. Especially since there is no way for us to really enforce that repository policy. I agree. I understand that we want users who choose to use an incubating project's artifacts to declaratively state that. If the artifact's name contains incubating then it's pretty clear. The only thing that muddles things for me is when using an m2 repository that contains a non-incubating project with a dependency on an incubating project. Then, a project that depends on the project that is itself not in the incubator might not even know that it's using an incubating project. The standard dependency report shows all transitive dependencies so you can definitely see what you're using: http://maven.apache.org/continuum/dependencies.html Could be a little better in display but you can see what's in your dependency set. There are also things like the netbeans m2 integration which draws nice graphs of the dependencies. Can this happen? Is it likely? If you don't look at the dependency report or a graph then I suppose it could. Is there any policy that we can put into place to avoid that projects with dependencies on projects with incubating projects accidentally have this dependency? Perhaps Maven can help by not allowing the transitive dependency on incubating projects? Just thinking out loud... If you can clearly see what you have in a report so I'm not sure we would want to put any special rules in place to deal with artifacts from incubator. Craig BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On Monday 28 August 2006 08:58, Jason van Zyl wrote: Perhaps Maven can help by not allowing the transitive dependency on incubating projects? Just thinking out loud... If you can clearly see what you have in a report so I'm not sure we would want to put any special rules in place to deal with artifacts from incubator. Could that report be made part of the release:prepare and the release manager had to explicitly approve it?? If so, then I'm totally cool with no other Maven adjustments to deal with incubating projects. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 27 Aug 06, at 10:26 PM 27 Aug 06, Niclas Hedhman wrote: On Monday 28 August 2006 08:58, Jason van Zyl wrote: Perhaps Maven can help by not allowing the transitive dependency on incubating projects? Just thinking out loud... If you can clearly see what you have in a report so I'm not sure we would want to put any special rules in place to deal with artifacts from incubator. Could that report be made part of the release:prepare and the release manager had to explicitly approve it?? How are we supposed to enforce that? And what if they are not using Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http get to get artifacts from a repository. If so, then I'm totally cool with no other Maven adjustments to deal with incubating projects. Generating the site is not part of a standard release, though it's usually done as part of a release, and I'm not sure how you're going to enforce that for every possible project that might use something from the incubator. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On Monday 28 August 2006 11:31, Jason van Zyl wrote: Could that report be made part of the release:prepare and the release manager had to explicitly approve it?? How are we supposed to enforce that? And what if they are not using Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http get to get artifacts from a repository. We are probably misunderstanding each other... The question that came up was about transitive dependencies, which the user do not necessarily check for, and could end up being dependent on incubating projects against his/her will. Something that can't happen for snapshots (unless you bypass Maven's intended behaviours) You said, that one can check the full set of dependencies from a report generated by Maven2. I said, if that report could be output during the release:prepare phase, and that if the release:prepare phase would require the release manager to approve the use of that dependency tree, then we put the responsibility in the hands of the Maven2 user. You then start talking about 'enforcement'... And I am lost. Enforcing what? If the report can be generated, then either your statement above isn't valid, or the report is not capable of reporting the dependencies, in which case the original statement is not accurate. I suspect that you are trying to find problems with non-Maven systems, but that can always happen and not the issue at hand. BuildSystemAbc could pull down all kinds of stuff for the users, including snapshots, pirated software and virii. IMHO, Maven repositories exist mainly to support Maven and Maven-compatible(!) build systems. Your suggestions in the original mail is very good, and *I* don't have any opinion about whether a separate Incubating repository is needed or not. Both arguments for and against sound reasonable. Cheers Niclas Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
