Bug 674114

Summary: Review Request: rhino-appjet - JavaScript for Java as modified by Appjet
Product: [Fedora] Fedora Reporter: Sebastian Dziallas <sebastian>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, mario.blaettermann, notting
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 201449, 674115    

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.