Mario,
> -----Original Message----- > From: Mario Ivankovits [mailto:[EMAIL PROTECTED] > 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
