[ovirt-devel] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "devel" <devel at ovirt.org>, "Oved Ourfali" <oourfali at redhat.com>, "Juan Hernández" <jhernand at redhat.com>
> Sent: Monday, January 9, 2017 9:46:18 PM
> Subject: Re: PatternFly upgrade - how to handle JS dependencies
> 
> On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs <vszocs at redhat.com> wrote:
> 
> > Hello,
> >
> > we'd like to upgrade the version of PatternFly (plus associated libraries,
> > namely Bootstrap and jQuery) used in oVirt UI.
> >
> > Today, PatternFly stuff (PF + associated libraries) comes from
> > `patternfly1`
> > package hosted at Copr repo:
> >
> >   https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/
> >
> > Today, we require `patternfly1` as both Engine RPM build dependency and the
> > Engine devel. env. dependency.
> >
> > To keep things simple, I'd like to propose the following approach:
> >
> > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,
> >   containing PatternFly + associated libraries (Bootstrap, jQuery) which
> >   are intended *specifically* for use by oVirt UI (hence the ovirt prefix)
> >
> 
> I've already done this, although it's currently named 'patternfly3'
> https://copr.fedorainfracloud.org/coprs/patternfly/patternfly3/

I really think we should put some `ovirt` prefix there, to avoid
people thinking that it's some kind of general-purpose PatternFly
package.

For example, `ovirt-engine-ui-dependencies` (for Engine GWT UI).

> 
> However, we want to move it to our ovirt infra because copr sometimes goes
> down, and that breaks CI jobs.

If we really want to do that, maybe we should add a new project
into releng-tools repo. The project would be at

  releng-tools/specs/ovirt-engine-ui-dependencies

containing package.json and build script that downloads JS dep's
and then packages all JS stuff as RPM.

(Basically a very similar build process as with nodejs-modules.)

> 
> So, +1 from me, but let's move to ovirt infra.
> 
> 
> >
> > - discontinue maintenance of `patternfly1` package at Copr
> >
> > - keep the existing approach: require `ovirt-patternfly` as both the Engine
> >   build dependency and the Engine devel. env. dependency
> >
> > An alternative approach would be to introduce Node.js as Engine devel. env.
> > dependency (use `npm install` to pull PF stuff), while using the existing
> > ovirt-engine-{nodejs,nodejs-modules} packages for Engine RPM build.
> >
> > However, this alternative has some downsides, namely complication of devel.
> > env. just to fetch the PF stuff. I don't like the idea of complicating the
> > existing devel. env. just for the sake of fetching some 3rd party libs.
> >
> > I'm wondering what others think about this.
> >
> > Regards,
> > Vojtech
> >
> 
> 
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gshereme at redhat.com
>