You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2006/07/27 12:50:49 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Carlos Sanchez <ca...@apache.org>.
I prefer several jars
On 7/27/06, Mario Ivankovits <ma...@ops.co.at> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Mladen Turk <mt...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Mario Ivankovits <ma...@ops.co.at>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by "C. Grobmeier" <gr...@possessed.de>.
-----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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Mladen Turk <mt...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by "C. Grobmeier" <gr...@possessed.de>.
-----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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Mladen Turk <mt...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by "C. Grobmeier" <gr...@possessed.de>.
-----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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Mario Ivankovits <ma...@ops.co.at>.
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-dev&m=114166113220091&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] split of vfs
Posted by Rahul Akolkar <ra...@gmail.com>.
On 7/27/06, Mario Ivankovits <ma...@ops.co.at> 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-dev&m=114166113220091&w=2
> Ciao,
> Mario
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org