[vfs] split of vfs

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[vfs] split of vfs

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Mladen Turk-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Chr. Grobmeier
In reply to this post by Mario Ivankovits
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Mladen Turk-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Chr. 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 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Chr. Grobmeier
In reply to this post by Mladen Turk-2
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Mario Ivankovits
In reply to this post by Mladen Turk-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [vfs] split of vfs

Jörg Schaible-2
In reply to this post by Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

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 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Arnaud Héritier
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

RE: [vfs] split of vfs

Jörg Schaible-2
In reply to this post by Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

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>
    <scope>test</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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Carlos Sanchez-4
In reply to this post by Jörg Schaible-2
On 7/27/06, Jörg Schaible <[hidden email]> 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>
   <optional>true</optional>
 </properties>

> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Carlos Sanchez-4
In reply to this post by Mario Ivankovits
I prefer several jars

On 7/27/06, Mario Ivankovits <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [vfs] split of vfs

vmassol
In reply to this post by Mario Ivankovits


> -----Original Message-----
> From: Mario Ivankovits [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 16:23
> To: Jakarta Commons Developers List
> Cc: [hidden email]
> 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>
>     <scope>test</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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Mladen Turk-2
In reply to this post by Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

Rahul Akolkar
In reply to this post by Mario Ivankovits
On 7/27/06, Mario Ivankovits <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] split of vfs

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]
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=114166113220091&w=2


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]