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