6:45 p.m.
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
10:14 p.m.
On Fri, Jan 6, 2017 at 6:45 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
+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).
6:43 p.m.
----- Original Message -----
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`.
5:01 p.m.
--iKWNDccBsK4naGr1WSmusK9GOKQdWld1j
Content-Type: multipart/mixed; boundary="iVLn4wAG3gbRDsROkjQH1cQM0ORMXuD7i";
protected-headers="v1"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <89baf0a8-178a-1f1e-c0c6-f3adf26d6fbd(a)mittwald.de>
Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies
References: <252863496.8562067.1483724740445.JavaMail.zimbra(a)redhat.com>
In-Reply-To: <252863496.8562067.1483724740445.JavaMail.zimbra(a)redhat.com>
--iVLn4wAG3gbRDsROkjQH1cQM0ORMXuD7i
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 06/01/17 18:45, Vojtech Szocs wrote:
Today, we require `patternfly1` as both Engine RPM build dependency
and=
the
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"
--iKWNDccBsK4naGr1WSmusK9GOKQdWld1j--
6:48 p.m.
----- Original Message -----
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..
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?
9:46 p.m.
On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
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.
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
7 p.m.
----- Original Message -----
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.)
10:28 p.m.
On Tue, Jan 10, 2017 at 1:00 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
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.
Sure, that sounds good. Let me verify with infra where it should go.
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
5 p.m.
----- Original Message -----
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.
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.
3048
days inactive
3053
days old
10 comments
4 participants
participants (4)
-
Greg Sheremeta -
Martin Perina -
Sven Kieske -
Vojtech Szocs