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.

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 :)

Re: [vfs] split of vfs

> 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

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.

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.

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.

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.

>
> 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]>
>

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#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?

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?
>

Re: [vfs] split of vfs

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

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 ;-)
>

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.