Just created an ebuild for the latest version of jabref. JabRef now requires glazedlists 1.5, so I updated that ebuild, too. Pretty straightforward.
Created attachment 79203 [details, diff] diff from glazedlists-0.9.6.ebuild
Created attachment 79204 [details, diff] diff from jabref-1.8.1.ebuild
Created attachment 79205 [details, diff] jabref/files patch
Created attachment 79206 [details, diff] jabref/files patch
*** Bug 120998 has been marked as a duplicate of this bug. ***
I installed glazedlist using your patch, and afterwards tried to install Jabref but it is failing. [mkdir] Created dir: /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/build/classes [javac] Compiling 358 source files to /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/build/classes [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/SearchManager2.java:41: package ca.odell.glazedlists.matchers does not exist [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/SearchManager2.java:42: package ca.odell.glazedlists does not exist [javac] import ca.odell.glazedlists.EventList; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/BasePanel.java:56: package ca.odell.glazedlists does not exist [javac] import ca.odell.glazedlists.FilterList; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/BasePanel.java:57: package ca.odell.glazedlists.matchers does not exist [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/BasePanel.java:58: package ca.odell.glazedlists.event does not exist [javac] import ca.odell.glazedlists.event.ListEventListener; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/BasePanel.java:59: package ca.odell.glazedlists.event does not exist [javac] import ca.odell.glazedlists.event.ListEvent;
oops, it works fine. Forgot to use your updated jabref patch. works fine now. Thanks
The ebuilds work fine for me too (x86 system)
*** Bug 123045 has been marked as a duplicate of this bug. ***
It works well for me on ~x86, even after the 1.8.1 ebuild was failing.
Worked seemlessly with my ~amd64. I had to add the keyword to the glazedlists ebuild.
Yet another 'works for me' here (x86).
Can we have this in portage ?
(In reply to comment #13) Can we have the binary for this??? non java coding people wouldn't love the idea of installing the while jdk for this one package. So if some1 can just share the binary package for this it'd be great.
(In reply to comment #14) > (In reply to comment #13) > > > Can we have the binary for this??? non java coding people wouldn't love the > idea of installing the while jdk for this one package. > > So if some1 can just share the binary package for this it'd be great. > well seems like the 3.6 mb .jar is available on the site :) sorry for the useless mail ;)
Glazedlists updated fine, but I'm seeing the same trouble as comment #6. I have patched the jabref ebuild, but I'm not sure I understand what you did wrong Ranjil (or rather, how you fixed it). BTW - ver 2.1 came out a few days ago, if anyone is feeling keen ;-) compile: [javac] Compiling 358 source files to /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/build/classes [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/SearchManager2.java:41: cannot resolve symbol [javac] symbol : class Matcher [javac] location: package matchers [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/BasePanel.java:57: cannot resolve symbol [javac] symbol : class Matcher [javac] location: package matchers [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/gui/MainTable.java:16: cannot resolve symbol [javac] symbol : class Matcher [javac] location: package matchers [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/search/SearchMatcher.java:7: cannot resolve symbol [javac] symbol : class Matcher [javac] location: package matchers [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/search/SearchMatcher.java:13: cannot resolve symbol [javac] symbol : class Matcher [javac] location: class net.sf.jabref.search.SearchMatcher [javac] public class SearchMatcher implements Matcher { [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/BasePanel.java:2321: cannot resolve symbol [javac] symbol : class Matcher [javac] location: class net.sf.jabref.BasePanel [javac] public void setGroupMatcher(Matcher matcher) { [javac] ^ [javac] /var/tmp/portage/jabref-2.0.1/work/jabref-2.0.1/src/java/net/sf/jabref/gui/MainTableFormat.java:6: cannot resolve symbol [javac] symbol : class Matcher [javac] location: package matchers [javac] import ca.odell.glazedlists.matchers.Matcher; [javac] ^ ...etc...
This appears to be a tad obsolete already. 2.1 has been released earlier this month. Meanwhile, the stable version in portage is 1.7.1 (released April 11th, 2005).
Created attachment 95238 [details] jabref-2.1.ebuild Updated to the new Java system. Contains one packaged jar for microba (http://sourceforge.net/projects/microba/) as this is not currently in the portage tree.
Created attachment 95239 [details, diff] jabref-2.1-fix_jarbundler.patch revised copy of the patch that was proposed for 2.0.1 to fix a jarbundler bug
Created attachment 95240 [details, diff] jabref-2.1-classpath_cleanup.patch revised copy of the classpath cleanup patch from the 2.0.1 version
Created attachment 95241 [details] glazedlists-1.5.0.ebuild glazedlists-1.5.0.ebuild to save people putting the diff down on the old version of the ebuild
Thanks for updating the ebuilds. However, these require ~x86 packages, is it possible to make them for stable tree?
(In reply to comment #22) > Thanks for updating the ebuilds. However, these require ~x86 packages, is it > possible to make them for stable tree? > In the case of jgoodies-looks, I am pretty sure the answer would be no. The distributed jar was from version 2.0 so that was what I matched it up to. I would suggest that someone does some testing to push 2.0* up out of unstable. The other one which is unstable would be glazedlists, which I have personally been using with the 2.0.1 version of jabref since this bug was first put down and have had no problems with it on my ~x86 system. So my vote is to put glazedlists 1.5.0 in as stable.
Created attachment 98358 [details] jabref-2.1.ebuild -jikes USE flag removed (not needed with new system) and all its occurences, compiler switching is done by other means (and Jabref works with "ecj jikes javac", tested all of them -changed virtual dependencies -removed junit as dependency
Created attachment 98359 [details] glazedlists-1.5.0.ebuild -Switched to java-ant-2.eclass (using eant allows compiler switching) -removed jikes USE flag
I ported the ebuild to the new Java system completely (compiler switching is now allowed) and fixed the dependencies which lead to a broken build when combined with the new system. I hope everything is corrected and would like to see this go into java experimental overlay. I dropped all keywords except ~x86, as glazedlists only has ~x86. glazedlists exists in version 1.7.0 now, but there are problems: It downloads additional components from its homepage during compilation and I can download them beforehand but they are ignored by the build system. As I don't know much about how building with Java packages works, I was not able to prevent glazedlists from downloading. 1.5 does the same for one additional package which is a swt extension unfortunately, which should be handled by an USE flag. To at least have a working ebuild for some. Enjoy.
Comment on attachment 98359 [details] glazedlists-1.5.0.ebuild glazedlists-1.5.0 now in overlay at https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/glazedlists I've tweaked the ebuild for style (you can see how) and disabled autodownloading and swt dependency for now. Also changed slot to 1.5 which means you will have to change your jarfrom call in jabref to glazedlists-1.5
Created attachment 98740 [details] microba-0.4.2.ebuild
Created attachment 98741 [details] jabref-2.1.ebuild Proper microba dependency (use separate ebuild)
Comment on attachment 98740 [details] microba-0.4.2.ebuild Slightly modified ebuild is now in http://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/microba/
Please don't keyword InOverlay until it's all there. Next time it would be better to file separate bug for each dependency and use bug depends/block to indicate dependencies.
Created attachment 98759 [details] updated ebuild Updated ebuild. Now deletes bundles dependencies and calls jar-from in proper directory (lib). Unfortunately, that has revealed following: [javac] 1. ERROR in /var/tmp/portage/jabref-2.1/work/jabref-2.1/src/java/net/sf/jabref/gui/date/DatePickerButton.java [javac] (at line 56) [javac] datePicker.showButtonOnly( true ) ; datePicker comes from microba (com.michaelbaranov.microba.calendar.DatePicker) but it seems no microba version ever provided showButtonOnly() method. After some fun with japitools, it looks to me that the bundled microba.jar is based on 0.4.1, but added this showButtonOnly() method. I'm starting to believe that this method was added by jabref people and exists only in their bundled jar, without providing source for this change. Not expert on licenses, but doesn't that violate microba's (BSD) license? Anyone care to ask jabref upstream about this?
Created attachment 99361 [details] microba-0.4.3.ebuild Working microba ebuild, needs jgraph-5.9.2.0 added to the tree. The more it needs a little rework: I insert jgraph.jar very dirty because normal Java eclass functions did not work. So, maybe Caster can have a look at the build system. Jabref emerges fine with that, unfortunately it dies with an exception (no X needed for that): Exception in thread "main" java.lang.NoClassDefFoundError: com/jgoodies/looks/plastic/theme/SkyBluer Oh man, this seems to be a neverending story. A quick glance at the bug tracker of Jabref did not find anything related.
microba and Jabref upstream were very helpful to resolve compilation problems and version 0.4.3 of microba has the changes we need. Unfortunately it needs a newer version of jgraph, see bug #129638
New jgraph is now in tree and microba in overlay. java-pkg_jar-from didn't work for you because you weren't running it inside lib-compiletime directory.
Jabref ebuild is now in https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/ . (In reply to comment #33) > Jabref emerges fine with that, unfortunately it dies with an exception (no X > needed for that): > Exception in thread "main" java.lang.NoClassDefFoundError: > com/jgoodies/looks/plastic/theme/SkyBluer Works fine here. Maybe you have some problems with jgoodies-looks installation. What version do you have installed? When you execute "GJL_DEBUG=1 jabref", can you see jgoodies-looks jar (should be /usr/share/jgoodies-looks-2.0/lib/looks.jar) on the classpath? Does the jar exist? Can you find com/jgoodies/looks/plastic/theme/SkyBluer.class inside the jar? Whats the output of "class-version-verify.py -t 1.4 /usr/share/jgoodies-looks-2.0/lib/looks.jar ?
(In reply to comment #36) > Jabref ebuild is now in > https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/ Excellent. Would you please correct the dependency to microba-0.4.3? > (In reply to comment #33) > > Jabref emerges fine with that, unfortunately it dies with an exception (no X > > needed for that): > > Exception in thread "main" java.lang.NoClassDefFoundError: > > com/jgoodies/looks/plastic/theme/SkyBluer > > Works fine here. Maybe you have some problems with jgoodies-looks installation. > What version do you have installed? 2.0.4 > When you execute "GJL_DEBUG=1 jabref", can > you see jgoodies-looks jar (should be > /usr/share/jgoodies-looks-2.0/lib/looks.jar) on the classpath? No. > Does the jar exist? Can you find com/jgoodies/looks/plastic/theme/SkyBluer.class inside the > jar? Yes on both. > Whats the output of "class-version-verify.py -t 1.4 > /usr/share/jgoodies-looks-2.0/lib/looks.jar ? CVV: 4 Checked: 247 Good: 247 Bad: 0 But: I could not emerge it with ibm-jdk (see bug #150970) and so used sun-jdk. Maybe it has to do with that?
(In reply to comment #37) > Excellent. Would you please correct the dependency to microba-0.4.3? Done. > > What version do you have installed? > > 2.0.4 Can you try 2.0.4-r1 from migrated overlay? (after you answer the next question still with 2.0.4). > > When you execute "GJL_DEBUG=1 jabref", can > > you see jgoodies-looks jar (should be > > /usr/share/jgoodies-looks-2.0/lib/looks.jar) on the classpath? > > No. What's the output of "GJL_DEBUG=1 jabref" then? How bout "java-config -dp jabref" ?
I miss you on IRC...did you change nick? (In reply to comment #38) > (In reply to comment #37) > > > What version do you have installed? > > 2.0.4 > Can you try 2.0.4-r1 from migrated overlay? (after you answer the next question > still with 2.0.4). -r1 also fails with ibm-jdk-bin It was a failure on my side...I installed jabref through the ebuild tool and did not take care of dependencies...glazedlists was missing. Thanks for your patience (and effort bringing this to Porage). Jabref now works here too
Just another report that current overlay works great for me.
Everything is now in portage tree, thanks everyone. I've decided to change glazedlists slot back to 0, because nothing depends on the 0.9 version so there's nothing that would break. Please remerge glazedlists and jabref if you have the overlay version to prevent any future breakage. Dropped ~amd64 and ~ppc because of microba and glazedlists, pending rekeywording in bug 153187.
