Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 674114 - Review Request: rhino-appjet - JavaScript for Java as modified by Appjet
Summary: Review Request: rhino-appjet - JavaScript for Java as modified by Appjet
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-DEADREVIEW 674115
TreeView+ depends on / blocked
 
Reported: 2011-01-31 17:19 UTC by Sebastian Dziallas
Modified: 2012-09-17 17:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-12 19:11:48 UTC


Attachments (Terms of Use)

Description Sebastian Dziallas 2011-01-31 17:19:15 UTC
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 08:28:21 UTC
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 08:30:58 UTC
Actually I'll take this one to be sure that we will work it out.

Comment 3 Alexander Kurtakov 2011-03-28 16:12:25 UTC
Any progress ?
If not I'll close this review in 2 weeks.

Comment 4 Sebastian Dziallas 2011-04-09 17:46:39 UTC
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 13:17:38 UTC
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-18 02:52:03 UTC
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 11:24:11 UTC
(In reply to comment #6)
> [1] https://github.com/tml/yuicompressor-js170

This link 404s for me.

Comment 8 Sebastian Dziallas 2011-04-25 16:49:04 UTC
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 21:41:37 UTC
(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 21:48:13 UTC
(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 16:19:20 UTC
I give up on this one - I see no hope for proper resolution of the issue.

Comment 12 Mario Blättermann 2012-09-12 19:11:48 UTC
(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.