Re: [vfs] split of vfs

2006-07-28 Thread Mario Ivankovits
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]

[vfs] split of vfs

2006-07-27 Thread Mario Ivankovits
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

Re: [vfs] split of vfs

2006-07-27 Thread Mladen Turk
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

Re: [vfs] split of vfs

2006-07-27 Thread C. Grobmeier
-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

Re: [vfs] split of vfs

2006-07-27 Thread Mladen Turk
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

Re: [vfs] split of vfs

2006-07-27 Thread C. Grobmeier
-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

Re: [vfs] split of vfs

2006-07-27 Thread C. Grobmeier
-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

Re: [vfs] split of vfs

2006-07-27 Thread Mario Ivankovits
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

RE: [vfs] split of vfs

2006-07-27 Thread Jörg Schaible
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,

Re: [vfs] split of vfs

2006-07-27 Thread Mario Ivankovits
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

Re: [vfs] split of vfs

2006-07-27 Thread Arnaud HERITIER
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 :

RE: [vfs] split of vfs

2006-07-27 Thread Jörg Schaible
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

Re: [vfs] split of vfs

2006-07-27 Thread Mario Ivankovits
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

Re: [vfs] split of vfs

2006-07-27 Thread Carlos Sanchez
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

Re: [vfs] split of vfs

2006-07-27 Thread Carlos Sanchez
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

Re: [vfs] split of vfs

2006-07-27 Thread Mladen Turk
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?

RE: [vfs] split of vfs

2006-07-27 Thread Vincent Massol
-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

Re: [vfs] split of vfs

2006-07-27 Thread Rahul Akolkar
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