On Sun, Mar 7, 2010 at 9:53 PM, Luc Maisonobe <luc.maison...@free.fr> wrote: > Phil Steitz a écrit : >> Niall Pemberton wrote: >>> On Sun, Mar 7, 2010 at 5:28 PM, Dennis Lundberg <denn...@apache.org> wrote: >>>> On 2010-03-07 16:45, Niall Pemberton wrote: >>>>> On Sun, Mar 7, 2010 at 3:28 PM, Dennis Lundberg <denn...@apache.org> >>>>> wrote: >>>>>> On 2010-03-07 12:41, Niall Pemberton wrote: >>>>>>> On Sat, Mar 6, 2010 at 12:15 AM, sebb <seb...@gmail.com> wrote: >>>>>>>> The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the >>>>>>>> next release should be 2.0 rather 1.5, as IO now requires Java 1.5, >>>>>>>> that requires a major version change. >>>>>>> The plan was to release it as 2.0 - but IMO its not a requirement. >>>>>>> >>>>>>> >>>>>>>> Does that make sense? >>>>>>>> If so, then the maven id can also be fixed (see IO-125). >>>>>>> -1 - see comments on JIRA ticket >>>>>> We need to make this switch sooner rather than later. Currently every >>>>>> release with a groupId och commons-* requires manual work from the >>>>>> people who manage Maven central repository. We're just about the only >>>>>> Apache project left not using a groupId of org.apache.*. >>>>> I thought it was only when we did the first m2 release for a component >>>>> and not for subsequent m2 releases for the group. Is that not the >>>>> case? >>>> It used to be that way, but it has changed. The repo maintainers want to >>>> remove all manual stuff, including anything from Apache that is not >>>> under groupId org.apache.*. We (the ASF) don't want anything pushed to >>>> the central repository that is from under groupId other than org.apache.*. >>>> >>>> It is only a matter of time before our current way (groupid commons-*) >>>> will be shut down completely. If people have opinions about this I >>>> suggest that you take them to reposit...@a.o for discussion. >>> OK >> >> I think we need to have that discussion. We (Commons) are happy to >> contribute to and subsequently follow ASF policy on how we publish >> maven artifacts. Unless I missed it on repository@, though, we have >> not as ASF agreed on a policy to retire the "legacy" groupIds. We >> also seem to be lacking consensus / clarity on how exactly we can >> accomplish "relocation" without potentially serious implications for >> the users of heavily-depended-on components. > > Does retiring legacy groupIds imply removing them from repository ? I > don't think so, but would like to be sure. One of the important features > in maven is to be able to reproduce builds long after the release. In my > field, we sometimes need to maintain software for a very long time > (think more than 20 years). Of course in our case we also use our own > repositories, but I think other people may need a few years later to > rebuild something despite they did not backup anything. > >> >> Therefore here in commons, I think we have agreed that we will move >> to org.apache.commons groupId when we make incompatible changes in a >> new release. That *must* coincide with a major release and it *may* >> coincide with a change in package name. It is possible, as in the >> present case with [io], that a major release will not introduce >> incompatible API changes, in which case we will not change the >> groupId. I see us cutting patch releases using "legacy" IDs for some >> time to come. > > I would prefer to adopt the new groupIds as fast as possible, perhaps at > major releases even if they don't break API, but this is not a strong > statement from me.
This may be the end what we decide eventually but you understand that this is going cause users pain when they get two copies of a component in their classpath and they waste hours trying to work out why their app no longer works. With redirects the answer will be simple - to remove older versions from their local repository - but it is going to cause pain. Niall > Luc > >> >> Please commons ppl respond if you disagree with the statements >> above. Assuming we are in agreement, we can continue the discussion >> on repository@ >> >> Phil >> >> >>>>>> We have previously said that we should make the switch to a groupId of >>>>>> org.apache.commons when we do a major release. IMO we need to stick by >>>>>> that decision. >>>>> I don't remember that decision, do you have a link to the thread? Even >>>>> if we did - this is going to cause problems for users who change their >>>>> dependency to the latest - but also depend on other artifacts that >>>>> have an older dependency on commons-io. Is this user pain worth it? >>>> I found this thread, which touches the issue: >>>> >>>> http://markmail.org/message/l3oezqvhehscm67l >>>> >>>> For such a change to be totally transparent we cannot rely on the >>>> relocation feature of Maven, which has been discussed before. We would >>>> have to change the package name, which I think was done in lang, from >>>> org.apache.commons.io to org.apache.commons.io2. >>> I'm sorry but having the build-tool/repository force a package rename is >>> nuts. >>> >>> Niall >>> >>>>> Niall >>>>> >>>>>>> Niall --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
