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) - 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 _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

----- Original Message ----- > From: "Martin Perina" <mperina(a)redhat.com&gt; > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > Cc: "devel" <devel(a)ovirt.org&gt;, "Juan Hernández" <jhernand(a)redhat.com&gt; > Sent: Friday, January 6, 2017 10:14:22 PM > Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies > > On Fri, Jan 6, 2017 at 6:45 PM, Vojtech Szocs <vszocs(a)redhat.com&gt; 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) > > > > - 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 > > > > ​+1 from me. > > The only issue is that we combine several javascript libraries in a package > named ovirt-patternfly. Well, this is the same approach like with ovirt-engine-nodejs-modules, with a difference that nodejs-modules is intended for build-time only. The proposed `ovirt-patternfly` (or whatever it's called) is intended for Engine run-time + as Engine devel. env. pre-requisite. The idea is to bundle all JS/CSS/etc. files required by $PROJECT into a single package. In case of `ovirt-patternfly`, $PROJECT == Engine. > Is there a high probabily that we will need some > other javascript libraries in near future? Not too likely, but there's always the chance. > If so, then I'd rather call the > package ovirt-javascript-dependencies (or ovirt-js-dependencies). OK, maybe even putting `engine` in the name, since we actually need it for the Engine (GWT UI), e.g. `ovirt-engine-ui-dependencies`.

> ​ > > > > > > 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 > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > >

On 06/01/17 18:45, Vojtech Szocs wrote: > 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) > > - discontinue maintenance of `patternfly1` package at Copr afaik you're also requiring patternfly1 for ovirt-engine installation, not just dev or build env? if that is correct and your new "ovirt-patternfly" would superseed that I'm afraid you would violate fedora and rhel/centos package guidelines by throwing this all together in one package?

I hope I understood the scope of this correct, if not, just disregard my comment. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

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)

- 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

----- Original Message ----- > From: "Greg Sheremeta" <gshereme(a)redhat.com&gt; > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > Cc: "devel" <devel(a)ovirt.org&gt;, "Oved Ourfali" <oourfali(a)redhat.com&gt;, "Juan Hernández" <jhernand(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)redhat.com >