Re: [jbosstools-dev] Do we still need Xulrunner in Devstudio?
by Alexey Kazakov
On 09/29/2016 06:37 AM, Aleksandar Kurtakov wrote:
>
> ----- Original Message -----
>> From: "Alexey Kazakov" <alkazako(a)redhat.com>
>> To: "Ilya Buziuk" <ibuziuk(a)redhat.com>, "Aleksandar Kurtakov" <akurtako(a)redhat.com>, "jbosstools-dev jbosstools-dev"
>> <jbosstools-dev(a)lists.jboss.org>
>> Cc: "Max Rydahl Andersen" <manderse(a)redhat.com>, "Nick Boldt" <nboldt(a)redhat.com>, "Leo Ufimtsev"
>> <lufimtse(a)redhat.com>
>> Sent: Thursday, 29 September, 2016 4:33:00 PM
>> Subject: Re: Do we still need Xulrunner in Devstudio?
>>
>> It looks like I missed some discussion here. So, I'm repeating my
>> question, why would we like to remove Xulrunner and/or deprecate VPE?
> The discussion started from xulrunner being usable only in GTK2 env when on RHEL 7 we support only GTK3. It would be really nice to not have recommendations to use GTK2 for using VPE as it would cause issues for other plugins.
OK. So, removing VPE is not a solution for this anyway ;)
Thanks.
>
>> Just want to understand if there is some real problem and our Xulrunner
>> stuff blocks us to solve it or this is just for cleanness sake.
>>
>> Thanks.
>>
>> On 09/29/2016 03:28 AM, Ilya Buziuk wrote:
>>> Hi, Aleksandr
>>> Alexey has already moved this discussion to jbosstools-dev.
>>>
>>> Unfortunately, I do not have Webkit POC ready to hand, but I think I
>>> remember the approach. Basically, the WebKit based transformation was
>>> done via SWT BrowserFunction[1] and the performance was much worse
>>> in comparison with the DOM API. If you want to figure out how the
>>> current Xulrunner based implementation work, you should probably start
>>> with tests[2] that cover things like mapping between source jsf / jsp
>>> tags and visual part via DOM API. However, I still want to put my 2
>>> cents in this discussion.
>>>
>>> Let's face the bullet - JSF is dying technology, and spending any time
>>> on new development is simply nonsensical IMO. Even if eventually a
>>> better WebKit based VPE will be created (which is doubtful because it
>>> was developed by big team ~ 10 developers for a couple of years) it
>>> will have very little value for both community and business. For now
>>> the only request from the community was - "please, leave it as is".
>>>
>>> If SWT will drop GTK 2 support than we will have to deprecate it on
>>> this Linux. But it worth mentioning that all Linux distros are just a
>>> couple of percents of the tools user base and our target audience ~ 85
>>> - 90 % is Windows developers. For me it is also not clear why it is
>>> important to deprecate it right now ? We already had this discussion
>>> and decided not to do it in 2015, so I can not come up with a reason
>>> why should it be done in 2016. Just to be clear, I am not against
>>> deprecation, I am just saying that we should think twice before doing
>>> it and get some agreement about Xulrunner future, so that we will not
>>> be returning to this discussion again and again.
>>> [1]
>>> http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.do...
>>> <http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.do...>
>>> [2]
>>> https://github.com/jbosstools/jbosstools-vpe/blob/master/tests/org.jboss....
>>>
>>>
>>> On Thu, Sep 29, 2016 at 8:07 AM, Aleksandar Kurtakov
>>> <akurtako(a)redhat.com <mailto:akurtako@redhat.com>> wrote:
>>>
>>> Adding Max and Alexey (maybe we should move to the mailing list?)
>>> and dropping Jeff to not spam him.
>>>
>>> ----- Original Message -----
>>> > From: "Aleksandar Kurtakov" <akurtako(a)redhat.com
>>> <mailto:akurtako@redhat.com>>
>>> > To: "Ilya Buziuk" <ibuziuk(a)redhat.com <mailto:ibuziuk@redhat.com>>
>>> > Cc: "Nick Boldt" <nboldt(a)redhat.com <mailto:nboldt@redhat.com>>,
>>> "Leo Ufimtsev" <lufimtse(a)redhat.com <mailto:lufimtse@redhat.com>>,
>>> "Jeff Johnston" <jjohnstn(a)redhat.com <mailto:jjohnstn@redhat.com>>
>>> > Sent: Thursday, 29 September, 2016 9:04:42 AM
>>> > Subject: Re: Do we still need Xulrunner in Devstudio?
>>> >
>>> >
>>> >
>>> > ----- Original Message -----
>>> > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com
>>> <mailto:ibuziuk@redhat.com>>
>>> > > To: "Aleksandar Kurtakov" <akurtako(a)redhat.com
>>> <mailto:akurtako@redhat.com>>
>>> > > Cc: "Nick Boldt" <nboldt(a)redhat.com
>>> <mailto:nboldt@redhat.com>>, "Leo Ufimtsev" <lufimtse(a)redhat.com
>>> <mailto:lufimtse@redhat.com>>,
>>> > > "Jeff Johnston" <jjohnstn(a)redhat.com <mailto:jjohnstn@redhat.com>>
>>> > > Sent: Wednesday, 28 September, 2016 8:23:47 PM
>>> > > Subject: Re: Do we still need Xulrunner in Devstudio?
>>> > >
>>> > > Basically, jsf tags can not be displayed as-is and be parsed
>>> correctly in
>>> > > browser like html, due to the fact that it is server side
>>> technology. So,
>>> > > the algorithm for VPE is the following: the content is
>>> rendered and all
>>> > > jsf tags are parsed through a set of templates via the native
>>> DOM API which
>>> > > is available only in particular older versions of XULRunner.
>>> So, in order
>>> > > to use Webkit or other engine and migrate all VPE features,
>>> reimplementing
>>> > > all of those temlpate transformations is required. Plus not to
>>> forget the
>>> > > performance thing - processing might take a long time (I think
>>> we had some
>>> > > WebKit POC but performance was just unacceptable). This is not
>>> a trivial
>>> > > task at all and I do believe that we have no resources for
>>> doing it - VPE
>>> > > component's code base is one of the biggest (if not the
>>> biggest) across
>>> > > tools.
>>> >
>>> > That's exactly the kind of info I was looking for. Can you point
>>> me to the
>>> > transformations used for the xulrunner? Sorry for being lazy but
>>> it's
>>> > foreing land for me so I would rather not lose time lurking around.
>>> > Do you have a pointer to the WebKit POC? It might be interested
>>> to reach out
>>> > to the desktop team (there is webkit developer there) with all
>>> the info so
>>> > maybe they can hint us how to achieve what's needed if latest
>>> webkit doesn't
>>> > fullfill the needs.
>>> >
>>> > > In a nutshell - after reimplementing there will be the same,
>>> or less
>>> > > powerful, VPE with more bugs and poor performance.
>>> >
>>> > That might be true now but you should think a bit further in
>>> time. In the not
>>> > so distant future (2018 release most probably, if not 2019 for
>>> sure) SWT
>>> > itself will drop support for running on GTK 2.x and that would be
>>> > effectively the end of this plugin if no action taken.
>>> >
>>> >
>>> > >
>>> > > On Wed, Sep 28, 2016 at 6:42 PM, Aleksandar Kurtakov
>>> <akurtako(a)redhat.com <mailto:akurtako@redhat.com>>
>>> > > wrote:
>>> > >
>>> > > >
>>> > > >
>>> > > > ----- Original Message -----
>>> > > > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com
>>> <mailto:ibuziuk@redhat.com>>
>>> > > > > To: "Nick Boldt" <nboldt(a)redhat.com
>>> <mailto:nboldt@redhat.com>>
>>> > > > > Cc: "Aleksandar Kurtakov" <akurtako(a)redhat.com
>>> <mailto:akurtako@redhat.com>>, "Leo Ufimtsev" <
>>> > > > lufimtse(a)redhat.com <mailto:lufimtse@redhat.com>>, "Jeff
>>> Johnston"
>>> > > > > <jjohnstn(a)redhat.com <mailto:jjohnstn@redhat.com>>
>>> > > > > Sent: Wednesday, 28 September, 2016 7:19:24 PM
>>> > > > > Subject: Re: Do we still need Xulrunner in Devstudio?
>>> > > > >
>>> > > > > Actually, we planned to remove xulrunner and deprecate VPE
>>> some time
>>> > > > > ago
>>> > > > > and leave only VPV as a WYSIWYG html editor.
>>> > > > As someone not familiar with the topic I don't see xulrunner
>>> and VPE
>>> > > > deprecation that closely coupled. What is the reason for
>>> that? What's
>>> > > > preventing to achieve it with webkit? Do you extend SWT
>>> Browser API
>>> > > > somehow?
>>> > > > Please give all the details you can think of so I can get better
>>> > > > understanding of the issue/reasons.
>>> > > >
>>> > > > > However, as soon as we gave a
>>> > > > > shout out about this on tools.jboss.org
>>> <http://tools.jboss.org> the first comment was:
>>> > > > >
>>> > > > > Nice. The reason I used JBoss Tools was the Visual Editor
>>> for JSF,
>>> > > > > > especially for the Visual parts, which was not perfect
>>> but was good
>>> > > > enough
>>> > > > > > to have it. Will you have alternatives for that ? [1]
>>> > > > >
>>> > > > >
>>> > > > > It was decided that we need to slow down with this
>>> process. I can not
>>> > > > > say
>>> > > > > if it is a high time for doing this assuming that some
>>> people actually
>>> > > > use
>>> > > > > it. Furthermore, some people treat it as a killer feature
>>> for JSF that
>>> > > > only
>>> > > > > one IDE is providing. So, we need to think twice before
>>> doing it.
>>> > > > >
>>> > > > > [1]
>>> http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA-
>>> <http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA->
>>> > > > for-luna.html
>>> > > > >
>>> > > > > On Wed, Sep 28, 2016 at 5:40 PM, Nick Boldt
>>> <nboldt(a)redhat.com <mailto:nboldt@redhat.com>> wrote:
>>> > > > >
>>> > > > > > On the Eclipse team call today, the question of why we
>>> need Xulrunner
>>> > > > > > was brought up again.
>>> > > > > >
>>> > > > > > As I understand it, the only reason we still include
>>> Xulrunner is for
>>> > > > > > the Visual Page Editor. But Alex pointed out today that
>>> Xulrunner
>>> > > > > > only
>>> > > > > > works on GTK2, which means a user has to explicity
>>> disable GTK3 in
>>> > > > > > order for Xulrunner to be used, as these days GTK3 is
>>> the default
>>> > > > > > OOTB
>>> > > > > > implementation on the platforms we support (Fedora
>>> 24/25, RHEL7,
>>> > > > > > etc.).
>>> > > > > >
>>> > > > > > So... is it time to remove Xulrunner from the Devstudio
>>> dependencies,
>>> > > > > > if most people are not even seeing it used?
>>> > > > > >
>>> > > > > > Alex suggested it might be useful to set up a call to
>>> discuss this in
>>> > > > > > more depth. Is there a good time tomorrow or Friday you
>>> guys would
>>> > > > > > like to meet to discuss this, if it can't be resolved
>>> asynchronously
>>> > > > > > via email?
>>> > > > > >
>>> > > > > > Whatever we decide here, we should make sure we announce
>>> this on the
>>> > > > > > jbosstools-dev@ list.
>>> > > > > >
>>> > > > > > --
>>> > > > > > Nick Boldt :: JBoss by Red Hat
>>> > > > > > Productization Lead :: JBoss Tools & Dev Studio
>>> > > > > > http://nick.divbyzero.com
>>> > > > > >
>>> > > > >
>>> > > >
>>> > > > --
>>> > > > Alexander Kurtakov
>>> > > > Red Hat Eclipse team
>>> > > >
>>> > >
>>> >
>>> > --
>>> > Alexander Kurtakov
>>> > Red Hat Eclipse team
>>> >
>>>
>>> --
>>> Alexander Kurtakov
>>> Red Hat Eclipse team
>>>
>>>
>>
8 years, 1 month
Re: [jbosstools-dev] Do we still need Xulrunner in Devstudio?
by Nick Boldt
Bear in mind that devstudio 10.2 (nov code freeze, dec GA) is targeted
to support only F24 (current) and F25 (avail in Nov before devstudio
GA code freeze).
So if F25 drops GTK2, we may have to follow suit.
On Thu, Sep 29, 2016 at 12:11 PM, Aleksandar Kurtakov
<akurtako(a)redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Alexey Kazakov" <alkazako(a)redhat.com>
>> To: "Nick Boldt" <nboldt(a)redhat.com>
>> Cc: "Aleksandar Kurtakov" <akurtako(a)redhat.com>, "Ilya Buziuk" <ibuziuk(a)redhat.com>, "jbosstools-dev jbosstools-dev"
>> <jbosstools-dev(a)lists.jboss.org>, "Max Rydahl Andersen" <manderse(a)redhat.com>, "Leo Ufimtsev" <lufimtse(a)redhat.com>,
>> "Leonard Dimaggio" <ldimaggi(a)redhat.com>, "Rick Wagner" <rwagner(a)redhat.com>
>> Sent: Thursday, 29 September, 2016 7:06:25 PM
>> Subject: Re: Do we still need Xulrunner in Devstudio?
>>
>> So, this all was about removing Xulrunner/VPE from RPM only?
> You can read it that way if you want.
>
>> RHEL 7
>> doesn't support GTK2 at all or it's just tricky to use it instead of
>> GTK3?
> RHEL 7 has GTK2 library but is missing a number of other libraries which render swt on gtk2 on rhel7 not fully functional.
>
>> What about Fedora?
>
> Fedora 24 still has most things for swt on gtk2 to work but there are more and more things planned ot be removed for next releases so we will drop support there too.
>
>>
>>
>> On 09/29/2016 08:37 AM, Nick Boldt wrote:
>> > Why wouldn't it be a solution?
>> >
>> > devstudio includes vpe. vpe depends on xulrunner. xulrunner needs
>> > GTK2. GTK2 on RHEL7 is not supported.
>> >
>> > Therefore devstudio rpm shouldn't include vpe/xulrunner/gtk2. QED. :D
>> >
>> > What if we provide two different install paths?
>> >
>> > a) rpm installs everything in devstudio except vpe/xulrunner (supported
>> > config)
>> >
>> > b) users who want vpe can then install it by hand from the devstudio
>> > *update site*, plus the 4 dependency RPMs, and enabling GTK3=0 to
>> > force Eclipse to run in unsupported GTK2 mode.
>> >
>> > I would also be open to the idea of building a quasi-supported ("Tech
>> > Preview") rh-eclipse 46-devstudio-vpe rpm, which provides the
>> > vpe/xulrunner and requires the 4 dependencies. It could maybe even
>> > enable GTK3=0 (?) on startup of Eclipse, provided it includes an
>> > eclipse.sh which would enable that property before starting the
>> > eclipse executable.
>> >
>> > This new rpm would of course require buy in from GSS and QE. Adding
>> > Len and Rick to cc:.
>> >
>> > N
>> >
>> >
>> >
>> > On Thu, Sep 29, 2016 at 10:53 AM, Alexey Kazakov <alkazako(a)redhat.com>
>> > wrote:
>> >>
>> >> On 09/29/2016 06:37 AM, Aleksandar Kurtakov wrote:
>> >>>
>> >>> ----- Original Message -----
>> >>>> From: "Alexey Kazakov" <alkazako(a)redhat.com>
>> >>>> To: "Ilya Buziuk" <ibuziuk(a)redhat.com>, "Aleksandar Kurtakov"
>> >>>> <akurtako(a)redhat.com>, "jbosstools-dev jbosstools-dev"
>> >>>> <jbosstools-dev(a)lists.jboss.org>
>> >>>> Cc: "Max Rydahl Andersen" <manderse(a)redhat.com>, "Nick Boldt"
>> >>>> <nboldt(a)redhat.com>, "Leo Ufimtsev"
>> >>>> <lufimtse(a)redhat.com>
>> >>>> Sent: Thursday, 29 September, 2016 4:33:00 PM
>> >>>> Subject: Re: Do we still need Xulrunner in Devstudio?
>> >>>>
>> >>>> It looks like I missed some discussion here. So, I'm repeating my
>> >>>> question, why would we like to remove Xulrunner and/or deprecate VPE?
>> >>> The discussion started from xulrunner being usable only in GTK2 env when
>> >>> on RHEL 7 we support only GTK3. It would be really nice to not have
>> >>> recommendations to use GTK2 for using VPE as it would cause issues for
>> >>> other
>> >>> plugins.
>> >>
>> >> OK. So, removing VPE is not a solution for this anyway ;)
>> >>
>> >> Thanks.
>> >>
>> >>
>> >>>> Just want to understand if there is some real problem and our Xulrunner
>> >>>> stuff blocks us to solve it or this is just for cleanness sake.
>> >>>>
>> >>>> Thanks.
>> >>>>
>> >>>> On 09/29/2016 03:28 AM, Ilya Buziuk wrote:
>> >>>>> Hi, Aleksandr
>> >>>>> Alexey has already moved this discussion to jbosstools-dev.
>> >>>>>
>> >>>>> Unfortunately, I do not have Webkit POC ready to hand, but I think I
>> >>>>> remember the approach. Basically, the WebKit based transformation was
>> >>>>> done via SWT BrowserFunction[1] and the performance was much worse
>> >>>>> in comparison with the DOM API. If you want to figure out how the
>> >>>>> current Xulrunner based implementation work, you should probably start
>> >>>>> with tests[2] that cover things like mapping between source jsf / jsp
>> >>>>> tags and visual part via DOM API. However, I still want to put my 2
>> >>>>> cents in this discussion.
>> >>>>>
>> >>>>> Let's face the bullet - JSF is dying technology, and spending any time
>> >>>>> on new development is simply nonsensical IMO. Even if eventually a
>> >>>>> better WebKit based VPE will be created (which is doubtful because it
>> >>>>> was developed by big team ~ 10 developers for a couple of years) it
>> >>>>> will have very little value for both community and business. For now
>> >>>>> the only request from the community was - "please, leave it as is".
>> >>>>>
>> >>>>> If SWT will drop GTK 2 support than we will have to deprecate it on
>> >>>>> this Linux. But it worth mentioning that all Linux distros are just a
>> >>>>> couple of percents of the tools user base and our target audience ~ 85
>> >>>>> - 90 % is Windows developers. For me it is also not clear why it is
>> >>>>> important to deprecate it right now ? We already had this discussion
>> >>>>> and decided not to do it in 2015, so I can not come up with a reason
>> >>>>> why should it be done in 2016. Just to be clear, I am not against
>> >>>>> deprecation, I am just saying that we should think twice before doing
>> >>>>> it and get some agreement about Xulrunner future, so that we will not
>> >>>>> be returning to this discussion again and again.
>> >>>>> [1]
>> >>>>>
>> >>>>> http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.do...
>> >>>>>
>> >>>>> <http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.do...>
>> >>>>> [2]
>> >>>>>
>> >>>>> https://github.com/jbosstools/jbosstools-vpe/blob/master/tests/org.jboss....
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Sep 29, 2016 at 8:07 AM, Aleksandar Kurtakov
>> >>>>> <akurtako(a)redhat.com <mailto:akurtako@redhat.com>> wrote:
>> >>>>>
>> >>>>> Adding Max and Alexey (maybe we should move to the mailing list?)
>> >>>>> and dropping Jeff to not spam him.
>> >>>>>
>> >>>>> ----- Original Message -----
>> >>>>> > From: "Aleksandar Kurtakov" <akurtako(a)redhat.com
>> >>>>> <mailto:akurtako@redhat.com>>
>> >>>>> > To: "Ilya Buziuk" <ibuziuk(a)redhat.com
>> >>>>> <mailto:ibuziuk@redhat.com>>
>> >>>>> > Cc: "Nick Boldt" <nboldt(a)redhat.com
>> >>>>> > <mailto:nboldt@redhat.com>>,
>> >>>>> "Leo Ufimtsev" <lufimtse(a)redhat.com
>> >>>>> <mailto:lufimtse@redhat.com>>,
>> >>>>> "Jeff Johnston" <jjohnstn(a)redhat.com
>> >>>>> <mailto:jjohnstn@redhat.com>>
>> >>>>> > Sent: Thursday, 29 September, 2016 9:04:42 AM
>> >>>>> > Subject: Re: Do we still need Xulrunner in Devstudio?
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> > ----- Original Message -----
>> >>>>> > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com
>> >>>>> <mailto:ibuziuk@redhat.com>>
>> >>>>> > > To: "Aleksandar Kurtakov" <akurtako(a)redhat.com
>> >>>>> <mailto:akurtako@redhat.com>>
>> >>>>> > > Cc: "Nick Boldt" <nboldt(a)redhat.com
>> >>>>> <mailto:nboldt@redhat.com>>, "Leo Ufimtsev" <lufimtse(a)redhat.com
>> >>>>> <mailto:lufimtse@redhat.com>>,
>> >>>>> > > "Jeff Johnston" <jjohnstn(a)redhat.com
>> >>>>> <mailto:jjohnstn@redhat.com>>
>> >>>>> > > Sent: Wednesday, 28 September, 2016 8:23:47 PM
>> >>>>> > > Subject: Re: Do we still need Xulrunner in Devstudio?
>> >>>>> > >
>> >>>>> > > Basically, jsf tags can not be displayed as-is and be parsed
>> >>>>> correctly in
>> >>>>> > > browser like html, due to the fact that it is server side
>> >>>>> technology. So,
>> >>>>> > > the algorithm for VPE is the following: the content is
>> >>>>> rendered and all
>> >>>>> > > jsf tags are parsed through a set of templates via the native
>> >>>>> DOM API which
>> >>>>> > > is available only in particular older versions of XULRunner.
>> >>>>> So, in order
>> >>>>> > > to use Webkit or other engine and migrate all VPE features,
>> >>>>> reimplementing
>> >>>>> > > all of those temlpate transformations is required. Plus not
>> >>>>> > > to
>> >>>>> forget the
>> >>>>> > > performance thing - processing might take a long time (I
>> >>>>> > > think
>> >>>>> we had some
>> >>>>> > > WebKit POC but performance was just unacceptable). This is
>> >>>>> > > not
>> >>>>> a trivial
>> >>>>> > > task at all and I do believe that we have no resources for
>> >>>>> doing it - VPE
>> >>>>> > > component's code base is one of the biggest (if not the
>> >>>>> biggest) across
>> >>>>> > > tools.
>> >>>>> >
>> >>>>> > That's exactly the kind of info I was looking for. Can you
>> >>>>> > point
>> >>>>> me to the
>> >>>>> > transformations used for the xulrunner? Sorry for being lazy
>> >>>>> > but
>> >>>>> it's
>> >>>>> > foreing land for me so I would rather not lose time lurking
>> >>>>> around.
>> >>>>> > Do you have a pointer to the WebKit POC? It might be interested
>> >>>>> to reach out
>> >>>>> > to the desktop team (there is webkit developer there) with all
>> >>>>> the info so
>> >>>>> > maybe they can hint us how to achieve what's needed if latest
>> >>>>> webkit doesn't
>> >>>>> > fullfill the needs.
>> >>>>> >
>> >>>>> > > In a nutshell - after reimplementing there will be the same,
>> >>>>> or less
>> >>>>> > > powerful, VPE with more bugs and poor performance.
>> >>>>> >
>> >>>>> > That might be true now but you should think a bit further in
>> >>>>> time. In the not
>> >>>>> > so distant future (2018 release most probably, if not 2019 for
>> >>>>> sure) SWT
>> >>>>> > itself will drop support for running on GTK 2.x and that would
>> >>>>> > be
>> >>>>> > effectively the end of this plugin if no action taken.
>> >>>>> >
>> >>>>> >
>> >>>>> > >
>> >>>>> > > On Wed, Sep 28, 2016 at 6:42 PM, Aleksandar Kurtakov
>> >>>>> <akurtako(a)redhat.com <mailto:akurtako@redhat.com>>
>> >>>>> > > wrote:
>> >>>>> > >
>> >>>>> > > >
>> >>>>> > > >
>> >>>>> > > > ----- Original Message -----
>> >>>>> > > > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com
>> >>>>> <mailto:ibuziuk@redhat.com>>
>> >>>>> > > > > To: "Nick Boldt" <nboldt(a)redhat.com
>> >>>>> <mailto:nboldt@redhat.com>>
>> >>>>> > > > > Cc: "Aleksandar Kurtakov" <akurtako(a)redhat.com
>> >>>>> <mailto:akurtako@redhat.com>>, "Leo Ufimtsev" <
>> >>>>> > > > lufimtse(a)redhat.com <mailto:lufimtse@redhat.com>>, "Jeff
>> >>>>> Johnston"
>> >>>>> > > > > <jjohnstn(a)redhat.com <mailto:jjohnstn@redhat.com>>
>> >>>>> > > > > Sent: Wednesday, 28 September, 2016 7:19:24 PM
>> >>>>> > > > > Subject: Re: Do we still need Xulrunner in Devstudio?
>> >>>>> > > > >
>> >>>>> > > > > Actually, we planned to remove xulrunner and deprecate
>> >>>>> > > > > VPE
>> >>>>> some time
>> >>>>> > > > > ago
>> >>>>> > > > > and leave only VPV as a WYSIWYG html editor.
>> >>>>> > > > As someone not familiar with the topic I don't see
>> >>>>> > > > xulrunner
>> >>>>> and VPE
>> >>>>> > > > deprecation that closely coupled. What is the reason for
>> >>>>> that? What's
>> >>>>> > > > preventing to achieve it with webkit? Do you extend SWT
>> >>>>> Browser API
>> >>>>> > > > somehow?
>> >>>>> > > > Please give all the details you can think of so I can get
>> >>>>> better
>> >>>>> > > > understanding of the issue/reasons.
>> >>>>> > > >
>> >>>>> > > > > However, as soon as we gave a
>> >>>>> > > > > shout out about this on tools.jboss.org
>> >>>>> <http://tools.jboss.org> the first comment was:
>> >>>>> > > > >
>> >>>>> > > > > Nice. The reason I used JBoss Tools was the Visual Editor
>> >>>>> for JSF,
>> >>>>> > > > > > especially for the Visual parts, which was not perfect
>> >>>>> but was good
>> >>>>> > > > enough
>> >>>>> > > > > > to have it. Will you have alternatives for that ? [1]
>> >>>>> > > > >
>> >>>>> > > > >
>> >>>>> > > > > It was decided that we need to slow down with this
>> >>>>> process. I can not
>> >>>>> > > > > say
>> >>>>> > > > > if it is a high time for doing this assuming that some
>> >>>>> people actually
>> >>>>> > > > use
>> >>>>> > > > > it. Furthermore, some people treat it as a killer feature
>> >>>>> for JSF that
>> >>>>> > > > only
>> >>>>> > > > > one IDE is providing. So, we need to think twice before
>> >>>>> doing it.
>> >>>>> > > > >
>> >>>>> > > > > [1]
>> >>>>> http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA-
>> >>>>> <http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA->
>> >>>>> > > > for-luna.html
>> >>>>> > > > >
>> >>>>> > > > > On Wed, Sep 28, 2016 at 5:40 PM, Nick Boldt
>> >>>>> <nboldt(a)redhat.com <mailto:nboldt@redhat.com>> wrote:
>> >>>>> > > > >
>> >>>>> > > > > > On the Eclipse team call today, the question of why we
>> >>>>> need Xulrunner
>> >>>>> > > > > > was brought up again.
>> >>>>> > > > > >
>> >>>>> > > > > > As I understand it, the only reason we still include
>> >>>>> Xulrunner is for
>> >>>>> > > > > > the Visual Page Editor. But Alex pointed out today that
>> >>>>> Xulrunner
>> >>>>> > > > > > only
>> >>>>> > > > > > works on GTK2, which means a user has to explicity
>> >>>>> disable GTK3 in
>> >>>>> > > > > > order for Xulrunner to be used, as these days GTK3 is
>> >>>>> the default
>> >>>>> > > > > > OOTB
>> >>>>> > > > > > implementation on the platforms we support (Fedora
>> >>>>> 24/25, RHEL7,
>> >>>>> > > > > > etc.).
>> >>>>> > > > > >
>> >>>>> > > > > > So... is it time to remove Xulrunner from the Devstudio
>> >>>>> dependencies,
>> >>>>> > > > > > if most people are not even seeing it used?
>> >>>>> > > > > >
>> >>>>> > > > > > Alex suggested it might be useful to set up a call to
>> >>>>> discuss this in
>> >>>>> > > > > > more depth. Is there a good time tomorrow or Friday you
>> >>>>> guys would
>> >>>>> > > > > > like to meet to discuss this, if it can't be resolved
>> >>>>> asynchronously
>> >>>>> > > > > > via email?
>> >>>>> > > > > >
>> >>>>> > > > > > Whatever we decide here, we should make sure we
>> >>>>> > > > > > announce
>> >>>>> this on the
>> >>>>> > > > > > jbosstools-dev@ list.
>> >>>>> > > > > >
>> >>>>> > > > > > --
>> >>>>> > > > > > Nick Boldt :: JBoss by Red Hat
>> >>>>> > > > > > Productization Lead :: JBoss Tools & Dev Studio
>> >>>>> > > > > > http://nick.divbyzero.com
>> >>>>> > > > > >
>> >>>>> > > > >
>> >>>>> > > >
>> >>>>> > > > --
>> >>>>> > > > Alexander Kurtakov
>> >>>>> > > > Red Hat Eclipse team
>> >>>>> > > >
>> >>>>> > >
>> >>>>> >
>> >>>>> > --
>> >>>>> > Alexander Kurtakov
>> >>>>> > Red Hat Eclipse team
>> >>>>> >
>> >>>>>
>> >>>>> --
>> >>>>> Alexander Kurtakov
>> >>>>> Red Hat Eclipse team
>> >>>>>
>> >>>>>
>> >
>> >
>>
>>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse team
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
8 years, 2 months
Re: [jbosstools-dev] Do we still need Xulrunner in Devstudio?
by Ilya Buziuk
Hi, Aleksandr
Alexey has already moved this discussion to jbosstools-dev.
Unfortunately, I do not have Webkit POC ready to hand, but I think I
remember the approach. Basically, the WebKit based transformation was done
via SWT BrowserFunction[1] and the performance was much worse in comparison
with the DOM API. If you want to figure out how the current Xulrunner based
implementation work, you should probably start with tests[2] that cover
things like mapping between source jsf / jsp tags and visual part via DOM
API. However, I still want to put my 2 cents in this discussion.
Let's face the bullet - JSF is dying technology, and spending any time on
new development is simply nonsensical IMO. Even if eventually a better
WebKit based VPE will be created (which is doubtful because it was
developed by big team ~ 10 developers for a couple of years) it will have
very little value for both community and business. For now the only request
from the community was - "please, leave it as is".
If SWT will drop GTK 2 support than we will have to deprecate it on this
Linux. But it worth mentioning that all Linux distros are just a couple of
percents of the tools user base and our target audience ~ 85 - 90 % is
Windows developers. For me it is also not clear why it is important to
deprecate it right now ? We already had this discussion and decided not to
do it in 2015, so I can not come up with a reason why should it be done in
2016. Just to be clear, I am not against deprecation, I am just saying that
we should think twice before doing it and get some agreement about
Xulrunner future, so that we will not be returning to this discussion again
and again.
[1] http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.
eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fbrowser%
2FBrowserFunction.html
[2]
https://github.com/jbosstools/jbosstools-vpe/blob/master/tests/org.jboss....
On Thu, Sep 29, 2016 at 8:07 AM, Aleksandar Kurtakov <akurtako(a)redhat.com>
wrote:
> Adding Max and Alexey (maybe we should move to the mailing list?) and
> dropping Jeff to not spam him.
>
> ----- Original Message -----
> > From: "Aleksandar Kurtakov" <akurtako(a)redhat.com>
> > To: "Ilya Buziuk" <ibuziuk(a)redhat.com>
> > Cc: "Nick Boldt" <nboldt(a)redhat.com>, "Leo Ufimtsev" <
> lufimtse(a)redhat.com>, "Jeff Johnston" <jjohnstn(a)redhat.com>
> > Sent: Thursday, 29 September, 2016 9:04:42 AM
> > Subject: Re: Do we still need Xulrunner in Devstudio?
> >
> >
> >
> > ----- Original Message -----
> > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com>
> > > To: "Aleksandar Kurtakov" <akurtako(a)redhat.com>
> > > Cc: "Nick Boldt" <nboldt(a)redhat.com>, "Leo Ufimtsev" <
> lufimtse(a)redhat.com>,
> > > "Jeff Johnston" <jjohnstn(a)redhat.com>
> > > Sent: Wednesday, 28 September, 2016 8:23:47 PM
> > > Subject: Re: Do we still need Xulrunner in Devstudio?
> > >
> > > Basically, jsf tags can not be displayed as-is and be parsed correctly
> in
> > > browser like html, due to the fact that it is server side technology.
> So,
> > > the algorithm for VPE is the following: the content is rendered and
> all
> > > jsf tags are parsed through a set of templates via the native DOM API
> which
> > > is available only in particular older versions of XULRunner. So, in
> order
> > > to use Webkit or other engine and migrate all VPE features,
> reimplementing
> > > all of those temlpate transformations is required. Plus not to forget
> the
> > > performance thing - processing might take a long time (I think we had
> some
> > > WebKit POC but performance was just unacceptable). This is not a
> trivial
> > > task at all and I do believe that we have no resources for doing it -
> VPE
> > > component's code base is one of the biggest (if not the biggest) across
> > > tools.
> >
> > That's exactly the kind of info I was looking for. Can you point me to
> the
> > transformations used for the xulrunner? Sorry for being lazy but it's
> > foreing land for me so I would rather not lose time lurking around.
> > Do you have a pointer to the WebKit POC? It might be interested to reach
> out
> > to the desktop team (there is webkit developer there) with all the info
> so
> > maybe they can hint us how to achieve what's needed if latest webkit
> doesn't
> > fullfill the needs.
> >
> > > In a nutshell - after reimplementing there will be the same, or less
> > > powerful, VPE with more bugs and poor performance.
> >
> > That might be true now but you should think a bit further in time. In
> the not
> > so distant future (2018 release most probably, if not 2019 for sure) SWT
> > itself will drop support for running on GTK 2.x and that would be
> > effectively the end of this plugin if no action taken.
> >
> >
> > >
> > > On Wed, Sep 28, 2016 at 6:42 PM, Aleksandar Kurtakov <
> akurtako(a)redhat.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Ilya Buziuk" <ibuziuk(a)redhat.com>
> > > > > To: "Nick Boldt" <nboldt(a)redhat.com>
> > > > > Cc: "Aleksandar Kurtakov" <akurtako(a)redhat.com>, "Leo Ufimtsev" <
> > > > lufimtse(a)redhat.com>, "Jeff Johnston"
> > > > > <jjohnstn(a)redhat.com>
> > > > > Sent: Wednesday, 28 September, 2016 7:19:24 PM
> > > > > Subject: Re: Do we still need Xulrunner in Devstudio?
> > > > >
> > > > > Actually, we planned to remove xulrunner and deprecate VPE some
> time
> > > > > ago
> > > > > and leave only VPV as a WYSIWYG html editor.
> > > > As someone not familiar with the topic I don't see xulrunner and VPE
> > > > deprecation that closely coupled. What is the reason for that? What's
> > > > preventing to achieve it with webkit? Do you extend SWT Browser API
> > > > somehow?
> > > > Please give all the details you can think of so I can get better
> > > > understanding of the issue/reasons.
> > > >
> > > > > However, as soon as we gave a
> > > > > shout out about this on tools.jboss.org the first comment was:
> > > > >
> > > > > Nice. The reason I used JBoss Tools was the Visual Editor for JSF,
> > > > > > especially for the Visual parts, which was not perfect but was
> good
> > > > enough
> > > > > > to have it. Will you have alternatives for that ? [1]
> > > > >
> > > > >
> > > > > It was decided that we need to slow down with this process. I can
> not
> > > > > say
> > > > > if it is a high time for doing this assuming that some people
> actually
> > > > use
> > > > > it. Furthermore, some people treat it as a killer feature for JSF
> that
> > > > only
> > > > > one IDE is providing. So, we need to think twice before doing it.
> > > > >
> > > > > [1] http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA-
> > > > for-luna.html
> > > > >
> > > > > On Wed, Sep 28, 2016 at 5:40 PM, Nick Boldt <nboldt(a)redhat.com>
> wrote:
> > > > >
> > > > > > On the Eclipse team call today, the question of why we need
> Xulrunner
> > > > > > was brought up again.
> > > > > >
> > > > > > As I understand it, the only reason we still include Xulrunner
> is for
> > > > > > the Visual Page Editor. But Alex pointed out today that Xulrunner
> > > > > > only
> > > > > > works on GTK2, which means a user has to explicity disable GTK3
> in
> > > > > > order for Xulrunner to be used, as these days GTK3 is the default
> > > > > > OOTB
> > > > > > implementation on the platforms we support (Fedora 24/25, RHEL7,
> > > > > > etc.).
> > > > > >
> > > > > > So... is it time to remove Xulrunner from the Devstudio
> dependencies,
> > > > > > if most people are not even seeing it used?
> > > > > >
> > > > > > Alex suggested it might be useful to set up a call to discuss
> this in
> > > > > > more depth. Is there a good time tomorrow or Friday you guys
> would
> > > > > > like to meet to discuss this, if it can't be resolved
> asynchronously
> > > > > > via email?
> > > > > >
> > > > > > Whatever we decide here, we should make sure we announce this on
> the
> > > > > > jbosstools-dev@ list.
> > > > > >
> > > > > > --
> > > > > > Nick Boldt :: JBoss by Red Hat
> > > > > > Productization Lead :: JBoss Tools & Dev Studio
> > > > > > http://nick.divbyzero.com
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Alexander Kurtakov
> > > > Red Hat Eclipse team
> > > >
> > >
> >
> > --
> > Alexander Kurtakov
> > Red Hat Eclipse team
> >
>
> --
> Alexander Kurtakov
> Red Hat Eclipse team
>
8 years, 2 months
Re: [jbosstools-dev] Do we still need Xulrunner in Devstudio?
by Nick Boldt
Just to be clear... Is the feedback coming from CUSTOMERS or from
community? If the latter, then maybe we can remove it since we don't
necessarily derive customer value from it.
(I realize community is important, but maybe we need to get them to step up
and contribute to a performant WebKit version?)
On Sep 28, 2016 1:24 PM, "Alexey Kazakov" <alkazako(a)redhat.com> wrote:
Adding jbosstools-dev
Yes, Ilya is correct. We tried to remove VPE and Xulrunner but got
immediate feedback from users that it's an important feature. Does having
VPE/Xulrunner in devstudio causes any problem? If so please speak up.
Otherwise we are planing to continue to include VPE and Xulrunner in
JBossTools/devstudio.
Thanks.
On 09/28/2016 09:22 AM, Ilya Buziuk wrote:
CC: Max Andersen & Alexey Kazakov
On Wed, Sep 28, 2016 at 6:19 PM, Ilya Buziuk <ibuziuk(a)redhat.com> wrote:
> Actually, we planned to remove xulrunner and deprecate VPE some time ago
> and leave only VPV as a WYSIWYG html editor. However, as soon as we gave a
> shout out about this on tools.jboss.org the first comment was:
>
> Nice. The reason I used JBoss Tools was the Visual Editor for JSF,
>> especially for the Visual parts, which was not perfect but was good enough
>> to have it. Will you have alternatives for that ? [1]
>
>
> It was decided that we need to slow down with this process. I can not say
> if it is a high time for doing this assuming that some people actually use
> it. Furthermore, some people treat it as a killer feature for JSF that only
> one IDE is providing. So, we need to think twice before doing it.
>
> [1] http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.
> GA-for-luna.html
>
> On Wed, Sep 28, 2016 at 5:40 PM, Nick Boldt <nboldt(a)redhat.com> wrote:
>
>> On the Eclipse team call today, the question of why we need Xulrunner
>> was brought up again.
>>
>> As I understand it, the only reason we still include Xulrunner is for
>> the Visual Page Editor. But Alex pointed out today that Xulrunner only
>> works on GTK2, which means a user has to explicity disable GTK3 in
>> order for Xulrunner to be used, as these days GTK3 is the default OOTB
>> implementation on the platforms we support (Fedora 24/25, RHEL7,
>> etc.).
>>
>> So... is it time to remove Xulrunner from the Devstudio dependencies,
>> if most people are not even seeing it used?
>>
>> Alex suggested it might be useful to set up a call to discuss this in
>> more depth. Is there a good time tomorrow or Friday you guys would
>> like to meet to discuss this, if it can't be resolved asynchronously
>> via email?
>>
>> Whatever we decide here, we should make sure we announce this on the
>> jbosstools-dev@ list.
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>>
>
>
8 years, 2 months
Re: [jbosstools-dev] Do we still need Xulrunner in Devstudio?
by Alexey Kazakov
Adding jbosstools-dev
Yes, Ilya is correct. We tried to remove VPE and Xulrunner but got
immediate feedback from users that it's an important feature. Does
having VPE/Xulrunner in devstudio causes any problem? If so please speak
up. Otherwise we are planing to continue to include VPE and Xulrunner in
JBossTools/devstudio.
Thanks.
On 09/28/2016 09:22 AM, Ilya Buziuk wrote:
> CC: Max Andersen & Alexey Kazakov
>
> On Wed, Sep 28, 2016 at 6:19 PM, Ilya Buziuk <ibuziuk(a)redhat.com
> <mailto:ibuziuk@redhat.com>> wrote:
>
> Actually, we planned to remove xulrunner and deprecate VPE some
> time ago and leave only VPV as a WYSIWYG html editor. However, as
> soon as we gave a shout out about this on tools.jboss.org
> <http://tools.jboss.org> the first comment was:
>
> Nice. The reason I used JBoss Tools was the Visual Editor for
> JSF, especially for the Visual parts, which was not perfect
> but was good enough to have it. Will you have alternatives for
> that ? [1]
>
>
> It was decided that we need to slow down with this process. I can
> not say if it is a high time for doing this assuming that some
> people actually use it. Furthermore, some people treat it as a
> killer feature for JSF that only one IDE is providing. So, we need
> to think twice before doing it.
>
> [1]
> http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA-for-luna.html
> <http://tools.jboss.org/blog/2015-04-02-devstudio-8.1.0.GA-for-luna.html>
>
> On Wed, Sep 28, 2016 at 5:40 PM, Nick Boldt <nboldt(a)redhat.com
> <mailto:nboldt@redhat.com>> wrote:
>
> On the Eclipse team call today, the question of why we need
> Xulrunner
> was brought up again.
>
> As I understand it, the only reason we still include Xulrunner
> is for
> the Visual Page Editor. But Alex pointed out today that
> Xulrunner only
> works on GTK2, which means a user has to explicity disable GTK3 in
> order for Xulrunner to be used, as these days GTK3 is the
> default OOTB
> implementation on the platforms we support (Fedora 24/25, RHEL7,
> etc.).
>
> So... is it time to remove Xulrunner from the Devstudio
> dependencies,
> if most people are not even seeing it used?
>
> Alex suggested it might be useful to set up a call to discuss
> this in
> more depth. Is there a good time tomorrow or Friday you guys would
> like to meet to discuss this, if it can't be resolved
> asynchronously
> via email?
>
> Whatever we decide here, we should make sure we announce this
> on the
> jbosstools-dev@ list.
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
>
>
>
8 years, 2 months
Re: [jbosstools-dev] Proposed 4.61.0.AM1-SNAPSHOT target platform change(s): Update to latest upstream Neon.1 version(s)
by Nick Boldt
As there have been no objections, I've updated the 4.42.AM1-SNAPSHOT
parent pom to start building with the new 4.61.0.AM1-SNAPSHOT target
platform.
See https://issues.jboss.org/browse/JBIDE-22581 for details. If you
encounter any problems please open a new JIRA and link it from
JBIDE-22581 so I can track it.
Note too that I've moved some TP update process-related issues to a
new Epic, https://issues.jboss.org/browse/JBIDE-23272.
On Fri, Sep 23, 2016 at 1:25 PM, Hudson <hudson(a)redhat.com> wrote:
> Here is a proposal for change(s) to the JBoss Tools / Red Hat JBoss Developer Studio / Red Hat Central target platforms.
>
> Affected Versions:
>
> jbosstools 4.4.2.AM2-SNAPSHOT
> devstudio 10.2.0.AM2-SNAPSHOT
>
> jbt/ds TPs 4.61.0.AM1-SNAPSHOT
> central TPs 4.61.0.AM1-SNAPSHOT
>
> Detail / Summary:
>
> Update to latest upstream Neon.1 version(s)
>
> Related JIRA(s):
>
> https://issues.jboss.org/browse/JBIDE-22581
>
> Pull Request(s):
>
> https://github.com/jbosstools/jbosstools-target-platforms/commit/6ee094a4...
> https://github.com/jbosstools/jbosstools-target-platforms/commit/febd6ea4...
> https://github.com/jbosstools/jbosstools-target-platforms/commit/22ed4b3f...
> https://github.com/jbosstools/jbosstools-discovery/pull/336
>
> p2diff Report(s):
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
>
> ----------
>
> Please review the above changes, as they will be applied as soon as possible -
> usually within 48 hours for big changes, or 2 hours for simple version bumps.
>
> You can use the following to build & test the target platforms locally against
> your component(s).
>
> Build target-platform:
>
> cd /path/to/jbosstools-target-platforms
> git fetch origin pull/<pull-request-number>/head && git checkout FETCH_HEAD
> # or, using hub for git
> git checkout <pull-request-URL>
>
> mvn clean install -f jbosstools/multiple/pom.xml
>
> Then, to test the new multiple target platform against your component's build:
>
> cd /path/to/your/jbosstools-component
>
> mvn clean verify -Dtpc.version=4.61.0.AM1-SNAPSHOT -Dtpc.targetKind=multiple
>
> For Central, fetch sources from jbosstools-discovery, then build as above.
>
> ----------
> Here is a proposal for change(s) to the JBoss Tools / Red Hat JBoss Developer Studio / Red Hat Central target platforms.
>
> Affected Versions:
>
> jbosstools 4.4.2.AM2-SNAPSHOT
> devstudio 10.2.0.AM2-SNAPSHOT
>
> jbt/ds TPs 4.61.0.AM1-SNAPSHOT
> central TPs 4.61.0.AM1-SNAPSHOT
>
> Detail / Summary:
>
> Update to latest upstream Neon.1 version(s)
>
> Related JIRA(s):
>
> https://issues.jboss.org/browse/JBIDE-22581
>
> Pull Request(s):
>
> https://github.com/jbosstools/jbosstools-target-platforms/commit/6ee094a4...
> https://github.com/jbosstools/jbosstools-target-platforms/commit/febd6ea4...
> https://github.com/jbosstools/jbosstools-target-platforms/commit/22ed4b3f...
> https://github.com/jbosstools/jbosstools-discovery/pull/336
>
> p2diff Report(s):
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt...
>
> ----------
>
> Please review the above changes, as they will be applied as soon as possible -
> usually within 48 hours for big changes, or 2 hours for simple version bumps.
>
> You can use the following to build & test the target platforms locally against
> your component(s).
>
> Build target-platform:
>
> cd /path/to/jbosstools-target-platforms
> git fetch origin pull/<pull-request-number>/head && git checkout FETCH_HEAD
> # or, using hub for git
> git checkout <pull-request-URL>
>
> mvn clean install -f jbosstools/multiple/pom.xml
>
> Then, to test the new multiple target platform against your component's build:
>
> cd /path/to/your/jbosstools-component
>
> mvn clean verify -Dtpc.version=4.61.0.AM1-SNAPSHOT -Dtpc.targetKind=multiple
>
> For Central, fetch sources from jbosstools-discovery, then build as above.
>
> ----------
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
8 years, 2 months
