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]
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
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
-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
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
-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
-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
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
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,
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
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 :
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
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
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
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
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?
-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
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
18 matches
Mail list logo