Re: [vfs] split of vfs
Hi Rahul! I supported this approach then [1], and I will support it now. Yes, its your idea I proposed now (+ adding the sandbox jar) :-) Well, at this [1] time I wasn't ready to go that road, now, during the months I had time think about ;-) Ciao, Mario [1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=114166113220091w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] split of vfs
Hi! The pressure to release VFS is getting higher and higher :-) And maybe there is a solution to restart the release cycle even with all the open stuff not solved. Whats missing to release VFS: *) commons-compress release *) webdav-client (slide) release *) solving the jcifs licensing issue If we split VFS in two pieces - commons-vfs.jar - commons-vfs-sandbox.jar it might be manageable. The sandbox jar isn't releasable, its a sandbox - so no additional work. Initially, this sandbox contains the following filesystems: * bz2 * tar * webdav * smb The user can activate them by simply plugging the commons-vfs-sandbox.jar into the classpath. What do you think? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
Mario Ivankovits wrote: Hi! Initially, this sandbox contains the following filesystems: * bz2 * tar * webdav * smb The user can activate them by simply plugging the commons-vfs-sandbox.jar into the classpath. Then why not split that further and have commons-vfs-bz2.jar etc... This way the core would be independent of the implementation, as well building the .bz2 or something like will not be dependent of the external libs used only by the specifics like webdav, ftp, etc... If some implementation needs an external lib like httpclient, and others don't, then only that component should be dependent of it, not the entire package. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Initially, this sandbox contains the following filesystems: * bz2 * tar * webdav * smb The user can activate them by simply plugging the commons-vfs-sandbox.jar into the classpath. I think this is a great idea?and would like to see that this way. This would also take some pressure from the compress project. For the legal issue: if this cannot be solved, a sf.net project would do fine. Maybe this is useful for other commons projects too? my2pence - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyJ2akv8rKBUE/T4RAkSfAJ41sr/34LXTA7sI3MR7kHrLPRNNqACgin3V +1B7sPVGpruD02P7MXNZgCI= =GCyR -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
C. Grobmeier wrote: The user can activate them by simply plugging the commons-vfs-sandbox.jar into the classpath. I think this is a great idea?and would like to see that this way. This would also take some pressure from the compress project. For the legal issue: if this cannot be solved, a sf.net project would do fine. Maybe this is useful for other commons projects too? What legal issues are you refering? The ASF has prove it can create anything from scratch under the ASF license :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What legal issues are you refering? - From the users mailinglist: * we depend on jcifs (samba/smb) which changed its license in the past to lgpl, so this is a violation of the ASF rules we currently investigate. (Mario) The ASF has prove it can create anything from scratch under the ASF license :) hehe truly :-) - - Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyJ/+kv8rKBUE/T4RAmMIAKCA2VOTtISdA23Yp+4wRbZ9qldIIgCdEsO7 zg63DwxD1IVal5n2+4KNbWY= =EWzJ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This way the core would be independent of the implementation, as well building the .bz2 or something like will not be dependent of the external libs used only by the specifics like webdav, ftp, etc... If some implementation needs an external lib like httpclient, and others don't, then only that component should be dependent of it, not the entire package. i don't like these thousand mini-jars... must there be a vote for every one of these mini-jars? Makes lots of noise -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyKBmkv8rKBUE/T4RAsmzAKCG6E22wFvojG7hVGJoKlBUAsPl+gCgj4Hj ez/itcSHmOD8XpZmdCGJpyU= =WUrF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
Hi! Then why not split that further and have commons-vfs-bz2.jar etc... Yes, this is something Vincent Massol also told me to do. The reasons I wanted to go down to two jars are: *) each jar will have its own release cycle, means, we have to vote for each artifact, no? I think the number of mails in commons-dev is already high enough ;-) *) I have the feeling that maintaining it is way too much work for me now, say, building all these releases, checking them and so on. Once VFS again has a significant number of developers (or its own release manager) such a structure might be manageable. I know that it will be the nicer structure, but should a commons project have such a complicated structure, I guess no. Maybe it might work better if VFS is a TLP (or at least out of commons) with its own mailing list and so on, though, not sure if/when this will happen. The lack of developers is definitely a NoNo for this. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] split of vfs
Mario Ivankovits wrote on Thursday, July 27, 2006 1:15 PM: Hi! Then why not split that further and have commons-vfs-bz2.jar etc... Yes, this is something Vincent Massol also told me to do. The reasons I wanted to go down to two jars are: *) each jar will have its own release cycle, means, we have to vote for each artifact, no? I think the number of mails in commons-dev is already high enough ;-) *) I have the feeling that maintaining it is way too much work for me now, say, building all these releases, checking them and so on. Once VFS again has a significant number of developers (or its own release manager) such a structure might be manageable. I know that it will be the nicer structure, but should a commons project have such a complicated structure, I guess no. Maybe it might work better if VFS is a TLP (or at least out of commons) with its own mailing list and so on, though, not sure if/when this will happen. The lack of developers is definitely a NoNo for this. Well, therefore I would not split it at all. If you feel that the core API is right, just release 1.0 with all stuff left outside, that might cause licensing trouble. You may release 1.1 later on easily with the stuff included as soon as you have answers. As marked out in the other thread, marking dependencies as optional is perfectly valid. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
Hi Jörg! Well, therefore I would not split it at all. If you feel that the core API is right, just release 1.0 with all stuff left outside, that might cause licensing trouble. You may release 1.1 later on easily with the stuff included as soon as you have answers. Not only licensing troubles, also the thing with snapshot/not-released dependencies. bz2 and tar hurts if they are not at least easily pluggable, sure, I can copy compress (its not that big) to VFSs codebase (to a different namespace), then, only smb and webdav is missing. Its an option, but I like the snapshot jar way more. As marked out in the other thread, marking dependencies as optional is perfectly valid. Uhm ... this is not possible with maven 1, is it? Could you give me a hint please. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
In M1 there's no transitive dependencies, thus your users will have to define each dependency one by one. But to improve the conversion between m1 and m2 poms for the repository, if you deploy VFS with m1 you can add the following setting : http://maven.apache.org/maven-1.x/using/bestpractices.html#Getting_ready_for_Maven_2 Arnaud On 7/27/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Jörg! Well, therefore I would not split it at all. If you feel that the core API is right, just release 1.0 with all stuff left outside, that might cause licensing trouble. You may release 1.1 later on easily with the stuff included as soon as you have answers. Not only licensing troubles, also the thing with snapshot/not-released dependencies. bz2 and tar hurts if they are not at least easily pluggable, sure, I can copy compress (its not that big) to VFSs codebase (to a different namespace), then, only smb and webdav is missing. Its an option, but I like the snapshot jar way more. As marked out in the other thread, marking dependencies as optional is perfectly valid. Uhm ... this is not possible with maven 1, is it? Could you give me a hint please. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] split of vfs
Arnaud HERITIER wrote on Thursday, July 27, 2006 3:57 PM: In M1 there's no transitive dependencies, thus your users will have to define each dependency one by one. But to improve the conversion between m1 and m2 poms for the repository, if you deploy VFS with m1 you can add the following setting : http://maven.apache.org/maven-1.x/using/bestpractices.html#Get ting_ready_for_Maven_2 Arnaud Wasn't there also a way to define optional, so that the POM 2.0 converter will automatically set them? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
Hi ! http://maven.apache.org/maven-1.x/using/bestpractices.html#Get ting_ready_for_Maven_2 Wasn't there also a way to define optional, so that the POM 2.0 converter will automatically set them? The documentations says that this will be the case when adding properties scopetest/scope /properties to the dependency. But I wonder how will this help Vincent? I added Vincent as cc - Vincent, will this be of any help? --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
On 7/27/06, Jörg Schaible [EMAIL PROTECTED] wrote: Arnaud HERITIER wrote on Thursday, July 27, 2006 3:57 PM: In M1 there's no transitive dependencies, thus your users will have to define each dependency one by one. But to improve the conversion between m1 and m2 poms for the repository, if you deploy VFS with m1 you can add the following setting : http://maven.apache.org/maven-1.x/using/bestpractices.html#Get ting_ready_for_Maven_2 Arnaud Wasn't there also a way to define optional, so that the POM 2.0 converter will automatically set them? properties optionaltrue/optional /properties - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
I prefer several jars On 7/27/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Then why not split that further and have commons-vfs-bz2.jar etc... Yes, this is something Vincent Massol also told me to do. The reasons I wanted to go down to two jars are: *) each jar will have its own release cycle, means, we have to vote for each artifact, no? I think the number of mails in commons-dev is already high enough ;-) You can release all of them together calling only for a vote, release them separately is an optional (but useful) feature VFS 1.0 can be a composition of several vfs-*-1.0 jars, with just one tag *) I have the feeling that maintaining it is way too much work for me now, say, building all these releases, checking them and so on. Once VFS again has a significant number of developers (or its own release manager) such a structure might be manageable. I know that it will be the nicer structure, but should a commons project have such a complicated structure, I guess no. Maybe it might work better if VFS is a TLP (or at least out of commons) with its own mailing list and so on, though, not sure if/when this will happen. The lack of developers is definitely a NoNo for this. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
Mario Ivankovits wrote: Hi! Then why not split that further and have commons-vfs-bz2.jar etc... Yes, this is something Vincent Massol also told me to do. The reasons I wanted to go down to two jars are: *) each jar will have its own release cycle, means, we have to vote for each artifact, no? I think the number of mails in commons-dev is already high enough ;-) No. The release process would be like for the httpd. We have core and we have core modules. The release depends on all core modules, but you can build core without modules. Take for example the httpd and mod_ssl. mod_ssl depends on OpenSSL, but the httpd itself does not, although its dependent on the mod_ssl, rely on mod_ssl. The point is to have the modular build system, that does not depend on protocol specific libs. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] split of vfs
-Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: jeudi 27 juillet 2006 16:23 To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: Re: [vfs] split of vfs Hi ! http://maven.apache.org/maven-1.x/using/bestpractices.html#Get ting_ready_for_Maven_2 Wasn't there also a way to define optional, so that the POM 2.0 converter will automatically set them? The documentations says that this will be the case when adding properties scopetest/scope /properties to the dependency. But I wonder how will this help Vincent? I added Vincent as cc - Vincent, will this be of any help? I have already answered to Jörg Schaible on the user list. If you recall I have even submitted a Maven2 POM (this optional stuff works only with Maven2). See http://issues.apache.org/jira/browse/VFS-70 This doesn't help really me but is something to do when you move to M2. Thanks -Vincent PS: My email is going to be moderated as I'm not subscribed. ___ Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences. http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] split of vfs
On 7/27/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! snip/ If we split VFS in two pieces - commons-vfs.jar - commons-vfs-sandbox.jar it might be manageable. The sandbox jar isn't releasable, its a sandbox - so no additional work. snap/ What do you think? snip/ I supported this approach then [1], and I will support it now. -Rahul [1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=114166113220091w=2 Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
