[VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!

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

[VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol
Hi,

I've started using VFS last week on Cargo. As there were no releases I used
a snapshot which Henri had kindly put in the Apache Maven1 Snapshot
repository.

Someone just told me that Cargo is not building anymore because the 20060719
snapshot is no longer there! I checked and it's not there...

Now Cargo is not building for all users and developers. I don't know who's
had that brilliant idea of removing snapshots but that was not a good idea,
especially without giving advance warnings to all projects using them.

Now mind you I'm only using the snapshot repo because I'm forced to! There's
no release at all of VFS. Not even a 0.1 version!

I really hope a quick version can be released or the snapshot repository
fixed (the former being the preferred solution I believe) very fast as
otherwise it'll cause problems and we can't tolerate that our build fails
arbitrarily. Luckily I had not gone too far in using VFS and it can be
removed quite easily but that would be a real pity as I'm starting to like
it...

Sorry for the rant but this is really annoying me like nothing else. For me
the build is sacred and I pride myself in having a functioning build at all
times. Maven detractors are going to love this. This is going to be a huge
loss for Maven BTW. Imagine all those Maven projects depending on apache
snapshots that are now going to fail suddenly. Hani is going like it ;-)

BTW this shows the big downside of Maven. It only works if the remote repo
is stable. The worse is that you don't notice it as your build will continue
to work happily as your local repo still has the missing jars.

Thanks
-Vincent


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Wendy Smoak
On 7/26/06, Vincent Massol <[hidden email]> wrote:

> Someone just told me that Cargo is not building anymore because the 20060719
> snapshot is no longer there! I checked and it's not there...

It looks like there is an automated process to keep a week's worth of
nightly builds.  Files from 7/20 to 7/26 are present right now:
   http://people.apache.org/repo/m1-snapshot-repository/commons-vfs/jars/

(Changing the build to publish both -YYYYMMDD.jar and -SNAPSHOT.jar
might help, then the latest code would always be available at a fixed
filename.)

--
Wendy

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

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Mario Ivankovits
In reply to this post by vmassol
Hi Vincent!
> Someone just told me that Cargo is not building anymore because the 20060719
> snapshot is no longer there! I checked and it's not there...
>  
Yes, the automated build process only keeps a week of builds.
As a quick fix I updated the -SNAPSHOT to point to the build from
26-July-2006 (its a copy for now, so wont disappear)
Could you change your build to use the -SNAPSHOT?

Eventually, later, we will automatically set this snapshot to always the
latest build.

Which again might bring up some problems for you, as then the build can
fail due to internal VFS changes, though, that happened not that often -
not to say, it happened never before ;-)

> Luckily I had not gone too far in using VFS and it can be
> removed quite easily but that would be a real pity as I'm starting to like
> it...
>  
Don't jump the gun, I'll help you :-)

Sorry for the inconvenience!

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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol


> -----Original Message-----
> From: Mario Ivankovits [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 09:01
> To: Jakarta Commons Users List
> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> Hi Vincent!
> > Someone just told me that Cargo is not building anymore because the
> 20060719
> > snapshot is no longer there! I checked and it's not there...
> >
> Yes, the automated build process only keeps a week of builds.
> As a quick fix I updated the -SNAPSHOT to point to the build from
> 26-July-2006 (its a copy for now, so wont disappear)
> Could you change your build to use the -SNAPSHOT?

I'll try to do this but it's only marginally better than before. I don't
want the cargo build to try every day to use a new snapshot if there's one.
That would be good for a tool like Gump but I don't want Cargo to track the
VFS snapshots. I want to decide what version I use and I want to control
when I want to move to a new version. Otherwise it's simply going to be too
much maintenance work.

So what I really need is a version of VFS that is not going to go away (even
a timestamped version is fine but don't delete it. Maybe simply put it in
the Maven 1 Release Repository so that it doesn't get deleted. Call it
1.0-200607271124 for example.

BTW on a related note I think the versioning scheme for VFS is not correct.
I think it should have the target version number in the file name. Instead
of "SNAPSHOT", it should be "1.0-SNAPSHOT". Imagine that you start working
on a 2.0 branch for example.

The best is of course for you to release a 0.1 version. VFS had been going
on for what, a year? More? It's really a bad practice to not release a
framework for such a long period of time. I understand the version (like the
API is not stabilized, etc) but that's not right. What you can be sure of is
that if a framework is late in releasing versions then people are going to
use snapshot versions as if they were releases and they'll complain the same
if something changes, etc.

This leads me to the conclusion that the VFS project doesn't want any
serious users at this point in time. Otherwise you would have released a
version. You're only interested in people doing experiments. Thus as Cargo
has been released several times already I don't think it should use VFS.
Right now I've kept the usage of VFS for our unit tests (not production
code) and unfortunately this is going to prevent us from using it for our
production code till there's a first version (even a 0.1 version).

> Eventually, later, we will automatically set this snapshot to always the
> latest build.
>
> Which again might bring up some problems for you, as then the build can
> fail due to internal VFS changes, though, that happened not that often -
> not to say, it happened never before ;-)
>
> > Luckily I had not gone too far in using VFS and it can be
> > removed quite easily but that would be a real pity as I'm starting to
> like
> > it...
> >
> Don't jump the gun, I'll help you :-)
>
> Sorry for the inconvenience!

Thanks for your help Mario, real appreciated! Now I've come to the
conclusion that the only way to progress is to get a 0.1 VFS release out.
Just release whatever you have in SVN trunk and call it 0.1.

WDYT?

Thanks
-Vincent


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Chr. Grobmeier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

not sure, but why don't you put the desired snapshot in a local repository?
- - Chris

Vincent Massol wrote:

>
>> -----Original Message-----
>> From: Mario Ivankovits [mailto:[hidden email]]
>> Sent: jeudi 27 juillet 2006 09:01
>> To: Jakarta Commons Users List
>> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
>> m1 snapshot repo!
>>
>> Hi Vincent!
>>> Someone just told me that Cargo is not building anymore because the
>> 20060719
>>> snapshot is no longer there! I checked and it's not there...
>>>
>> Yes, the automated build process only keeps a week of builds.
>> As a quick fix I updated the -SNAPSHOT to point to the build from
>> 26-July-2006 (its a copy for now, so wont disappear)
>> Could you change your build to use the -SNAPSHOT?
>
> I'll try to do this but it's only marginally better than before. I don't
> want the cargo build to try every day to use a new snapshot if there's one.
> That would be good for a tool like Gump but I don't want Cargo to track the
> VFS snapshots. I want to decide what version I use and I want to control
> when I want to move to a new version. Otherwise it's simply going to be too
> much maintenance work.
>
> So what I really need is a version of VFS that is not going to go away (even
> a timestamped version is fine but don't delete it. Maybe simply put it in
> the Maven 1 Release Repository so that it doesn't get deleted. Call it
> 1.0-200607271124 for example.
>
> BTW on a related note I think the versioning scheme for VFS is not correct.
> I think it should have the target version number in the file name. Instead
> of "SNAPSHOT", it should be "1.0-SNAPSHOT". Imagine that you start working
> on a 2.0 branch for example.
>
> The best is of course for you to release a 0.1 version. VFS had been going
> on for what, a year? More? It's really a bad practice to not release a
> framework for such a long period of time. I understand the version (like the
> API is not stabilized, etc) but that's not right. What you can be sure of is
> that if a framework is late in releasing versions then people are going to
> use snapshot versions as if they were releases and they'll complain the same
> if something changes, etc.
>
> This leads me to the conclusion that the VFS project doesn't want any
> serious users at this point in time. Otherwise you would have released a
> version. You're only interested in people doing experiments. Thus as Cargo
> has been released several times already I don't think it should use VFS.
> Right now I've kept the usage of VFS for our unit tests (not production
> code) and unfortunately this is going to prevent us from using it for our
> production code till there's a first version (even a 0.1 version).
>
>> Eventually, later, we will automatically set this snapshot to always the
>> latest build.
>>
>> Which again might bring up some problems for you, as then the build can
>> fail due to internal VFS changes, though, that happened not that often -
>> not to say, it happened never before ;-)
>>
>>> Luckily I had not gone too far in using VFS and it can be
>>> removed quite easily but that would be a real pity as I'm starting to
>> like
>>> it...
>>>
>> Don't jump the gun, I'll help you :-)
>>
>> Sorry for the inconvenience!
>
> Thanks for your help Mario, real appreciated! Now I've come to the
> conclusion that the only way to progress is to get a 0.1 VFS release out.
> Just release whatever you have in SVN trunk and call it 0.1.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>
>
>
>
> ___________________________________________________________________________
> 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]
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEyIzBkv8rKBUE/T4RApIxAKCOZnBkh9bn/g/ih+PIxq4jRpnQ/ACcC4h0
3UpsESH/jD5J/b1k+nOsLrE=
=ZHQN
-----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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol
Hi Chris,

> -----Original Message-----
> From: C. Grobmeier [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 11:52
> To: Jakarta Commons Users List
> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> not sure, but why don't you put the desired snapshot in a local
> repository?

Because I want everyone to be able to build cargo... A build is supposed to
work out of the box. If cargo developers and users have to go through a step
of fishing for jars before they can build it then it's a no-go and BTW
defeats completely one primary purpose of Maven (dependency handling).

Thanks
-Vincent

> - - Chris
>
> Vincent Massol wrote:
> >
> >> -----Original Message-----
> >> From: Mario Ivankovits [mailto:[hidden email]]
> >> Sent: jeudi 27 juillet 2006 09:01
> >> To: Jakarta Commons Users List
> >> Subject: Re: [VFS] Snapshot timestamped version has disappeared from
> the
> >> m1 snapshot repo!
> >>
> >> Hi Vincent!
> >>> Someone just told me that Cargo is not building anymore because the
> >> 20060719
> >>> snapshot is no longer there! I checked and it's not there...
> >>>
> >> Yes, the automated build process only keeps a week of builds.
> >> As a quick fix I updated the -SNAPSHOT to point to the build from
> >> 26-July-2006 (its a copy for now, so wont disappear)
> >> Could you change your build to use the -SNAPSHOT?
> >
> > I'll try to do this but it's only marginally better than before. I don't
> > want the cargo build to try every day to use a new snapshot if there's
> one.
> > That would be good for a tool like Gump but I don't want Cargo to track
> the
> > VFS snapshots. I want to decide what version I use and I want to control
> > when I want to move to a new version. Otherwise it's simply going to be
> too
> > much maintenance work.
> >
> > So what I really need is a version of VFS that is not going to go away
> (even
> > a timestamped version is fine but don't delete it. Maybe simply put it
> in
> > the Maven 1 Release Repository so that it doesn't get deleted. Call it
> > 1.0-200607271124 for example.
> >
> > BTW on a related note I think the versioning scheme for VFS is not
> correct.
> > I think it should have the target version number in the file name.
> Instead
> > of "SNAPSHOT", it should be "1.0-SNAPSHOT". Imagine that you start
> working
> > on a 2.0 branch for example.
> >
> > The best is of course for you to release a 0.1 version. VFS had been
> going
> > on for what, a year? More? It's really a bad practice to not release a
> > framework for such a long period of time. I understand the version (like
> the
> > API is not stabilized, etc) but that's not right. What you can be sure
> of is
> > that if a framework is late in releasing versions then people are going
> to
> > use snapshot versions as if they were releases and they'll complain the
> same
> > if something changes, etc.
> >
> > This leads me to the conclusion that the VFS project doesn't want any
> > serious users at this point in time. Otherwise you would have released a
> > version. You're only interested in people doing experiments. Thus as
> Cargo
> > has been released several times already I don't think it should use VFS.
> > Right now I've kept the usage of VFS for our unit tests (not production
> > code) and unfortunately this is going to prevent us from using it for
> our
> > production code till there's a first version (even a 0.1 version).
> >
> >> Eventually, later, we will automatically set this snapshot to always
> the
> >> latest build.
> >>
> >> Which again might bring up some problems for you, as then the build can
> >> fail due to internal VFS changes, though, that happened not that often
> -
> >> not to say, it happened never before ;-)
> >>
> >>> Luckily I had not gone too far in using VFS and it can be
> >>> removed quite easily but that would be a real pity as I'm starting to
> >> like
> >>> it...
> >>>
> >> Don't jump the gun, I'll help you :-)
> >>
> >> Sorry for the inconvenience!
> >
> > Thanks for your help Mario, real appreciated! Now I've come to the
> > conclusion that the only way to progress is to get a 0.1 VFS release
> out.
> > Just release whatever you have in SVN trunk and call it 0.1.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
> >
> >
> >
> __________________________________________________________________________
> _
> > 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]
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEyIzBkv8rKBUE/T4RApIxAKCOZnBkh9bn/g/ih+PIxq4jRpnQ/ACcC4h0
> 3UpsESH/jD5J/b1k+nOsLrE=
> =ZHQN
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Mario Ivankovits
In reply to this post by vmassol
Hi Vincent!

If VFSs live would only be that easy ;-) .... but read on ...

> So what I really need is a version of VFS that is not going to go away (even
> a timestamped version is fine but don't delete it.
Ok, no problem, I'll copy the current snapshot to a different name.
Done: commons-vfs-20060726051400.jar is yours, as far as I know now it
wont match the nightly algo and so wont be deleted (at least with the
other snapshots its the case)


> The best is of course for you to release a 0.1 version. VFS had been going
> on for what, a year? More? It's really a bad practice to not release a
> framework for such a long period of time.
There are still a couple of problems:
* we depend on commons-compress which itself is a sandbox component and
therefore cant be released and therefore we cant release as its not
allow to release with a snapshot dependency
* 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.
* we depend on slide-client (webdav) where also no release is in sight

commons-compress is on the way to stabilize/rewrite the api, but this is
only done on a contributor base (no committer active now) and thus might
take some time. Though, we received the contributors CLA and Thorsten
would like to help to commit the stuff.
Afterwards its planned to promote compress and release it, though, its
questionable how the other developers in commons think about it, still,
there are not that much developers working on compress (as in VFS)

The jcifs problem is in discussion. During the ApacheCon EU this year I
was told about a way how to solve it within apache, its now on legal@ to
fell the last decision.

Well, and slide, I thought I'll fell a decision about it once the above
both points are fixed.

> This leads me to the conclusion that the VFS project doesn't want any
> serious users at this point in time.
Not true, the API is stable, in fact I wished I could release. One
solution a developer outlined was to import the commons-compress and
slide codebase into vfs and externalize the jcifs file provider. While
possible, I dont want to maintain this code in VFS. Especially slide is
too "heavy".


Still, really bad preconditions for a early release, unhappily :-(
Sorry!

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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Chr. Grobmeier
In reply to this post by vmassol
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> Because I want everyone to be able to build cargo... A build is supposed to
>> work out of the box. If cargo developers and users have to go through a step
>> of fishing for jars before they can build it then it's a no-go and BTW
>> defeats completely one primary purpose of Maven (dependency handling).

sorry, didn't know what cargo is. I understand your problem now
- - Chris

>
>> Thanks
>> -Vincent
>
> - Chris
>
> Vincent Massol wrote:
>>>>> -----Original Message-----
>>>>> From: Mario Ivankovits [mailto:[hidden email]]
>>>>> Sent: jeudi 27 juillet 2006 09:01
>>>>> To: Jakarta Commons Users List
>>>>> Subject: Re: [VFS] Snapshot timestamped version has disappeared from
> the
>>>>> m1 snapshot repo!
>>>>>
>>>>> Hi Vincent!
>>>>>> Someone just told me that Cargo is not building anymore because the
>>>>> 20060719
>>>>>> snapshot is no longer there! I checked and it's not there...
>>>>>>
>>>>> Yes, the automated build process only keeps a week of builds.
>>>>> As a quick fix I updated the -SNAPSHOT to point to the build from
>>>>> 26-July-2006 (its a copy for now, so wont disappear)
>>>>> Could you change your build to use the -SNAPSHOT?
>>>> I'll try to do this but it's only marginally better than before. I don't
>>>> want the cargo build to try every day to use a new snapshot if there's
> one.
>>>> That would be good for a tool like Gump but I don't want Cargo to track
> the
>>>> VFS snapshots. I want to decide what version I use and I want to control
>>>> when I want to move to a new version. Otherwise it's simply going to be
> too
>>>> much maintenance work.
>>>>
>>>> So what I really need is a version of VFS that is not going to go away
> (even
>>>> a timestamped version is fine but don't delete it. Maybe simply put it
> in
>>>> the Maven 1 Release Repository so that it doesn't get deleted. Call it
>>>> 1.0-200607271124 for example.
>>>>
>>>> BTW on a related note I think the versioning scheme for VFS is not
> correct.
>>>> I think it should have the target version number in the file name.
> Instead
>>>> of "SNAPSHOT", it should be "1.0-SNAPSHOT". Imagine that you start
> working
>>>> on a 2.0 branch for example.
>>>>
>>>> The best is of course for you to release a 0.1 version. VFS had been
> going
>>>> on for what, a year? More? It's really a bad practice to not release a
>>>> framework for such a long period of time. I understand the version (like
> the
>>>> API is not stabilized, etc) but that's not right. What you can be sure
> of is
>>>> that if a framework is late in releasing versions then people are going
> to
>>>> use snapshot versions as if they were releases and they'll complain the
> same
>>>> if something changes, etc.
>>>>
>>>> This leads me to the conclusion that the VFS project doesn't want any
>>>> serious users at this point in time. Otherwise you would have released a
>>>> version. You're only interested in people doing experiments. Thus as
> Cargo
>>>> has been released several times already I don't think it should use VFS.
>>>> Right now I've kept the usage of VFS for our unit tests (not production
>>>> code) and unfortunately this is going to prevent us from using it for
> our
>>>> production code till there's a first version (even a 0.1 version).
>>>>
>>>>> Eventually, later, we will automatically set this snapshot to always
> the
>>>>> latest build.
>>>>>
>>>>> Which again might bring up some problems for you, as then the build can
>>>>> fail due to internal VFS changes, though, that happened not that often
> -
>>>>> not to say, it happened never before ;-)
>>>>>
>>>>>> Luckily I had not gone too far in using VFS and it can be
>>>>>> removed quite easily but that would be a real pity as I'm starting to
>>>>> like
>>>>>> it...
>>>>>>
>>>>> Don't jump the gun, I'll help you :-)
>>>>>
>>>>> Sorry for the inconvenience!
>>>> Thanks for your help Mario, real appreciated! Now I've come to the
>>>> conclusion that the only way to progress is to get a 0.1 VFS release
> out.
>>>> Just release whatever you have in SVN trunk and call it 0.1.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEyI41kv8rKBUE/T4RAhnlAJ9rX3uAvFn6J7OfaJAj6Dh0BwCYigCbByEz
8bASzesRx3X9dBPddRF/Urs=
=tPRn
-----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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol
In reply to this post by Mario Ivankovits


> -----Original Message-----
> From: Mario Ivankovits [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 11:52
> To: Jakarta Commons Users List
> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> Hi Vincent!
>
> If VFSs live would only be that easy ;-) .... but read on ...
>
> > So what I really need is a version of VFS that is not going to go away
> (even
> > a timestamped version is fine but don't delete it.
> Ok, no problem, I'll copy the current snapshot to a different name.
> Done: commons-vfs-20060726051400.jar is yours, as far as I know now it
> wont match the nightly algo and so wont be deleted (at least with the
> other snapshots its the case)

Ok thanks!
 

> > The best is of course for you to release a 0.1 version. VFS had been
> going
> > on for what, a year? More? It's really a bad practice to not release a
> > framework for such a long period of time.
> There are still a couple of problems:
> * we depend on commons-compress which itself is a sandbox component and
> therefore cant be released and therefore we cant release as its not
> allow to release with a snapshot dependency
> * 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.
> * we depend on slide-client (webdav) where also no release is in sight
>
> commons-compress is on the way to stabilize/rewrite the api, but this is
> only done on a contributor base (no committer active now) and thus might
> take some time. Though, we received the contributors CLA and Thorsten
> would like to help to commit the stuff.
> Afterwards its planned to promote compress and release it, though, its
> questionable how the other developers in commons think about it, still,
> there are not that much developers working on compress (as in VFS)
>
> The jcifs problem is in discussion. During the ApacheCon EU this year I
> was told about a way how to solve it within apache, its now on legal@ to
> fell the last decision.
>
> Well, and slide, I thought I'll fell a decision about it once the above
> both points are fixed.

I think you have 2 solutions here:

1) Do a release of those projects. You're using them in VFS which means
they're working to some level and having a first release would be good.
Basically do to them what I'm asking you for VFS :-). That will allow you to
release a first version of VFS.

2) Separate VFS core from the different filesystem implementations:
- vfs-core.jar
- vfs-fs-ram.jar, etc

Release VFS core and all the filesystems that can be released.

Personally I only use the core and the ram and local filesystems so that
would fit my need too.

I think solution 1) is the best and probably the easiest to do quickly.
 
> > This leads me to the conclusion that the VFS project doesn't want any
> > serious users at this point in time.
> Not true, the API is stable, in fact I wished I could release. One
> solution a developer outlined was to import the commons-compress and
> slide codebase into vfs and externalize the jcifs file provider. While
> possible, I dont want to maintain this code in VFS. Especially slide is
> too "heavy".

You could also do it using jarjar. In this manner you won't have to maintain
anything. The downside (which is why I wouldn't recommend it) is that users
will not be able to use a newer version of those dependencies if they want
so and they need to wait for a vfs release.

I think solutions 1 and 2 above should work fine, no?
 
> Still, really bad preconditions for a early release, unhappily :-(
> Sorry!

You shouldn't let your project be stopped from releasing simply because one
of your dependency is not releasing! Let me know if solutions 1 or 2 are
acceptable.

Thanks
-Vincent


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Mario Ivankovits
Hi Vincent!
> 1) Do a release of those projects.
Commons-compress is on the way.
Slide is simply not my project, I am neither a committer nor a
contributor, so I cant decide to release it.
What I'll do once compress is there and the lgpl stuff has solved, is,
to have a oversight about the activity of this project then, and then
move the parts depending on inactive projects into its own jar as you
outline below.

> 2) Separate VFS core from the different filesystem implementations:
> - vfs-core.jar
> - vfs-fs-ram.jar, etc
>  
I dont think that the users want have such fine grained bundles, I
perfectly understand that it fits your needs, but having to put e.g. 10
vfs jars to get what you have now might become a pain.
This decision is not put in stone, if other users come up telling me
that they would appreciate it, I can go to the dev list and discuss this
further.

Though, an additional question come in my mind with such a solution:
I have to release each "artifact" on its own to make the scenario work,
not only that the releases then start to divergence, do I have to start
a vote for each of them then?
The other developer have to check releases during the vote, this means a
great multiplication of work.
Whew .... I already hear what they will tell me ;-)

Hmmm .... but having
- vfs.jar
- vfs-extensions.jar - where in extensions (or what name ever) all the
code is which is not releasable ... well ... this can be done.

I'll move to commons-dev with this - Follow me :-)

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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol
In reply to this post by vmassol
Mario,

 

> -----Original Message-----

> From: Mario Ivankovits [mailto:[hidden email]]

> Sent: jeudi 27 juillet 2006 12:36

> To: Jakarta Commons Users List

> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the

> m1 snapshot repo!

>

> Hi Vincent!

> > 1) Do a release of those projects.

> Commons-compress is on the way.

> Slide is simply not my project, I am neither a committer nor a

> contributor, so I cant decide to release it.

 

No but you could ask them to do a timestamped version.

 

> What I'll do once compress is there and the lgpl stuff has solved, is,

> to have a oversight about the activity of this project then, and then

> move the parts depending on inactive projects into its own jar as you

> outline below.

 

ok

 

> > 2) Separate VFS core from the different filesystem implementations:

> > - vfs-core.jar

> > - vfs-fs-ram.jar, etc

> >

> I dont think that the users want have such fine grained bundles, I

> perfectly understand that it fits your needs, but having to put e.g. 10

> vfs jars to get what you have now might become a pain.

 

It really depends. You have different types of users. Some will only want 2
or 3 filesystem providers and they may not like that to have to download the
other 30 providers.

 

BTW this is really the Maven philosophy and each filesystem would make a
perfect demarcation for being a Maven build module. You could still decide
to release them all at once or separately. In Cargo we release the different
container implementations together for now but we also make them available
as both a single jar and as individual jars.

 

This is what we do in Cargo, this is what is done in Maven itself and in all
projects using Maven that have provider (SPI) architectures.

 

There are several advantages of this, the biggest one being that you can
ensure a clean (and enforced!) separation of concerns between the different
part of your code.

 

> This decision is not put in stone, if other users come up telling me

> that they would appreciate it, I can go to the dev list and discuss this

> further.

 

You should have a look at cargo for an example of what this means and how it
could be done. We really like this structure and it has helped us a lot.
When we made that move we discovered several issues in our code that were
not apparent before.

 

> Though, an additional question come in my mind with such a solution:

> I have to release each "artifact" on its own to make the scenario work,

> not only that the releases then start to divergence, do I have to start

> a vote for each of them then?

 

We haven't gone so far as doing separate releases in Cargo but that's
something I want to do ASAP. The main reason is that having the same
lifecycle for the different providers doesn't scale. Imagine that you make
change to one provider (like a bug fix). You'll have to wait till all the
other providers are ready before being able to do a release. Why have users
suffer from your build structure? If you separate them you'll have a more
fluid delivery cycle. BTW this is what is done in Maven itself (there's a
core and there are plugins which are released each using its own delivery
cycle).

 

> The other developer have to check releases during the vote, this means a

> great multiplication of work.

 

No, quite the opposite. Working with thinner slices is always easier than
working with bulk. Saying it differently, it's much easier to do regular
releases than longer ones because less has changed. Take the example of
Maven again. Releasing a plugin is really a breeze, including the votes. The
same would be true of VFS. The core might require lots of thoughts as it's
critical but the providers would be real easy to release.

 

> Whew .... I already hear what they will tell me ;-)

>

> Hmmm .... but having

> - vfs.jar

> - vfs-extensions.jar - where in extensions (or what name ever) all the

> code is which is not releasable ... well ... this can be done.

>

> I'll move to commons-dev with this - Follow me :-)

 

I'm not prepared to sustain that level of emails (I already have too much)
so I'll be following sporadically from nabble.

 

Thanks

-Vincent

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Mario Ivankovits
Hi Vincent!

> No but you could ask them to do a timestamped version.
>  
Not sure if this fits the needs in commons to allow a release.

>> e.g. 10 vfs jars to get what you have now might become a pain.
>>    
> It really depends. You have different types of users. Some will only want 2
> or 3 filesystem providers and they may not like that to have to download the
> other 30 providers.
>  
I understand.
I also see its mavens philosophy, and AFAIK OSGi.
You also say, in cargo you provide a single jar and individual jars.
Unhappily, this wont work in VFS if we cant release one of the
individual jars due to the outlined problems.

I perfectly understand that VFSs filesystem implementations fits
perfectly in such a scheme, to say the truth, for now I think its just
way too much work for me. Not to separate the code, this might not be
that hard, but to maintain them and its different releases.

Once VFSs again has a significant number of developers we can go that way.

Having the two-jar solution is a good compromise for now, no?
Lets see what the other devs think about it.

> I'm not prepared to sustain that level of emails (I already have too much)
> so I'll be following sporadically from nabble.
>  
No problem, I'll keep you informed.


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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol


> -----Original Message-----
> From: Mario Ivankovits [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 13:05
> To: Jakarta Commons Users List
> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> Hi Vincent!
>
> > No but you could ask them to do a timestamped version.
> >
> Not sure if this fits the needs in commons to allow a release.
>
> >> e.g. 10 vfs jars to get what you have now might become a pain.
> >>
> > It really depends. You have different types of users. Some will only
> want 2
> > or 3 filesystem providers and they may not like that to have to download
> the
> > other 30 providers.
> >
> I understand.
> I also see its mavens philosophy, and AFAIK OSGi.
> You also say, in cargo you provide a single jar and individual jars.
> Unhappily, this wont work in VFS if we cant release one of the
> individual jars due to the outlined problems.
>
> I perfectly understand that VFSs filesystem implementations fits
> perfectly in such a scheme, to say the truth, for now I think its just
> way too much work for me. Not to separate the code, this might not be
> that hard, but to maintain them and its different releases.

I understand. I was just debating the possibility.
 
> Once VFSs again has a significant number of developers we can go that way.

True and to have that number of developers you need to do a first release to
get the attention...
 
> Having the two-jar solution is a good compromise for now, no?

Sure. Sounds good to me.

> Lets see what the other devs think about it.
>
> > I'm not prepared to sustain that level of emails (I already have too
> much)
> > so I'll be following sporadically from nabble.
> >
> No problem, I'll keep you informed.

I'll check periodically.

Thanks
-Vincent


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Jörg Schaible-2
In reply to this post by vmassol
Vincent Massol wrote on Thursday, July 27, 2006 11:51 AM:

> Hi Chris,
>
>> -----Original Message-----
>> From: C. Grobmeier [mailto:[hidden email]]
>> Sent: jeudi 27 juillet 2006 11:52
>> To: Jakarta Commons Users List
>> Subject: Re: [VFS] Snapshot timestamped version has disappeared from
>> the m1 snapshot repo!
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> not sure, but why don't you put the desired snapshot in a local
>> repository?
>
> Because I want everyone to be able to build cargo... A build
> is supposed to
> work out of the box. If cargo developers and users have to go
> through a step
> of fishing for jars before they can build it then it's a no-go and BTW
> defeats completely one primary purpose of Maven (dependency handling).

Why not use an own cargo:commons-vfs:version of a nightly snapshot of your choice? You might even tailor it down to the functionality you need. Other projects have done so, too (Axis, FOP, Batik, Ant, ...). While we all agree, that this is not the best approach, in case of Cargo this might be the perfect option. Despite the other mensioned projects Cargo is more a product and should normally not introduce version clashes for clients. As long as there is no official release from vfs, it would be my way to go.

- 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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Jörg Schaible-2
In reply to this post by vmassol
Vincent Massol wrote on Thursday, July 27, 2006 12:51 PM:

>> -----Original Message-----
>
>> From: Mario Ivankovits
>> Sent: jeudi 27 juillet 2006 12:36
>> To: Jakarta Commons Users List
>> Subject: Re: [VFS] Snapshot timestamped version has disappeared from
>> the m1 snapshot repo!

[snip]

>> I dont think that the users want have such fine grained bundles, I
>> perfectly understand that it fits your needs, but having to put e.g.
>> 10
>> vfs jars to get what you have now might become a pain.
>
> It really depends. You have different types of users. Some
> will only want 2
> or 3 filesystem providers and they may not like that to have
> to download the
> other 30 providers.

Well, Carlos proposed once in case of Spring the usage of different POMs. And there's no reason, why the dependencies of the different filesystems are not marked as optional.

[snip]

- 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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol


> -----Original Message-----
> From: Jörg Schaible [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 13:55
> To: Jakarta Commons Users List
> Subject: RE: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> Vincent Massol wrote on Thursday, July 27, 2006 12:51 PM:
>
> >> -----Original Message-----
> >
> >> From: Mario Ivankovits
> >> Sent: jeudi 27 juillet 2006 12:36
> >> To: Jakarta Commons Users List
> >> Subject: Re: [VFS] Snapshot timestamped version has disappeared from
> >> the m1 snapshot repo!
>
> [snip]
>
> >> I dont think that the users want have such fine grained bundles, I
> >> perfectly understand that it fits your needs, but having to put e.g.
> >> 10
> >> vfs jars to get what you have now might become a pain.
> >
> > It really depends. You have different types of users. Some
> > will only want 2
> > or 3 filesystem providers and they may not like that to have
> > to download the
> > other 30 providers.
>
> Well, Carlos proposed once in case of Spring the usage of different POMs.
> And there's no reason, why the dependencies of the different filesystems
> are not marked as optional.

I know... check the m2 pom that I have submitted :-)

http://issues.apache.org/jira/browse/VFS-70

Thanks
-Vincent


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol
In reply to this post by Jörg Schaible-2


> -----Original Message-----
> From: Jörg Schaible [mailto:[hidden email]]
> Sent: jeudi 27 juillet 2006 13:51
> To: Jakarta Commons Users List; [hidden email]
> Subject: RE: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> Vincent Massol wrote on Thursday, July 27, 2006 11:51 AM:
>
> > Hi Chris,
> >
> >> -----Original Message-----
> >> From: C. Grobmeier [mailto:[hidden email]]
> >> Sent: jeudi 27 juillet 2006 11:52
> >> To: Jakarta Commons Users List
> >> Subject: Re: [VFS] Snapshot timestamped version has disappeared from
> >> the m1 snapshot repo!
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> not sure, but why don't you put the desired snapshot in a local
> >> repository?
> >
> > Because I want everyone to be able to build cargo... A build
> > is supposed to
> > work out of the box. If cargo developers and users have to go
> > through a step
> > of fishing for jars before they can build it then it's a no-go and BTW
> > defeats completely one primary purpose of Maven (dependency handling).
>
> Why not use an own cargo:commons-vfs:version of a nightly snapshot of your
> choice? You might even tailor it down to the functionality you need. Other
> projects have done so, too (Axis, FOP, Batik, Ant, ...). While we all
> agree, that this is not the best approach, in case of Cargo this might be
> the perfect option. Despite the other mensioned projects Cargo is more a
> product and should normally not introduce version clashes for clients. As
> long as there is no official release from vfs, it would be my way to go.

Yes that's a possibility. As you say this I not a recommended practice as it
doesn't improve the overall ecosystem. I'll do this as a last resort if we
don’t find a better way to solve it.

BTW Cargo is first and foremost a framework (a Java API). It has some
extensions like the m2 plugin, etc that transforms it into an "application"
but it's meant to be a framework above all.

Thanks Jörg
-Vincent


       

       
               
___________________________________________________________________________
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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Jörg Schaible-2
In reply to this post by vmassol
Hi Vincent,

Vincent Massol wrote on Thursday, July 27, 2006 2:26 PM:

>> -----Original Message-----
>> From: Jörg Schaible
>> Sent: jeudi 27 juillet 2006 13:51
>> Subject: RE: [VFS] Snapshot timestamped version has disappeared from
>> the m1 snapshot repo!

[snip]

>> Why not use an own cargo:commons-vfs:version of a nightly snapshot
>> of your choice? You might even tailor it down to the functionality
>> you need. Other projects have done so, too (Axis, FOP, Batik, Ant,
>> ...). While we all agree, that this is not the best approach, in
>> case of Cargo this might be the perfect option. Despite the other
>> mensioned projects Cargo is more a product and should normally not
>> introduce version clashes for clients. As long as there is no
>> official release from vfs, it would be my way to go.
>
> Yes that's a possibility. As you say this I not a recommended
> practice as it doesn't improve the overall ecosystem. I'll do this as
> a last
> resort if we
> don't find a better way to solve it.
>
> BTW Cargo is first and foremost a framework (a Java API). It has some
> extensions like the m2 plugin, etc that transforms it into an
> "application" but it's meant to be a framework above all.

Thanks for enlightening me more about Cargo. Yeah, in this case I would also try not to use a private version - at least not without changing the package names.

- 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] Snapshot timestamped version has disappeared from the m1 snapshot repo!

Stephen Colebourne
In reply to this post by vmassol
Vincent Massol wrote:
> No, quite the opposite. Working with thinner slices is always easier than
> working with bulk. Saying it differently, it's much easier to do regular
> releases than longer ones because less has changed. Take the example of
> Maven again. Releasing a plugin is really a breeze, including the votes. The
> same would be true of VFS. The core might require lots of thoughts as it's
> critical but the providers would be real easy to release.

This whole debate is a matter of perspective - cargo and vfs have very
different perspectives on two points:
- community
- ease of release

Cargo, and hence maven, comes to the table with a decent-sized community
and the full knowledge and use of maven. Together these two points
probably do make releasing a plugin 'a breeze'.

However vfs is effectively a single person project (at present), and
does not heavily use maven. (Commons does use maven, but does not have
the background knowledge, desire, etc to commit fully to it, in
particular maven version 2). Together, these points make it virtually
inconceivable to release lots of small jars, one per filesystem.

To further complicate this, commons rules currently effectively require
every release to be manually checked by every voter. Or to put it
another way, there is no trust of the releasable artifacts, maven
generated or not. (In fact, I typically raise more issues with a maven
generated release than a non maven generated release.)


My point here is that IMHO the 'correct' solution is a single core jar,
plus one jar per filsystem, together with an 'all' jar for users who
want everything in one go. But such a solution is unfortunately not
viable in the commons of today. Which is one reason why commons does not
release early release often.

Stephen

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

Reply | Threaded
Open this post in threaded view
|

RE: [VFS] Snapshot timestamped version has disappeared from the m1 snapshot repo!

vmassol
Hi Stephen,

> -----Original Message-----
> From: Stephen Colebourne [mailto:[hidden email]]
> Sent: vendredi 28 juillet 2006 01:07
> To: Jakarta Commons Users List
> Subject: Re: [VFS] Snapshot timestamped version has disappeared from the
> m1 snapshot repo!
>
> Vincent Massol wrote:
> > No, quite the opposite. Working with thinner slices is always easier
> than
> > working with bulk. Saying it differently, it's much easier to do regular
> > releases than longer ones because less has changed. Take the example of
> > Maven again. Releasing a plugin is really a breeze, including the votes.
> The
> > same would be true of VFS. The core might require lots of thoughts as
> it's
> > critical but the providers would be real easy to release.
>
> This whole debate is a matter of perspective - cargo and vfs have very
> different perspectives on two points:
> - community
> - ease of release
>
> Cargo, and hence maven, comes to the table with a decent-sized community
> and the full knowledge and use of maven. Together these two points
> probably do make releasing a plugin 'a breeze'.

That's true for Maven but certainly not for Cargo. I wish Cargo had a good
size developer's community but that's completely there yet... But you're
right, Cargo doesn't release containers individually but this is something
I'd like us to do because right now it's just too bad for end users who have
to wait for long release cycles before getting new features implemented for
their favorite container.

> However vfs is effectively a single person project (at present), and
> does not heavily use maven. (Commons does use maven, but does not have
> the background knowledge, desire, etc to commit fully to it, in
> particular maven version 2). Together, these points make it virtually
> inconceivable to release lots of small jars, one per filesystem.

I agree. It's only because we have Maven and especially Maven2 that we can
easily perform releases.
 
> To further complicate this, commons rules currently effectively require
> every release to be manually checked by every voter. Or to put it
> another way, there is no trust of the releasable artifacts, maven
> generated or not. (In fact, I typically raise more issues with a maven
> generated release than a non maven generated release.)

I'm a commons committer. So do you mean that I'm expected to vote on every
single component, even those that I have never heard of, never used and
never participated to? That would be pretty useless... Isn't the rule that
you need at least 3 +1 and no -1? Is it really that hard to release a
commons component? If so maybe there's something to fix there. I haven't
participated in commons for a few years now so I'm a bit away from out it
works these days.
 
> My point here is that IMHO the 'correct' solution is a single core jar,
> plus one jar per filsystem, together with an 'all' jar for users who
> want everything in one go. But such a solution is unfortunately not
> viable in the commons of today. Which is one reason why commons does not
> release early release often.

In any case there's no point in arguing about this I believe as it's up to
Mario to decide what he wants to do. I don't like when people tell me what
to do on my project so I won't tell Mario or VFS what to do. I'm just
highlighting options :-)

However, more generally speaking, I have the feeling that the reason for not
releasing more often in commons is more a state of mind. It seems it has
become the rule and that it's ok for components to remain unreleased for
long period of time. I don't think it's doing any good for commons and VFS.

Back to VFS, it has never had any release for years. There are probably lots
of reasons but from what I hear from Mario, the main reason is that this
project is too monolithic and has only one jar. As a consequence there are
VFS providers lagging behind, either in term of implementation of in term of
their dependencies being themselves released... But Mario has make a good
decision: split vfs in 2 jars: a main one and a sandbox one. So that's a
step in the right direction.

Thanks
-Vincent


       

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