This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 674114 - Review Request: rhino-appjet - JavaScript for Java as modified by Appjet
Review Request: rhino-appjet - JavaScript for Java as modified by Appjet
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW 674115
  Show dependency treegraph
 
Reported: 2011-01-31 12:19 EST by Sebastian Dziallas
Modified: 2012-09-17 13:12 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-12 15:11:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Sebastian Dziallas 2011-01-31 12:19:15 EST
Spec URL: http://sdz.fedorapeople.org/rpmbuild/rhino-appjet.spec
SRPM URL: http://sdz.fedorapeople.org/rpmbuild/rhino-appjet-1.7-0.1.R1.fc14.src.rpm
Description: Package is required for Etherpad!
Comment 1 Alexander Kurtakov 2011-02-01 03:28:21 EST
I propose contacting rhino maintainer(me) and working together to get this both upstream and in our package. Having same source with one additional patch as additional package is not the way we are supposed to work.
This means that you will have to update your patch for 1.7R2 of course.
Comment 2 Alexander Kurtakov 2011-02-01 03:30:58 EST
Actually I'll take this one to be sure that we will work it out.
Comment 3 Alexander Kurtakov 2011-03-28 12:12:25 EDT
Any progress ?
If not I'll close this review in 2 weeks.
Comment 4 Sebastian Dziallas 2011-04-09 13:46:39 EDT
I'm trying to figure out how to proceed here. Appjet is its own framework and I'm leaning to argue that it needs its own package. It was part of the initial etherpad package and I'm not sure whether the patch (or porting it) will affect other rhino apps. Can you maybe have a look at the patch?
Comment 5 Alexander Kurtakov 2011-04-11 09:17:38 EDT
Well, if you give me some unresolvable reasons why appjet requires its own framework you might convince me. But I don't see any reason to not move to latest rhino even if the patches are unavoidable.
Comment 6 Sebastian Dziallas 2011-04-17 22:52:03 EDT
Well, so the thing is that yuicompressor breaks significantly if anything other than rhino 1.7 R1 is being used. And appjet apparently needs it's own versions of rhino and yuicompressor, which is why this looks like a butchered version of a rhino 1.7 R1 compat package.

Now I just found [1] which might be a way around all this but didn't exist at the time when I filed the review. I'm not sure whether this would work with the appjet changes, though.

[1] https://github.com/tml/yuicompressor-js170
Comment 7 Mat Booth 2011-04-25 07:24:11 EDT
(In reply to comment #6)
> [1] https://github.com/tml/yuicompressor-js170

This link 404s for me.
Comment 8 Sebastian Dziallas 2011-04-25 12:49:04 EDT
That is very true. Sorry. The developer apparently changed the repository name. Here it is now: https://github.com/tml/yuicompressor

Mat, do you think this might be useful?
Comment 9 Sebastian Dziallas 2011-07-11 17:41:37 EDT
(In reply to comment #5)
> Well, if you give me some unresolvable reasons why appjet requires its own
> framework you might convince me. But I don't see any reason to not move to
> latest rhino even if the patches are unavoidable.

Sorry for taking so long to get back to this. So, let me try pitching it this way:

Etherpad's Appjet requires both a modified version of yuicompressor (and hence rhino). I'm not comfortable arguing that these patches won't affect anybody else using rhino -- simply because I don't know. I have tried compiling etherpad against upstream versions of rhino and yuicompressor, but it throws errors during the compilation.

I feel that it'd be fair to argue that in this case patched compat packages for both rhino and yuicompressor could be doable.

Did I convice you? :)
Comment 10 Sebastian Dziallas 2011-07-11 17:48:13 EDT
(In reply to comment #9)
> (In reply to comment #5)
> > Well, if you give me some unresolvable reasons why appjet requires its own
> > framework you might convince me. But I don't see any reason to not move to
> > latest rhino even if the patches are unavoidable.
> 
> Sorry for taking so long to get back to this. So, let me try pitching it this
> way:
> 
> Etherpad's Appjet requires both a modified version of yuicompressor (and hence
> rhino). I'm not comfortable arguing that these patches won't affect anybody
> else using rhino -- simply because I don't know. I have tried compiling
> etherpad against upstream versions of rhino and yuicompressor, but it throws
> errors during the compilation.
> 
> I feel that it'd be fair to argue that in this case patched compat packages for
> both rhino and yuicompressor could be doable.
> 
> Did I convice you? :)

And before I forget, upstream has been notified awhile ago, so there'd be tracking of the situation: https://github.com/ether/pad/issues/173
Comment 11 Alexander Kurtakov 2011-11-01 12:19:20 EDT
I give up on this one - I see no hope for proper resolution of the issue.
Comment 12 Mario Blättermann 2012-09-12 15:11:48 EDT
(In reply to comment #11)
> I give up on this one - I see no hope for proper resolution of the issue.

OK, after one more year I close this review request, adding it to FE-DEADREVIEW.

Note You need to log in before you can comment on or make changes to this bug.