Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating
Le 5/9/12 6:35 PM, sebb a écrit : On 9 May 2012 07:42, Emmanuel Lécharnyelecha...@gmail.com wrote: Le 5/9/12 2:27 AM, sebb a écrit : On 8 May 2012 13:06, Emmanuel Lécharnyelecha...@gmail.comwrote: Comments inline Le 5/8/12 11:05 AM, sebb a écrit : On 8 May 2012 09:13, Francesco Chicchiriccòilgro...@apache.org wrote: Hi Sebb, you can find my replies embedded below. I am going to send a [CANCEL] reply to this thread, remove Nexus staging repo and SVN tag, fix everything and start again the release process for 1.0.0-RC1-incubating from scratch. Regards. The NOTICE file is very long; I suspect that not all of the entries are *required*. The LICENSE and NOTICE files were written against the parent POM: all the dependencies with scope != test were considered, then. The NL files must relate to what is actually included in the archive. We release sources, so making a distinction between scope != test dependencies and scope=test dependencies does not make sense, AFAICT. If we use a 3rd party product to test Syncope, then I think we must refer their licenses in NOTICE and LICENSE. No, AIUI the NL files only relate to what is being released, not any external dependencies. See JDBM example in http://incubator.apache.org/guides/releasemanagement.html#note-license-and-notice. Typically, JDBM will be a dependencies, but still it requires you to include the needed references into NL files. I'm a bit lost here, as the idea is to allow users to download the source package we release, and not infringe any of the 3rd party software Licences, by including in our own NL files what the 3rd party product requires us to include. The cited link says: So, if the release _redistributes_ any source or artifacts ... As Syncope is distributing wars, I guess it enters into this category. ... This product _includes_ software developed by ... [My _emphasis_] It's clear from the above that the NL must relate to what is actually included in the release package. Unless dependencies are included in the release, they should not be mentioned in the NL files. Ok, loud and clear... There are separate rules for what 3rd party software ASF projects are allowed to depend on. Yep. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating
Le 5/7/12 2:47 PM, sebb a écrit : On 7 May 2012 10:38, Francesco Chicchiriccòilgro...@apache.org wrote: I've created a 1.0.0-RC1-incubating release, with the following artifacts up for a vote: SVN source tag (r1333797): https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/ There must be an Incubator DISCLAIMER. This is required in all distributions (and on the web-site, which has been done). Holly cow... I totally forgot this guy... http://incubator.apache.org/incubation/Incubation_Policy.html#Releases ( the release archive MUST contain an Incubation disclaimer (as described in the previous section), clearly visible in the main documentation or README file.) see http://incubator.apache.org/guides/branding.html for the DISCLAIMER content... Please add the DISCLAIMER file to SVN and make sure it gets added to all archives. The NOTICE file is very long; I suspect that not all of the entries are *required*. For example, cglib is available under AL 2.0, so I don't think it needs to be mentioned in the NOTICE file. The LICENSE file should mention all software included in the release. I do think this is the case. Do you have any missing software in mind ? Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-034/ The syncope-root POM does not use the Apache POM as parent. ASF product Poms should normally chain back to a version of the Apache pom to ensure that the correct settings are established. [the other poms do chain back to the Apache pom] Adding : parent groupIdorg.apache/groupId artifactIdapache/artifactId version10/version relativePath / /parent should do the trick (Check that the current version is not 10) Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] CloudStack for Apache Incubator
+1: accept CloudStack into Incubator (binding) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Missing reports
Le 4/5/12 12:51 PM, Simone Tripodi a écrit : Hi Jukka, apologize for being late, Syncope report is now available. Apologize once again but that's not exactly the easier era of my life, had been overloaded :( Many many thanks Simone. I totally missed the notification. My bad :/ -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Le 3/29/12 3:41 PM, Daniel Shahaf a écrit : Jukka Zitting wrote on Thu, Mar 29, 2012 at 14:41:02 +0200: Hi, On Wed, Mar 28, 2012 at 5:19 PM, Leo Simonsm...@leosimons.com wrote: Shipping a set of CDDL jars out of some java.net projects that oracle has all but abandoned is far beyond my imagined threshold of reasonable on the scale. Do you actually see that differently? Agreed. These are exactly the kinds of questions that legal-discuss@ has been working on. I.e. which kinds of dependencies are acceptable, and how they should be referenced/included/documented/etc.? It seems like Roy is much more categorical about this. Assuming I understand his point correctly, *no* binary dependencies are acceptable within a source tarball. What I don't quite (yet) understand is how a reference like junit:junit:4.10 to a download service maintained by a third party is more acceptable than directly including the referenced bits. The only difference I see is whether we have the right to redistribute those bits ourselves, but that question is already covered by legal. junit is only needed for unit tests and not for the software itself; is this relevant to the example? We have *many* external depencies in Directory (like antlr, xpp3, dom4j, openSymphony, councycastle, ...) which are stored and managed by Maven. When you build the project, all those jars will be pulled from the repository, and injected into the binary resulting from the build. If someone pull the sources from SVN, and build the project, he will get the complete working binary. One more step, and he will also get the installers (we have one sub-project that build those installers for each platform we are supporting - currently windows, linux, mac OSX, and a standard jar -. So far, so good. Now, building the project is just a nightmare for our users, so we provide the binary installers. So are most of the Java TLP, AFAICT, and thos binary contains all those external jars. My understanding is that, as far as we offer our users a way to build the binaries from svn, and as far as we don't have included the jars in SVN, we are golden. And My understanding is that this is *the release*. OTOH, the binaries we provide, ie the installers/jars/whatever are just convenient deliveries that are not blessed by The ASF. Those users who chose to pick those binaries, and expect The ASF to protect themselves against a trial because the project has badly included a binary that is not compatible with the ASL 2.0 licence, will not be protected by the ASL 2.0 licence. Now, the maven repository being hosted at The ASF, the difference is, imho, really really thin. Am I missing something ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator site modifcations question
Hi guys, yesterday I tried to update the incubator web site to reflect the renaming of the deft project to AWF. To some extent, it was successful : http://incubator.apache.org/projects/ points to AWF However, the main site at http://incubator.apache.org/ still refers to Deft. I committed site-publish and the modifed file, is there something else I have to update ? Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator site modifcations question
Le 2/21/12 11:28 AM, Mohammad Nour El-Din a écrit : Hi Emmanuel... This should be updated in another XML file which I can not remember out of my mind now, I would do it by the end of today if no one else picks this up! I did a grep -ri deft, and found nothing... The file must be stored somewhere else than in incubator/public/trunk -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244915 - /incubator/public/trunk/site-publish/.htaccess
Le 2/21/12 9:19 PM, sebb a écrit : On 21 February 2012 03:15, sebbseb...@gmail.com wrote: On 16 February 2012 10:12,franci...@apache.org wrote: Author: francisdb Date: Thu Feb 16 10:12:31 2012 New Revision: 1244915 URL: http://svn.apache.org/viewvc?rev=1244915view=rev Log: added redirect for empire-db Modified: incubator/public/trunk/site-publish/.htaccess That won't last - you need to update the source file in site-author and regenerate. PING - the last site rebuild overwrote your change. Ok, many thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
[X] +1 Recommend Jukka Zitting for the IPMC chair position. (binding) Go Jukka !!! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 2/1/12 10:39 AM, Ross Gardler wrote: On 1 February 2012 09:06, Emmanuel Lecharnyelecha...@gmail.com wrote: On 2/1/12 1:04 AM, Benson Margulies wrote: Dear Proposed Syncope mentors: Please post messages on this thread indicating your prior experience as mentors, Does mentors have to have any experience ? Is this a new policy for being a mentor on an incubator project, or something you just are interested in ? Personally I find the request for mentors to justify themselves in this way quite disturbing. I do understand what Benson is trying to address here, I just don't think this is the right way. We have not, to my knowledge, agreed any changes to the mentor role. All people currently able to mentor have been pre-approved by the IPMC. Frankly I find it distasteful expecting volunteers with good intentions to further justify themselves. Same feeling here. This would raise a barrier that is most likely to discourage potential mentors. This is a meritocracy, those who already have gain access to the IPMC have already proved themselves, and have qualified as potential mentors, imho. Not to say that every ASF member will be good mentors, but the reason we require that any podling have 3 mentors is just to mitigate the risk that one of them is not fullfiling his duty. Now, if we are to discuss the way incubator should be managed, then the best is to start another thread. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [grammar] pure java syntax analyzer (this is not a compiler of compiler)
Gaël Lalire wrote: Hello, Hi ! Today if you want to do syntax analysis, you have to use a compiler of compiler (bison, yacc, javaCC ...) which generates source code. After generation, you need to compile your generated source code and then you can parse some input. I dislike this method because : - you need to learn a meta-language (the language which describe the grammar) - reusability of grammar is excluded - the grammar cannot be dynamic (self described) However I did not found any dynamical grammar analyzer so I decided to write it. I separate my project in 3 modules : - API : define Token, Terminal, Grammar, exceptions, ... ; A lexical analyzer have to depends on this module to send terminals to the syntax analyzer - Impl : The analyzers (LR, LL, SLR, ...) and some calculation utilities. - SPI : This module provide user friendly abstract classes. For example, if you create a grammar using this module there will be a type checking (generics) on non-terminals and its rules, so you will be sure that there will be no ClassCastException. It also provide a easy way to create arithmetic expression (you just need to provide terminals, the helper will create the rules). I checked the code base and there are interesting (though partial) good ideas there. I really like the approach, ie providing a way to define your grammar in Java. Make me think that at some point, it could be cool to use annotations to define the grammar ... Why donate to apache ? I hope that I'm not the only one interested by having a runtime grammar tool, and I hope I could create a community on this project (because I'm alone). This isn't an easy domain, there is many things I do not know about compilation, so a community could bring speeder or new implementations. Also apache is well-known in university, which could be interested on this project for practical exercises. As Gurkan stated, the very first step is to fill a proposal : http://incubator.apache.org/guides/proposal.html Future tasks : - LL(*) to create (abstract LL exists and is untested) - LR(1+) to create (I need documentations) - LALR(*) to create (need documentations too) - SLR(2+) to create (need documentations always) - Naming issue (bad english, bad words ...) - Comments - Tutorial - Find a way to serialize the grammar's states (actions on terminal input maps) and restore it with a simple bindings of terminals instead of grammar analyze. - Create bindings with a lexer (ORO ? JDK ?) - More reusable grammar part (boolean expression, sql parser, ...) - Parsing error management - Create a BNF to the SPI convertor - ... I join a source code to this mail. This is a maven2 / eclipse project [eclipse is not mandatory but the .project is provided] Now I need a champion (If I understand the mechanism : apache rule are not simple) to integrate the project. Apache rules are simple. It's just that they are formal. This is the key to get a successful project out of incubation : The ASF is not sourceForge, and we promote Community above Code : the project must remain alive even if you quit it. Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Depending on incubating project
Niklas Gustavsson wrote: On Wed, Sep 17, 2008 at 7:11 AM, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Branch and experiment. FtpServer does not need to be one-dimensional. You will probably not release this code to an unsuspecting public anyway, will you? ;-) I wouldn't know about unsuspecting :-) Yes, I would like to include this code in the FtpServer releases. Of course we due warning in place, like the incubation disclaimer. It might be better to used directly a JSecurit release. As they already have released a 0.9 version outside of Apache, maybe helping them to get a first release inside Apache would help. Branching may be a problem as the code base will evolve in both projects, making it difficult to merge later. (IMHO) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
