<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 10, 2017 at 6:43 PM, Vojtech Szocs <span dir="ltr"><<a href="mailto:vszocs@redhat.com" target="_blank">vszocs@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
----- Original Message -----<br>
> From: "Martin Perina" <<a href="mailto:mperina@redhat.com">mperina@redhat.com</a>><br>
> To: "Vojtech Szocs" <<a href="mailto:vszocs@redhat.com">vszocs@redhat.com</a>><br>
> Cc: "devel" <<a href="mailto:devel@ovirt.org">devel@ovirt.org</a>>, "Juan Hernández" <<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>><br>
> Sent: Friday, January 6, 2017 10:14:22 PM<br>
> Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies<br>
><br>
> On Fri, Jan 6, 2017 at 6:45 PM, Vojtech Szocs <<a href="mailto:vszocs@redhat.com">vszocs@redhat.com</a>> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > we'd like to upgrade the version of PatternFly (plus associated libraries,<br>
> > namely Bootstrap and jQuery) used in oVirt UI.<br>
> ><br>
> > Today, PatternFly stuff (PF + associated libraries) comes from<br>
> > `patternfly1`<br>
> > package hosted at Copr repo:<br>
> ><br>
> > <a href="https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/" rel="noreferrer" target="_blank">https://copr.fedorainfracloud.<wbr>org/coprs/patternfly/<wbr>patternfly1/</a><br>
> ><br>
> > Today, we require `patternfly1` as both Engine RPM build dependency and the<br>
> > Engine devel. env. dependency.<br>
> ><br>
> > To keep things simple, I'd like to propose the following approach:<br>
> ><br>
> > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,<br>
> > containing PatternFly + associated libraries (Bootstrap, jQuery) which<br>
> > are intended *specifically* for use by oVirt UI (hence the ovirt prefix)<br>
> ><br>
> > - discontinue maintenance of `patternfly1` package at Copr<br>
> ><br>
> > - keep the existing approach: require `ovirt-patternfly` as both the Engine<br>
> > build dependency and the Engine devel. env. dependency<br>
> ><br>
><br>
> +1 from me.<br>
><br>
> The only issue is that we combine several javascript libraries in a package<br>
> named ovirt-patternfly.<br>
<br>
Well, this is the same approach like with ovirt-engine-nodejs-modules,<br>
with a difference that nodejs-modules is intended for build-time only.<br>
<br>
The proposed `ovirt-patternfly` (or whatever it's called) is intended<br>
for Engine run-time + as Engine devel. env. pre-requisite.<br>
<br>
The idea is to bundle all JS/CSS/etc. files required by $PROJECT into<br>
a single package. In case of `ovirt-patternfly`, $PROJECT == Engine.<br>
<br>
> Is there a high probabily that we will need some<br>
> other javascript libraries in near future?<br>
<br>
Not too likely, but there's always the chance.<br>
<br>
> If so, then I'd rather call the<br>
> package ovirt-javascript-dependencies (or ovirt-js-dependencies).<br>
<br>
OK, maybe even putting `engine` in the name, since we actually need it<br>
for the Engine (GWT UI), e.g. `ovirt-engine-ui-dependencies`<wbr>.<br></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">AFAIK new user portal is called ovirt-web-ui</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">so term engine is really not needed in package name :-)<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
><br>
><br>
> ><br>
> > An alternative approach would be to introduce Node.js as Engine devel. env.<br>
> > dependency (use `npm install` to pull PF stuff), while using the existing<br>
> > ovirt-engine-{nodejs,nodejs-<wbr>modules} packages for Engine RPM build.<br>
> ><br>
> > However, this alternative has some downsides, namely complication of devel.<br>
> > env. just to fetch the PF stuff. I don't like the idea of complicating the<br>
> > existing devel. env. just for the sake of fetching some 3rd party libs.<br>
> ><br>
> > I'm wondering what others think about this.<br>
> ><br>
> > Regards,<br>
> > Vojtech<br>
> > ______________________________<wbr>_________________<br>
> > Devel mailing list<br>
> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
> ><br>
><br>
</blockquote></div><br></div></div>