PatternFly upgrade - how to handle JS dependencies
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
On Fri, Jan 6, 2017 at 6:45 PM, Vojtech Szocs <vszocs@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)
- 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. Is there a high probabily that we will need some other javascript libraries in near future? If so, then I'd rather call the package ovirt-javascript-dependencies (or ovirt-js-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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Martin Perina" <mperina@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org>, "Juan Hernández" <jhernand@redhat.com> 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@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)
- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Tue, Jan 10, 2017 at 6:43 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
From: "Martin Perina" <mperina@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org>, "Juan Hernández" <jhernand@redhat.com> 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@redhat.com> wrote:
Hello,
we'd like to upgrade the version of PatternFly (plus associated
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
- 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
----- Original Message ----- libraries, prefix) 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`.
AFAIK new user portal is called ovirt-web-ui so term engine is really not needed in package name :-)
An alternative approach would be to introduce Node.js as Engine devel.
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
env. 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Today, we require `patternfly1` as both Engine RPM build dependency and=
--iKWNDccBsK4naGr1WSmusK9GOKQdWld1j Content-Type: multipart/mixed; boundary="iVLn4wAG3gbRDsROkjQH1cQM0ORMXuD7i"; protected-headers="v1" From: Sven Kieske <s.kieske@mittwald.de> To: devel@ovirt.org Message-ID: <89baf0a8-178a-1f1e-c0c6-f3adf26d6fbd@mittwald.de> Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies References: <252863496.8562067.1483724740445.JavaMail.zimbra@redhat.com> In-Reply-To: <252863496.8562067.1483724740445.JavaMail.zimbra@redhat.com> --iVLn4wAG3gbRDsROkjQH1cQM0ORMXuD7i Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/01/17 18:45, Vojtech Szocs wrote: the
Engine devel. env. dependency. =20 To keep things simple, I'd like to propose the following approach: =20 - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Cop= r, containing PatternFly + associated libraries (Bootstrap, jQuery) whic= h are intended *specifically* for use by oVirt UI (hence the ovirt pref= ix) =20 - 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. --=20 Mit freundlichen Gr=FC=DFen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=F6nigsberger Stra=DFe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=E4ftsf=FChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause= n Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha= usen --iVLn4wAG3gbRDsROkjQH1cQM0ORMXuD7i-- --iKWNDccBsK4naGr1WSmusK9GOKQdWld1j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYcRDhAAoJEMby9TMDAbQRp24P/2WvzyytsDFeNu7hu7v2QxjC n2idYSQN8eMHPCwaPld7amSygvAtaiHxlaizfLsTZmlvftmFBTwk39hNZ+iHJa4L nBkPQM8/GnPXNbQyinYo6q9/23hzhtEPi5DZYLS7sdRMR83YcQxwOSKCkBSsciUj rcIVqN1IWtvbFbPakMW7/KtoLv6758XjNKbcA44lRxM27470fpRyvDXMzYZFGhMi eAKJDdpm+PzmoVwUkfF1lm4li16GY7bnMptUGrVE/tInFYoB3h3CfdrzMW24sN+S gtYmWvALL5GFHPCzm7ykN45QBphs5p6dpwBxrfANIx2F5pE6UM/FGQ/SoS0Vpht3 OQjm2DkNK6JXVH7aBWmaL88ppimYALO1tCAp8ScdXp97c920p3v1JOv1vO7sA+BM jO+SnxMGzx2y2VhbwvNjjNUV7E+GahrnHf62qoh2+r8zJjFf3LYAuZYAFO6zpEUl /0s8ieNpj9P3uyEVw4046bu5FYCzkbQGCAUZ+dv/HzcQ/TnATz3yr88HOzR8WXTW 4RfEDgvgD5rHFrnzN28+zoKab92BGxc4Is/Gdm4JwIBJu4hUalONuDVDrmj9RKmD KufFXPDTgri4SATf6rbGwMbg4Ak9aBKT5eK7wEhuYsqU2/BSM2U7ACPcp0Shl44N 3DTi/ffAAjWy6kT5egUT =TkfT -----END PGP SIGNATURE----- --iKWNDccBsK4naGr1WSmusK9GOKQdWld1j--
On Sat, Jan 7, 2017 at 11:01 AM, Sven Kieske <s.kieske@mittwald.de> wrote:
Today, we require `patternfly1` as both Engine RPM build dependency and
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
On 06/01/17 18:45, Vojtech Szocs wrote: the 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?
Yeah. It's all thrown into the 'patternfly1' package currently anyway, so there's really no change here.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: devel@ovirt.org Sent: Saturday, January 7, 2017 5:01:37 PM Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies
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?
Sven, you are correct. Today, `patternfly1` is needed at Engine RPM install-time (via Requires) and as Engine devel. env. pre-requisite. It's not needed at Engine RPM build-time (no BuildRequires). Apologies for confusion. I realized it after I sent my mail..
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?
The newly proposed package should be oVirt-specific, for oVirt by oVirt. It's not meant to be a general-purpose RPM containing PatternFly stuff. Is it a violation of Fedora pkg guidelines if a project creates its own package, bundling 3rd party dependencies?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs <vszocs@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/ However, we want to move it to our ovirt infra because copr sometimes goes down, and that breaks CI jobs. 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@redhat.com
----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org>, "Oved Ourfali" <oourfali@redhat.com>, "Juan Hernández" <jhernand@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@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@redhat.com
On Tue, Jan 10, 2017 at 1:00 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org>, "Oved Ourfali" <oourfali@redhat.com>, "Juan Hernández" <jhernand@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@redhat.com> wrote:
Hello,
we'd like to upgrade the version of PatternFly (plus associated
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
----- Original Message ----- libraries, 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).
That's fine. I had created the repo long before your suggestion, that's all. I think it should have 'js' in the name somewhere.
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.)
Sure, that sounds good. Let me verify with infra where it should go.
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
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
Engine 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@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org>, "Oved Ourfali" <oourfali@redhat.com>, "Juan Hernández" <jhernand@redhat.com> Sent: Tuesday, January 10, 2017 10:28:06 PM Subject: Re: PatternFly upgrade - how to handle JS dependencies
On Tue, Jan 10, 2017 at 1:00 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
From: "Greg Sheremeta" <gshereme@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "devel" <devel@ovirt.org>, "Oved Ourfali" <oourfali@redhat.com>, "Juan Hernández" <jhernand@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@redhat.com> wrote:
Hello,
we'd like to upgrade the version of PatternFly (plus associated
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
----- Original Message ----- libraries, 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).
That's fine. I had created the repo long before your suggestion, that's all.
I know, I just wanted to suggest the future change. Having `patternfly3` right now allows us to experiment with upgrading the PatternFly version in GWT UI so for the moment, I'm OK with that.
I think it should have 'js' in the name somewhere.
OK, this is Martin's suggestion actually =) ovirt-js-dependencies.
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.)
Sure, that sounds good. Let me verify with infra where it should go.
Thanks. Note that I'm totally OK with Copr too. But having an RPM built by oVirt infra (with JS dependencies fetched in a way consistent with e.g. nodejs-modules) indeed seems as the more correct approach.
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
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
Engine 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@redhat.com
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
participants (4)
-
Greg Sheremeta -
Martin Perina -
Sven Kieske -
Vojtech Szocs