I have from now to Octorber to either: 1. Implement test requirement to graduate vfs-cifs out of sandbox at Apache common
2. Release it as a alpha/beta at Codehaus together with vfs-maven-plugin 3. Release to our internal repo. The prefer one is 1 What is VFS 2.1 schedule? Thanks -Dan On Sun, Jul 22, 2012 at 11:01 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Dan? What are your plans or intentions here? > > Thank you, > Gary > > On Sat, Jul 21, 2012 at 12:48 AM, Gary Gregory <garydgreg...@gmail.com>wrote: > >> On Jul 19, 2012, at 12:11, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> > >> > On Jul 18, 2012, at 10:38 AM, sebb wrote: >> > >> >>>>> >> >>>>> Can the above be read as follows for VFS and JCIFS: you cannot copy >> the >> >>>>> JCIFS jar into VFS (which we do not) but the VFS POM can point to it >> (which >> >>>>> we do). >> >>>> >> >>>> The above document is only proposed, not actual policy. >> >>>> >> >>>> The following is the resolved list of questions: >> >>>> >> >>>> http://www.apache.org/legal/resolved.html >> >>>> >> >>>> In particular: >> >>>> >> >>>> http://www.apache.org/legal/resolved.html#optional >> >>>> >> >>>> "Will the majority of users want to use my product without adding the >> >>>> optional components? >> >>> >> >>> I do not see how this helps. It's yes or no: Can the VFS POM point to >> >>> a set of artifacts that are LGPL? >> >> >> >> Whether the answer is yes or no depends on the answer to the above >> question. >> > >> > There are only a few file systems in VFS that should be considered >> required. All the ones that require the user to include a third-party jar - >> even if it is Jackrabbit's - are optional. We could easily include file >> systems that have dependencies on artifacts that are licensed under the >> LGPL or similar licenses (although I would still shy away from GPL'd works >> because of the FSF's interpretation of their license). >> > >> > The biggest issue I see with the stuff in the sandbox isn't licensing >> but if anyone will support it. >> >> Ok, so the short answer is yes, we can move to trunk. The issue is >> whether someone can bring the code up to par. That person sounds like >> the author of the original post. After that, it's up to the >> committers, like me, to keep up. >> >> Gary >> >> > >> > Ralph >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
