On 8/19/06, Oliver Heger <[EMAIL PROTECTED]> wrote:
Tomasz Pik wrote: > On 8/16/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >> > Yes, but instead of transiting something, that depends on other commons >> > IMHO something without dependencies should be transited first. >> > In other words, first thing to be done should be a graph of >> dependencies >> > between various commons packages and those without dependencies >> > should be migrated first. I guess commons-lang is a good candidate >> here, >> > not configuration that depdends on many other (not migrated yet) >> > components. >> >> What would we gain from this? A transition of component A will not >> include updating existing commons-dependencies in component A to the new >> ones with the new groupId. That will require a new release of that >> component A. If fact we don't even have to wait for a release of a >> component to do this. >> >> There is a good reason for *not* picking commons-lang or >> commons-logging, two components without dependencies on other commons >> components, as the first component to transition. That is that both are >> on ibiblio's top 10 downloads list. I had link to it before but can't >> seem to find it now, sorry. If we do it wrong there then all hell will >> break loose. It'd be better to choose a "medium used" component. > > But this means, that all of those users, that downloading those top10 > jars in near future will have obosolete jars. > Maven is not re-downloading nonSNAPSHOT artifacts so... > Let's imagine I'm a new maven user having project with a dependency on > commons-lang:commons-lang-2.1 and maven will download it for me. > Some time later this package will be relocated to > org.apache.commons.lang:commons-lang:2.1 (or similar). > After that there'll be new, let's say acegi v1.4 depending on this 'new' > commons-lang (org.apache....:commons-lang:2.1) and I need this acegi > in my project. > So after adding dependency on acegi maven will download > org.apache.commons.lang:commons-lang:2.1 and won't download > commons-lang:commons-lang:2.1 (which should result as relocation > info) and finally, maven will be adding those two commons-lang jars > into classpath, copy into WEB-INF/lib and so on. > All of this till the time I'll manually remove > commons-lang:commons-lang:2.1 > from my repository so maven will be forced to reload them (and will > download relocation info then). > So finally I think that sooner those jars will be relocated there'll be > less > users having problems like this. > > Regards, > Tomek > > -- >> Dennis Lundberg > There are good reasons in this thread from both sides. Being no maven expert I cannot judge which ones are better. But as long as this point is open I don't want to cut the next release candidate for [configuration]. So can we come to a consensus?
FWIW, I am planning to provide both .asc and .sha1 signing keys on the upcoming Shale release I'm working on. The .md5 files aren't really a signature ... they're just a checksum useful in determining whether the download has been corrupted or not (it is based solely on the content, not on any private key of the signer). Oliver Craig ---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
