Re: [IP CLEARANCE] Apache Maven - Mvndaemon
In case the code was rewritten or greatly modified, we'd need to check the IP again, but this isn't the case. There has been only minor modifications / bug fixes, so that should be fine. Le lun. 6 déc. 2021 à 06:52, Olivier Lamy a écrit : > The mentioned issue has been fixed. > We are moving the GitHub repo under asf org. > I don’t understand your question > > On Mon, 6 Dec 2021 at 1:51 pm, Justin Mclean > wrote: > > > Hi, > > > > > AFAIK, Guillaume fixed the issue as described in > > > https://issues.apache.org/jira/browse/LEGAL-586 < > > https://issues.apache.org/jira/browse/LEGAL-586> > > > > > > Nothing blocks now, isn't it? > > > > I’m nt aware of anything. > > > > > Do we consider the clearance ok as a conclusion, or should we restart a > > new > > > thread? > > > > Is what you donating the same or has it changed and has a different VC > > hash? If it’s changed I would start a new thread. > > > > Kind Regards, > > Justin > -- Guillaume Nodet
Re: [IP CLEARANCE] Apache Maven - Mvndaemon
Le lun. 6 sept. 2021 à 03:03, Olivier Lamy a écrit : > Hi > Thanks for looking into this. > > On Mon, 6 Sept 2021 at 09:15, Justin Mclean > wrote: > >> Hi, >> >> I have a couple of questions: >> I see we have ICLAs for the two main contributors, do we have ICLAs for >> any for the the other contributors? >> > > ?? You mean we need CLAs for every person who contributed a Pull Request > to an Apache License project? ( > https://github.com/mvndaemon/mvnd/graphs/contributors) > I don't understand the point. If folks have contributed to Apache license > project I do not think a CLA is needed. > We are not even doing that here @ ASF > > >> The repro includes GPL licensed code how is this going to be handled? >> (GPL is category X and not compatible with the Apache license). >> > > we need to address the native part. Not sure how ATM > > > >> There also seems to be other non open source code? (e.g. "Copyright 2004 >> Sun Microsystems, Inc. All rights reserved. SUN PROPRIETARY/CONFIDENTIAL. >> Use is subject to license terms.”) How will this be handled? >> > > yup the native part has some problems which need to be addressed. > Can we replace the header with the following one instead: https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/include/jni.h It is more clearly GPLv2 w/ CPE, so it should be allowed, as my understanding is that it is an exception to category X. Guillaume > > >> >> There is Apache licensed code from 3rd parties included the donations, do >> take care when updating the headers after donation, and don’t replace these >> headers. > > >> Kind Regards, >> Justin >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy > -- Guillaume Nodet
Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
+1 (binding) On Thu, Feb 9, 2012 at 16:16, Mattmann, Chris A (388J) wrote: > Hi Folks, > > OK there has been enough discussion here. It's time to VOTE for a new IPMC > chair and it looks like the remaining folks (including me) that were in the > running > have aligned beyond the following nominee: Jukka Zitting. Suffice to say, he > was > *my first choice* :) > > In the interest of moving the current discussion matters forward, please VOTE > on this recommendation to the board by the IPMC. I'll leave the VOTE open > for at least the next 72 hours: > > [ ] +1 Recommend Jukka Zitting for the IPMC chair position. > [ ] +0 Don't care. > [ ] -1 Don't recommend Jukka Zitting for the IPMC chair position because... > > Note that only VOTEs from the Incubator PMC members are binding, but > all are welcome to voice their opinion and it will be recorded in the final > tallies. > > Finally, just to note, these VOTEs on personnel are normally the only > thing in Apache that is discussed in private (human/social issues), but > in the interest of openness and transparency that has been demonstrated > here during these discussions, I will hold this VOTE on the public list. > > Thanks! > > Cheers, > Chris > > P.S. Here's my +1. Thanks buddy. > > On Feb 8, 2012, at 3:11 PM, Benson Margulies wrote: > >> I am happy to step out of the way for Jukka. He was clever enough to >> stay out of the email s*** storm, and that alone, in my mind, renders >> him most qualified. >> >> On Wed, Feb 8, 2012 at 6:02 PM, Christian Grobmeier >> wrote: >>> I already mentioned that I would have nominated you, and so I am >>> delighted to read your message. It will be very difficult to choose >>> between all these strong candidates. >>> >>> Cheers >>> >>> On Wed, Feb 8, 2012 at 11:49 PM, Jukka Zitting >>> wrote: >>>> Hi, >>>> >>>> After consideration and some convincing (thanks!), I've decided to >>>> throw also my hat into the ring as a candidate to be the next chairman >>>> of the IPMC. >>>> >>>> I believe in that role I could be more effective in focusing more of >>>> our collective attention at where I think it would do most good - at >>>> the actual podlings we're here to help. >>>> >>>> That said, the current incubation process clearly has problems and I >>>> very much support efforts to improve the way we work (even if the >>>> result is to replace the Incubator with something better). However, >>>> I'd like to leave the leadership on these efforts to others and, as >>>> mentioned elsewhere, rather try to act as a balancing force that helps >>>> achieve consensus where possible. >>>> >>>> Should I be elected, I'd resign as the chairman of the Jackrabbit PMC. >>>> In fact I think it's in any case high time for Jackrabbit to be >>>> rotating that role. >>>> >>>> Finally, if elected (and assuming the IPMC still exists), I'd serve >>>> for at most two years before calling for a re-election, or possibly >>>> much less if I don't find enough free cycles to perform the duty as >>>> well as it should. >>>> >>>> BR, >>>> >>>> Jukka Zitting >>>> > > > ++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.a.mattm...@nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++ > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Fw: [VOTE] Graduate ACE from the Apache Incubator
oing most non-trivial ACE > >>>>>>>> >>> development is going to want. One source > >> distribution makes this easy, > >>>>>>>> >>> making them have to download them all > >> separately isn't particularly > >>>>>>>> >>> practical. That > >> https://svn.apache.org/repos/asf/incubator/ace/trunk/ > >>>>>>>> >>> is structured so the ASF committers can > >> work with them as one single > >>>>>>>> >>> buildable checkout i think shows thats > >> true. > >>>>>>>> >>> > >>>>>>>> >>> 2) If there is only individually buildable > >> source for each jar how are > >>>>>>>> >>> people really going to verify that the > >> release is actually buildable > >>>>>>>> >>> and the artifacts match the SVN tag source > >> when reviewing and voting > >>>>>>>> >>> on release votes? No one reviewing > >>> is really likely to download 60 > >>>>>>>> >>> separate distros and build them all one by > >> one are they? > >>>>>>>> >> > >>>>>>>> >> I disagree. There seems to be some > >> misunderstanding that there is one > >>>>>>>> single > >>>>>>>> >> product that must be built. > >>>>>>>> >> > >>>>>>>> >> When you develop independently evolving > >> modules, "big bang" releases do > >>>>>>>> not > >>>>>>>> >> make sense. Each module has its own release > >> cycle. Occasionally you may > >>>>>>>> end > >>>>>>>> >> up creating some sort of > >> "distribution" out of the modules and release > >>>>>>>> that, > >>>>>>>> >> but that is just one potential distribution. > >>>>>>>> >> > >>>>>>>> > > >>>>>>>> > I agree thats an approach used and works in many > >> projects but if that > >>>>>>>> > was really the case _here_ then surely the > >>> SVN would be structured so > >>>>>>>> > that there were separate trunk/branch/tag folders > >> for each module, > >>>>>>>> > there would have been more releases than just the > >> single 0.8.0 > >>>>>>>> > release, and there would be separate release votes > >> for each module > >>>>>>>> > being released. > >>>>>>>> > >>>>>>>> We have a tag per module and that is enough. > >> Furthermore, we do > >>>>>>>> combine several modules if it makes sense (i.e., we > >> want to release > >>>>>>>> them at the same time) in one vote as it would > >> otherwise create a lot > >>>>>>>> of extra traffic. That's all. It is the same set-up > >> some of the other > >>>>>>>> OSGi projects at the asf have (I did quite a lot of > >> their releases). > >>>>>>>> The only thing we missed was the source distributions > >> per artifact. > >>>>>>>> > >>>>>>>> > >>>>>>> And that IMHO is not enough to consider the release a > >> failure. Let it > >>> be > >>>>>>> noted and corrected for future releases. AFAIC there's > >> no reason to hold > >>>>>>> this podling back because of some minor release > >> inconsistencies which are > >>>>>>> natural as we shift from monolithic products to component > >> based OSGi > >>>>>>> products. > >>>>>>> > >>>>>>> Best, > >>>>>>> Alex > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Karl Pauls > >>>>> karlpa...@gmail.com > >>>>> http://twitter.com/karlpauls > >>>>> http://www.linkedin.com/in/karlpauls > >>>>> https://profiles.google.com/karlpauls > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> - > >>> 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 > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Graduate ACE from the Apache Incubator
+1 On Thu, Nov 17, 2011 at 11:42, Marcel Offermans wrote: > In my opinion, ACE is ready to begin the process of graduating from the > Apache Incubator to a Top Level Project. > > Since joining the incubator in in May 2009 we've added 4 new committers > (12 in total now) from diverse organizations and did a release in May this > year to demonstrate we follow the Apache guidelines. We've shown an ability > to self-govern using accepted Apache practices and ACE continues to attract > new contributors and users. > > The first step is to vote as a community, demonstrating that ACE is ready > and willing to graduate. Once this vote is succesful we create a board > resolution proposal or Charter and start a vote on the general incubator > list. The full process is described at > http://incubator.apache.org/guides/graduation.html#toplevel > > The vote is open for at least 72 hours. > > Greetings, Marcel > > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Graduate ACE from the Apache Incubator
--- > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com > > http://twitter.com/karlpauls > > http://www.linkedin.com/in/karlpauls > > https://profiles.google.com/karlpauls > > > > - > > 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 > > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Graduate ACE from the Apache Incubator
As much as I don't like this layout, this is not the first projet to use it, and I don't really see how / why the IPMC should decide the svn layout for the project. You won't be the one to manage it daily afaik, so that's not up to you to decide imho. Sling and Felix already use such a layout and they are both TLP, so I really don't see that as a problem. On Thu, Nov 17, 2011 at 13:07, sebb wrote: > On 17 November 2011 10:42, Marcel Offermans > wrote: > > In my opinion, ACE is ready to begin the process of graduating from the > Apache Incubator to a Top Level Project. > > > > Since joining the incubator in in May 2009 we've added 4 new committers > (12 in total now) from diverse organizations and did a release in May this > year to demonstrate we follow the Apache guidelines. We've shown an ability > to self-govern using accepted Apache practices and ACE continues to attract > new contributors and users. > > > > The first step is to vote as a community, demonstrating that ACE is > ready and willing to graduate. Once this vote is succesful we create a > board resolution proposal or Charter and start a vote on the general > incubator list. The full process is described at > http://incubator.apache.org/guides/graduation.html#toplevel > > > > The vote is open for at least 72 hours. > > The last (and only) release was 0.8, as far as I can tell. > > There is no KEYS file in http://www.apache.org/dist/incubator/ace/, > and there does not appear to be a full source archive of the project > anywhere. > The download page does not have a link to any source archives as far > as I can tell. > It does link to KEYS in SVN, but almost all other ASF projects have a > copy of KEYS in the appropriate /dist directory. > > Normally releases are divided into binaries/ and source/ directories, > with a KEYS file in the top-level, i.e. > > /dist/incubator/ace > - KEYS > - binaries/ace zip > - sources/acezip > > Most of the files in the /dist/incubator/ace directory appear to be > Maven artifacts; normally these are not stored in /dist but only in > the Maven repo. > Indeed most of the files are also in Maven Central. The only non-Maven > files appear to be > > org.apache.ace.target.devgateway-0.8.0-incubator-distribution.zip > org.apache.ace.target.devserver-0.8.0-incubator-distribution.zip > > neither of which contains the source. > > I would expect the above zips to be in > > /dist/incubator/ace/binaries > > with corresponding source files in > > /dist/incubator/ace/source > > The SVN layout [1] is also a bit unusual. > There is no tags/ directory for release tags, although there is a > releases/ directory containing individual entries for each release for > each component. > This is likely to become unmanageable very quickly, if every release > adds another 63 directory entries under releases/ > > [1] https://svn.apache.org/repos/asf/incubator/ace/ > > ----- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Accept OpenOffice.org for incubation
New >> Zealand]] || || >> ||Florent André || flor...@apache.org ||individual ||yes || >> ||Allen Pulsifer ||pulsifer at openoffice.org ||individual || || >> ||Herbert Duerr || h...@openoffice.org ||individual || || >> ||Kazunari Hirano || khir...@openoffice.org ||individual || || >> ||Kent Åberg || kent.ab...@newformat.se ||[[ >> http://www.newformat.se/newformat/eng/newformat-home-index.html|NewFormat]] >> || || >> ||Maho NAKATA || m...@openoffice.org ||ja/qa project lead, FBSD porting || >> || >> ||Miguel Á. Ríos ||mariosv@miguelangel dot mobi ||Individual || || >> ||Dave !McKay || thegur...@openoffice.org ||Individual || || >> ||Louis Suárez-Potts || lo...@openoffice.org ||individual || || >> ||Fernand Vanrie || s...@pmg.be ||individual || || >> ||Arthur Buijs || artie...@openoffice.org ||[[ >> http://nl.openoffice.org/|Dutch Native Language Project]] ||Yes || >> ||Dave Barton || d...@tasit.net >> ||[[http://www.tutorialsforopenoffice.org|Tutorials >> For OpenOffice]] || || >> ||Jian Fang Zhang || zhan...@cn.ibm.com ||[[http://symphony.lotus.com|IBM, >> Symphony Chief Programmer, G11N, Security]] ||Yes || >> ||Zhe Wang || wangz...@cn.ibm.com ||[[http://symphony.lotus.com|IBM, >> Impress]] || || >> ||Don Harbison || donald_harbi...@us.ibm.com ||[[http://ibm.com/|IBM]] >> ||Yes || >> ||Jian Hong Cheng || chen...@cn.ibm.com ||[[http://symphony.lotus.com|IBM, >> Writer, Impress]] || || >> ||Chao Sun || sunc...@redoffice.com ||[[www.redoffice.com|RedOffice]] || >> || >> ||Heng Lee || lih...@redoffice.com ||[[www.redoffice.com|RedOffice]] || || >> ||Shu Wang Han || hanshuw...@redoffice.com ||[[www.redoffice.com|RedOffice]] >> || || >> ||Hong Yun An || anhong...@redoffice.com ||[[www.redoffice.com|RedOffice]] >> || || >> ||Jin Hua Chen || chenj...@cn.ibm.com ||IBM, Symphony Presentation || || >> ||Yegor Kozlov || ye...@apache.org ||individual ||yes || >> ||Juan C. Sanz || jucasac...@openoffice.org ||Spanish documentation || || >> ||Peter Junge || p...@openoffice.org ||Individual || || >> ||Cyril Beaussier ||oooforum at free dot fr ||[[ >> http://user.services.openoffice.org/fr|French forum admin]],[[ >> http://fr.openoffice.org/|French Project webmaster]] || || >> ||Damjan Jovanovic || dam...@apache.org ||individual ||yes || >> ||Fernando Cassia || fcas...@sdf.lonestar.org ||individual || || >> >> >> >> >> = Sponsors = >> == Champion == >> Sam Ruby, Apache Foundation >> >> == Nominated Mentors == >> Because of the scope and complexity of this proposed project, we believe >> that the incubation process would benefit from multiple mentors, especially >> ones willing to be the "point person" for each of the following disciplines: >> >> a. IP review >> a. infrastructure >> a. release management >> a. community development >> >> Mentors (these are all Members of the Foundation): >> >> * Jim Jagielski >> * Sam Ruby >> * Danese Cooper >> * Shane Curcuru >> * Nóirín Plunkett >> * Joe Schaefer >> * Christian Grobmeier >> * Ross Gardler >> >> == Sponsoring Entity == >> The Apache Incubator >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Director & Chief Scientist; Lanka Software Foundation; > http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2; http://wso2.com/ > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > Blog: http://sanjiva.weerawarana.org/ > -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][PROPOSAL] EasyAnt incubator
gt; > Many of the committers have experience working on open source projects. Two > of them have experience as committers on other Apache projects. > > == Homogenous Developers == > > The existing committers are spread over a number of countries and employers. > > == Reliance on Salaried Developers == > > None of the developers rely on EasyAnt for consulting work. > > == Relationships with Other Apache Products == > > As already stated above, EasyAnt is intended to have a quite good > integration with both Apache Ant and Apache Ivy. > > == A Excessive Fascination with the Apache Brand == > > As we're already based on many Apache project (Ant + Ivy), it seems natural > for us that Apache Software Foundation could be a good host for this. > > = Documentation = > > Further reading on EasyAnt can be found at: http://www.easyant.org/doc/ > > Mailing list is located at http://groups.google.com/group/easyant > > = Initial Source = > > The initial code base can be found at: http://svn.easyant.org/ > > = Source and Intellectual Property Submission Plan = > > Every developer is willing to sign the proper papers to make EasyAnt enter > the ASF. > > = External Dependencies = > > Easyant requires at compile/runtime : > > * apache ant > * apache ivy > * ant contrib > > = Required Resources = > > == Mailing lists == > > * easyant-private (with moderated subscriptions) > * easyant-dev > > == Subversion Directory == > > https://svn.apache.org/repos/asf/incubator/easyant > > == Issue Tracking == > > JIRA EasyAnt (EASYANT) > > = Initial Committers = > > * Xavier Hanin > * J ér ôme Benois > * Jason Trump > * Siddhartha Purkayastha > * Nicolas Lalev ée > * Jean-Louis Boudart > > = Sponsors = > > == Champions == > > * Antoine L évy-Lambert > > == Nominated Mentors == > > * Antoine L évy-Lambert > * Stefan Bodewig > > == Sponsoring Entity == > > * Apache Ant > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Aries Graduation to TLP
+1 On Mon, Nov 22, 2010 at 12:51, Jeremy Hughes wrote: > Hi IPMCers and Incubator community, > > The Aries community has been discussing graduation and we feel we are > ready to graduate to a new TLP [1]. We subsequently voted [2]. As a > commnunity we were unanimous in deciding to graduate to a new TLP. We > voted [3] on putting forward the resolution below for the next Board > meeting to promote Aries to an Apache TLP and graduate from the > Incubator. As per the graduation guide [4], the Aries PPMC voted on > the position of Chair. That Vote is here [5] and Result is here [6] > (Aries PPMC list membership required). > > Please VOTE on the below resolution for promoting Aries to an Apache > TLP and graduating from the Incubator. The VOTE is open for 72 hours. > > [ ] +1 Accept Aries' graduation from the Incubator > [ ] +0 Don't care. > [ ] -1 Don't accept Aries' graduation from the Incubator because ... > > > ## Resolution to create a TLP from graduating Incubator podling > > X. Establish the Apache Aries Project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project Management > Committee charged with the creation and maintenance of > open-source software related to a set of pluggable Java > components enabling an enterprise OSGi application programming > model for deployment to a variety of OSGi based runtimes, for > distribution at no charge to the public. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache Aries Project", > be and hereby is established pursuant to Bylaws of the > Foundation; and be it further > > RESOLVED, that the Apache Aries Project be and hereby is > responsible for the creation and maintenance of software > related to a set of pluggable Java components enabling an > enterprise OSGi application programming model for deployment to > a variety of OSGi based runtimes; > and be it further > > RESOLVED, that the office of "Vice President, Apache Aries" be > and hereby is created, the person holding such office to > serve at the direction of the Board of Directors as the chair > of the Apache Aries Project, and to have primary responsibility > for management of the projects within the scope of > responsibility of the Apache Aries Project; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Aries Project: > > * A. J. David Bosschaert > * Adam Wojtuniak > * Alan Cabrera > * Alan T Keane > * Alasdair Nottingham > * Andrew Osborne > * Bartosz Kowalewski > * Bertrand Delacretaz > * Carsten Ziegeler > * Chris Wilkinson > * Davanum Srinivas > * David Jencks > * Emily Jiang > * Eoghan Glynn > * Graham Charters > * Guillaume Nodet > * Hiram R. Chirino > * Holly Cummins > * Ian Robinson > * J. Daniel Kulp > * James Strachan > * Jarek Gawor > * Jean Sebastien Delfino > * Jeremy Hughes > * Joseph Alan Bohn > * Kevan Lee Miller > * Kiril Malenkov Mitov > * Lei Wang > * Lin Sun > * Mark Nuttall > * Niklas Gustavsson > * Nikolai Dimitrov Tankov > * Par Niclas Hedhman > * Richard McGuire > * Sabine Heider > * Sergey Beryozkin > * Stuart McCulloch > * Timothy James Ward > * Valentin Mahrwald > * Violeta Georgieva Georgieva > * Zhaohui Feng > * Zoe Slattery > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Jeremy > Hughes be appointed to the office of Vice President, Apache Aries, > to serve in accordance with and subject to the direction of the > Board of Directors and the Bylaws of the Foundation until > death, resignation, retirement, removal or disqualification, > or until a successor is appointed; and be it further > > RESOLVED, that the initial Apache Aries PMC be and hereby is > tasked with the creation of a set of bylaws intended to > encourage open development and increased participation in the > Apache Aries Project; and
Re: Podling to use native git
On Fri, Oct 1, 2010 at 10:45, Mark Struberg wrote: > > > I think it's really worse, as branches aren't maintained > > > anymore in the apache svn area, > > yes, and anyone ever asked yourself _why_ this happens? > The answer imo is: because its _sooo_ painful to do feature branches in SVN > (and merge them back). > Yes, this is the real reason ... and having an offline commit in svn won't solve that problem. > > GIT otoh has it's flaws too. There is e.g. no way to keep one big fat > unique Apache SVN where you can move around directories. This would have to > be done with git-submodules, which is much less handy. > > So I'm with Gav here: we need to evaluate this in multiple steps > > 1st) in theory, and later > 2nd) via an incubator podling project > > If it turns out that we cannot live with GIT, then we could still import > all the history of 'master' into our SVN. > > LieGrue, > strub > > > --- On Fri, 10/1/10, Guillaume Nodet wrote: > > > From: Guillaume Nodet > > Subject: Re: Podling to use native git > > To: general@incubator.apache.org > > Date: Friday, October 1, 2010, 8:20 AM > > On Fri, Oct 1, 2010 at 09:44, Gav... > > > > wrote: > > > > > > > > > > > > -Original Message- > > > > From: Guillaume Nodet [mailto:gno...@gmail.com] > > > > Sent: Friday, 1 October 2010 5:11 PM > > > > To: general@incubator.apache.org > > > > Subject: Re: Podling to use native git > > > > > > > > I do agree with you. I don't > > really get this argument either. > > > > > > > > But in the meantime, you need to use an svn > > backend, and ask for a git > > > > mirror. You can then fork > > / merge at github the way you want, merge > > > > back > > > > into trunk and git svn dcommit from there. > > > > > > > > I think it's really worse, as branches aren't > > maintained anymore in the > > > > apache svn area, > > > > > > What's wrong with 'git tag' ?? > > > > > > > What I'm saying is that having to maintain some branches at > > github outside > > of svn in git is not the best thing. But > > that's really the only option we > > have here. > > > > > > > > > > > > > > but that's what we need to live with until git > > can be > > > > properly supported at Apache. > > > > > > It will be a while. > > > > > > > > > Gav... > > > > > > > > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg > > > > wrote: > > > > > > > > > Hmm, to be honest, I don't see this > > argument. Because you can also > > > > use a > > > > > centralised model with GIT. > > > > > > > > > > Also, the main benefit of GIT is not only > > that you can do offline > > > > commits, > > > > > but mostly that it's sooo much easier to > > merge! > > > > > I had a merge hell with my colleague in the > > company this week. He > > > > kept a > > > > > SVN feature branch for only one week and > > merging his feature branch > > > > into the > > > > > trunk (team with 10 developers) did cost us > > a whole day... > > > > > > > > > > The reason is that SVN applies an end to end > > diff while git aims to > > > > merge > > > > > by walking the commit tree of the branch and > > applying each commit > > > > > separately. > > > > > > > > > > GIT even supports signing off commits. So > > each committer who pushes > > > > to the > > > > > central repo 'signs' that the contribution > > is ASL licensed. > > > > > > > > > > LieGrue, > > > > > stru > > > > > > > > > > --- On Thu, 9/30/10, Noel J. Bergman > > wrote: > > > > > > > > > > > From: Noel J. Bergman > > > > > > Subject: RE: Podling to use native git > > > > > > To: general@incubator.apache.org > > > > > > Date: Thursday, September 30, 2010, > > 11:13 PM > > > > > > > Does any other podling use > > > > > > git-only workflow. > > > > > > > > >
Re: Podling to use native git
On Fri, Oct 1, 2010 at 09:44, Gav... wrote: > > > > -Original Message- > > From: Guillaume Nodet [mailto:gno...@gmail.com] > > Sent: Friday, 1 October 2010 5:11 PM > > To: general@incubator.apache.org > > Subject: Re: Podling to use native git > > > > I do agree with you. I don't really get this argument either. > > > > But in the meantime, you need to use an svn backend, and ask for a git > > mirror. You can then fork / merge at github the way you want, merge > > back > > into trunk and git svn dcommit from there. > > > > I think it's really worse, as branches aren't maintained anymore in the > > apache svn area, > > What's wrong with 'git tag' ?? > What I'm saying is that having to maintain some branches at github outside of svn in git is not the best thing. But that's really the only option we have here. > > > > but that's what we need to live with until git can be > > properly supported at Apache. > > It will be a while. > > > Gav... > > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg wrote: > > > > > Hmm, to be honest, I don't see this argument. Because you can also > > use a > > > centralised model with GIT. > > > > > > Also, the main benefit of GIT is not only that you can do offline > > commits, > > > but mostly that it's sooo much easier to merge! > > > I had a merge hell with my colleague in the company this week. He > > kept a > > > SVN feature branch for only one week and merging his feature branch > > into the > > > trunk (team with 10 developers) did cost us a whole day... > > > > > > The reason is that SVN applies an end to end diff while git aims to > > merge > > > by walking the commit tree of the branch and applying each commit > > > separately. > > > > > > GIT even supports signing off commits. So each committer who pushes > > to the > > > central repo 'signs' that the contribution is ASL licensed. > > > > > > LieGrue, > > > stru > > > > > > --- On Thu, 9/30/10, Noel J. Bergman wrote: > > > > > > > From: Noel J. Bergman > > > > Subject: RE: Podling to use native git > > > > To: general@incubator.apache.org > > > > Date: Thursday, September 30, 2010, 11:13 PM > > > > > Does any other podling use > > > > git-only workflow. > > > > > > > > No ASF project is permitted to use git-only. And the > > > > typical git workflow is part of the problem. We > > > > strongly believe in a single, central, repository as part of > > > > the process of community building. The git model is > > > > better suited to disparate groups partially sharing a > > > > codebase. > > > > > > > > Fundamentally, we WANT people working in a central, shared, > > > > repository. > > > > > > > > If/when the ASF allows git as a technology, you can expect > > > > that the workflow will be an ASF workflow. And once > > > > Greg gets offline commmit working with SVN, I suspect that > > > > it will be harder to push for git. > > > > > > > > --- Noel > > > > > > > > > > > > > > > > --- > > -- > > > > 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 > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > > > Blog: http://gnodet.blogspot.com/ > > > > Open Source SOA > > http://fusesource.com > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Podling to use native git
I do agree with you. I don't really get this argument either. But in the meantime, you need to use an svn backend, and ask for a git mirror. You can then fork / merge at github the way you want, merge back into trunk and git svn dcommit from there. I think it's really worse, as branches aren't maintained anymore in the apache svn area, but that's what we need to live with until git can be properly supported at Apache. On Fri, Oct 1, 2010 at 08:49, Mark Struberg wrote: > Hmm, to be honest, I don't see this argument. Because you can also use a > centralised model with GIT. > > Also, the main benefit of GIT is not only that you can do offline commits, > but mostly that it's sooo much easier to merge! > I had a merge hell with my colleague in the company this week. He kept a > SVN feature branch for only one week and merging his feature branch into the > trunk (team with 10 developers) did cost us a whole day... > > The reason is that SVN applies an end to end diff while git aims to merge > by walking the commit tree of the branch and applying each commit > separately. > > GIT even supports signing off commits. So each committer who pushes to the > central repo 'signs' that the contribution is ASL licensed. > > LieGrue, > stru > > --- On Thu, 9/30/10, Noel J. Bergman wrote: > > > From: Noel J. Bergman > > Subject: RE: Podling to use native git > > To: general@incubator.apache.org > > Date: Thursday, September 30, 2010, 11:13 PM > > > Does any other podling use > > git-only workflow. > > > > No ASF project is permitted to use git-only. And the > > typical git workflow is part of the problem. We > > strongly believe in a single, central, repository as part of > > the process of community building. The git model is > > better suited to disparate groups partially sharing a > > codebase. > > > > Fundamentally, we WANT people working in a central, shared, > > repository. > > > > If/when the ASF allows git as a technology, you can expect > > that the workflow will be an ASF workflow. And once > > Greg gets offline commmit working with SVN, I suspect that > > it will be harder to push for git. > > > > --- Noel > > > > > > > > - > > 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 > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] HISE
torage. > > Known Risks > > Orphaned products > > Initial contributors are vendors of this product. So there's no risk > or warnings for abandoning this project. > > Moreover there's already an interest from external communities to join > this project for development when it enters Apache Incubator. > > Inexperience with Open Source > > WSHT was started as a closed source project. > > Core developers are already experienced with other open source > projects including Apache OfBiz, Apache ServiceMix, Apache ODE. One of > the initial committers is a committer in Apache ODE project and is > expected to share knowledge of open source development process among > others. > > WSHT current code base also depends on various open source projects > like Apache CXF, Apache Geronimo and it was developed by core > developers. > > Homogenous Developers > > WSHT includes committers from only one company (TouK). > > Current committers know each other from TouK, so they are not really > homogenous. This is expected to change during incubation. > > Reliance on Salaried Developers > > All of the developers at TouK are salaried developers. This is > expected to change during incubation phase. > > Relationships with Other Apache Products > > OpenJPA will be used by HISE for it's internal storage. Apache CXF > will be used to expose Web Services to external world. Apache > ServiceMix will be used to expose and test WSHT services as JBI > service. > > Maven2 is used for building. > > There's no competition among other Apache projects for this project. > > An Excessive Fascination with the Apache Brand > > WSHT is donated to Apache because of ability to gather communities > among other projects (Apache ServiceMix and Apache ODE) and external > communities both developers and users. This donation of WSHT project > is for increasing contacts and visibility in open source world and to > develop a satisfying implementation for WS-Human-Task spec. > > This spec currently has closed source implementations usually bricked > up with larger products. HISE is expected to provide an open source > solution for WS-Human-Task spec, which may be adopted in those > projects too to follow DRY rule among various companies. > > Documentation > > Informations about WSHT project can be found at > http://top.touk.pl/confluence/display/top/WSHT+-+WS+Human+Tasks+Implementation > > Initial Source > > WSHT is the only code base for HISE. > > WSHT project has been developed since April 2009 at TouK. > > It was used to vend inside larger products. It was developed from the > beginning under Apache 2.0 License with aim to become open source > project. > > Source and Intellectual Property Submission Plan > > WSHT code base from TouK company (it's developed from the beginning > under Apache 2.0 License). > > External Dependencies > > The dependencies with Apache compatible licenses: > > * > > H2 embedded database (modified MPL 1.1 > http://www.h2database.com/html/license.html) > * jaxb (Apache 2.0 and W3C license) > * aspectj (Eclipse Public License) > * > > jMock Project License (http://www.jmock.org/license.html) > * saaj API and Impl (CDDL v. 1.0) > * Other dependencies are licensed under MIT, BSD, Common Public > License, Eclipse Public License, and Apache 2.0 Licenses > > Not compatible with Apache license (and expected to be removed in > binary distros during incubation): > > * Hibernate (LGPL) > * Jboss Archive Browsing (LGPL) > > Cryptography > > - > > Required Resources > > Mailing lists > > hise-private, hise-dev > > Subversion Directory > > https://svn.apache.org/repos/asf/incubator/hise > > Issue Tracking > > JIRA HISE (HISE) > > Other Resources > > - > > Initial Committers > > * > > Jakub Kurlenda > * > > Mateusz Lipczyński > * > > Michał Zalewski > * > > Rafał Rusin > * > > Ula Trzaskowska > * > > Warren Crossing > * > > Witek Wołejszo > > Affiliations > > * > > Jakub Kurlenda (TouK company) > * > > Mateusz Lipczyński (TouK company) > * > > Michał Zalewski (TouK company) > * > > Rafał Rusin (TouK company) > * > > Ula Trzaskowska (TouK company) > * > > Warren Crossing (TouK company) > * > > Witek Wołejszo (TouK company) > > Sponsors > > Champion > > Matthieu Riou > > Nominated Mentors > > Paul Fremantle > > Sponsoring Entity > > Apache ODE PMC > > > Regards, > -- > Rafał Rusin > http://www.touk.pl > http://top.touk.pl > http://people.apache.org/~rr/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Aries initial commiters list
The problem is that the list that has been voted on is the one that has been sent in the initial vote email. When people have already voted, you can't change things afterwards. FWIW, I've just started a discussion on the aries dev list ... You need to subscribe to this list, if you haven't done so yet. On Tue, Sep 29, 2009 at 20:19, adam wojtuniak wrote: > Hi > > I was removed from initial committers list of Apache Aries project. > Can someone explain me what is the reason? > I joined the list almost by the end of voting but I was in contact with > couple > committers before. > I voted as well but that was after announcement of voting results. > > Cheers, > > Adam Wojtuniak > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [aries] Moved geronimo blueprint implementation into aries podling
Please note that the aries-private mailing list is subscription moderated and currently restricted to mentors or ASF *members* until the community is bootstrapped. So please do not subscribe unless you fall into one of those two categories. On Tue, Sep 29, 2009 at 05:22, Kevan Miller wrote: > > On Sep 28, 2009, at 3:23 PM, Guillaume Nodet wrote: > >> Ok, let's put everything in standby until those lists are created. > > OK, the mailing lists have been created. Thanks Brett Porter! > > aries-dev-subscr...@incubator.apache.org > aries-user-subscr...@incubator.apache.org > aries-commits-subscr...@incubator.apache.org > aries-private-subscr...@incubator.apache.org > > --kevan > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [aries] Moved geronimo blueprint implementation into aries podling
Ok, let's put everything in standby until those lists are created. On Mon, Sep 28, 2009 at 21:19, Stuart McCulloch wrote: > 2009/9/29 Alan D. Cabrera > >> >> On Sep 28, 2009, at 12:01 PM, Guillaume Nodet wrote: >> >> 2009/9/28 Alan D. Cabrera : >>> >>>> >>>> On Sep 28, 2009, at 7:12 AM, Kevan Miller wrote: >>>> >>>> >>>>> On Sep 28, 2009, at 9:32 AM, Guillaume Nodet wrote: >>>>> >>>>> On Mon, Sep 28, 2009 at 15:24, David Bosschaert >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Great - let me see if I can make it part of a larger Aries build with >>>>>>> a >>>>>>> shared parent pom, a pom in the root dir etc... >>>>>>> I'd also like to rename some things from Geronimo to Aries... >>>>>>> >>>>>> >>>>>> Sure. >>>>>> I guess the first thing though is to decide on the svn layout. >>>>>> I think we should aim for a single trunk/tags/branches for now. >>>>>> This does no preclude having blueprint released separatly if needed, >>>>>> but this is another problem we can address later. >>>>>> >>>>> >>>>> Personally, I'd much prefer to see some community setup, prior to these >>>>> types of discussions and code changes -- mailing lists, committer account >>>>> setup, etc. The fact that we're forced to discuss this on general@ is, >>>>> IMO, not very good. >>>>> >>>> >>>> Agreed. Plus a quick 30 minute email discussion does not constitute >>>> community consensus. While this does not require that everything move lock >>>> step through community discussions, do not get upset if a discussion moves >>>> in a different direction after you have made impromptu changes. >>>> >>> >>> That's the whole purpose of RTC, isn't it ? >>> >> >> Yep. I think I pointed that out, albeit obliquely, above. But, since you >> point this out I'll add a finer point to RTC. The gist of RTC is that as >> people's work gets more narrowly focused, running every minute detail by the >> community makes the work impossible. Hence RTC. >> >> We are no where near there at this point. We're at the point where >> newcomers can grok what's going on in the project. It's a perfect time to >> collect opinions and to build community. > > > +1 I'd really like to see the mailing lists appear asap... it would be > annoying to have to monitor the general list for Aries discussions > > >> Regards, >> Alan >> > > -- > Cheers, Stuart > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [aries] Moved geronimo blueprint implementation into aries podling
2009/9/28 Alan D. Cabrera : > > On Sep 28, 2009, at 7:12 AM, Kevan Miller wrote: > >> >> On Sep 28, 2009, at 9:32 AM, Guillaume Nodet wrote: >> >>> On Mon, Sep 28, 2009 at 15:24, David Bosschaert >>> wrote: >>>> >>>> Great - let me see if I can make it part of a larger Aries build with a >>>> shared parent pom, a pom in the root dir etc... >>>> I'd also like to rename some things from Geronimo to Aries... >>> >>> Sure. >>> I guess the first thing though is to decide on the svn layout. >>> I think we should aim for a single trunk/tags/branches for now. >>> This does no preclude having blueprint released separatly if needed, >>> but this is another problem we can address later. >> >> Personally, I'd much prefer to see some community setup, prior to these >> types of discussions and code changes -- mailing lists, committer account >> setup, etc. The fact that we're forced to discuss this on general@ is, IMO, >> not very good. > > Agreed. Plus a quick 30 minute email discussion does not constitute > community consensus. While this does not require that everything move lock > step through community discussions, do not get upset if a discussion moves in > a different direction after you have made impromptu changes. That's the whole purpose of RTC, isn't it ? > Regards, > Alan > > > ----- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [aries] Moved geronimo blueprint implementation into aries podling
I have only set up svn write access to the four mentors. I was planning on checking with the other ones the right wau to go forward. On Mon, Sep 28, 2009 at 16:05, David Bosschaert wrote: > 2009/9/28 Guillaume Nodet > >> >> Sounds good to me. We need to set up the trunk/tags/branches first I >> think. >> > > I don't seem to have the permissions to create these. Could someone create > them or give me enough permissions so I could? > > Cheers, > > David > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [aries] Moved geronimo blueprint implementation into aries podling
On Mon, Sep 28, 2009 at 15:46, David Bosschaert wrote: > 2009/9/28 Guillaume Nodet > >> On Mon, Sep 28, 2009 at 15:24, David Bosschaert >> wrote: >> > Great - let me see if I can make it part of a larger Aries build with a >> > shared parent pom, a pom in the root dir etc... >> > I'd also like to rename some things from Geronimo to Aries... >> >> Sure. >> I guess the first thing though is to decide on the svn layout. >> I think we should aim for a single trunk/tags/branches for now. >> This does no preclude having blueprint released separatly if needed, >> but this is another problem we can address later. >> > > Yes, I was thinking a single build system for now. The layout would be: > /pom.xml (references all the submodules), can be used to kick off a build > for everything in Aries > /parent/... (parent poms, I was thinking of taking the ones from Geronimo > Genesis as the starting point > /blueprint (blueprint submodule) > /xyz (other submodule) Sounds good to me. We need to set up the trunk/tags/branches first I think. > >> >> > Finally, should we asking INFRA for a Hudson build? Or is this normally >> not >> > done for podlings? >> >> I guess Hudson should be ok. >> I don't think podlings can use Nexus for the release, but that needs >> to be double checked. >> >> > I will get back when the root pom.xml is there. Dan or someone else with > Hudson credentials can then enable. > > Cheers, > > David > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [aries] Moved geronimo blueprint implementation into aries podling
On Mon, Sep 28, 2009 at 15:24, David Bosschaert wrote: > Great - let me see if I can make it part of a larger Aries build with a > shared parent pom, a pom in the root dir etc... > I'd also like to rename some things from Geronimo to Aries... Sure. I guess the first thing though is to decide on the svn layout. I think we should aim for a single trunk/tags/branches for now. This does no preclude having blueprint released separatly if needed, but this is another problem we can address later. > Finally, should we asking INFRA for a Hudson build? Or is this normally not > done for podlings? I guess Hudson should be ok. I don't think podlings can use Nexus for the release, but that needs to be double checked. > Cheers, > > David > > 2009/9/28 Guillaume Nodet > >> The Geronimo PMC has voted to donate the blueprint implementation to >> aries, so I've gone ahead and moved the code to: >> https://svn.apache.org/repos/asf/incubator/aries/blueprint/ >> >> I guess we need to discuss how we want to organized the svn tree / >> build, and until the mailing lists are set up, we can start discussing >> that here. >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[aries] Moved geronimo blueprint implementation into aries podling
The Geronimo PMC has voted to donate the blueprint implementation to aries, so I've gone ahead and moved the code to: https://svn.apache.org/repos/asf/incubator/aries/blueprint/ I guess we need to discuss how we want to organized the svn tree / build, and until the mailing lists are set up, we can start discussing that here. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Aries project
FWIW, the web site is already up and availabe at: http://incubator.apache.org/aries/ Though there's nothing there yet. Mailing lists are not created yet, but I'' update the site as soon as they are. On Tue, Sep 22, 2009 at 20:42, Mohammad Nour El-Din wrote: > Hi Alan... > > Thanks a lot for you desire to contribute :). You should follow the > progress of Aries incubation on this list and Aries should have a site > which you can follow at this location http://incubator.apache.org/ . > There the dev mailing list and another useful info will be found. You > send a subscribtion request to the dev mailing list and follow the > dev. activities and communicate with the community and contribute > patches as much as you like ;) . > > On Tue, Sep 22, 2009 at 2:40 PM, Alan Keane wrote: >> Hi, >> I am a developer with specific interests in OSGi and JEE. I am currently >> working on a common OSGi based platform for Ericsson. The Aries proposal >> looks very interesting and I would like to contribute. >> >> Regards, >> >> Alan Keane >> > > > > -- > Thanks > - Mohammad Nour > - LinkedIn: http://www.linkedin.com/in/mnour > > "Life is like riding a bicycle. To keep your balance you must keep moving" > - Albert Einstein > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
See https://issues.apache.org/jira/browse/INFRA-2242 I've already addressed those I could (i.e. confluence and svn) On Tue, Sep 22, 2009 at 22:03, Guillaume Nodet wrote: > On Tue, Sep 22, 2009 at 21:40, Kevan Miller wrote: >> >> On Sep 22, 2009, at 2:47 PM, Upayavira wrote: >> >>> On Tue, 2009-09-22 at 10:15 -0700, Martin Cooper wrote: >>>> >>>> >>>> I'd be interested in what people thought they voted for. The list of >>>> participants seems to have been constantly changing throughout the >>>> vote, but we can only be voting on one proposal, so which one was it? >>>> Did people who voted early implicitly vote for people who were not on >>>> the list at the time they voted? That doesn't sound right to me. >>> >>> They were voting on the proposal included in the initial vote mail. The >>> wiki is nothing more than a collaboration point for coming up with the >>> vote email. >>> >>> Any additions to the wiki since that vote are irrelevant, and must not >>> be included in the initial committer list. >> >> OK. So, I see two people (Adam Wojtuniak and Alan Keane) who asked to join >> the project yesterday and today. Agreed that they should be joining the >> project through normal community process, not via initial committer list. > > Agreed > >> >> I also see Niclas Hedhman's name on the Wiki list, but not on the initial >> committer's list. I'll also assume that Niclas should be joining the project >> via normal community processes. > > Given Niclas is a trusted ASF member, we may apply different rules here. > >> Finally, Bertrand Delacretaz volunteered to be a mentor, during the vote. I >> will assume his oversight is welcomed by all and will treat him as an >> initial mentor. > > +1 > > I will raise the INFRA issues to set up all the resources asap. > >> --kevan >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
On Tue, Sep 22, 2009 at 21:40, Kevan Miller wrote: > > On Sep 22, 2009, at 2:47 PM, Upayavira wrote: > >> On Tue, 2009-09-22 at 10:15 -0700, Martin Cooper wrote: >>> >>> >>> I'd be interested in what people thought they voted for. The list of >>> participants seems to have been constantly changing throughout the >>> vote, but we can only be voting on one proposal, so which one was it? >>> Did people who voted early implicitly vote for people who were not on >>> the list at the time they voted? That doesn't sound right to me. >> >> They were voting on the proposal included in the initial vote mail. The >> wiki is nothing more than a collaboration point for coming up with the >> vote email. >> >> Any additions to the wiki since that vote are irrelevant, and must not >> be included in the initial committer list. > > OK. So, I see two people (Adam Wojtuniak and Alan Keane) who asked to join > the project yesterday and today. Agreed that they should be joining the > project through normal community process, not via initial committer list. Agreed > > I also see Niclas Hedhman's name on the Wiki list, but not on the initial > committer's list. I'll also assume that Niclas should be joining the project > via normal community processes. Given Niclas is a trusted ASF member, we may apply different rules here. > Finally, Bertrand Delacretaz volunteered to be a mentor, during the vote. I > will assume his oversight is welcomed by all and will treat him as an > initial mentor. +1 I will raise the INFRA issues to set up all the resources asap. > --kevan > > > --------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
I guess this is really a wording problem. I don't think anyone is thinking about bringing Geronimo, James, ServiceMix, CXF, Axis, ActiveMQ or anything like that into Aries. The real goal as it has been said an OSGi Enterprise Programming Model, and the comparison that has been made with Geronimo is not bad. We already know it will include some of the specs that comes from the OSGi Enterprise Expert Group and that's why they have been mentioned. Just keep the following sentences in mind: "The Aries project will deliver a set of pluggable Java components enabling an enterprise OSGi application programming model. This includes implementations and extensions of application-focused specifications defined by the OSGi Alliance Enterprise Expert Group (EEG) and an assembly format for multi-bundle applications, for deployment to a variety of OSGi based runtimes." The first sentence is the key one. The second one just try to explicit it by listing things that we know or think will be developed in Aries. Or at least, that Aries would need to define its programming model.Please read the relationship between Aries and various other TLPs. For example the OpenJPA section. Aries doesn't aim at implementing JPA, but it aims at integrating JPA into OSGi. I think the same would be true for JMS / ActiveMQ. I think for each technology Aries enables, we'll have first to develop this integration layer, then if it makes more sense to contribute it back to another TLP, it will be done. I think that's how it should work. It is what happened in other TLPs: Camel was first developed inside ActiveMQ but moved to TLP because it did not really fit in ActiveMQ. Felix Karaf has originally been developed inside ServiceMix for its use, but given it was not really tied to ServiceMix, nor in the real scope of the project, it has been moved as a Felix subproject. Just let us create the community and I'm sure it will find a good way to nicely cooperate with other TLPs. On Fri, Sep 18, 2009 at 13:26, Niclas Hedhman wrote: > On Fri, Sep 18, 2009 at 4:50 PM, Robert Burrell Donkin > wrote: > >> targeting an exit as a felix sub-project would require the aries >> proposes to start again with approval from the felix proposal and so >> on. it may also prove controversial. > > You missed the point. It is not about exit strategy, it is about "What > belongs and/or not in Aries?". That question is answered in the > proposal like "enterprise spec impl", but also "anything OSGi > enterprisey", which I then claim includes he components for just about > every single project (impl using OSGi) at the ASF. ServiceMix is using > OSGi, so of course anything that can be componentized should be stuck > into Aries. How about James? Are you guys in OSGi yet? So, your > components go into Aries, right? How about Geronimo? WS-*? > If the proposal is re-written to a more concise language of what the > focus really is, then I gladly change my vote. > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug > > ----- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
ding vendors of OSGi-based technologies and > have a long standing in the OSGi Alliance whose application-centric > specifications this project will implement. There is minimal risk of > this work becoming non-strategic and the contributors are confident > that a larger community will form within the project in a relatively > short space of time. > Inexperience with Open Source > > Many of the committers have experience working in one or more open > source projects including Apache Geronimo, Felix, ServiceMix, OpenEJB, > and CXF. > > Homogeneous Developers > > The list of initial committers, geographically distributed across the > U.S. and Europe, consists of developers from two companies - IBM and > Progress software - with similar goals but for different scenarios. > Many of these developers are experienced Apache committers already and > all are experienced with working in distributed development > communities. It is our hope that, through the incubator, further > contributors with a broad background of experience but common interest > in enterprise OSGi technologies will become involved with this > project. > > Relationships with Other Apache Projects > > Aries will have a potential relationship with the Apache projects > listed in this section. These projects all serve different purposes > from Aries and have their own communities. It is hoped that each of > these communities will become involved with Aries and help to build a > diverse but independent Aries community. > > Apache Felix Karaf - > http://felix.apache.org/site/apache-felix-karaf.html Apache Felix > Karaf is an OSGi based runtime which provides a lightweight container > onto which various components and applications can be deployed. It is > related to Aries: > > 1. as a target OSGi based runtime to which Aries applications can > be deployed. In this role, Karaf is a consumer of Aries technology. > > Apache Felix - http://felix.apache.org/site/index.html Apache Felix is > primarily a core OSGi framework implementation. It is related to > Aries: > > 1. as an underlying OSGi framework implementation and potentially > other extensions that can be used both by Aries run-time components > and the applications which use them. > > Apache Geronimo - http://geronimo.apache.org/ Apache Geronimo is a > server runtime framework and fully certified Java EE 5 application > server runtime. It is related to Aries in two ways: > > 1. as a target runtime to which Aries applications can be deployed. > In this role, Geronimo is a consumer of Aries technology. > 2. the Geronimo blueprint sandbox - > http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/ - contains > an implementation of the OSGi Blueprint container which will be moved > to Aries. > > Apache Tuscany - http://tuscany.apache.org/ Apache Tuscany provides a > comprehensive infrastructure for SOA development and management that > is based on Service Component Architecture (SCA) standard. It can be a > consumer of Aries technology to provide an Aries SCA implementation > type for composing Aries applications in coarse grained and > potentially heterogeneous service assemblies. > > Apache CXF - http://cxf.apache.org/ Apache CXF provides a Java Web > Services framework for distributed computing and remote service > realization and invocation using API's such as JAX-WS and JAX-RS. It > also provides the OSGi Remote Services (OSGi RFC 119) reference > implementation in a subproject: > http://cxf.apache.org/distributed-osgi.html. It is related to Aries in > the following way: > > 1. As Remote Services is a significant Enterprise specification > being produced by the EEG, it is expected that consumers of Aries will > be looking for an implementation of this specification. CXF provides > an implementation of this specification which already has a > significant active community. The Aries project will make it easy for > Aries consumers to consume the CXF Remote Services implementation, > possibly by providing an instance of the application model that > references the CXF Remote Services implementation. This would mean > that end users will seamlessly pull in the required componen -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
I've added both Jean-Sebastien and you to the proposal. 2009/9/11 Carsten Ziegeler : > Hi, > > sounds like interesting stuff. I would like to be added to the initial > committer list as well :) > > Thanks > Carsten > -- > Carsten Ziegeler > cziege...@apache.org > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
For things that come from ServiceMix, I think the story is really different. ServiceMix TLP charter is the following: "an extensible messaging bus for service integration, mediation and composition and its related components". So clearly, Karaf, as an enhanced OSGi runtime distribution, does not really fit in ServiceMix. However, the ASF has never prevented two projects to have overlapping charters. And the scope of Aries is much more narrow than Felix to avoid becoming an umbrella project with lots of disjoint communities. On Fri, Sep 4, 2009 at 15:03, Karl Pauls wrote: > Let me point out one more time: Nobody is talking about Aries as a > Felix "incubator" project. We are only talking about the OSGi EE spec > implementations that are part of the proposed Aries scope. > > I'd be more then happy to see the rest of the proposal (namely, to > explore how to build an enterprise component model on OSGi and the > other non-spec related topics) become a reality by means of a new > incubator project. Whether that ends-up as a felix sub-project or as a > sub-project or TLP in the end we don't have to discuss right now. > > In regard to the other half of the proposal I do think you would be > better off to develop them over at Felix and I'm sure we would be more > then happy to support you and find solutions to any issues you might > have (as we recently did with karaf). Not the end of the world if not > but not what I would prefer nor see as the best solutions for neither > Felix nor Aries. > > regards, > > Karl > > On Fri, Sep 4, 2009 at 1:51 PM, Guillaume Nodet wrote: > > There are a few things I don't understand well. I thought the ASF over > the > > past years was trying to discourage umbrella projects. I also thought > that > > overlap between the projects was indeed accepted (we already have > multiple > > JAX-WS or JAX-RS implementations in various TLPs / podlings). > > That was rather clear in my mind, so I must have missed something. > > > > But let's try to be constructive ... > > > > Given the state and objectives of Aries (which means there's not much > code > > right now), I don' think it's wise to start splitting now between pure > OSGi > > specs implementations and other extensions, especially because some of > the > > possible specs mentionned are not yet spec, and Aries would become an > input > > / feedback source for creating those specifications. > > > > That said, we need to find a home for this proposal. It seems Felix > might > > be a good place, so this basically means incubating Aries inside a Felix > as > > a subproject (I still think this is the role of the incubator, but let's > put > > that aside). > > It means creating a subproject in Felix in a sandbox opened to all ASF > > committers, and having a very low entry barrier for people that are not > ASF > > committers yet but want to contribute to Aries (as I said, it's difficult > to > > contribute patches when the code is inexistant at this point). Another > > thing to help creating a community around Aries would be to have the > > possibility to have dedicated mailing lists and web site as a lot of TLP > do > > for their subprojects. Plus, there are some code donations, so we also > need > > to take care of the IP clearance. Binding votes would be those of the > Felix > > PMC of course. Then, when the pseudo-incubation is completed, Aries > could > > either become a real Felix subproject, its own TLP, or be split. > > > > I really don't see the value in that, as it seems I've just described > what > > the Incubator has been set up for afaik. And as any new podling > proposal, > > any ASF committer is free to join at this point. So there's really not > much > > difference between every people from felix joining aries podling. But I > > really don't want to fight for that and I'd personally be ok if the Felix > > PMC wants to become an incubator for Aries. > > > > > > On Fri, Sep 4, 2009 at 11:29, Bertrand Delacretaz < > bdelacre...@apache.org>wrote: > > > >> On Fri, Sep 4, 2009 at 7:50 AM, Niclas Hedhman > wrote: > >> > On Fri, Sep 4, 2009 at 1:23 PM, Kevan Miller > >> wrote: > >> > > >> >>... What would be the > >> >> benefit for the Aries community of developing these spec > implementations > >> at > >> >> Felix? > >> > > >> > Ideally, you have more people taking care of any issues. More > >> > importantly, you need
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
he anyway, and I think the > other projects mentioned above are working like that, which is a Good > Thing, > > I'm very happy to see Guillaume as a mentor for Aries, that will > hopefully help in building bridges between Felix and Aries. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Fri, Sep 4, 2009 at 07:50, Niclas Hedhman wrote: > On Fri, Sep 4, 2009 at 1:23 PM, Kevan Miller > wrote: > > > So, let's assume that one or more OSGi spec implementations are a core > part > > of Aries -- with specific features/customization for Aries. Personally, > it > > seems reasonable that an Aries project would want these customized spec > > implementations close at hand -- within their project. > > I would like to draw attention to "Pax Web", which is both a OSGi Http > Service implementation as well as many extensions, such as war, jsp, > filter support. Yet it is done in a way of a custom extension > mechanism (Pax Web Extender), so that if you only use Pax Web, you > only get the basic spec implementation, nothing more, nothing less. I > am sure a similar approach could be made here, where the clean spec > part is at one place and the customizations are "close at hand". > My real problem is not the location, but really the fact that we'd split things. Do you really see how easy it would be if pax-web was developed at apache and pax-web-extender in ops4j ? The two are somewhat tied together, and the value for having pax-web somewhere else is much lessened by the problems it would bring (it would be much more difficult to keep both in sync, meaning the communities have to be roughly the same, and what about the release process which would be much more difficult too). For Aries, I would see the same problem. That might be even worse given some of the things that are supposed to be done don't exist yet. So when you have an existing code base, you can envision splitting it into two when it's mature enough. Another thing, is that some things are not yet OSGi spec, but might become so in the future (such as application metadata and such), so it might be difficult to choose a destination right now. For blueprint, some aspects are not yet standardized (such as custom namespaces), so they are tightly bound to the implementation. I don't think it would make much sense to split that either. Let's try to find a solution to this problem. > > > What would be the > > benefit for the Aries community of developing these spec implementations > at > > Felix? > > Ideally, you have more people taking care of any issues. More > importantly, you need to think outside the project and ask "What would > be the benefit for ASF...?", and IMHO having a complete spec suite > from one place benefits ASF as a whole. > > >> The only conclusions I see being drawn by people who have invested very > >> little in Felix is that we should dismantle the Felix charter so that we > can > >> accommodate the fact that some people don't want to play with us. > > > > I don't know why anybody would want to "dismantle the Felix charter". I'm > > not sure why Aries would impact that one way or another... > > Richard is over-reacting, and statements like that should be left for > it is; an attempt to blow things out of proportion to gain sympathy, > possibly out of frustration. > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
> wrote: >>>> >>>> I'm not sure I understand the issue here. Whether Aries becomes its >>>> own TLP, or a sub-project of Felix or some other TLP, isn't relevant >>>> until the project is ready to exit incubation. Why does it warrant >>>> such apparently intense discussion before the project is even accepted >>>> >>>> >>> We are actually discussing something else. We are discussing the scope of >>> the proposal, which includes hosting OSGi standard service implementations, >>> which is part of Felix' scope. >>> >>> If we are developing standard OSGi services within Apache, then Felix >>> provides an enthusiastic community to do this and there is no need to start >>> another incubator project for such a purpose. On the other hand, stuff like >>> "a set of pluggable Java components enabling an enterprise OSGi application >>> programming model" makes perfect sense to be incubated. >>> >> >> Thanks for the clarification... So, your issue is mainly with "It is a >> goal of the Aries project to provide a natural home for open source >> implementations of current and future OSGi EEG specifications..."? >> Personally, I tend to think of Felix in terms of OSGi Core Platform. I >> certainly hadn't expected it to be the source for all OSGi standard >> implementations from Apache -- not for implementations of Enterprise Expert >> Group specs, anyway. I'm sure there are flaws with my perceptions... >> >> So, we have a group that is interested in working on an enterprise OSGi >> application programming model at Apache (including implementations of at >> least some EEG specifications). An incubator project would seem to be an >> excellent place for this work to start. Interested Felix community members >> would certainly be able to join this effort. >> >> It then becomes a question of, assuming successful incubation, where does >> the community graduate to? TLP, Felix subproject(s), or elsewhere. All >> successful outcomes, IMO. >> >> --kevan >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Tue, Sep 1, 2009 at 18:06, Richard S. Hall wrote: > > Creating another project to host OSGi spec implementations seems > unnecessary. And, from my point of view, only serves to foster this > mentality that Felix projects are framework specific. I do not buy your > argument that we cannot educate the non-techie that this is not true. Do > such work at Felix is exactly how we educate them. Of course, we could also > discuss other ways to improve this. > > Well, the problem I see here is that we *need* to educate non-techies. This obvisouly mean that there is a confusion. Education is just a work around the need to remove the confusion imho. So let's discuss that on d...@felix.a.o, I don't think this thread belongs here. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
g entity scanning and enhancement. The Aries project >> will make it easy for JPA persistence providers such as OpenJPA to be >> used in an OSGi environment and will provide container managed >> persistence for the Blueprint container. >> >> Documentation >> >> An early draft of OSGi v4.2 core and compendium specifications - which >> includes the Blueprint container specification - is available at: >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf >> Initial Source >> >>* The Blueprint container impl from the Geronimo sandbox will be >> moved to the Aries project for further development: >> http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint >>* IBM will also contribute code for: >> o container-managed JPA support in an OSGi environment. >> o making OSGi services visible to Java EE components through >> JNDI. >> o packaging web components as bundles and a URL handler for >> recognizing and converting non-bundled Web components >>* We will also be soliciting implementations of other OSGi >> enterprise application-centric specifications. >> >> External Dependencies >> >>* Apache Ant http://ant.apache.org Apache License >>* Apache Commons http://commons.apache.org Apache License >>* Junit (Java unit test framework) http://junit.sourceforge.net CPL >> v1.0 license: http://junit.sourceforge.net/cpl-v10.html >>* Apache Felix (implementation of the OSGi Core and Compendium >> specifications - compliance level unknown) http://felix.apache.org >> Apache License (hosted by ASF). >>* Eclipse Equinox (compliant implementation of the OSGi Core >> Specification and Compendium specifications) >> http://eclipse.org/equinox/ Eclipse Public License >>* OpenJPA http://openjpa.apache.org Apache License >>* Serp http://serp.sourceforge.net/ BSD >>* Apache Geronimo http://geronimo.apache.org Apache License >> >> Required Resources >> Mailing lists >> >> aries-private (with moderated subscriptions) >> aries-dev >> aries-commits >> aries-user >> >> Subversion Directory >> >> http://svn.apache.org/repos/asf/incubator/aries >> >> Issue Tracking >> >> JIRA (ARIES) >> >> Web Site >> >> Confluence (Aries) >> >> Initial Committers >> >> Names of initial committers with affiliation and current ASF status: >> >>* Alasdair Nottingham (IBM) >>* Andrew Osborne (IBM) >>* Dan Kulp (Progress, ASF member) >>* David Bosschaert (Progress, ASF committer) >>* David Jencks (IBM, ASF member) >>* Eoghan Glynn (Progress, ASF committer) >>* Graham Charters (IBM) >>* Guillaume Nodet (Progress, ASF member) >>* Hiram Chirino (Progress, ASF member) >>* Ian Robinson (IBM) >>* James Strachan (Progress, ASF member) >>* Jarek Gawor (IBM, ASF member) >>* Jeremy Hughes (IBM, ASF committer) >>* Joe Bohn (IBM, ASF committer) >>* Lin Sun (IBM, ASF committer) >>* Mark Nuttall (IBM) >>* Oisin Hurley (Progress) >>* Rick McGuire (IBM, ASF committer) >>* Sergey Beryozkin (Progress, ASF committer), >>* Timothy Ward (IBM) >>* Valentin Mahrwald (IBM) >>* Zoe Slattery (IBM) >> >> Affiliations >> >> The majority of the initial committers are employed by IBM corp or >> Progress Software. One objective of the incubator is to attract a >> diverse community of contributors and we anticipate future >> contributors to have other affiliations. >> >> Sponsors >> Champions >> >> Kevan Miller, Guillaume Nodet >> >> Nominated Mentors >> >> Guillaume Nodet, Davanum Srinivas (Dims) >> >> Sponsoring Entity >> >> The incubator. Successful graduation from Incubator should result in >> Aries becoming a new TLP. >> >> - >> 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 > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
r composing Aries applications in coarse >> grained and potentially heterogeneous service assemblies. >> >> Apache CXF - http://cxf.apache.org/ Apache CXF provides a Java >> Web Services framework for distributed computing and remote service >> realization and invocation using API's such as JAX-WS and JAX-RS. It >> also provides the OSGi Remote Services (OSGi RFC 119) reference >> implementation in a subproject: >> http://cxf.apache.org/distributed-osgi.html. It is related to Aries in >> the following way: >> >> 1. As Remote Services is a significant Enterprise specification >> being produced by the EEG, it is expected that consumers of Aries will >> be looking for an implementation of this specification. CXF provides >> an implementation of this specification which already has a >> significant active community. The Aries project will make it easy for >> Aries consumers to consume the CXF Remote Services implementation, >> possibly by providing an instance of the application model that >> references the CXF Remote Services implementation. This would mean >> that end users will seamlessly pull in the required components from >> CXF by using the Aries-provided definition. >> >> Apache ServiceMix - http://servicemix.apache.org/ Apache >> ServiceMix provides an ESB that combines the functionality of a >> Service Oriented Architecture (SOA) and Event Driven Architecture >> (EDA) to create an agile ESB. ServiceMix runs on OSGi and was the >> source of the Apache Felix Karaf runtime. It can be a consumer of >> Aries applications and associated componentry as a natural evolution >> of its existing Karaf "feature" usage. >> >> Apache OpenJPA - http://openjpa.apache.org/ Apache OpenJPA is a >> Java persistence project. It is related to Aries as a JPA persistence >> provider, including entity scanning and enhancement. The Aries project >> will make it easy for JPA persistence providers such as OpenJPA to be >> used in an OSGi environment and will provide container managed >> persistence for the Blueprint container. >> >> Documentation >> >> An early draft of OSGi v4.2 core and compendium specifications - which >> includes the Blueprint container specification - is available at: >> http://www.osgi.org/download/osgi-4.2-early-draft3.pdf >> Initial Source >> >> * The Blueprint container impl from the Geronimo sandbox will be >> moved to the Aries project for further development: >> http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint >> * IBM will also contribute code for: >> o container-managed JPA support in an OSGi environment. >> o making OSGi services visible to Java EE components through JNDI. >> o packaging web components as bundles and a URL handler for >> recognizing and converting non-bundled Web components >> * We will also be soliciting implementations of other OSGi >> enterprise application-centric specifications. >> >> External Dependencies >> >> * Apache Ant http://ant.apache.org Apache License >> * Apache Commons http://commons.apache.org Apache License >> * Junit (Java unit test framework) http://junit.sourceforge.net CPL >> v1.0 license: http://junit.sourceforge.net/cpl-v10.html >> * Apache Felix (implementation of the OSGi Core and Compendium >> specifications - compliance level unknown) http://felix.apache.org >> Apache License (hosted by ASF). >> * Eclipse Equinox (compliant implementation of the OSGi Core >> Specification and Compendium specifications) >> http://eclipse.org/equinox/ Eclipse Public License >> * OpenJPA http://openjpa.apache.org Apache License >> * Serp http://serp.sourceforge.net/ BSD >> * Apache Geronimo http://geronimo.apache.org Apache License >> >> Required Resources >> Mailing lists >> >> aries-private (with moderated subscriptions) >> aries-dev >> aries-commits >> aries-user >> >> Subversion Directory >> >> http://svn.apache.org/repos/asf/incubator/aries >> >> Issue Tracking >> >> JIRA (ARIES) >> >> Web Site >> >> Confluence (Aries) >> >> Initial Committers >> >> Names of initial committers with affiliation and current ASF status: >> >> * Alasdair Nottingham (IBM) >> * Andrew Osborne (IBM) >> * Dan Kulp (Progress, ASF member) >> * David Bosschaert (Progress, ASF committer) >> * David Jencks (IBM, ASF member) >> * Eoghan Glynn (Progress, ASF committer) >> * Graham Charters (IBM) >> * Guillaume Nodet (Progress, ASF member) >> * Hiram Chirino (Progress, ASF member) >> * Ian Robinson (IBM) >> * James Strachan (Progress, ASF member) >> * Jarek Gawor (IBM, ASF member) >> * Jeremy Hughes (IBM, ASF committer) >> * Joe Bohn (IBM, ASF committer) >> * Lin Sun (IBM, ASF committer) >> * Mark Nuttall (IBM) >> * Oisin Hurley (Progress) >> * Rick McGuire (IBM, ASF committer) >> * Sergey Beryozkin (Progress, ASF committer), >> * Timothy Ward (IBM) >> * Valentin Mahrwald (IBM) >> * Zoe Slattery (IBM) >> >> Affiliations >> >> The majority of the initial committers are employed by IBM corp or >> Progress Software. One objective of the incubator is to attract a >> diverse community of contributors and we anticipate future >> contributors to have other affiliations. >> >> Sponsors >> Champions >> >> Kevan Miller, Guillaume Nodet >> >> Nominated Mentors >> >> Guillaume Nodet, Davanum Srinivas (Dims) >> >> Sponsoring Entity >> >> The incubator. Successful graduation from Incubator should result in >> Aries becoming a new TLP. >> >> - >> 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 > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: POLOKA proposal in context of existing Apache projects
I think it would be beneficial for the project to have a clear distinction between the WS-BrokeredNotification engine and its web service binding, so that it could be reused without any binding inside ServiceMix. My understanding is that the POLOKA implementation goes way beyond what ServiceMix WS-BrokeredNotification engine currently provides, so ServiceMix may be able to switch to use it. About the RETE engine, it would also be nice to ensure that this engine is reusable by itself and may become a subproject on its own (or maybe even a TLP at some point). I also think, that aiming for its own TLP may be better for POLOKA, but it will be to the PPMC to decide when times to graduate comes. Imho, we should just start a vote at some point on the incubator mailing list, which should be able to sponsor this project itself (there is no requirement to have any other TLP so sponsor a podling). That said, I'd like to offer my help as a mentor on this project. On Fri, Nov 7, 2008 at 9:54 PM, Mankovskii, Serge <[EMAIL PROTECTED]> wrote: > Hi Davanum, > > > > In our search for a Champion and Sponsor for the Poloka proposal > http://wiki.apache.org/incubator/PolokaProposal We looked into the > Savan, ServiceMix, Axis2, and MUSE projects. > > > > We find that it makes most sense, so far, to have Poloka as a project > under Axis2. It also makes sense to go into the ServiceMix, that > implements WS-Notification already, but objectives of ServiceMix and > POLOKA are somewhat different in respect to POLOKA goal to provide a > stand-alone reference implementation of the spec. Bringing entire > ServiceMix in the picture might be too much. However ServiceMix could > benefit from the POLOKA work in the future. > > > > Poloka (http://poloka.org) could create an Axis2 module implementing > handlers creating a messaging network for a federation of Axis2 servers. > This way we would be able to support > > - Standalone WS-Notification compliant notification producer and > notification consumer > > - Standalone WS-BrokeredNotification broker > > - Federation of WS-BrokeredNotification brokers. > > > > It would make sense to integrate Savan functionality within Poloka as > time goes but not other way around. I think so because Poloka objective > is broader than Savan objective in respect to: > > - Broker support > > Broker support is defined in WS-Notification and not in WS-Eventing. > Although it is possible that once a broker with WS-Eventing interface is > created, the picture might change. > > - Subscription > > WS-Eventing defines subscription language based on XPath (content-based > semantic). WS-Notification defines subscription Filers using Topic > Dialects (topic-based semantic), XPath over message content > (content-based semantic, same as in WS-Eventing), and resource > properties (optional and unclear semantics, needs refinement in the > spec). > > - Matching performance > > It seems that we can improve performance of XPath matching based on the > research done by the PADRES http://research.msrg.utoronto.ca/pub/Padres > project. It would be equally applicable to WS-Notification and > WS-Eventing. Naweed Tajuddin, a Master student of Prof. Arno Jacobsen, > is looking specifically into this issue for his master thesis. > > > > What do you think? > > > > We are looking for the input and guidance of the Apache community in > moving the POLOKA proposal forward. Please help! > > > > Regards > > Serge > > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: On incubating releases
What about allowing podlings to do release without using the org.apache.* packages or the apache brand anywhere in the release ? These would be just plain Apache Licensed releases without any ties to the Apache brand. Such releases, not endorsed by the ASF could be synced to the central repo without any objections as there would be no more ties to the Apache brand. When the podling graduates, it could use the org.apache packages as the ASF endorses the project. This would be more incentive for the podling to graduate, without adding barriers to be able to build the community. On Fri, Oct 3, 2008 at 4:09 PM, Aidan Skinner <[EMAIL PROTECTED]> wrote: > On Fri, Oct 3, 2008 at 2:53 PM, Jukka Zitting <[EMAIL PROTECTED]>wrote: > > >> Do people think that we shouldn't make such a distinction, or that we >> should perhaps explicitly consider "community quality" as a release >> criteria? >> > > Getting releases out of the incubator is difficult and subjective enough as > it is. Without regular releases it would be nearly impossible to build a > community around a project. Without being able to do that, why would anybody > engage in this process in the first place? > > - Aidan > -- > Apache Qpid - World Domination through Advanced Message Queueing > http://cwiki.apache.org/qpid > "Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
+1 On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > We've had a number of long discussions about the incubating projects > using the central Maven repository to distribute their releases. The > current policy is that incubating releases should not go to there. The > related discussion threads have died with no consensus but the issue > still exists and affects many podlings. I would like to finally > resolve the issue one way or another by calling the Incubator PMC to > vote on the matter. > > In INCUBATOR-82 I have prepared a patch (also attached below) that > changes the policy document to explicitly _allow_ extra distribution > channels like the central Maven repository for incubating releases. > Note that the proposed patch allows any such channels instead of > focusing just on the Maven repository. Also, any releases must still > be approved, comply with the disclaimer and naming rules, and be > primarily distributed through the official > http://www.apache.org/dist/incubator/ channel. > > Please vote on accepting or rejecting this policy change! This > majority vote is open for a week and only votes from the Incubator PMC > members are binding. > > [ ] +1 Yes, allow extra release distribution channels like the central > Maven repository > [ ] -1 No, keep the current policy > > My vote is +1 > > BR, > > Jukka Zitting > > Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: > > Index: site-author/incubation/Incubation_Policy.xml > === > --- site-author/incubation/Incubation_Policy.xml(revision 692094) > +++ site-author/incubation/Incubation_Policy.xml(working copy) > @@ -489,6 +489,8 @@ > > Releases for podling MUST be distributed through > http://www.apache.org/dist/incubator/podling. > +In addition, the Podling MAY choose to distribute approved releases through > +other channels like the central Maven repository. > > > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Poloka
Yeah, one of our user wants to contribute new features to the WS notification broker, so she may be interested. FYI, the WS-Notification service engine code is located here: https://svn.apache.org/repos/asf/servicemix/components/engines/servicemix-wsn2005/trunk/ We're using CXF wsdl2java tool to generate the classes and interfaces from the WSDL, then provide implementation of those on top of a JMS broker. On Thu, Sep 4, 2008 at 5:56 PM, Mankovskii, Serge <[EMAIL PROTECTED]> wrote: > Hi Guillaume, > > This is interesting! Thank you for the tip on ServiceMix. I will take a > look in the ServiceMix code. > > Do you think it would make sense to send the Poloka proposal to the > ServiceMix mailing list? > > > Cheers > Serge > > > -Original Message- > From: Guillaume Nodet [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2008 5:05 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] Poloka > > Btw, Apache ServiceMix also has a JBI service engine implementating > WS-BrokeredNotification on top of a JMS broker (which btw saves a lot > of work ...). It would be interesting to see if we can come up with > something that could be shared by the three projects (Savan, Poloka > and ServiceMix) ... > > On Wed, Aug 20, 2008 at 5:55 PM, Mankovskii, Serge > <[EMAIL PROTECTED]> wrote: >> I am re-sending this proposal because the first time it ended up in > the >> Etch proposal thread. Sorry Etch guys! >> >> >> >> >> >> This is a proposal to enter Poloka in to the incubator. >> >> >> >> See http://wiki.apache.org/incubator/PolokaProposal >> >> >> >> We do not have a champion at the moment. >> >> >> >> We are looking forward to the community input. >> >> >> >> >> >> Cheers >> >> Serge Mankovski >> >> -- >> >> >> >> = POLOKA Project Proposal = >> >> >> >> >> >> == Abstract == >> >> >> >> Poloka will be a standalone reference implementation of the >> WS-BaseNotification, WS-Topics and the WS-BrokeredNotification >> standards. It is aiming to go beyond the WS-BrokeredNotification >> specification and deliver a reliable and scalable network of >> WS-BrokeredNotification brokers. All existing implementations of >> WS-BrokeredNotification focus on implementation of a message broker. >> >> Poloka will implement additional features that would allow for a >> federation of brokers. It will extend WS-BrokeredNotification >> specification with the notion of a federated broker network and allow >> for a reliable, a scalable and a highly available implementation of > the >> WS-BrokeredNotification standard. >> >> >> >> == Proposal == >> >> >> >> Poloka will provide a reference implementation of WS-BaseNotification, >> WS-Topics and WS-BrokeredNotification standards. The project will >> provide a clear separation of functionality required by the existing >> standards from additional functionality provided as an enhancement and >> elaboration on the standards >> >> >> >> Poloka will: >> >> 1. not be tightly coupled with WS-RF and WSDM standards >> >> 1. implement the WS-BrokeredNotification specification absent in >> >> the Apache Muse project >> >> 1. will implement a network of brokers that will provide >> >> scalability, reliability and fault tolerance >> >> 1. feed implementation and design experiences into the OASIS >> >> standards process and might lead to new revisions of the > WS-Notification >> stack of standards >> >> >> >> == Background == >> >> >> >> Poloka is a second generation of the research project going on for the >> last five years at the University of Toronto's Middleware Systems >> Research Group under the >> [http://research.msrg.utoronto.ca/Padres/WebHome PADRES] project. >> >> During these years the group developed a stable code base that will > form >> a base for the first release of Poloka. >> >> >> >> The PADRES project has developed a number of new technologies that > allow >> for a scalable and reliable federation of publish/subscribe brokers. > The >> PADRES federation mechanisms allow for redundant message routing, load >> balancing, complex event processing and other useful features that >> become available to the federated network of the > WS-BrokeredNotification >> broke
Re: [PROPOSAL] Poloka
eneral Public license > > * pg73jdbc3.jar: BSD license > > > > Dependency on Exolab, GNU, BSD and Sun licensed code is localized and > non-essential. > > > > === Cryptography === > > > > Some of the aspects of secure message transport include message > encryption > > > > === Required Resources === > > > > * Mailing Lists - there are two mailing lists > > * Subversion Directory - it exists, but it is not available outside of > the Middleware Systems Research Group > > * Issue Tracking - it exists, but it is not available outside of the > Middleware Research Systems Group > > * Other Resources > > > > == Initial Committers == > > > > * Arno Jacobsen > > * Serge Mankovski > > * NaweedTajuddin > > * Balasubramaneyam Maniymaran > > * Vinod Muthusamy > > * Alex Cheung > > * Guoli Li > > * Reza Sherafat > > > > > > == Affiliations == > > * Hans-Arno Jacobsen - University of Toronto > > * Serge Mankovski - CA Labs > > * Kirk Wilson - CA Labs > > * Peter Niblett - IBM > > * Mark Weitzel - IBM > > * Naweed Tajuddin - University of Toronto > > * Balasubramaneyam Maniymaran - University of Toronto > > * Vinod Muthusamy - University of Toronto > > * Alex Cheung - University of Toronto > > * Guoli Li - University of Toronto > > * Reza Sherafat - University of Toronto > > * Shuang Hou - Academy of Science of China > > > > > > > > == Sponsors == > > * Champion TBD > > * Nominated Mentors TBD > > * Sponsoring Entity TBD, but we think we should be somewhere in > WS-Commons > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: INCUBATOR-57 aka IPMC votes to ratify PPMC committers
+1 On Tue, Jun 3, 2008 at 10:29 PM, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: > Currently on http://incubator.apache.org/guides/ppmc.html, we have: > --- > Vote on the podling's private (PPMC) list, with notice posted to the > Incubator private list. The notice is a separate email forwarding the > vote email with a cover statement that this vote is underway on the > podling's private list. Many consider this approach to be best > practice. After completing the vote on the PPMC list, the proposer > calls a vote on the Incubator PMC private list, summarizing the > discussion and vote, with a reference to the archived discussion and > vote threads by the PPMC. The Incubator vote is done even if there are > three +1 votes from Incubator PMC members during the PPMC vote, in > order to give all Incubator PMC members a chance to express their > support or disapproval after seeing the PPMC discussion and vote > results. Note that only the Incubator PMC members can see the > Incubator private discussion, and the podling's Mentors should review > all Incubator PMC feedback with the PPMC. Moreover, only Apache > members may review the private PPMC list (this is normally not an > issue since most Incubator PMC members are Apache members). > --- > > I'd like to make the suggestion that we alter this to: > --- > Vote on the podling's private (PPMC) list, with notice posted to the > Incubator private list. The notice is a separate email forwarding the > vote email with a cover statement that this vote is underway on the > podling's private list. Many consider this approach to be best > practice. After completing the vote on the PPMC list, the proposer > *sends a note to* the Incubator PMC private list, summarizing the > discussion and vote, with a reference to the archived discussion and > vote threads by the PPMC. *Any member of the Incubator PMC can ACK > the receipt of the vote. This starts a 72-hour window for lazy > consensus. After 72 hours and no requests by any Incubator PMC member > for a full vote by the Incubator PMC, the committer request is > approved by the Incubator PMC and the PPMC can start the committer > invitation process.* > --- > > This intentionally follows the procedure for adding a PMC member wrt > full ASF board. I like the concept of expanding this for committers > as well for Incubation, so there. I don't like needless 'dual > voting', but I do want the IPMC to have the chance to execute > oversight. > > WDYT?-- justin > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
I don't care about all the transitive deps maven is downloading and caching in my local repository and I don't expect any maven user to control the content of its local repository (mine is more than 2 Go and i've no clue what's inside besides what i directly use). I'm talking about maven as a build tool to generate *something*. When your goal is to generate a web application, i expect the developer to look at what's inside. If your goal is to generate a zip file with some jars inside, I also expect the developer to make sure the zip contains what it needs and not gigabytes of unused jars. On Mon, Jun 2, 2008 at 8:08 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Guillaume Nodet wrote: > >> Maven is just a tool to build something, it's not used to launch a >> process while downloading the binaries at the same time. At the >> end, people check what ends up in their distribution (be it a war >> or a tar.gz) and at this point, they know that there is an incubator >> artifact. > > Oh, please. Most maven users couldn't find their repository with a roadmap, > and haven't a clue what is in it. Unless something goes wrong, forcing them > to look closer or ask for help, all they know is that they issue a command > and something comes out the other end. > >--- Noel > > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
Why would someone care or even see them ? Are you regularly crawling the maven repo for new artifacts ? We don't have to be ashamed if a podling does not graduate, so I don't think we have to try erasing the memory of this podling. A non graduated podling could still be revived at a later time or being forked outside of the ASF. On Mon, Jun 2, 2008 at 6:21 PM, James Carman <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 12:17 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: >>>Part of the Incubation process is to ensure that there is sufficient >>>community to maintain the code after incubation. >> >> >>>It seems a bad idea to allow artefacts into the main repository where >>>they can become dependencies unless there is some chance that they >>>will be maintained. >> >> This is an argument for saying that TLP Apache projects can't depend on >> incubator artifacts then. Otherwise those projects suddenly don't work >> because a dependency disappeared. >> >> I personally don't think this should be the case. If they are released >> and someone wants to use them, then they should go into central where >> they live forever like everything else. Just because the community goes >> away does not mean the artifact should disappear too. >> > > But, doesn't that somewhat hurt the Apache name if we have a bunch of > orphaned projects sitting out there in limbo with our name on it? > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
On Mon, Jun 2, 2008 at 5:47 PM, sebb <[EMAIL PROTECTED]> wrote: > On 02/06/2008, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> That's just the thing though: >> >> At the end of the day, the vast majority of TLP end users could care less if >> the TLP uses an incubator dependency or not, as long as it is Apache 2.0 >> compatible and easily available (i.e. in the central repo). They trust the >> TLP to do their due diligence to ensure the dependency works as expected >> within the TLP, is tested and has gone through stability sanity checks. The >> 'incubator' name in the release plus maybe a DISCLAIMER or entry in a README >> file is good enough. Anything requiring manual intervention is just a pain >> to deal with for almost everyone. >> >> I feel very strongly the incubator releases should be in the main repo for >> simplicity's sake and to encourage adoption, and that a TLP should be able >> to use its judgment on whether or not to include an incubator dependency - >> they know their project best and will support their community best. >> >> So I'm very much in agreement with 1) allowing incubator releases to go to >> the central repo and 2) allowing TLPs to decide themselves to include an >> incubator dependency or not. >> >> Both Incubator _and_ TLP communities will feel unnecessary burden or >> hindrance otherwise. >> > > Part of the Incubation process is to ensure that there is sufficient > community to maintain the code after incubation. > > Not all incubator projects achieve this. > > It seems a bad idea to allow artefacts into the main repository where > they can become dependencies unless there is some chance that they > will be maintained. > > Yes, there are ASF projects that fall by the wayside too, but that is > not the point. The more projects use a given podling, the more changes there are that the project will create a good community.And again, it's exactly the same problem when a project use an artifact under ASL or any compatible license which is not hosted at the ASF: if the project is not maintained anymore by its community, the PMC has to decide what to do with it, but it's not related to being an incubating project per se. > >> On Mon, Jun 2, 2008 at 10:52 AM, sebb <[EMAIL PROTECTED]> wrote: >> >> >> > On 02/06/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> > > On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> >> > wrote: >> > > > >> > > >> > > > 1. Incubator releases go into Central >> > > >> > > >> > > +1 >> > > >> > > I think having the "incubator" or "incubating" word in the version >> > > name brings sufficient awareness to the users. >> > >> > But Maven does not warn about using incubator versions. >> > >> > If you are adding a direct dependency on an incubator version, then >> > the user may understand the significance of the word. Or they may not, >> > depending on whether they understand the jargon correctly. >> > >> > But if the dependency is a transitive one, then the user does not get >> > to know about this (unless they scan the maven log very carefully) >> > >> > > While ServiceMix was in incubation, we had sometime a hard time to >> > > tell our users that being in incubation has nothing to do with the >> > > quality of the code, but rather with IP and mostly community building. >> > > Given we had to explain that, it is clear our users were aware that >> > > the project was still incubating. >> > > >> > > >> > > > >> > > > 2. Regular releases cannot use Incubator artifacts >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > -- >> > > Cheers, >> > > Guillaume Nodet >> > > >> > > Blog: http://gnodet.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] >> > >> > >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
I disagree, the problem is not when using a transitive dependencies. Maven is just a tool to build something, it's not used to launch a process while downloading the binaries at the same time. At the end, people check what ends up in their distribution (be it a war or a tar.gz) and at this point, they know that there is an incubator artifact. You could argue the same thing about non-incubating artifact also: when building a release, I check what's inside to ensure there is no incompatible or unneeded artifacts ... On Mon, Jun 2, 2008 at 4:52 PM, sebb <[EMAIL PROTECTED]> wrote: > On 02/06/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: >> > >> >> > 1. Incubator releases go into Central >> >> >> +1 >> >> I think having the "incubator" or "incubating" word in the version >> name brings sufficient awareness to the users. > > But Maven does not warn about using incubator versions. > > If you are adding a direct dependency on an incubator version, then > the user may understand the significance of the word. Or they may not, > depending on whether they understand the jargon correctly. > > But if the dependency is a transitive one, then the user does not get > to know about this (unless they scan the maven log very carefully) > >> While ServiceMix was in incubation, we had sometime a hard time to >> tell our users that being in incubation has nothing to do with the >> quality of the code, but rather with IP and mostly community building. >> Given we had to explain that, it is clear our users were aware that >> the project was still incubating. >> >> >> > >> > 2. Regular releases cannot use Incubator artifacts >> > >> > >> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.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] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > 1. Incubator releases go into Central +1 I think having the "incubator" or "incubating" word in the version name brings sufficient awareness to the users. While ServiceMix was in incubation, we had sometime a hard time to tell our users that being in incubation has nothing to do with the quality of the code, but rather with IP and mostly community building. Given we had to explain that, it is clear our users were aware that the project was still incubating. > > 2. Regular releases cannot use Incubator artifacts > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > 1. Incubator releases go into Central > > 2. Regular releases cannot use Incubator artifacts > > > > Since the whole point of the incubator releases is to get some people to > use them and prove them out, I say 2 is not really an option. If the PMC > of a given project tests out an incubator artifact and deems it good > enough for a release, then that should be enough But let's make it > easier for the users by having those dependencies available. > Imho, #2 is not a good option. Projects are allowed to use external dependencies if their license is compatible. This is a legal issue. Incubator releases are obviously under the ASL, so as Dan said, the only thing is that it would make building a community harder for the podling, without any real benefits imho. In particular, this is really weird for projects coming into the incubator with an existing code base and a community. ASF projects would be able to use the pre-incubator versions, but not the releases published while inside the incubator ? I really thing it's up to the PMC to decide if they want to depend on some incubating projects or not and I'd say we should even encourage that to help building the community around the incubating project. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apache Tuscany Graduation as TLP
+1 On Wed, May 14, 2008 at 8:51 PM, ant elder <[EMAIL PROTECTED]> wrote: > After 29 months in the incubator, 19 releases, 25 new committers, and > tons of emails the Apache Tuscany community (with support from our > mentors) again feels that we are ready to graduate to an official top > level project at Apache as indicated by the community vote recorded > at: http://apache.markmail.org/message/lss5jhjxail7m67r > > We would like the resolution below to be presented to the board for > consideration at the next possible board meeting. > > For additional information, the Tuscany status file is here: > https://svn.apache.org/repos/asf/incubator/tuscany/STATUS > > Thanks in advance for your time and consideration. > > ...ant > > X. Establish the Apache Tuscany Project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the Foundation's > purpose to establish a Project Management Committee charged with > the creation and maintenance of open-source software for > distribution at no charge to the public, that simplifies the > development, deployment and management of distributed applications > built as compositions of service components. These components > may be implemented with a range of technologies and connected > using a variety of communication protocols. This software will > implement relevant open standards including, but not limited to, > the Service Component Architecture standard defined by the OASIS > OpenCSA member section, and related technologies. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache Tuscany Project", > be and hereby is established pursuant to Bylaws of the > Foundation; and be it further > > RESOLVED, that the Apache Tuscany Project be and hereby is > responsible for the creation and maintenance of software > related to Apache Tuscany; > and be it further > > RESOLVED, that the office of "Vice President, Apache Tuscany" be > and hereby is created, the person holding such office to > serve at the direction of the Board of Directors as the chair > of the Apache Tuscany Project, and to have primary responsibility > for management of the projects within the scope of > responsibility of the Apache Tuscany Project; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Tuscany Project: > >* Adriano Crestani >* ant elder >* Brady Johnson >* Frank Budinsky >* Ignacio Silva-Lepe >* Jean-Sebastien Delfino >* kelvin goodson >* Luciano Resende >* Mark Combellack >* Matthieu Riou >* Mike Edwards >* Paul Fremantle >* Pete Robbins >* Raymond Feng >* Simon Laws >* Simon Nash >* Venkata Krishnan > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder > be appointed to the office of Vice President, Apache Tuscany, to > serve in accordance with and subject to the direction of the > Board of Directors and the Bylaws of the Foundation until > death, resignation, retirement, removal or disqualification, > or until a successor is appointed; and be it further > > RESOLVED, that the Apache Tuscany Project be and hereby > is tasked with the migration and rationalization of the Apache > Incubator Tuscany podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Incubator Tuscany podling encumbered upon the Apache Incubator > Project are hereafter discharged. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Audit Scripts -> RAT...?
+1 On Sat, May 10, 2008 at 3:40 PM, Yoav Shapira <[EMAIL PROTECTED]> wrote: > On Sat, May 10, 2008 at 4:01 AM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: >> ATM the audit release scripts used to scan and record the releases >> distributed by the incubator are in >> http://svn.apache.org/repos/asf/incubator/public/trunk/. a number of >> enhancements have been requested which i hope to code up over the next >> few weeks. these will start to make them reasonably substantial. >> perhaps some other projects might also find them useful as well. so, >> i've been wonder whether the code should be (eventually) be moved to >> RAT. > > +1, I think it makes sense to consolidate these in one place. The > typical users of these scripts are the same people and they (or at > least I) would find them convenient to have and run from one place. > > Yoav > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Size of websites in incubator.apache.org
On Tue, Apr 22, 2008 at 6:22 PM, Tony Stevenson <[EMAIL PROTECTED]> wrote: > Good day, > > As part of rolling out the new backup server for the infra team, I have > discovered that several podling sites are extremely large. > > Namely: > > 119M/x1/www/incubator.apache.org/activemq > 324M/x1/www/incubator.apache.org/cxf > 102M/x1/www/incubator.apache.org/directory > 166M/x1/www/incubator.apache.org/lucene.net > 587M/x1/www/incubator.apache.org/openjpa > 299M/x1/www/incubator.apache.org/servicemix incubator.apache.org/servicemix is already redirecting to servicemix.apache.org I'll clean the remove the content of the directory asap. > 166M/x1/www/incubator.apache.org/uima > > > I am singling out all sites that over 100MB in size here. Can someone > please check the contents of these directories? I appreciate that some of > them have graduated from the incubator and as such, these datasets are > either redundant or should be archived. > > I would appreciate a definitive directive as to what should be done with > these directories. > > I will also be updating the documentation on how to handle > graduation/removal from the incubator. I'll send an update once this has > been done too. > > > Cheers, > Tony > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release CXF 2.0.5-incubator
True, but I usually feel better when all -1's concerns have been addressed. On Mon, Mar 31, 2008 at 8:06 PM, Martijn Dashorst < [EMAIL PROTECTED]> wrote: > On 3/31/08, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > On Mar 31, 2008, at 4:41 AM, sebb wrote: > > > On 31/03/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > >> On Thu, Mar 27, 2008 at 11:15 PM, sebb <[EMAIL PROTECTED]> wrote: > > >>> -1: there should be NOTICE and LICENSE files at the top level in > > >>> SVN. > > > May I suggest resolving this via Legal discuss? > > > It's also pretty easy to add the two files to SVN... > > Nice to have but, as I think Guillaume pointed out, still an evolving > > issue. Certainly not deserving a veto. > > AFIAK, releases can't be vetoed. So if enough folks think this release > is good to go, it is good to go. > > From the voting policy [1]: > > > Votes on Package Releases > > Votes on whether a package is ready to be released follow a format > similar to majority approval -- except that the decision is officially > determined solely by whether at least three +1 votes were registered. > *Releases may not be vetoed.* Generally the community will table the > vote to release if anyone identifies serious problems, but in most > cases the ultimate decision, once three or more positive votes have > been garnered, lies with the individual serving as release manager. > The specifics of the process may vary from project to project, but the > 'minimum of three +1 votes' rule is universal. > > > Please note the *Releases may not be vetoed.* part. > > Martijn > > [1] http://www.apache.org/foundation/voting.html > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.2 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Approve release CXF 2.0.5-incubator
On Thu, Mar 27, 2008 at 11:15 PM, sebb <[EMAIL PROTECTED]> wrote: > > -1: there should be NOTICE and LICENSE files at the top level in SVN. > > -1: SVN and the source archive don't agree; there are files and > directories in each that are not in the other. > > Could you please reconsider your vote? AFAIK, we have always voted on releases, not on the SVN tag. The tag is just a way to (re-)build the release and not something we vote on and distribute. Furthermore, there's no policies yet around these issues that are still being discussed. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Approve release CXF 2.0.5-incubator
On Fri, Mar 28, 2008 at 2:51 AM, sebb <[EMAIL PROTECTED]> wrote: > On 28/03/2008, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > On Thursday 27 March 2008, sebb wrote: > > > On 26/03/2008, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > > > The staging area is at: > > > > > > http://people.apache.org/~dkulp/stage_cxf/2.0.5-incubator<http://people.apache.org/%7Edkulp/stage_cxf/2.0.5-incubator> > > > > > > The binary jar contains lots of non-CXF jars in the lib directory; > > > these should probably be dropped and listed as external dependencies. > > > > > > Huh? Then the binary distibution wouldn't work. That's silly. Users > > should be able to download this, unpack it, and run the samples and > > stuff to see it working without tramping all over the internet to find > > jars and stuff. If you install MS office on your machine, do you then > > have to go off and find the spell checker, the thesauras, etc...? > > > > > > Well - it makes the download much bigger, and they may have some of > the dependencies already. Also, some of the included jars have been > updated with newer versions. You could provide a separate libraries > archive for the external jars. If you want a small distribution, just use the source one. The binary distribution are provided as an easy way for the user to use the product and get started. If he has to download and unzip other things, it removes some of the benefit of having a binary distribution. I would agree for optional stuff that we *can not* distribute due to licensing problems for example. > > > > > > > Typo in LICENSE file in binary zip: "librarie" should be "libraries" > > > > > > Fixed on trunk. Good catch. I must have looked at that several times > > and it never triggered my brain. Must be getting old... :-( > > > > > > > > > The CXF jar manifests should really include source and target Java > > > versions. > > > > > > Why? > > > > So that one can tell which Java version is required ... I've honestly never looked at the manifest for such information. If you read the CXF doc, I'm sure you'll find it requires java 5 and that's all you really need. > > > > > > > The CXF jars contain the file DEPENDENCIES in META-INF - this seems > > > out of place. > > > > > > This was discussed on legal-discuss and no objections raised. > > > > > > > Also the DEPENDENCIES contents still refer to jakarta for some > commons > > > modules, and 'Apache Software Foundation' => 'The Apache Software > > > Foundation' > > > > > > Well. It's automatically generated from the information the other > > projects provide. As long as Jakarta/commons keep providing > > crap. > > Seriously, if the poms say they came from jakarta, the versions we are > > using probably are the jakarta versions. See Davids response at: > > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200803.mbox/ > <4047F63C-2D55-437A-AE95-6B52E98BEF7D%40yahoo.com> > > > > > > > > The distributions are in the "dist" directory. The "m2repo" > > > > directory contains the stuff that will by pushed to the > > > > m2-incubating-repository. > > > > > > > > This release is tagged at: > > > > > > > > > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.5-incubat > > > >or/ > > > > > > -1: there should be NOTICE and LICENSE files at the top level in SVN. > > > > SVN is *not* a distribution, so legal problems can't be applied to that afaik. > > > > -1: SVN and the source archive don't agree; there are files and > > > directories in each that are not in the other. > Same as above. It has been said lots of times over the past months that the official release is the *source distribution*, not the svn tag or the binary distro. So i don't see why this would be a problem at all. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Approve release CXF 2.0.5-incubator
+1 On Wed, Mar 26, 2008 at 5:49 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > We held a vote on cxf-dev to release a new version of CXF. This version > is pretty much just a big "bug fix rollup" compared to 2.0.4 fixing over > 30 JIRA issues reported by users, one of which is a security issue. > > For a full list of the issues, see: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312931&styleName=Html&projectId=12310511&Create=Create > > The vote thread is at: > http://www.nabble.com/-VOTE--Release-CXF-2.0.5-incubator-to16207118.html > > In summary, we have 12 +1 votes, no 0 or -1 votes. Three of the votes > are from IPMC folks and are thus binding (jim, bsnyder, and gnodet). > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.0.5-incubator<http://people.apache.org/%7Edkulp/stage_cxf/2.0.5-incubator> > > The distributions are in the "dist" directory. The "m2repo" directory > contains the stuff that will by pushed to the m2-incubating-repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.5-incubator/ > > We and our users appreciate you taking the time to look over this > release! > > > -- > J. Daniel Kulp > Principal Engineer, IONA > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Statements from Qpid mentors would help me decide... [WAS Re: [VOTE] Apache Qpid Graduation as TLP]
The "project" means the people that can vote and make decisions. Committers who are not PMC members can not as their vote is not binding. On Tue, Mar 25, 2008 at 4:14 PM, Aidan Skinner <[EMAIL PROTECTED]> wrote: > On Tue, Mar 25, 2008 at 3:06 PM, Martijn Dashorst > <[EMAIL PROTECTED]> wrote: > > > It is not a question of who is active on the list, but how the > > PMC/committership looks like at graduation. All the names you supplied > > are *not* on the PMC, and therefore don't count for the diversity > > requirement. > > I was under the impression that it was the committership that was > looked at, not the PPMC. Am I misreading "The project is not highly > dependent on any single contributor (there are at least 3 legally > independent committers and there is no single company or entity that > is vital to the success of the project)" from > http://incubator.apache.org/incubation/Incubation_Policy.html ? > > - Aidan > -- > aim/y!:aidans42 g:[EMAIL PROTECTED] > http://aidan.skinner.me.uk/ > "We belong to nobody and nobody belongs to us. We don't even belong to > each other." > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Graduation resolution feedback - Qpid as TLP
On Thu, Feb 28, 2008 at 3:20 PM, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > > RESOLVED, that the Apache Qpid PMC be and hereby is responsible > for the creation and maintenance of the Qpid Messaging implementations, > clients and related software components, based on software licensed to the > Foundation; and for ensuring that the Qpid community pursue its goal of > furthering the adoption of an open network protocol implementation for > messaging in the spirit of the Foundation; and be it further > Should it be a bit more descriptive wrt to the technical goal of the QPid TLP ? The goal of a TLP in the ASF is to deliver software, not to "furthering the adoption" of anything ... The ASF does not promote any technology. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removing ServiceMix from the list of incubating project
It does, thx ! On Nov 13, 2007 1:26 AM, sebb <[EMAIL PROTECTED]> wrote: > Does this help? > > http://incubator.apache.org/guides/website.html > > On 13/11/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > Is the web site archived somewhere, should I just edit the web page > under > > /www/incubator.apache.org/projects/index.html > > or is there a better way to do that ? > > > > -- > > Cheers, > > Guillaume Nodet > > > > Blog: http://gnodet.blogspot.com/ > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Removing ServiceMix from the list of incubating project
Is the web site archived somewhere, should I just edit the web page under /www/incubator.apache.org/projects/index.html or is there a better way to do that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] RAT to enter incubator
oped. There > are overlaps with Tika and there has been some talk of collaboration. > The discordia lab will likely be used for license and artifact > meta-data. RAT may integrate with Gump for continuous code scanning. > > Initial Source > > * [WWW] http://code.google.com/p/arat/source > * [WWW] http://mojo.codehaus.org/rat-maven-plugin > > External Dependencies > > Compliant with current Apache policy. > > Cryptography > - > Required to check signatures. > > Required Resources > > Mailing lists: > * rat-private > * rat-dev > * rat-commits > Subversion Directory: [WWW] https://svn.apache.org/repos/asf/incubator/rat > Issue Tracking: JIRA (RAT) > Other Resources: Continuous integration may eventually required hardware > > Initial Committers > --- > * Stefan Bodewig > * Robert Burrell Donkin > * Nodet Guillaume > * Garrett Rooney > * Matthieu Riou > * Jochen Wiedmann > * Henri Yandell > * Karl Pauls > > Sponsors > === > Champion > > Robert Burrell Donkin > > Mentors > > * Yoav Shapira > * Ross Gardler > * Matt Hogstrom > * Jim Jagielski > > The final destination is still uncertain. If RAT accumulates code then > it is possible that a top level project would be appropriate. If RAT > pushes code out to other projects then it might make more sense as a > subproject of Maven or Gump. If RAT is finished before it creates a > viable community then it may make sense as an Incubator subproject. > > So I would like to ask the Incubator PMC to sponsor RAT. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Graduation: how do we check "three or more independent committers" ?
Well, 4 committers with 2 from the same organization: you still have 3 organizations involved. I think 3 is not that big a number: committers do not have to be full time employee, and level of activity may vary greatly between committers if some are full time employee and others work on their spare time. But having 3 or more independant committers is also a result of the openness of the project. I know that when you have a bunch of full time employee devoted to a project, it's much more difficult to attract new committers, but still... On 10/16/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: > On 10/16/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > > > On 10/13/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > > Do we have a solid process for checking this? > > > > > > I'm not sure we do - each project's status page (like [1] for example) > > > contains the "Are there three or more independent committers?" > > > question, but unless I'm missing something we don't have a defined way > > > of checking this. > > > > > > The simplest way to fix this might be to include, in the graduation > > > vote requests, the list of active committers and affiliations, so that > > > people can check it if they want. > > > > sounds like a reasonable approach > > > As I mentioned in another thread I'm not so big on this rule. Having a fixed > number is IMHO a bit too rigid. Do we forbid graduation for a project with 4 > active committers among which 2 are in the same company? How the project > deals with its governance (are the independent committers opinion taken into > account? are they ignored?) is, I think, more important. Am I the only one > to think that way? > > That being said, having the list of active committers with affiliations in > the graduation vote request would be helpful. > > Cheers, > Matthieu > > - robert > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synapse isn't just SOAP/WSDL [WAS] Re: [VOTE] Graduate Tuscany as a top level project
Agreed. This is why we have avoided putting JBI in the ServiceMix TLP charter. In addition, ServiceMix may provide support for SCA in the future, has JBI and SCA are not incompatible at all (this may be done leveraging some parts of Tuscany, but not necesseraly, as the only interesting bit of Tuscany for ServiceMix would be the optional Java programming model). FYI, here is the charter for ServiceMix: "an extensible messaging bus for service integration, mediation and composition". On 10/14/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > Noel > > Just an aside. Synapse implements a number of standards, and is not limited > to SOAP/WSDL. We have simple samples that take CSV files from FTP and > publish pure XML/JMS. I also think that ServiceMix would like to say they do > more than JBI. > > Paul > > On 10/13/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > > > Robert Burrell Donkin wrote: > > > > > "Tuscany will implement relevant open standards including ..." > > > > As previously noted, the core standards for Tuscany are SCA and SDO, with > > others as desired by the community. What distinguishes Tuscany from > > ServiceMix from Synapse is: > > > > Tuscany: SCA / SDO > > ServiceMix: JBI > > Synapse: WSDL / SOAP > > > > --- Noel > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Paul Fremantle > Co-Founder and VP of Technical Sales, WSO2 > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On 9/28/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > What we care about is that podlings get the "legal stuff" right, and > letting releases out without this being ok is not an option, due to > potential legal risks. I thought projects in incubator were not endorsed by the ASF, hence the ASF could not be responsible for the legal stuff in podling releases... Did I miss something here ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Effects on corporate backing withdrawals [was: Incubator Proposal: Pig]
One of the purpose of the incubator is to ensure that there is a sustainable developer community, so I don't see failure of incubating projects as a real problem. On 9/25/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Dims wrote: > > Niclas Hedhman asked: > > > Do we have any examples where corporate backing has been withdrawn, and > how > > > the project was affected, whether inside or outside ASF? > > TSIK -> Verisign folks lost interest, community did not form, project > shelved. > > Plus Kabuki, Heraldry, and possibly Lokahi. We still hope to save the > latter, as there is consistently a lot of user interest, but the developer > input has dwindled, and we need developers! > > --- Noel > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: All licenses in a single file [WAS: Re: [VOTE] Publish the Woden M7b release]
I must agree about the nightmare.
Including separate files is much easier and could be automated by
maven or any other build tool much more easily...
On 7/31/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> On 7/31/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > +1 from me.
> >
> > Some of the same comments on the previous M7a release still apply, eg, its
> > preferred to have a separate DISCLAIMER file, having all licenses in a
> > single LICENSE file, and have src and binary distro's unpack into
> > different
> > folders.
>
>
> Actually I was wondering about this recommendation of having all (non ASL)
> license files for dependencies in a *single* LICENSE file. It seems to me
> that it's a maintenance nightmare when you have a lot of dependencies (very
> long file, you have to do a search to find anything, checking what could be
> missing takes a looong time). I'd rather have all the specific licenses each
> in there file reproduced side by side with the library the license is
> applied on (with similar namings, i.e. dom4j-1.3.LICENSE) and a simple
> pointer in the main LICENSE file ("licenses for each dependency library are
> reproduced in the lib directory along with the library").
>
> So is there a legal justification behind this that I missed? And sorry if
> I'm rehashing a subject that has already been discussed in the past :)
>
> Matthieu
>
>...ant
> >
> > On 7/30/07, Graham Turrell (gmail) <[EMAIL PROTECTED]> wrote:
> > >
> > > The Woden incubator project is developing a WSDL 2.0 processor in
> > > conjunction with efforts of the W3C to deliver the new WSDL
> > > 2.0 specification. The Woden project team would like to ask the
> > > Incubator PMC for approval to publish the Woden Milestone 7b release to
> > > support the
> > > upcoming Apache WS Axis2 1.3 release.
> > >
> > > Could Incubator PMC members please vote by Wednesday 1st August.
> > >
> > > Woden M7b is an incremental release of Woden M7 which was released on
> > 19th
> > > February 2007. M7b adds to M7 and M7a fixes delivered by JIRAs:
> > >
> > > * WODEN-33 DocumentationElement should extend NestedElement.
> > > * WODEN-149 Update Woden with New WSDL 2.0 Assertions Numbers for
> > > Proposed
> > > Recommendation.
> > > * WODEN-161 Style default from interface not applied to operations.
> > > * WODEN-165 SAX attribution in NOTICE file is not required.
> > > * WODEN-168 OMXMLElementTest class incorrectly returning the
> > > DOMXMLElementTest
> > > class as its test suit.
> > >
> > > Also included is a fix to DOMWSDLReader to set base URI before calling
> > > XmlSchema.
> > >
> > > The Woden M7b release files are at:
> > > http://people.apache.org/~gturrell/woden/milestones/1.0M7b-incubating/
> > >
> > > This build is based on revision 560591 at
> > > http://svn.apache.org/repos/asf/incubator/woden/branches/M7b/
> > >
> > > The results of the vote from the woden-dev list was:
> > > Davanum Srinivas +1 (WSPMC, IPMC)
> > > Deepal Jayasinghe +1
> > > Thilina Gunarath +1
> > > Jeremy Hughes +1 (WSPMC)
> > > Graham Turrell +1
> > > John Kaputin +1
> > >
> > > --
> > >
> > > Kind Regards,
> > > Graham
> > >
> >
>
--
Cheers,
Guillaume Nodet
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
Sorry. I missed a few votes: - Robert Burrel Donkin (*) - Ant Elder On 7/24/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: The vote to graduate ServiceMix as a TLP is over. Thanks to everyone! No -1 or 0 votes were recorded and the following +1 were recorded (binding votes starred): - Guillaume Nodet - James Strachan (*) - Matthieu Riou - Thomas Termin - Tony Ambrozie - Eelco Hillenius - Craig L Russel (*) - Martinj Dahorst - Bruce Snyder - Alex Boisvert - Davanum Srinivas (*) The proposed resolution can be read below and I will send it to the board for consideration during the next meeting. Cheers, Guillaume Nodet Guillaume Nodet wrote: > The ServiceMix podling respectfully requests the Incubator to consider > its graduation to a Top Level Project. Please vote on recommending > the attached draft board resolution. > > [ ] +1 Recommend to the board to establish Apache ServiceMix > [ ] -1 Do not recommend establishing Apache ServiceMix... > > ServiceMix has been in incubation for more than one year and has > demonstrated its ability to govern itself, perform releases and voting in > new committers and PPMC members. > > Note: the first vote has been cancelled due to a rephrase in the > project scope. > > == > > Establish the Apache ServiceMix project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project, to be known as > "Apache ServiceMix Project", related to an extensible messaging > bus for service integration, mediation and composition and its > related > components, for distribution at no charge to the public. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC) is hereby established pursuant to Bylaws > of the Foundation; and be it further > > RESOLVED, that the Apache ServiceMix PMC be and hereby is > charged with the creation and maintenance of "Apache ServiceMix"; > and be it further > > RESOLVED, that the office of "Vice President, Apache ServiceMix" > be and > hereby is created, the person holding such office to serve at > the direction of the Board of Directors as the chair of the > Apache ServiceMix PMC, and to have primary responsibility for > management of the projects within the scope of responsibility > of the Apache ServiceMix PMC; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache ServiceMix PMC: > > * Hiram Chirino <[EMAIL PROTECTED]> > * Adrian Co <[EMAIL PROTECTED]> > * Rob Davies <[EMAIL PROTECTED]> > * Philips Dodds <[EMAIL PROTECTED]> > * Jeff Genender <[EMAIL PROTECTED]> > * Matt Hogstrom <[EMAIL PROTECTED]> > * David Jencks <[EMAIL PROTECTED]> > * Jacek Laskowski <[EMAIL PROTECTED]> > * Jonas Lim <[EMAIL PROTECTED]> > * Aaron Mulder <[EMAIL PROTECTED]> > * Guillaume Nodet <[EMAIL PROTECTED]> > * Bruce Snyder <[EMAIL PROTECTED]> > * James Strachan <[EMAIL PROTECTED]> > * Thomas Termin <[EMAIL PROTECTED]> > * Gert Vanthienen <[EMAIL PROTECTED]> > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet > be appointed to the office of Vice President, Apache ServiceMix, > to serve > in accordance with and subject to the direction of the Board of > Directors and the Bylaws of the Foundation until death, > resignation, retirement, removal or disqualification, or until > a successor is appointed; and be it further > > RESOLVED, that the Apache ServiceMix Project be and hereby > is tasked with the migration and rationalization of the Apache > Incubator ServiceMix podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Incubator ServiceMix podling encumbered upon the Apache Incubator > PMC are hereafter discharged. > > == > > -- > Cheers, > Guillaume Nodet > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][doc] Promote http://incubator.apache.org/guides/proposal.html
+1 On 7/23/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: http://incubator.apache.org/guides/proposal.html is marked DRAFT but it seems good enough to be promoted to a guide. this isn't policy and the document will still be CTR so this vote is just to establish consensus that we've happy enough with it's contents. hopefully any one who wants to add more content will be inspired to jump in. here's my +1 - robert --8<--- [ ] +1 Good enough [ ] +0 Ok [ ] -0 Not ok [ ] -1 No good - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
The vote to graduate ServiceMix as a TLP is over. Thanks to everyone! No -1 or 0 votes were recorded and the following +1 were recorded (binding votes starred): - Guillaume Nodet - James Strachan (*) - Matthieu Riou - Thomas Termin - Tony Ambrozie - Eelco Hillenius - Craig L Russel (*) - Martinj Dahorst - Bruce Snyder - Alex Boisvert - Davanum Srinivas (*) The proposed resolution can be read below and I will send it to the board for consideration during the next meeting. Cheers, Guillaume Nodet Guillaume Nodet wrote: > The ServiceMix podling respectfully requests the Incubator to consider > its graduation to a Top Level Project. Please vote on recommending > the attached draft board resolution. > > [ ] +1 Recommend to the board to establish Apache ServiceMix > [ ] -1 Do not recommend establishing Apache ServiceMix... > > ServiceMix has been in incubation for more than one year and has > demonstrated its ability to govern itself, perform releases and voting in > new committers and PPMC members. > > Note: the first vote has been cancelled due to a rephrase in the > project scope. > > == > > Establish the Apache ServiceMix project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project, to be known as > "Apache ServiceMix Project", related to an extensible messaging > bus for service integration, mediation and composition and its > related > components, for distribution at no charge to the public. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC) is hereby established pursuant to Bylaws > of the Foundation; and be it further > > RESOLVED, that the Apache ServiceMix PMC be and hereby is > charged with the creation and maintenance of "Apache ServiceMix"; > and be it further > > RESOLVED, that the office of "Vice President, Apache ServiceMix" > be and > hereby is created, the person holding such office to serve at > the direction of the Board of Directors as the chair of the > Apache ServiceMix PMC, and to have primary responsibility for > management of the projects within the scope of responsibility > of the Apache ServiceMix PMC; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache ServiceMix PMC: > > * Hiram Chirino <[EMAIL PROTECTED]> > * Adrian Co <[EMAIL PROTECTED]> > * Rob Davies <[EMAIL PROTECTED]> > * Philips Dodds <[EMAIL PROTECTED]> > * Jeff Genender <[EMAIL PROTECTED]> > * Matt Hogstrom <[EMAIL PROTECTED]> > * David Jencks <[EMAIL PROTECTED]> > * Jacek Laskowski <[EMAIL PROTECTED]> > * Jonas Lim <[EMAIL PROTECTED]> > * Aaron Mulder <[EMAIL PROTECTED]> > * Guillaume Nodet <[EMAIL PROTECTED]> > * Bruce Snyder <[EMAIL PROTECTED]> > * James Strachan <[EMAIL PROTECTED]> > * Thomas Termin <[EMAIL PROTECTED]> > * Gert Vanthienen <[EMAIL PROTECTED]> > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet > be appointed to the office of Vice President, Apache ServiceMix, > to serve > in accordance with and subject to the direction of the Board of > Directors and the Bylaws of the Foundation until death, > resignation, retirement, removal or disqualification, or until > a successor is appointed; and be it further > > RESOLVED, that the Apache ServiceMix Project be and hereby > is tasked with the migration and rationalization of the Apache > Incubator ServiceMix podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Incubator ServiceMix podling encumbered upon the Apache Incubator > PMC are hereafter discharged. > > == > > -- > Cheers, > Guillaume Nodet > > - > 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] Graduate ServiceMix to a Top Level Project (2nd thread)
Any other IPMC member wants to vote? On 7/13/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: The ServiceMix podling respectfully requests the Incubator to consider its graduation to a Top Level Project. Please vote on recommending the attached draft board resolution. [ ] +1 Recommend to the board to establish Apache ServiceMix [ ] -1 Do not recommend establishing Apache ServiceMix... ServiceMix has been in incubation for more than one year and has demonstrated its ability to govern itself, perform releases and voting in new committers and PPMC members. Note: the first vote has been cancelled due to a rephrase in the project scope. == Establish the Apache ServiceMix project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as "Apache ServiceMix Project", related to an extensible messaging bus for service integration, mediation and composition and its related components, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is hereby established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ServiceMix PMC be and hereby is charged with the creation and maintenance of "Apache ServiceMix"; and be it further RESOLVED, that the office of "Vice President, Apache ServiceMix" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ServiceMix PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ServiceMix PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ServiceMix PMC: * Hiram Chirino <[EMAIL PROTECTED]> * Adrian Co <[EMAIL PROTECTED]> * Rob Davies <[EMAIL PROTECTED]> * Philips Dodds <[EMAIL PROTECTED]> * Jeff Genender <[EMAIL PROTECTED]> * Matt Hogstrom <[EMAIL PROTECTED]> * David Jencks <[EMAIL PROTECTED]> * Jacek Laskowski <[EMAIL PROTECTED]> * Jonas Lim <[EMAIL PROTECTED]> * Aaron Mulder <[EMAIL PROTECTED]> * Guillaume Nodet <[EMAIL PROTECTED]> * Bruce Snyder <[EMAIL PROTECTED]> * James Strachan <[EMAIL PROTECTED]> * Thomas Termin <[EMAIL PROTECTED]> * Gert Vanthienen <[EMAIL PROTECTED]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet be appointed to the office of Vice President, Apache ServiceMix, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ServiceMix Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ServiceMix podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ServiceMix podling encumbered upon the Apache Incubator PMC are hereafter discharged. == -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
Here are the digest: http://www.nabble.com/Fwd%3A-servicemix-private-Digest-of%3A-thread.249-tf4108599s12049.html http://www.nabble.com/Fwd%3A-servicemix-private-Digest-of%3A-thread.203-tf4108591s12049.html On 7/17/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: Since graduation is a public event, the vote should be public and, at least, the IPMC should be given those links either way. On Jul 17, 2007, at 2:38 AM, Guillaume Nodet wrote: > Theses threads are on ServiceMix private list... > > On 7/16/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: >> Can you provide URL to the PPMC vote for graduation >> as well as the PPMC vote for proposed chair as well? >> >> Thanks! >> >> On Jul 13, 2007, at 2:35 PM, Guillaume Nodet wrote: >> >> > The ServiceMix podling respectfully requests the Incubator to >> consider >> > its graduation to a Top Level Project. Please vote on recommending >> > the attached draft board resolution. >> > >> > [ ] +1 Recommend to the board to establish Apache ServiceMix >> > [ ] -1 Do not recommend establishing Apache ServiceMix... >> > >> > ServiceMix has been in incubation for more than one year and has >> > demonstrated its ability to govern itself, perform releases and >> > voting in >> > new committers and PPMC members. >> > >> > Note: the first vote has been cancelled due to a rephrase in the >> > project scope. >> > >> > == >> > >> > Establish the Apache ServiceMix project >> > >> > WHEREAS, the Board of Directors deems it to be in the best >> > interests of the Foundation and consistent with the >> > Foundation's purpose to establish a Project, to be known as >> > "Apache ServiceMix Project", related to an extensible messaging >> > bus for service integration, mediation and composition and its >> > related >> > components, for distribution at no charge to the public. >> > >> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management >> > Committee (PMC) is hereby established pursuant to Bylaws >> > of the Foundation; and be it further >> > >> > RESOLVED, that the Apache ServiceMix PMC be and hereby is >> > charged with the creation and maintenance of "Apache >> ServiceMix"; >> > and be it further >> > >> > RESOLVED, that the office of "Vice President, Apache >> > ServiceMix" be and >> > hereby is created, the person holding such office to serve at >> > the direction of the Board of Directors as the chair of the >> > Apache ServiceMix PMC, and to have primary responsibility for >> > management of the projects within the scope of responsibility >> > of the Apache ServiceMix PMC; and be it further >> > >> > RESOLVED, that the persons listed immediately below be and >> > hereby are appointed to serve as the initial members of the >> > Apache ServiceMix PMC: >> > >> > * Hiram Chirino <[EMAIL PROTECTED]> >> > * Adrian Co <[EMAIL PROTECTED]> >> > * Rob Davies <[EMAIL PROTECTED]> >> > * Philips Dodds <[EMAIL PROTECTED]> >> > * Jeff Genender <[EMAIL PROTECTED]> >> > * Matt Hogstrom <[EMAIL PROTECTED]> >> > * David Jencks <[EMAIL PROTECTED]> >> > * Jacek Laskowski <[EMAIL PROTECTED]> >> > * Jonas Lim <[EMAIL PROTECTED]> >> > * Aaron Mulder <[EMAIL PROTECTED]> >> > * Guillaume Nodet <[EMAIL PROTECTED]> >> > * Bruce Snyder <[EMAIL PROTECTED]> >> > * James Strachan <[EMAIL PROTECTED]> >> > * Thomas Termin <[EMAIL PROTECTED]> >> > * Gert Vanthienen <[EMAIL PROTECTED]> >> > >> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet >> > be appointed to the office of Vice President, Apache >> > ServiceMix, to serve >> > in accordance with and subject to the direction of the >> Board of >> > Directors and the Bylaws of the Foundation until death, >> > resignation, retirement, removal or disqualification, or until >> > a successor is appointed; and be it further >> > >> > RESOLVED, that the Apache ServiceMix Project be and hereby >> > is tasked with the migration an
Re: [VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
Sorry about that, I did the same as Ode and thought it was good enough ;) How can we fix that if we need to? On 7/17/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: On Tuesday 17 July 2007 14:38, Guillaume Nodet wrote: > Theses threads are on ServiceMix private list... FWIW, non-personal/non-sensitive work of the PMC is supposed to happen on the public dev list. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
Theses threads are on ServiceMix private list... On 7/16/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: Can you provide URL to the PPMC vote for graduation as well as the PPMC vote for proposed chair as well? Thanks! On Jul 13, 2007, at 2:35 PM, Guillaume Nodet wrote: > The ServiceMix podling respectfully requests the Incubator to consider > its graduation to a Top Level Project. Please vote on recommending > the attached draft board resolution. > > [ ] +1 Recommend to the board to establish Apache ServiceMix > [ ] -1 Do not recommend establishing Apache ServiceMix... > > ServiceMix has been in incubation for more than one year and has > demonstrated its ability to govern itself, perform releases and > voting in > new committers and PPMC members. > > Note: the first vote has been cancelled due to a rephrase in the > project scope. > > == > > Establish the Apache ServiceMix project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project, to be known as > "Apache ServiceMix Project", related to an extensible messaging > bus for service integration, mediation and composition and its > related > components, for distribution at no charge to the public. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC) is hereby established pursuant to Bylaws > of the Foundation; and be it further > > RESOLVED, that the Apache ServiceMix PMC be and hereby is > charged with the creation and maintenance of "Apache ServiceMix"; > and be it further > > RESOLVED, that the office of "Vice President, Apache > ServiceMix" be and > hereby is created, the person holding such office to serve at > the direction of the Board of Directors as the chair of the > Apache ServiceMix PMC, and to have primary responsibility for > management of the projects within the scope of responsibility > of the Apache ServiceMix PMC; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache ServiceMix PMC: > > * Hiram Chirino <[EMAIL PROTECTED]> > * Adrian Co <[EMAIL PROTECTED]> > * Rob Davies <[EMAIL PROTECTED]> > * Philips Dodds <[EMAIL PROTECTED]> > * Jeff Genender <[EMAIL PROTECTED]> > * Matt Hogstrom <[EMAIL PROTECTED]> > * David Jencks <[EMAIL PROTECTED]> > * Jacek Laskowski <[EMAIL PROTECTED]> > * Jonas Lim <[EMAIL PROTECTED]> > * Aaron Mulder <[EMAIL PROTECTED]> > * Guillaume Nodet <[EMAIL PROTECTED]> > * Bruce Snyder <[EMAIL PROTECTED]> > * James Strachan <[EMAIL PROTECTED]> > * Thomas Termin <[EMAIL PROTECTED]> > * Gert Vanthienen <[EMAIL PROTECTED]> > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet > be appointed to the office of Vice President, Apache > ServiceMix, to serve > in accordance with and subject to the direction of the Board of > Directors and the Bylaws of the Foundation until death, > resignation, retirement, removal or disqualification, or until > a successor is appointed; and be it further > > RESOLVED, that the Apache ServiceMix Project be and hereby > is tasked with the migration and rationalization of the Apache > Incubator ServiceMix podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Incubator ServiceMix podling encumbered upon the Apache Incubator > PMC are hereafter discharged. > > == > > -- > Cheers, > Guillaume Nodet > > - > 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] -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
And here's my +1 On 7/13/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: The ServiceMix podling respectfully requests the Incubator to consider its graduation to a Top Level Project. Please vote on recommending the attached draft board resolution. [ ] +1 Recommend to the board to establish Apache ServiceMix [ ] -1 Do not recommend establishing Apache ServiceMix... ServiceMix has been in incubation for more than one year and has demonstrated its ability to govern itself, perform releases and voting in new committers and PPMC members. Note: the first vote has been cancelled due to a rephrase in the project scope. == Establish the Apache ServiceMix project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as "Apache ServiceMix Project", related to an extensible messaging bus for service integration, mediation and composition and its related components, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is hereby established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ServiceMix PMC be and hereby is charged with the creation and maintenance of "Apache ServiceMix"; and be it further RESOLVED, that the office of "Vice President, Apache ServiceMix" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ServiceMix PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ServiceMix PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ServiceMix PMC: * Hiram Chirino <[EMAIL PROTECTED]> * Adrian Co <[EMAIL PROTECTED]> * Rob Davies <[EMAIL PROTECTED]> * Philips Dodds <[EMAIL PROTECTED]> * Jeff Genender <[EMAIL PROTECTED]> * Matt Hogstrom <[EMAIL PROTECTED]> * David Jencks <[EMAIL PROTECTED]> * Jacek Laskowski <[EMAIL PROTECTED]> * Jonas Lim <[EMAIL PROTECTED]> * Aaron Mulder <[EMAIL PROTECTED]> * Guillaume Nodet <[EMAIL PROTECTED]> * Bruce Snyder <[EMAIL PROTECTED]> * James Strachan <[EMAIL PROTECTED]> * Thomas Termin <[EMAIL PROTECTED]> * Gert Vanthienen <[EMAIL PROTECTED]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet be appointed to the office of Vice President, Apache ServiceMix, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ServiceMix Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ServiceMix podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ServiceMix podling encumbered upon the Apache Incubator PMC are hereafter discharged. == -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Graduate ServiceMix to a Top Level Project (2nd thread)
The ServiceMix podling respectfully requests the Incubator to consider its graduation to a Top Level Project. Please vote on recommending the attached draft board resolution. [ ] +1 Recommend to the board to establish Apache ServiceMix [ ] -1 Do not recommend establishing Apache ServiceMix... ServiceMix has been in incubation for more than one year and has demonstrated its ability to govern itself, perform releases and voting in new committers and PPMC members. Note: the first vote has been cancelled due to a rephrase in the project scope. == Establish the Apache ServiceMix project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as "Apache ServiceMix Project", related to an extensible messaging bus for service integration, mediation and composition and its related components, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is hereby established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ServiceMix PMC be and hereby is charged with the creation and maintenance of "Apache ServiceMix"; and be it further RESOLVED, that the office of "Vice President, Apache ServiceMix" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ServiceMix PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ServiceMix PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ServiceMix PMC: * Hiram Chirino <[EMAIL PROTECTED]> * Adrian Co <[EMAIL PROTECTED]> * Rob Davies <[EMAIL PROTECTED]> * Philips Dodds <[EMAIL PROTECTED]> * Jeff Genender <[EMAIL PROTECTED]> * Matt Hogstrom <[EMAIL PROTECTED]> * David Jencks <[EMAIL PROTECTED]> * Jacek Laskowski <[EMAIL PROTECTED]> * Jonas Lim <[EMAIL PROTECTED]> * Aaron Mulder <[EMAIL PROTECTED]> * Guillaume Nodet <[EMAIL PROTECTED]> * Bruce Snyder <[EMAIL PROTECTED]> * James Strachan <[EMAIL PROTECTED]> * Thomas Termin <[EMAIL PROTECTED]> * Gert Vanthienen <[EMAIL PROTECTED]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet be appointed to the office of Vice President, Apache ServiceMix, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ServiceMix Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ServiceMix podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ServiceMix podling encumbered upon the Apache Incubator PMC are hereafter discharged. == -- Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] Graduate ServiceMix to a Top Level Project
Good idea, thx! On 7/13/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: On Saturday 14 July 2007 00:30, Guillaume Nodet wrote: > Agreed. So here is the new version: > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project, to be known as > "Apache ServiceMix Project", related to an extensible messaging > bus for service integration, mediation and composition and its > related components, for distribution at no charge to the public. Work for me. I suggest that you restart the vote with this new paragraph, so public records later will be cleaner. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] Graduate ServiceMix to a Top Level Project
Agreed. So here is the new version: WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as "Apache ServiceMix Project", related to an extensible messaging bus for service integration, mediation and composition and its related components, for distribution at no charge to the public. (Other paragraphs unchanged) On 7/13/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: On 7/13/07, Bruce Snyder <[EMAIL PROTECTED]> wrote: > On 7/13/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > What about "a pluggable messaging bus for enterprise service > > integration, mediation and composition and its related components" ? > > I'd like to keep out the acronyms if possible ... > > No objection from me. I'd prefer to keep out the acronyms - I was > simply trying to satisfy Nic's request. works for me perhaps pluggable'-> extensible maybe cut enterprise (it's pretty meaningless and unduly restrictive) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] Graduate ServiceMix to a Top Level Project
What about "a pluggable messaging bus for enterprise service integration, mediation and composition and its related components" ? I'd like to keep out the acronyms if possible ... On 7/12/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: What about a service oriented messaging bus, allowing both in VM and outside of VM exchanges and composition? On 7/12/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > On 7/12/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > ServiceMixis an ESB based on JBI that can be used for SOA. > > We purposedly avoided those acronyms in the scope. Do you think > > we should bring them back or add a longer description ? > > please don't bring them back in - let's try to cut through the acronyms > > starting from your description, AIUI ServiceMix connects, orchestrates > and composes services but you'll probably be able to do better than > that... > > - robert > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] Graduate ServiceMix to a Top Level Project
ServiceMixis an ESB based on JBI that can be used for SOA. We purposedly avoided those acronyms in the scope. Do you think we should bring them back or add a longer description ? On 7/12/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: On Thursday 12 July 2007 05:59, Guillaume Nodet wrote: > enterprise service integration I find this project description too broad. Since I don't know what ServiceMix is about I can't suggest something better. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Graduate ServiceMix to a Top Level Project
The ServiceMix podling respectfully requests the Incubator to consider its graduation to a Top Level Project. Please vote on recommending the attached draft board resolution. [ ] +1 Recommend to the board to establish Apache ServiceMix [ ] -1 Do not recommend establishing Apache ServiceMix... ServiceMix has been in incubation for more than one year and has demonstrated its ability to govern itself, perform releases and voting in new committers and PPMC members. == Establish the Apache ServiceMix project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as "Apache ServiceMix Project", related to enterprise service integration for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is hereby established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ServiceMix PMC be and hereby is charged with the creation and maintenance of "Apache ServiceMix"; and be it further RESOLVED, that the office of "Vice President, Apache ServiceMix" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ServiceMix PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ServiceMix PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ServiceMix PMC: * Hiram Chirino <[EMAIL PROTECTED]> * Adrian Co <[EMAIL PROTECTED]> * Rob Davies <[EMAIL PROTECTED]> * Philips Dodds <[EMAIL PROTECTED]> * Jeff Genender <[EMAIL PROTECTED]> * Matt Hogstrom <[EMAIL PROTECTED]> * David Jencks <[EMAIL PROTECTED]> * Jacek Laskowski <[EMAIL PROTECTED]> * Jonas Lim <[EMAIL PROTECTED]> * Aaron Mulder <[EMAIL PROTECTED]> * Guillaume Nodet <[EMAIL PROTECTED]> * Bruce Snyder <[EMAIL PROTECTED]> * James Strachan <[EMAIL PROTECTED]> * Thomas Termin <[EMAIL PROTECTED]> * Gert Vanthienen <[EMAIL PROTECTED]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Nodet be appointed to the office of Vice President, Apache ServiceMix, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ServiceMix Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ServiceMix podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ServiceMix podling encumbered upon the Apache Incubator PMC are hereafter discharged. == -- Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate ODE to a Top Level Project
+1 On 7/9/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: Forwarding from [EMAIL PROTECTED] Note that you're very welcome to vote on this as well, it's not only an IPMC thing (just add non-binding after your +1 unless you're a mentor of course). Just don't forget to cc the [EMAIL PROTECTED] list in your reply. Thanks! Matthieu -- Forwarded message -- From: Matthieu Riou <[EMAIL PROTECTED]> Date: Jul 9, 2007 12:33 PM Subject: [VOTE] Graduate ODE to a Top Level Project To: general@incubator.apache.org Cc: [EMAIL PROTECTED] Hi all, This is a vote to recommend Apache ODE for graduation as a top level project to the Apache Board. Since the first days of our graduation we believe we've demonstrated our ability to build a community and grow it in an open and respectful manner, hopefully in a true Apache way. We've resolved the conflicts created before our incubation around two different donated code bases. We've since then continued the development of the project and have grown a community of supporting users. We've recently built an incubator release and attracted a new committer. Finally, the formation of our PPMC has been a bit tardy but all the individuals composing it have demonstrated their ability to take decisions and organize the project in a positive way as part of our development community. For all these reasons we believe we're ready for graduation. The incubator checklist for ODE can be found here: http://incubator.apache.org/projects/ode Please vote for the board resolution reproduced at the end of this e-mail. Note that this resolution is the result of a consensus in the ODE community. The vote will end in 72 hours, Thursday 12-July-2007. [ ] +1 Recommend to the board to establish Apache ODE [ ] -1 Do not recommend establishing Apache ODE because... Thanks! Matthieu - Establish the Apache ODE project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to business process management (BPM), workflow and process automation, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "The Apache ODE Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ODE Project be and hereby is responsible for the creation and maintenance of software related to business process management (BPM), workflow and process automation; and be it further RESOLVED, that the office of "Vice President, Apache ODE" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ODE Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ODE Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ODE Project: * Alan Cabrera ([EMAIL PROTECTED]) * Assaf Arkin( [EMAIL PROTECTED]) * Alex Boisvert ( [EMAIL PROTECTED]) * Cory Harper( [EMAIL PROTECTED]) * Davanum Srinivas ([EMAIL PROTECTED]) * Guillaume Nodet( [EMAIL PROTECTED]) * Lance Waterman ( [EMAIL PROTECTED]) * Maciej Szefler ( [EMAIL PROTECTED]) * Matthieu Riou ( [EMAIL PROTECTED]) * Niclas Hedhman ([EMAIL PROTECTED]) * Paul R. Brown ( [EMAIL PROTECTED]) * Paul Fremantle ( [EMAIL PROTECTED]) * Rob Davies ( [EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that John Smith be appointed to the office of Vice President, Apache ODE, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ODE Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ODE podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ODE podling encumbered upon the Apache Incubator PMC are hereafter discharged. -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ --
[RESULT] [VOTE] Release ServiceMix 3.0-incubating
The vote passes with 12 +1s and no other votes. 3 +1 from IPMC members: jstrachan, dims, robert +1 from ServiceMix community: Gert Vanthienen, Guillaume Nodet, Thomas Termin, Matt Hogstrom, Daniel Kulp, Jevgeni Holodkov, Philips Dodds, Bruce Snyder, Rob Davies I will move the repo to its final location. Thanks everyone ! Guillaume Nodet wrote: > The ServiceMix community voted on and approved to release > the 3.0-incubating version [1]. Pursuant to the Releases section of > the Incubation Policy and we would now like to request the > permission of the Incubator PMC to publish this release. > The release / download page is available at [2]: > > [1] > http://www.nabble.com/-VOTE--ServiceMix-3.0-M2-incubating-%28second-try%29-tf2251652.html > [2] http://servicemix.goopen.org/site/servicemix-30.html > > > Cheers, > Guillaume Nodet > > > > - > 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] Release ServiceMix 3.1.1 (2nd try)
Thanks you very much Robert :-) robert burrell donkin wrote: > On 7/3/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> Robert, did you had time to take a look ? > > i'm +1 > >> (other IPMC members are >> welcome too) > > maybe one day :-) > > - robert > > - > 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] Release ServiceMix 3.1.1 (2nd try)
Robert, did you had time to take a look ? (other IPMC members are welcome too) Cheers, Guillaume Nodet Guillaume Nodet wrote: > As a new release with updated LICENSE file has been uploaded, all > signatures have been updated too. > I've just checked and they all seem ok. > > Cheers, > Guillaume Nodet > > robert burrell donkin wrote: > >> On 7/2/07, James Strachan <[EMAIL PROTECTED]> wrote: >> >>> Robert, are you happy to +1 the release now? >>> >> after checking this thread, my substantive issue was the bad signatures >> >> if they've been updated, i'll take another look >> >> - robert >> >> > > - > 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] Release ServiceMix 3.1.1 (2nd try)
As a new release with updated LICENSE file has been uploaded, all signatures have been updated too. I've just checked and they all seem ok. Cheers, Guillaume Nodet robert burrell donkin wrote: > On 7/2/07, James Strachan <[EMAIL PROTECTED]> wrote: >> >> Robert, are you happy to +1 the release now? > > > after checking this thread, my substantive issue was the bad signatures > > if they've been updated, i'll take another look > > - robert > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release ServiceMix 3.1.1 (2nd try)
Just a friendly reminder that we're still missing an IPMC vote ;-) Thanks ! Guillaume Nodet wrote: > I have fixed the LICENSE with the missing informations > and redeployed a release to the same staging area. > Hopefully we will find a better way to handle the license informations > (I've seen some generated informations using maven) for the next major > release and fix the generated license files somehow. > > Could everyone quickly review the changes ? > I won't start a new vote as only the LICENSE file has > changed, but I can if someone objects. > > robert burrell donkin wrote: > >> On 5/29/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >>> robert burrell donkin wrote: >>> >>>> On 5/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>>> >>>>> Just a friendly reminder. We're missing anoter IPMC vote ... >>>>> >>>> issues >>>> --- >>>> >>>> i think that apache-servicemix-3.1.1-incubating.tar.gz has some >>>> libraries in lib that are missing their LICENSE/NOTICE entries (eg >>>> howl, jencks) >>>> >>> There are licensed under ASL 2.0 and don't have any NOTICE file afaik. >>> >> cool >> >> >>> Should all the jars be listed in the LICENSE / NOTICE file ? My >>> assumption >>> was that only those who had some attributions somehow or with a >>> different license >>> need to be, but correct me if I'm wrong. >>> >> it is safe to release without listing them (and if this were the only >> issue then i would probably have voted affirmatively) >> >> but the aim should be to allow people to understand the licensing of >> releases without need to ask questions or do research. if i don't >> understand the licensing then i will ask. so, it's a good idea to note >> the licenses for all jars since it avoids the need to answer questions >> like this... >> >> >> >> >>>> otherwise generally ok but i have a few questions >>>> >>>> source in >>>> >>>> >>> http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apache/servicemix/samples/wsdl-first/wsdl-first-jsr181-su/3.1.1-incubating/ >>> >>> >>>> lacks headers. is this going to be released? if so, are these >>>> generated? >>>> >>>> are the jars under >>>> http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/ going to >>>> be released? >>>> >>>> servicemix-wsn2005-3.1.1-incubating-sources.jar contains lots of java >>>> sources without headers (mostly under >>>> org.apache.servicemix.wsn.jaxws). is this going to be released? if so, >>>> are these generated? >>>> >>> Yeah, lots of these files are generated. Files generated are not in svn >>> so we usually check the headers on the svn tree rather than the source >>> jars generated by maven. These jars are not meant to be built for only >>> contain all the java sources for debugging purposes. If you want to >>> build these jars, you need to use the source distribution or use the svn >>> tag. >>> >> fine >> >> i hope to be a bit more prompt with the review next time >> >> - robert >> >> - >> 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] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release ServiceMix 3.1.1 (2nd try)
I have fixed the LICENSE with the missing informations and redeployed a release to the same staging area. Hopefully we will find a better way to handle the license informations (I've seen some generated informations using maven) for the next major release and fix the generated license files somehow. Could everyone quickly review the changes ? I won't start a new vote as only the LICENSE file has changed, but I can if someone objects. robert burrell donkin wrote: > On 5/29/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >> >> robert burrell donkin wrote: >> > On 5/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >> Just a friendly reminder. We're missing anoter IPMC vote ... >> > >> > issues >> > --- >> > >> > i think that apache-servicemix-3.1.1-incubating.tar.gz has some >> > libraries in lib that are missing their LICENSE/NOTICE entries (eg >> > howl, jencks) >> There are licensed under ASL 2.0 and don't have any NOTICE file afaik. > > cool > >> Should all the jars be listed in the LICENSE / NOTICE file ? My >> assumption >> was that only those who had some attributions somehow or with a >> different license >> need to be, but correct me if I'm wrong. > > it is safe to release without listing them (and if this were the only > issue then i would probably have voted affirmatively) > > but the aim should be to allow people to understand the licensing of > releases without need to ask questions or do research. if i don't > understand the licensing then i will ask. so, it's a good idea to note > the licenses for all jars since it avoids the need to answer questions > like this... > > > >> > otherwise generally ok but i have a few questions >> > >> > source in >> > >> http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apache/servicemix/samples/wsdl-first/wsdl-first-jsr181-su/3.1.1-incubating/ >> >> > >> > lacks headers. is this going to be released? if so, are these >> > generated? >> > >> > are the jars under >> > http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/ going to >> > be released? >> > >> > servicemix-wsn2005-3.1.1-incubating-sources.jar contains lots of java >> > sources without headers (mostly under >> > org.apache.servicemix.wsn.jaxws). is this going to be released? if so, >> > are these generated? >> Yeah, lots of these files are generated. Files generated are not in svn >> so we usually check the headers on the svn tree rather than the source >> jars generated by maven. These jars are not meant to be built for only >> contain all the java sources for debugging purposes. If you want to >> build these jars, you need to use the source distribution or use the svn >> tag. > > fine > > i hope to be a bit more prompt with the review next time > > - robert > > - > 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: 3rd party dependencies that don't provide maven binary artifacts
This one is mainly for fixes on existing metadata. The one for uploading new artifacts is available at http://jira.codehaus.org/browse/MAVENUPLOAD See also the instructions available at: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Cheers, Guillaume Guillaume Nodet wrote: > Sorry. > Here it is: http://jira.codehaus.org/browse/MEV > > kelvin goodson wrote: > >> Hi Guillame, >> thanks for the tip. Could you post the reference [1] that you >> referred to please? >> >> Regards, Kelvin. >> >> On 25/06/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >>> I think you can just create a JIRA at [1] so that your dependencies >>> will be uploaded in the public repository. >>> The public maven repository is handled by the maven guys. >>> >>> I guess another way is to make an archive of your local repository >>> and store it in a publicly available location so that one can always >>> rebuild the release if needed. I know maven has a feature to create >>> this zip file, but I can't recall where. >>> >>> Cheers, >>> Guillaume Nodet >>> >>> kelvin goodson wrote: >>> >>>> How can an Apache project robustly handle the situation where 3rd >>>> party dependencies don't provide maven binary artifacts? In >>>> particular, when an Apache release is made, we need to be sure that >>>> the 3rd party dependencies are available for as long as the release is >>>> available. >>>> >>>> Regards, Kelvin. >>>> >>>> - >>>> 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] >>> >>> >>> >> - >> 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] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3rd party dependencies that don't provide maven binary artifacts
Sorry. Here it is: http://jira.codehaus.org/browse/MEV kelvin goodson wrote: > Hi Guillame, > thanks for the tip. Could you post the reference [1] that you > referred to please? > > Regards, Kelvin. > > On 25/06/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> I think you can just create a JIRA at [1] so that your dependencies >> will be uploaded in the public repository. >> The public maven repository is handled by the maven guys. >> >> I guess another way is to make an archive of your local repository >> and store it in a publicly available location so that one can always >> rebuild the release if needed. I know maven has a feature to create >> this zip file, but I can't recall where. >> >> Cheers, >> Guillaume Nodet >> >> kelvin goodson wrote: >> > How can an Apache project robustly handle the situation where 3rd >> > party dependencies don't provide maven binary artifacts? In >> > particular, when an Apache release is made, we need to be sure that >> > the 3rd party dependencies are available for as long as the release is >> > available. >> > >> > Regards, Kelvin. >> > >> > - >> > 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] >> >> > > - > 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: 3rd party dependencies that don't provide maven binary artifacts
I think you can just create a JIRA at [1] so that your dependencies will be uploaded in the public repository. The public maven repository is handled by the maven guys. I guess another way is to make an archive of your local repository and store it in a publicly available location so that one can always rebuild the release if needed. I know maven has a feature to create this zip file, but I can't recall where. Cheers, Guillaume Nodet kelvin goodson wrote: > How can an Apache project robustly handle the situation where 3rd > party dependencies don't provide maven binary artifacts? In > particular, when an Apache release is made, we need to be sure that > the 3rd party dependencies are available for as long as the release is > available. > > Regards, Kelvin. > > - > 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] Release ServiceMix 3.1.1 (2nd try)
robert burrell donkin wrote: > On 5/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> Just a friendly reminder. We're missing anoter IPMC vote ... > > issues > --- > > i think that apache-servicemix-3.1.1-incubating.tar.gz has some > libraries in lib that are missing their LICENSE/NOTICE entries (eg > howl, jencks) There are licensed under ASL 2.0 and don't have any NOTICE file afaik. Should all the jars be listed in the LICENSE / NOTICE file ? My assumption was that only those who had some attributions somehow or with a different license need to be, but correct me if I'm wrong. > > apache-servicemix-3.1.1-incubating-src.zip contains a directory that > seems like somethings gone wrong (src/C:tmp) I will fix that. > > https://svn.apache.org/repos/asf/incubator/servicemix/tags/servicemix-3.1.1/web/servicemix-web-console/src/main/webapp/WEB-INF/sitemesh-decorator.tld > > is licensed under "The OpenSymphony Software License, Version 1.1" - i > can't see this in LICENSE or NOTICE. same goes to > https://svn.apache.org/repos/asf/incubator/servicemix/tags/servicemix-3.1.1/web/servicemix-web-console/src/main/webapp/WEB-INF/sitemesh-page.tld > > > i think that > https://svn.apache.org/repos/asf/incubator/servicemix/tags/servicemix-3.1.1/web/servicemix-web-console/src/main/webapp/js/common.js > > requires attribution but i can't see anything in NOTICE > > i think that > https://svn.apache.org/repos/asf/incubator/servicemix/tags/servicemix-3.1.1/web/servicemix-web-console/src/main/webapp/js/css.js > > is missing from the LICENSE > > also > https://svn.apache.org/repos/asf/incubator/servicemix/tags/servicemix-3.1.1/web/servicemix-web-console/src/main/webapp/js/plotkit/*.js > > > (after re-reading the latest version of > http://www.apache.org/legal/src-headers.html, i'm not sure how this > applies javascript and other distributed source. i'll follow this up > with legal.) I will add these informations to the LICENSE / NOTICE files. > > otherwise generally ok but i have a few questions > > source in > http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apache/servicemix/samples/wsdl-first/wsdl-first-jsr181-su/3.1.1-incubating/ > > lacks headers. is this going to be released? if so, are these > generated? > > are the jars under > http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/ going to > be released? > > servicemix-wsn2005-3.1.1-incubating-sources.jar contains lots of java > sources without headers (mostly under > org.apache.servicemix.wsn.jaxws). is this going to be released? if so, > are these generated? Yeah, lots of these files are generated. Files generated are not in svn so we usually check the headers on the svn tree rather than the source jars generated by maven. These jars are not meant to be built for only contain all the java sources for debugging purposes. If you want to build these jars, you need to use the source distribution or use the svn tag. Cheers, Guillaume Nodet > > > comments and observations (not requirements) > > > README is good. one issue that you might have with linking to the > website is that the information is likely to apply to the current > release which may not be the release that the user has. there are > various ways around this for example archiving documentation for every > release on the website or linking to a distributed document. > > - robert > > - > 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] Release ServiceMix 3.1.1 (2nd try)
Just a friendly reminder. We're missing anoter IPMC vote ... On 5/22/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: I have uploaded a version of ServiceMix 3.1.1 in the standard repo for you to review. See http://incubator.apache.org/servicemix/servicemix-311.html for the future download page and release notes (these are also included in the distribution). The distribution have been uploaded to http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apache/servicemix/apache-servicemix/3.1.1-incubating/<http://people.apache.org/%7Egnodet/servicemix-3.1.1-incubating/org/apache/servicemix/apache-servicemix/3.1.1-incubating/> I send this mail both to the dev list and [EMAIL PROTECTED], as a first vote has been conducted on the ServiceMix dev list and some issues have been fixed since that, so hopefully this one will be fine. [ ] +1 Release ServiceMix 3.1.1 [ ] +/- 0 [ ] -1 Do not release ServiceMix 3.1.1 The rat log is available at http://people.apache.org/~gnodet/rat-servicemix-3.1.1-incubating.txt <http://people.apache.org/%7Egnodet/rat-servicemix-3.1.1-incubating.txt> Here's my +1 -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
[VOTE] Release ServiceMix 3.1.1 (2nd try)
I have uploaded a version of ServiceMix 3.1.1 in the standard repo for you to review. See http://incubator.apache.org/servicemix/servicemix-311.html for the future download page and release notes (these are also included in the distribution). The distribution have been uploaded to http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apache/servicemix/apache-servicemix/3.1.1-incubating/ I send this mail both to the dev list and [EMAIL PROTECTED], as a first vote has been conducted on the ServiceMix dev list and some issues have been fixed since that, so hopefully this one will be fine. [ ] +1 Release ServiceMix 3.1.1 [ ] +/- 0 [ ] -1 Do not release ServiceMix 3.1.1 The rat log is available at http://people.apache.org/~gnodet/rat-servicemix-3.1.1-incubating.txt<http://people.apache.org/%7Egnodet/rat-servicemix-3.1.1-incubating.txt> Here's my +1 -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: [VOTE] approve the release of Trinidad's Core (1.0.0-incubating)
Matthias Wessendorf wrote: >> >> the pom has it's license stripped out. IIRC this is a maven bug >> (hopefully someone will jump in with more information). anyone know >> when this is likely to be fixed? > > sorry, I don't The way to work around the problem is to move the license header under the root tag as shown at http://svn.apache.org/repos/asf/incubator/servicemix/trunk/pom.xml Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incentive for Graduation
I don't think this would be a good idea to not allow one podling to release anything. Let me state my thoughts: the goal of a podling is to build a lively and heterogeneous community to be able to graduate. Usually, there is one or more company behind a project. If there are more than one company, the community will not be completely homogeneous, so things will be eased. So the problem is when a single company provides resources for a given project. In such a case, other committers usually come from the user community and this takes time. I think that one of the goal of the podling should be to build a user community, so that users can become developers. So not allowing podlings to release anything will certainly not help building / growing the user community, hence the dev community. Cheers, Guillaume Nodet Davanum Srinivas wrote: > Niclas, > > Here the scenario is a project with all committers from one employer > and regular releases. > > -- dims > > On 3/17/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: >> On Friday 16 March 2007 19:46, Davanum Srinivas wrote: >> > What are we going to do >> > about projects that will show signs of life but will remain in >> > incubator for a very long time. when do we kick them out? 3 years? 5 >> > years? >> >> No community -> no releases ?? >> >> >> Cheers >> Niclas >> >> - >> 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: Killing the incubator m2 repository
Here they are: https://issues.apache.org/activemq/browse/SM-608 https://issues.apache.org/activemq/browse/SM-838 http://www.nabble.com/Maven-repository-problem-tf2811096s12049.html#a7851593 http://www.nabble.com/WSDL-First-example-tf2373483s12049.html#a6612649 http://www.nabble.com/Installing-loan-broker-bpel-example-tf2374581s12049.html#a6783204 http://www.nabble.com/Error-building-tooling-projects-tf2500901s12049.html#a6996849 http://www.nabble.com/Help-running-Maven-examples-tf2598289s12049.html#a7346692 Just a few notes: We have somewhat managed to lower the problems which were caused mainly by the examples shipped in ServiceMix distribution that did not include the incubating repository: this means that users could not even use our examples out of the box :-( While I think ServiceMix is known as being in incubator at the ASF (the distribution, main dir and all jars have incubator in their name, in addition to the incubator logo on the web site, disclaimers, etc ...), i have exchanged mails from people who do not understand what incubator is. They are really thinking it is a sandbox for non mature projects (i don't say community here): they are referring to code, so that it is clear that they don't get what the incubator is about. Usually, when you use maven to reference a project, you know this project, so that it seems quite unnecessary to force people to add the incubating repo in their pom, as they already know that the project is in incubation (even if they don't understand what it means, but this is another problem). For people who already understand maven, this is not a problem. For beginners, it is quite a problem to understand why this does not work. Some may post a mail to the mailing list, but how many did not and gave up ? While the incubator is a good idea, it seems that it is more difficult to build a community inside the incubator than outside, because of all the existing rules. And remember that the release early, release often mantra can not be applied on podlings, given the pain to release a project in incubation. Cheers, Guillaume Nodet Davanum Srinivas wrote: > Sorry, i lost you. this whole "we need podling artifacts in central > repo" because right now you are putting our user through a meat > grinder has no basis in fact. Am asking for JIRA issues, email threads > that show that this is indeed a serious issue and not just a made up > issue. Show me the evidence is what i am asking. > > thanks, > dims > > On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: >> On 3/16/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >> >> > Please see #1 item here: >> > http://marc.info/?l=incubator-general&m=117397443306478&w=2 >> >> Did you read #5 as well? It contradicts your point. >> >> -- >> Emacs 22 will support MacOS and CygWin. It is not yet decided, whether >> these will be used to run Emacs or the other way round. >> >> - >> 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]
Request to create the account for Eric Dofonsou
Eric Dofonsou has been voted in as a committer on Apache ServiceMix some time ago, but there were some problems with his CLA. Jim said it is now filed, so, I kindly request root to create an account for Eric Dofonsou and grant him access to ServiceMix (incubator). username : ewrick forward email : [EMAIL PROTECTED] full name : Eric Dofonsou -- Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE RESULTS] Release Apache Servicemix 3.1-incubating
The vote is now closed with the following votes: * +1 votes: James Strachan, Yoav Shapira, Davanum Srinivas * 0 votes: none * -1 votes: none The vote passes. Thanks to everyone ! Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Apache ServiceMix 3.1-incubating (2nd try)
The ServiceMix community has voted to relase apache-serviemix-3.1-incubating. We now ask the Incubator PMC to approve this release. Download page, release notes, etc ... http://incubator.apache.org/servicemix/servicemix-31.html Direct links: http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating.tar.gz http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating-src.tar.gz The rat log output is available at: http://people.apache.org/~gnodet/rat-servicemix-3,1-incubating.txt Cheers, Guillaume Nodet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Apache ServiceMix 3.1-incubating
I have uploaded a new version of which includes the missing license for JAXB and JAXWS. I will start a new vote. Cheers, Guillaume Nodet Guillaume Nodet wrote: > Thilo Goetz wrote: > >> Hi, >> >> I'm currently involved in preparing the first UIMA incubator release, >> so I looked at your release with a view to what I could learn ;-) To >> my (newbie) eyes it all looks very clean, license headers everywhere etc. >> > Thanks ! > >> One thing I noted is that you're distributing the Java Activation >> framework. It is my understanding that the Activation framework has a >> bit of a problematic license, which is why it is not available from >> our m2 repository, for example. You also do not copy the license in >> your LICENSE file. The license has some legalese that I do not >> pretend to understand. If this is all above-board and you can point >> me to some previous discussion, all the better. >> > JAF (1.1) and JavaMail 91.4) are now distributed under CDDL, which is > compatible with the ASL > (see http://people.apache.org/~cliffs/3party.html). > The CDDL License has been included for JAXB and JAXWS, but you're right, > it seems to be missing > for jaf and mail :-( > > Cheers, > Guillaume Nodet > >> --Thilo >> >> Guillaume Nodet wrote: >> >>> The ServiceMix community has voted to relase >>> apache-serviemix-3.1-incubating. >>> We now ask the Incubator PMC to approve this release. >>> >>> Download page, release notes, etc ... >>> http://incubator.apache.org/servicemix/servicemix-31.html >>> >>> >>> Direct links: >>> >>> http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating.tar.gz >>> >>> >>> http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating-src.tar.gz >>> >>> >>> Cheers, >>> Guillaume Nodet >>> >>> >>> - >>> 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] >> >> >> >> > > - > 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] Release Apache ServiceMix 3.1-incubating
Here it is: http://people.apache.org/~gnodet/rat-servicemix-3,1-incubating.txt Cheers, Guillaume Nodet Guillaume Nodet wrote: > Yoav Shapira wrote: > >> Hi, >> The bug / improvement list shows an impressive amount of work for a >> point release. Just out of curiosity (not related to approving the >> release), what kind of automated testing do you use? >> > > We have junit test cases and constant feedback of the user community ;-) > >> As for the release itself: have you had a chance to run Robert's RAT >> tool (http://code.google.com/p/arat/)? >> > Yeah, I ran it some days ago. > I will try to post the output log somewhere so that it can be reviewed. > > Cheers, > Guillaume Nodet > >> Yoav >> >> On 2/8/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >>> The ServiceMix community has voted to relase >>> apache-serviemix-3.1-incubating. >>> We now ask the Incubator PMC to approve this release. >>> >>> Download page, release notes, etc ... >>> http://incubator.apache.org/servicemix/servicemix-31.html >>> >>> >>> Direct links: >>> >>> http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating.tar.gz >>> >>> >>> http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating-src.tar.gz >>> >>> >>> Cheers, >>> Guillaume Nodet >>> >>> >>> - >>> 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] >> >> >> >> > > - > 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] Release Apache ServiceMix 3.1-incubating
Thilo Goetz wrote: > Hi, > > I'm currently involved in preparing the first UIMA incubator release, > so I looked at your release with a view to what I could learn ;-) To > my (newbie) eyes it all looks very clean, license headers everywhere etc. Thanks ! > > One thing I noted is that you're distributing the Java Activation > framework. It is my understanding that the Activation framework has a > bit of a problematic license, which is why it is not available from > our m2 repository, for example. You also do not copy the license in > your LICENSE file. The license has some legalese that I do not > pretend to understand. If this is all above-board and you can point > me to some previous discussion, all the better. JAF (1.1) and JavaMail 91.4) are now distributed under CDDL, which is compatible with the ASL (see http://people.apache.org/~cliffs/3party.html). The CDDL License has been included for JAXB and JAXWS, but you're right, it seems to be missing for jaf and mail :-( Cheers, Guillaume Nodet > > --Thilo > > Guillaume Nodet wrote: >> The ServiceMix community has voted to relase >> apache-serviemix-3.1-incubating. >> We now ask the Incubator PMC to approve this release. >> >> Download page, release notes, etc ... >> http://incubator.apache.org/servicemix/servicemix-31.html >> >> >> Direct links: >> >> http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating.tar.gz >> >> >> http://people.apache.org/repo/m2-incubating-repository/org/apache/servicemix/apache-servicemix/3.1-incubating/apache-servicemix-3.1-incubating-src.tar.gz >> >> >> Cheers, >> Guillaume Nodet >> >> >> - >> 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] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
