> On Sep 21, 2018, at 11:26 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Fri, Sep 21, 2018 at 7:05 AM Gilles <gil...@harfang.homelinux.org > <mailto:gil...@harfang.homelinux.org>> wrote: > >> On Fri, 21 Sep 2018 08:52:37 -0400, Rob Tompkins wrote: >>>> On Sep 20, 2018, at 9:31 AM, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>> >>>> On Thu, 20 Sep 2018 08:53:38 -0400, Rob Tompkins wrote: >>>>>> On Sep 20, 2018, at 3:10 AM, Benedikt Ritter <brit...@apache.org> >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Reverting this change was discussed here [1]. It was a result of >>>>>> this >>>>>> commit [2] breaking multiple component builds. As Stefan points >>>>>> out the >>>>>> initial change does not make sense, since the componentId is >>>>>> always just >>>>>> the name without "commons-" (e.g. math4). But the folders for all >>>>>> the >>>>>> websites have the commons prefix (e.g. commons-math). >>>>>> >>>>>> I just restored the old (working) behavior. I'm fine with making >>>>>> things >>>>>> easier/more straight forward. But let's make sure that all the >>>>>> other >>>>>> components still work. >>>>> >>>>> I’m relatively indifferent to how we accomplish this. For the sake >>>>> of >>>>> discussion let our project.artifactId=commons-something where N >>>>> represents the major version of the release with N being the empty >>>>> string for a major version equal to 1. We still are stuck with half >>>>> of >>>>> our projects in one state for building with componentid=something >>>>> and >>>>> the other half with componentid=somethingN. Furthermore we need a >>>>> properties representing both “something” as well as “somethingN” >>>>> given >>>>> that we have our dist urls and site urls not containing the major >>>>> release version. >>>>> >>>>> Do you propose something other than: >>>>> >>>>> <commons.componentid>something</commons.componentid> >>>>> <commons.packageId>somethingN</commons.pachageId> >>>>> >>>>> and change [parent] back to >>>>> >>>>> <commons.scmPubUrl> >>>>> >>>>> >>>>> >> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${commons.componentid} >>>>> </commons.scmPubUrl> >>>>> ???? >>>> >>>> What about starting from maven requirements and try and avoid >>>> redundancies (that ultimately lead to inconsistencies)? >>>> >>>> Given are >>>> <artefactId> >>>> <version> >>> >>> I’m actually indifferent to how we approach this. >> >> Discussion should be on what is >> 1. desirable >> 2. achievable >> >> And, if you are willing to continue your work on this, it is >> IMO desirable to take this opportunity to actually reduce the >> level of redundancy found in the projects' POMs, with all their >> slight variations that keep things more complicated than they >> could be. >> >>> I’m more just >>> motivated to pick a direction and get it behind us. >> >> Do you know whether it is possible to go in the direction >> which I propose? >> > > The original problem this solved is that components that did use a version > number in their artifact ID has to do to much redefining in their POMs. > > We are now entering bike-shedding territory IMO. As Sebb (IIRC) pointed out > elsewhere, a component does not have to update to a new CP version. If it > does, obviously, it has to adapt. I sincerely believe that we are all > trying to make Commons better. There is no compatibility guarantees for our > internal components but of course we do not want to create headaches if we > do not have to. We MUST make the distinction between an artifactId and > OtherID (pick names, today, packageId and componentId) which does not > include the major version number. That's what the current CP does and works > for some components that have been released. CP also reduces the amount of > properties you have to redefine in components, like the various URLs. My > POV here is that we can make adjustments to CP but there is no need for > some higher level discussion about "desirable" and "achievable". The goal > has been achieved IMO, using packageId and componentId, you can write POMs > that work for components that either have a version number or not in their > artifact IDs.
I’ll try to over the next few days sort this out across all the projects consuming cp 47 so that we don’t see this problem again. -Rob > > Gary > > >> Gilles >> >>> @Benedikt - you >>> have any thoughts on how we keep records of both “lang” as well as >>> “lang3” in the parent for the sake of our surrounding ecosystem?? >>> >>> -Rob >>> >>>> >>>> Can the parent POM generate the properties values required by >>>> the "Commons" infrastructure from those (using maven plugin >>>> code, I guess)? >>>> >>>> E.g. generate "commons-lang" (a.o. to generate the path to the >>>> web site's SVN repository) from >>>> <artifactId>commons-lang3</artifactId> >>>> <version>3.9-SNAPSHOT</version> >>>> >>>> [Side-effect would be to enforce the rule for changing top-level >>>> package name in step with a new major version.] >>>> >>>> Best regards, >>>> Gilles >>>> >>>>> >>>>> If so, what is it? Let’s pick it and move forward. >>>>> >>>>> Cheers, >>>>> -Rob >>>>> >>>>> [Ref] >>>>> June conversation on the matter as well. >>>>> https://markmail.org/message/7xbk3zm6pornsrto >>>>> <https://markmail.org/message/7xbk3zm6pornsrto> >>>>> >>>>>> >>>>>> [...] >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org
