Re: Idea of JCMS
hi oliver, > (1) Where can I get the (tentative) JCR API? you can download the snapshot that was out for public review in may-2004 ( http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html ) which is a quite a bit outdated now. or you can get the binaries that are used by maven to build for jackrabbit from http://www.day.com/maven/ "proposed final draft" will be submitted soon (i hope). i think you bring up a good point, we should somehow manage to get the java-doc of the jsr-170 into the jackrabbit api doc. > (2) When *presumably* will Jackrabbit be mature enought > to be an alternative to the current Slide backend? since i do not know slide well enough to understand how mature it is and i cannot judge what it would mean to be an alternative to the slide backend, i can only speak for jackrabbit. even when jackrabbit was still a slide proposal people (unfortuntately) started to use it in production. there are already mature applications that are built uniquely on jackrabbit, so far people have been very happy with the stability. i am sure there are very different mechanisms to measure robustness, which are usually very dependant on the requirements of the users. do you have any sort of performance metrics in mind? uptime? size of the repository in bytes or nodes (resources)? transactions per second? functionality (versioning, query, transactions,...?)? memory consumption? if there are any standard loadtests that are used for slide i am sure we could port them over to jsr-170 and see how jackrabbit compares today... (which as a side effect would allow us to have the worlds first "general purpose content repository benchmark" that would run against any jsr-170 compliant repository ;) ) david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Idea of JCMS
hi oli, thanks for your comments. i really appreciate your interest. > first of all let me say that I really appreciate your help! Second, > let me say that I have no reservations concerning Jackrabbit and > certainly do not see it as a threat to Slide or the other way round > (which others seemed to feel in other posts), but rather want to > explore where each project can learn from the other or where they > could combine efforts or benefit from each other - like with sharing a > WebDAV implementation. agreed. i certainly would be great to share a webdav library for example. > > > (1) Where can I get the (tentative) JCR API? > > you can download the snapshot that was out for public review > > in may-2004 > > ( http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html ) > > which is a quite a bit outdated now. or you can get the binaries that > > are used by maven to build for jackrabbit from http://www.day.com/maven/ > > "proposed final draft" will be submitted soon (i hope). > Thanks, got it now! Is this the API you were programming Jackrabbit to? precisely... the versions of the jcr.jar (v0.15) are in sync with the versions of the spec. > > > (2) When *presumably* will Jackrabbit be mature enought > > > to be an alternative to the current Slide backend? > > since i do not know slide well enough to understand how > > mature it is and i cannot judge what it would mean to be an alternative > > to the slide backend, i can only speak for jackrabbit. even when > > jackrabbit was still a slide proposal people (unfortuntately) > > started to use it in production. > Which is not your fault! which is other peoples fault, and they know that the have to live with the continous changes, in the api. > > there are already mature applications that are built > > uniquely on jackrabbit, so far people have been very > > happy with the stability. > That's great! Do you have links to them? sure... i think one of the earliest adopters you can find for example at http://www.magnolia.info > I suppose this is without authentication, access rights management and > locking, right? well, not entirely. but it is correct that currently locking and access control are currently still being developed. but applications can most certainly deal with those topics themselves, which i would (as i mentioned before) not suggest. > Please forbear with me as I am not yet familiar with Jackrabbit, but > as far as I have seen there is only a backend to the file system and > none to a relational database, right? Or have I missed something? there could be a wide variety of PerstistenceManagers that people could think of. personally, i believe that an fs backend certainly has great value when it comes to ease of deployment, but as you might see on the jackrabbit list other people are already discussing jdbc contributions... we will see... > How does the JCRQL look like? Is there any link to documentation? see the spec that you downloaded ;) however, it is subject to change. > > i am sure there are very different mechanisms to measure > > robustness, which are usually very dependant on the > > requirements of the users. do you have any sort of > > performance metrics in mind? uptime? size of the > > repository in bytes or nodes (resources)? transactions > > per second? functionality (versioning, query, > > transactions,...?)? memory consumption? > Bottom line is Jackrabbit is something you would advice to program to > for production? Even now? Well, that's good news for me! Why not > moving it out of the incubator then? first of all the criteria for moving something out of the incubator is has nothing to do with the stability of the code, but with the maturity of a project from a community perspective. from that perspective jackrabbit certainly still belongs into the incubator, we are still a very young community. as the spec-lead i would of course discourage anybody from using jsr-170 until it is finally approved by the executive committee of the jcp unless they are willing to accept the consequences of continuous change of the api. of course personally as a developer i would refuse to work with anything else but jsr-170 when it comes to communicating with a content repository, and i much rather incurr the impact of continuous changes in the jsr-170, than having to deal with a proprietary api. thanks again for all the excellent questions. regards, david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] add Jukka Zitting to Jackrabbit committers
> I hereby nominate Jukka Zitting ([EMAIL PROTECTED]) on the > basis of his sustained interest, quality of work, and desire > to contribute to the project on a long-term basis. Please vote > with your +1 for yes, +0 for abstain, or -1 (not at this time). +1 regards, david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] add Dominique Pfister to Jackrabbit committers
> I hereby nominate Dominique Pfister (dominique.pfister day.com) > on the basis of his sustained interest, quality of work, and desire > to contribute to the project on a long-term basis. Please vote > with your +1 for yes, +0 for abstain, or -1 (not at this time). > Naturally, only the votes coming from the incubator PMC and > Jackrabbit committers currently listed on our project status > page will be counted as binding. +1 regards, david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
hi all, On Thu, Dec 10, 2009 at 12:09 PM, Gianugo Rabellino wrote: > None of the above issues is a blocker, but the sum of the parts > doesn't give me exactly a warm, fuzzy feeling. I would appreciate the > proponents having a discussion with Chemistry first. If OpenCMIS, > however, prefers to skip that step and manages to score champions and > mentors, I won't stand in the way. same here. thanks gianugo for phrasing things so eloquently. i can just tell you that from my experience with the chemistry community every input from the group of initial committers would be very welcome. be architectural input or code, you are all very welcome on the list. regards, david .ps: thanks to florent for pointing out that chemistry has no jcr coupling ;) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
hi all, here are my two cents. i believe the cmis community is too small to fork at this point and at least the chemistry part of the community does not want to fork (at least that's my take, as a part of it). so i would personally assume that all chemistry committers would join the opencmis initial committers even before the incubation starts and would actively work in a true commuity effort to consolidate the efforts. the mentors and champions would probably be the same people aswell. so in my mind the bottom-line would be same result as if we had the opencmis people join chemistry, except that we give infra a bit of extra work and create extra effort for the incubator from a reporting perspective... i am sure we can find a good way forward between the two communities. we just need a couple of days to sort things out... keep in mind we all know each other personally ;) regards, david On Sun, Dec 13, 2009 at 10:16 AM, ant elder wrote: > On Sun, Dec 13, 2009 at 2:42 AM, Niclas Hedhman wrote: >> The Board has in the past condemned "balkanization" of community, and my >> take on this situation is exactly that. >> >> This is not "yet another web framework", which often brought forward as >> examples that the ASF encourages competition within. Those typically have a >> different "angle", "approach" or "metaphor", something making each very >> different beasts. But in this case we are talking about "the same spec". >> There is no real distinguishing features and huge overlap of commonality. >> >> I think this is a NIH-syndrome in play, in the best case "oh we have the >> code working already" and the worst case "we don't like to collaborate with >> them", and there is reason to think that that goes for both sides of the >> fence. >> >> I want to see Chemistry capable to absorb such contribution and collaborate >> heavily to bring such codebase in. >> And I want to see the people of the OpenCMIS proposal to show that they >> indeed can work with others. >> >> Exactly how the merged community goes about with the technical integration >> is its own business, but I am worried that the new codebase will not receive >> the welcome I hope, the Chemistry base will dominate, and the OpenCMIS >> proposer get fed up and leaves. Important Mentors understand the risks here, >> and keep eyes extra open for attrition, domination and forceful >> consensus-seeking. >> > > I agree with those sentiments. > >> I think discussion should continue on Chemistry dev@ list. If agreement >> can't be reached there, then I am NOT in favor of incubating OpenCMIS >> separately and will vote -1 to such proposal. I will also form myself an >> opinion of how well Chemistry is trying to collaborate, and it may improve >> or deteriorate its status with me. >> > > I don't think it would be helpful for either OpenCMIS or Chemistry for > the IPMC to just unilaterally dictate that "it must be done in > Chemistry". IMHO that would make for too unlevel a playing field which > could adversely impact any attempts to collaborate (or even just get > stuff done). That works both ways - it would be hard for OpenCMIS > being forced to be part of Chemistry, but also potentially hard for > Chemistry to all of a sudden have a significant number of new > committers forced upon them and upsetting the status quo. > > The Incubator has always been very clear about having a very low bar > of entry to incubation so IMHO it shouldn't matter that the incoming > podling is doing the same spec as another poddling, thats something > that could be worked out during incubation. So I'd +1 accepting this > new OpenCMIS proposal (if they can find champion and mentors). If > we're really concerned about having multiple spec impls then we can > make this a graduation requirement - neither Chemistry or OpenCMIS > graduate until they've both worked out how to exist together. > > >> This can become an excellent opportunity for all involved to show off their >> ApacheWay skills >> > > +1! > >> -- Niclas >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Flex to join the Apache Incubator
+1 regards, david On Tue, Dec 27, 2011 at 10:51 AM, Bertrand Delacretaz wrote: > Hi Incubator PMC members (*), > > I've just reviewed the "[PROPOSAL] Flex for Apache Incubator" thread > and I think all relevant issues have been adressed now. > > I have added Anne and Dave Fisher as mentors, pending their final > approval as Incubator PMC members. In the unlikely worst case that > this approval doesn't happen the project has two confirmed mentors to > start with anyway. > > Let's cast your votes to accept Flex as an incubating project, > proposal is at http://wiki.apache.org/incubator/FlexProposal, copied > below as well: > > [ ] +1 approve Flex as an incubating project. > [ ] -1 reject (explaining why) > [ ] +/- 0 don't care. > > This majority vote is open for 72 hours. > > Here's my +1. > > -Bertrand > > (*) although only votes from Incubator PMC members are binding, > anybody is welcome to cast a vote > > ** Flex proposal copy *** > > = Apache Flex Proposal = > > == Abstract == > > Apache Flex is an application framework for easily building > Flash-based applications for mobile devices, the browser and desktop. > > == Proposal == > > Apache Flex allows developers to target a variety of platforms, > initially Apple iOS, Google Android, RIM !BlackBerry, Microsoft > Windows, and Mac OS X with a single codebase. Flex provides a > compiler, skinnable user-interface components and managers to handle > styling, skinning, layout, localization, animation, module-loading and > user interaction management. > > == Background == > > Apache Flex is the software evolution of the popular Adobe Flex SDK project. > Adobe Flex SDK evolved from the need to provide developers with an > easy programming model for creating rich Internet applications that > can run in the browser, on the desktop or on mobile devices. > > Adobe Flex SDK has always focused on a single goal: to provide > application developers with all of the constructs needed to boost > their productivity while building large-scale, visually expressive > applications. This meant that Flex provided all the traditional UI > components in a way that designers and developers could interact with > them along with a dynamic scripting language, !ActionScript, and a > declarative markup language, MXML. > > Adobe will donate the Flex trademark to the Apache Software Foundation > as part of the incubation process. The source code, documentation and > related assets will all be contributed to the Apache Foundation as > Flex. > > == Rationale == > > Content developers need to target multiple screens and the cost of > creating applications native to every target platform is high. > Additionally, the dominant window to the web is quickly becoming > devices, mostly phones, and delivering consistent experiences is key. > The Apache Flex project exists to bring the focus back to a consistent > development model, one where a single application can run the exact > same way across the web, desktop and mobile devices. > > == Initial Goals == > > * Donate all Adobe Flex SDK source code and documentation to the > Apache Software Foundation. > * Setup and standardize the open governance of the Apache Flex project. > * Rename all assets from Adobe Flex SDK to Apache Flex in project > source code, docs, tests and related infrastructure. > > == Current Status == > > Flex is a mature software project. 1.0 was shipped in March of 2004 > with 7 major releases having shipped since. The most recent release > was the 4.6 version which shipped on November 29th, 2011. > > This proposal is currently being > [[http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCB14DCA2.3885F%25aharui%40adobe.com%3E|discussed]] > on the incubator general mailing list, once that's done we'll ask the > Incubator PMC to vote to accept it. > > == Meritocracy == > > The Adobe Flex source code is available to the community on the Adobe > opensource site: > http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK. Currently, > while the community has been invited to contribute patches to the > codebase, only Adobe employees decided on which patches to commit. > There were no external committers and this caused frustration in the > community. > > Going forward, both Adobe and our community are eager to become one > single merit-based community working together. To that end, Adobe > employes only have a minority representation on the initial committers > list. Adobe is working to educate our community with meetings and > blog posts on how the Apache model makes this possible for them. > > We have made it clear to our community that going forward, the > community, rather than Adobe, will determine the future of Flex. > > == Community == > > The community surrounding Flex is vast, diverse, distributed globally, > and with all levels of proficiency in software development. The common > thread of application development binds all Flex developers together. > > It is estimated that there is between
Re: Thrift Status?
On Thu, May 8, 2008 at 10:40 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Thu, May 8, 2008 at 8:57 PM, David Reiss <[EMAIL PROTECTED]> wrote: >> I'm not sure exactly what else needs to go into the software grant >> process. I still have not gotten an answer to my question about our >> CCLA. More Facebook engineers have contributed to Thrift since I first >> got it signed, and more are going to in the future. I cannot go back to >> our CEO to get a CCLA signed for each engineer who contributes to >> Thrift, so I need to know what other, more scalable options are >> available. > AIUI other corporations use CCLA. if anyone knows how they scale, > please jump in. > if this is likely to be an ongoing problem then raise on legal-discuss This is likely to be an ongoing issue, at least in my experience it is... I resorted in the meantime to do sort of a periodic update to the CCLA (sort of yearly) where I just add all the recent new contributors and all the potential committers, just to be sure. I think given the proper company culture there is no harm in including too many people in the blanket CCLA... (I wish there was a "joker" including all employees) regards, david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduating a part of an incubating project into an existing TLP
Hi Jukka, Just a random thought. "to move the codebase *and* to bring the mapping tool developers in as Jackrabbit committers" This is probably stating the obvious (my apologies): If there is no precedent that we could align with, then we possibly could look at this particular case just like any other code contribution. Which would mean that the current committers would contribute their code to the Jackrabbit community and would then follow the normal path to become committers in the Jackrabbit community. While I understand that this would mean that the current committers are sort of giving up a little bit of their more direct influence on "their" code (for a while), this may still be a clean and efficient way of doing it. I guess you already had this process in mind and were looking for more elegant alternatives. regards, david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
