From shiva at sewingwitch.com Sat Apr 1 01:19:48 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 31 Mar 2006 17:19:48 -0800 Subject: [fedora-java] Trying to follow JPackage installations per Paul Howath per FC4 for FC5 In-Reply-To: <1143838643.2865.117.camel@copper.cdkkt.com> References: <1143838643.2865.117.camel@copper.cdkkt.com> Message-ID: On Friday, March 31, 2006 12:57 PM -0800 Dan Thurman wrote: > I am trying to get a Java development environment setup and > I was directed to follow the FC4 jpackage instructions but > for FC5 and apparently the first thing required was to install > fedora-rpmdevtools from the extras repository but this file > is nowhere to be found! > > All I got for the list is: > > fedora-buildrpmtree Create RPM build tree within user's home > directory Looks like the package must have been renamed, since the next step in Paul's HOWTO is to run fedora-buildrpmtree to create the RPM packaging infrastructure for a non-root user. Maybe the renamed package should include a virtual Provides for the old name. From aph at redhat.com Sat Apr 1 09:46:17 2006 From: aph at redhat.com (Andrew Haley) Date: Sat, 1 Apr 2006 10:46:17 +0100 Subject: [fedora-java] Re: How to setup full-fledged Java development environment under FC5? In-Reply-To: References: <1143825776.2865.77.camel@copper.cdkkt.com> Message-ID: <17454.19433.416351.842636@zapata.pink> Ian Pilcher writes: > Dan Thurman wrote: > > Can anyone give me some pointers on how to get a serious > > Java development environment setup going? I want to have > > full flexibility to download and install Eclipse tools and > > applications without being unencumbered with Fedora's port > > version preventing such operations, for example if I need > > to get RCP, WSP, Swing, AWT, and the zillions of other things > > that are rapidly being released by the Eclipse community. > > It takes a little work, but it can be done. For a 100% "real" Java > environment, you'll first want to remove all the gcj-compiled packages > from your system. What for? They will still work. Install whatever runtime environment you want via an RPM from jpackage.org and use /usr/sbin/alternatives to switch to it. Andrew. From i.pilcher at comcast.net Sat Apr 1 16:29:08 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 01 Apr 2006 10:29:08 -0600 Subject: [fedora-java] Re: How to setup full-fledged Java development environment under FC5? In-Reply-To: <17454.19433.416351.842636@zapata.pink> References: <1143825776.2865.77.camel@copper.cdkkt.com> <17454.19433.416351.842636@zapata.pink> Message-ID: Andrew Haley wrote: > Ian Pilcher writes: > > > > It takes a little work, but it can be done. For a 100% "real" Java > > environment, you'll first want to remove all the gcj-compiled packages > > from your system. > > What for? They will still work. I think it's more accurate to say that they *should* work. The OP expressed some concern about this. > Install whatever runtime environment you want via an RPM from > jpackage.org and use /usr/sbin/alternatives to switch to it. I've done this on Fedora Core 5, and everything is working so far. Nice work! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From green at redhat.com Sun Apr 2 16:28:53 2006 From: green at redhat.com (Anthony Green) Date: Sun, 02 Apr 2006 09:28:53 -0700 Subject: [fedora-java] release note omission Message-ID: <1143995333.17730.9.camel@localhost.localdomain> Hi Karsten, The release notes for java used to have a link to a page giving step-by-step instructions on installing proprietary java implementations with the JPackage wrappers. I'm not sure when it went away, but it's a problem. You don't have to google very long to find lots of FC5 installation notes telling people to just go ahead and install Sun's java as-is. These notes are full of bad advice (like, telling people to disable key SELinux functionality). Can we add that reference back in? AG From jdf.lists at gmail.com Mon Apr 3 17:22:50 2006 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Mon, 3 Apr 2006 10:22:50 -0700 Subject: [fedora-java] Re: How to setup full-fledged Java development environment under FC5? In-Reply-To: References: <1143825776.2865.77.camel@copper.cdkkt.com> <17454.19433.416351.842636@zapata.pink> Message-ID: <67437bc40604031022o4da15066m7cecb3eaa8c46e10@mail.gmail.com> On 4/1/06, Ian Pilcher wrote: > Andrew Haley wrote: > > Ian Pilcher writes: > > > > > > It takes a little work, but it can be done. For a 100% "real" Java > > > environment, you'll first want to remove all the gcj-compiled packages > > > from your system. > > > > What for? They will still work. > > I think it's more accurate to say that they *should* work. The OP > expressed some concern about this. Depending on what you want to do with them, they do work. The rebuilt JAR files include all the normal java class files that Sun/IBM/BEA java need, but also the native stuff for gcj. See, for example: https://www.zarb.org/pipermail/jpackage-discuss/2005-October/008918.html So there is no need to remove gcj-compiled packages. > > Install whatever runtime environment you want via an RPM from > > jpackage.org and use /usr/sbin/alternatives to switch to it. This certainly works. What I currently recommend to devs using eclipse here is to download the latest eclipse and run it from their home directory (so if you might remove the gcj native ecplise so /usr/bin/eclipse doesn't confuse them, but that's optional). I recommend that because eclipse is still somewhat picky about where it finds things, and if (for example) a dev installs the WTP plugin, eclipse is going to download everything to their home directory anyway. In this sense the /usr/share/java/ jars don't "work" but that's not JPackage or Fedora's fault, it's an Eclipse platform decision. Someday it might get all smoothed out. From dant at cdkkt.com Mon Apr 3 18:41:23 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 03 Apr 2006 11:41:23 -0700 Subject: [fedora-java] Re: How to setup full-fledged Java development environment under FC5? In-Reply-To: <67437bc40604031022o4da15066m7cecb3eaa8c46e10@mail.gmail.com> References: <1143825776.2865.77.camel@copper.cdkkt.com> <17454.19433.416351.842636@zapata.pink> <67437bc40604031022o4da15066m7cecb3eaa8c46e10@mail.gmail.com> Message-ID: <1144089684.2887.42.camel@copper.cdkkt.com> Folks, I have pretty much downloaded just about everything I have needed to get back to the development level I wanted when I was using Eclipse under the windoes environment but I have encountered some strange situations so here it is... [ Note: I followed recommendations per Paul Howarth's JPackage installation guidelines so as not to blow apart the gcj (native) java port. ] Success: ======== 1) Installed SubEclipse successfully and it appears for all users. 2) Installed GEF and EMF successfully and it appears for all users. 3) Installed PhpEclipse successfully and it appears for all users. Unknown: ======== 1) Downloaded and installed JEM, but I was not able to determine if the package was installed successfully as it does not appear in the configuration list for "Manage Configurations". I do note however JEM (Java EMF Model) does appear listed in the 'About Eclipse' feature listings. I assume all is well but cannot confirm this. GEF, EMF, and JEM is required for WST. Problems: ========= 1) As any user (root and non-root), I am unable to uninstall any older plugins (or packages). I was trying to remove pyDev 0.9.3 because a newer version of pyDev 0.9.8.7 supersedes it and the 'uninstall' menu item refuses to appear for selection. I got this new update via the Help->Software Updates->Find and Install... Please note that the update for 'Change Logs' was a very weird one and it causes problems if you try to update this one. Someone should probably remove this unless it is really needed? 2) Downloaded and installed WTP 1.0.1 as root user (login) and it was installed into /usr/share/eclipse. When I brought up eclipse, I noticed that the JSEE (WTP) was not within the IDE, so I proceed to the Help->Software Updates->Manage Configurations, and enabled the 'Show disabled features', WTP appeared but was not enabled. Ok... then I enabled it, and closed Eclipse and brought it back up and added the J2EE perspective and all seems to be there. Haven't tried to see if J2EE works at this point. Now here is the weird part. I logged out as 'root' user from Gnome, logged in as myself, and started up Eclipse. This is a first-time eclipse start-up. Ok, proceeding, I wanted to add the J2EE perspective but it wasn't there. Hmm... ok, then I again selected Help->Software Updates-> Manage Configurations and this time I note the following is not enabled: 1) J2EE for standard tools (JST) SDK 1.0.1.v200602130105 2) SDK for Web Standard Tools (WST) 1.0.1.v200602130105 I tried to enable these plugins but now for (1), a message pops up: "The requested operation could not be performed because it will invalidate the configuration. See details for more information." Details: Requested operation cannot be performed because it would invalidate the current configuration. See details for more information. J2EE Standard Tools (JST) SDK (1.0.1.v200602130105) The site is not updateable: file:/usr/share/eclipse/. J2EE Standard Tools (JST) (1.0.1.v200602130105) requires feature "org.eclipse.wst". JST Common Feature (1.0.1.v200602151554) requires feature "org.eclipse.wst.common_core.feature (1.0.0)", or equivalent. JST Server Core Feature (1.0.1.v200602151554) requires feature "org.eclipse.wst.server_core.feature (1.0.0)", or equivalent. JST Web Core Feature (1.0.1.v200602151554) requires feature "org.eclipse.wst.web_core.feature (1.0.0)", or compatible. JST Enterprise Core Feature (1.0.1.v200602151554) requires feature "org.eclipse.wst.ws_core.feature (1.0.0)", or compatible. JST Enterprise UI Feature (1.0.1.v200602151554) requires feature "org.eclipse.wst.rdb_core.feature (1.0.0)", or equivalent. So - Eclipse refuses to allow me to enable these plugins. I went one step further: I added a eclipse user group, changed the group ownership to eclipse, and added group read-write-execute and the problem still remains. I am not able to continue any further on enabling J2EE. I cannot even uninstall it either. 3) The same/similar problem appears for these plugins: a) RMI plugins for Eclipse 1.6.5.4 Please let me know if there is anything I can do at this point. Kind regards, Dan From dant at cdkkt.com Mon Apr 3 20:07:58 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 03 Apr 2006 13:07:58 -0700 Subject: [fedora-java] [SOLVED] Re: How to setup full-fledged Java development environment under FC5? In-Reply-To: <1144089684.2887.42.camel@copper.cdkkt.com> References: <1143825776.2865.77.camel@copper.cdkkt.com> <17454.19433.416351.842636@zapata.pink> <67437bc40604031022o4da15066m7cecb3eaa8c46e10@mail.gmail.com> <1144089684.2887.42.camel@copper.cdkkt.com> Message-ID: <1144094878.2887.49.camel@copper.cdkkt.com> On Mon, 2006-04-03 at 11:41 -0700, Dan Thurman wrote: Sorry to top-post and to reply to my own reporting... I have resolved all the issues pointed out below. Turns out that I had to enable all of the aforementioned items in regards to completing the WST installation my starting eclipse in the root user account and enabling the (1), (2), and (3) items below, all the non-root users have access to these plugins. Also, I note that if there are any updates for Eclipse, if root user hadn't already updated all items, all users who attempt to update would get the update items installed into their own home .eclipse folders. Can be a pain in regards to code bloat... but I also figured out that blowing the user's .eclipse directories is not a problem assuming that no other user-installs were made outside of that of what root is updating. Other than that - so far it appears everything works well. As for the ChangeLog updates and for deleting older versions, I am still not able to do it even as a root user. Perhaps this is a minor issue but perhaps you can manually delete the items in question but this may tend to be error prone. Dan > Folks, > > I have pretty much downloaded just about everything I have > needed to get back to the development level I wanted when > I was using Eclipse under the windoes environment but I have > encountered some strange situations so here it is... > > [ > Note: I followed recommendations per Paul Howarth's JPackage > installation guidelines so as not to blow apart the > gcj (native) java port. > ] > > Success: > ======== > 1) Installed SubEclipse successfully and it appears for all users. > 2) Installed GEF and EMF successfully and it appears for all users. > 3) Installed PhpEclipse successfully and it appears for all users. > > Unknown: > ======== > 1) Downloaded and installed JEM, but I was not able to determine > if the package was installed successfully as it does not appear > in the configuration list for "Manage Configurations". I do note > however JEM (Java EMF Model) does appear listed in the 'About > Eclipse' feature listings. I assume all is well but cannot > confirm this. GEF, EMF, and JEM is required for WST. > > Problems: > ========= > 1) As any user (root and non-root), I am unable to uninstall > any older plugins (or packages). I was trying to remove > pyDev 0.9.3 because a newer version of pyDev 0.9.8.7 > supersedes it and the 'uninstall' menu item refuses to > appear for selection. I got this new update via the > Help->Software Updates->Find and Install... Please > note that the update for 'Change Logs' was a very weird > one and it causes problems if you try to update this one. > Someone should probably remove this unless it is really > needed? > > 2) Downloaded and installed WTP 1.0.1 as root user (login) > and it was installed into /usr/share/eclipse. When I > brought up eclipse, I noticed that the JSEE (WTP) was > not within the IDE, so I proceed to the Help->Software > Updates->Manage Configurations, and enabled the 'Show > disabled features', WTP appeared but was not enabled. > Ok... then I enabled it, and closed Eclipse and brought > it back up and added the J2EE perspective and all seems > to be there. Haven't tried to see if J2EE works at this > point. > > Now here is the weird part. I logged out as 'root' user > from Gnome, logged in as myself, and started up Eclipse. > This is a first-time eclipse start-up. Ok, proceeding, > I wanted to add the J2EE perspective but it wasn't there. > Hmm... ok, then I again selected Help->Software Updates-> > Manage Configurations and this time I note the following is > not enabled: > > 1) J2EE for standard tools (JST) SDK 1.0.1.v200602130105 > 2) SDK for Web Standard Tools (WST) 1.0.1.v200602130105 > > I tried to enable these plugins but now for (1), a message pops up: > > "The requested operation could not be performed because it will > invalidate the configuration. See details for more information." > > Details: > Requested operation cannot be performed because it would invalidate the > current configuration. See details for more information. > J2EE Standard Tools (JST) SDK (1.0.1.v200602130105) The site is not > updateable: file:/usr/share/eclipse/. > J2EE Standard Tools (JST) (1.0.1.v200602130105) requires feature > "org.eclipse.wst". > JST Common Feature (1.0.1.v200602151554) requires feature > "org.eclipse.wst.common_core.feature (1.0.0)", or equivalent. > JST Server Core Feature (1.0.1.v200602151554) requires feature > "org.eclipse.wst.server_core.feature (1.0.0)", or equivalent. > JST Web Core Feature (1.0.1.v200602151554) requires feature > "org.eclipse.wst.web_core.feature (1.0.0)", or compatible. > JST Enterprise Core Feature (1.0.1.v200602151554) requires feature > "org.eclipse.wst.ws_core.feature (1.0.0)", or compatible. > JST Enterprise UI Feature (1.0.1.v200602151554) requires feature > "org.eclipse.wst.rdb_core.feature (1.0.0)", or equivalent. > > So - Eclipse refuses to allow me to enable these plugins. I went > one step further: I added a eclipse user group, changed the group > ownership to eclipse, and added group read-write-execute and the > problem still remains. I am not able to continue any further on > enabling J2EE. I cannot even uninstall it either. > > 3) The same/similar problem appears for these plugins: > a) RMI plugins for Eclipse 1.6.5.4 > > > Please let me know if there is anything I can do at this point. > > Kind regards, > Dan > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-java-list From dant at cdkkt.com Mon Apr 3 20:53:23 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 03 Apr 2006 13:53:23 -0700 Subject: [fedora-java] Using JPackage Repo Message-ID: <1144097604.2887.61.camel@copper.cdkkt.com> Folks, I followed Paul Horwarth's instructions for installing JPackages and on has to do with installing JPackage's repo - of which you can download the jpackage.repo file into your /etc/yum.repo.d directory. Today, I tried to yum update and the jpackage repo is blowing up on me. Says that I am missing a geronimo-specs-* dependency but apparently it is installed but perhaps it is trying to install new geronimo-specs but cannot do so due to dependencies of other files on it! What do I do in this case? Also to note, that I have been using the [generic] repo version instead of the fedora core version since I could not get this repo to even work. Perhaps the repo does not exist. Anyway, I have disabled all jpackage repos until I can get a resolution to this issue. Kind regards, Dan From overholt at redhat.com Mon Apr 3 20:56:02 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 3 Apr 2006 16:56:02 -0400 Subject: [fedora-java] Using JPackage Repo In-Reply-To: <1144097604.2887.61.camel@copper.cdkkt.com> References: <1144097604.2887.61.camel@copper.cdkkt.com> Message-ID: <20060403205601.GK18954@redhat.com> * Dan Thurman [2006-04-03 16:53]: > > Today, I tried to yum update and the jpackage repo is blowing > up on me. Says that I am missing a geronimo-specs-* dependency > but apparently it is installed but perhaps it is trying to > install new geronimo-specs but cannot do so due to dependencies > of other files on it! > > What do I do in this case? Try jpackage-discuss at zarb.org or perhaps JPackage Bugzilla. Andrew From jdf.lists at gmail.com Tue Apr 4 21:52:42 2006 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Tue, 4 Apr 2006 14:52:42 -0700 Subject: [fedora-java] Using JPackage Repo In-Reply-To: <1144097604.2887.61.camel@copper.cdkkt.com> References: <1144097604.2887.61.camel@copper.cdkkt.com> Message-ID: <67437bc40604041452m734515f2l791de4036614af7a@mail.gmail.com> On 4/3/06, Dan Thurman wrote: > Also to note, that I have been using the [generic] repo version > instead of the fedora core version since I could not get this > repo to even work. Perhaps the repo does not exist. I haven't had this specific issue, but you need both the generic repo (which is for distribution-independent files) *and* the one for your distribution. From dant at cdkkt.com Tue Apr 4 22:27:34 2006 From: dant at cdkkt.com (Dan Thurman) Date: Tue, 04 Apr 2006 15:27:34 -0700 Subject: [fedora-java] Using JPackage Repo In-Reply-To: <67437bc40604041452m734515f2l791de4036614af7a@mail.gmail.com> References: <1144097604.2887.61.camel@copper.cdkkt.com> <67437bc40604041452m734515f2l791de4036614af7a@mail.gmail.com> Message-ID: <1144189654.2967.27.camel@copper.cdkkt.com> On Tue, 2006-04-04 at 14:52 -0700, Joshua Daniel Franklin wrote: > On 4/3/06, Dan Thurman wrote: > > Also to note, that I have been using the [generic] repo version > > instead of the fedora core version since I could not get this > > repo to even work. Perhaps the repo does not exist. > > I haven't had this specific issue, but you need both the generic > repo (which is for distribution-independent files) *and* the one > for your distribution. Well, I tried enabling the repo for Fedora and it says: ============================ jpackage-fc [3/6] Cannot find a valid baseurl for repo: jpackage-fc Error: Cannot find a valid baseurl for repo: jpackage-fc Here is the jpackage-fc spec: ============================ [jpackage-fc] name=JPackage (free) for Fedora Core $releasever mirrorlist=http://www.jpackage.org/jpackage_fedora-$releasever.txt failovermethod=priority gpgcheck=1 gpgkey=http://www.jpackage.org/jpackage.asc enabled=1 It does not work, so I disabled it again. Dan From dant at cdkkt.com Tue Apr 4 22:31:33 2006 From: dant at cdkkt.com (Dan Thurman) Date: Tue, 04 Apr 2006 15:31:33 -0700 Subject: [fedora-java] Using JPackage Repo In-Reply-To: <67437bc40604041452m734515f2l791de4036614af7a@mail.gmail.com> References: <1144097604.2887.61.camel@copper.cdkkt.com> <67437bc40604041452m734515f2l791de4036614af7a@mail.gmail.com> Message-ID: <1144189894.2967.29.camel@copper.cdkkt.com> On Tue, 2006-04-04 at 14:52 -0700, Joshua Daniel Franklin wrote: > On 4/3/06, Dan Thurman wrote: > > Also to note, that I have been using the [generic] repo version > > instead of the fedora core version since I could not get this > > repo to even work. Perhaps the repo does not exist. > > I haven't had this specific issue, but you need both the generic > repo (which is for distribution-independent files) *and* the one > for your distribution. I tried to run yum update but with jpackage-fc disabled, but generic enabled and I *still* get dependency problems. Here is the full log: [root at copper log]# yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories macromedia [1/5] core [2/5] updates [3/5] updates 100% |=========================| 951 B 00:00 jpackage-generic [4/5] jpackage-generic 100% |=========================| 951 B 00:00 extras [5/5] extras 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 94 kB 00:02 updates : ################################################## 314/314 Added 3 new packages, deleted 0 old in 1.67 seconds primary.xml.gz 100% |=========================| 351 kB 00:09 jpackage-g: ################################################## 1529/1529 Added 0 new packages, deleted 0 old in 4.56 seconds primary.xml.gz 100% |=========================| 879 kB 00:23 extras : ################################################## 2470/2470 Added 19 new packages, deleted 3 old in 11.59 seconds Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package xml-commons-apis-javadoc.noarch 0:1.3.02-2jpp set to be updated ---> Package cryptix.noarch 0:3.2.0-5jpp set to be updated ---> Downloading header for python-imaging to pack into transaction set. python-imaging-1.1.5-4.fc 100% |=========================| 32 kB 00:00 ---> Package python-imaging.i386 0:1.1.5-4.fc5 set to be updated ---> Package junit.noarch 0:3.8.1-4jpp set to be updated ---> Downloading header for azureus to pack into transaction set. azureus-2.4.0.3-0.2006032 100% |=========================| 10 kB 00:00 ---> Package azureus.i386 0:2.4.0.3-0.20060328cvs_3.fc5 set to be updated ---> Package xalan-j2-demo.noarch 0:2.7.0-1jpp set to be updated ---> Package cryptix-asn1-javadoc.noarch 0:20011119-5jpp set to be updated ---> Package jdom.noarch 0:1.0-2jpp set to be updated ---> Package avalon-framework-manual.noarch 0:4.1.5-1jpp set to be updated ---> Package xml-commons.noarch 0:1.3.02-2jpp set to be updated ---> Package adaptx.noarch 0:0.9.6-2jpp set to be updated ---> Package junit-demo.noarch 0:3.8.1-4jpp set to be updated ---> Package jdepend.noarch 0:2.6-3jpp set to be updated ---> Package jdepend-demo.noarch 0:2.6-3jpp set to be updated ---> Package antlr.noarch 0:2.7.6-1jpp set to be updated ---> Package classpathx-mail-javadoc.noarch 0:1.1-1jpp set to be updated ---> Package jlex-javadoc.noarch 0:1.2.6-2jpp set to be updated ---> Package castor-test.noarch 0:0.9.6-1jpp set to be updated ---> Package jsch.noarch 0:0.1.20-1jpp set to be updated ---> Package jakarta-commons-daemon.noarch 1:1.0.1-1jpp set to be updated ---> Package jzlib.noarch 0:1.0.7-1jpp set to be updated ---> Package bcel.noarch 0:5.1-5jpp set to be updated ---> Package oro.noarch 0:2.0.8-2jpp set to be updated ---> Package cryptix-javadoc.noarch 0:3.2.0-5jpp set to be updated ---> Package concurrent.noarch 0:1.3.4-1jpp set to be updated ---> Package concurrent-javadoc.noarch 0:1.3.4-1jpp set to be updated ---> Package bsf.noarch 0:2.3.0-8jpp set to be updated ---> Downloading header for logwatch to pack into transaction set. logwatch-7.2.1-1.fc5.noar 100% |=========================| 39 kB 00:01 ---> Package logwatch.noarch 0:7.2.1-1.fc5 set to be updated ---> Package xml-commons-apis.noarch 0:1.3.02-2jpp set to be updated ---> Package jlex.noarch 0:1.2.6-2jpp set to be updated ---> Package xml-commons-resolver-javadoc.noarch 0:1.1-3jpp set to be updated ---> Package xml-commons-which-javadoc.noarch 0:1.3.02-2jpp set to be updated ---> Package log4j-javadoc.noarch 0:1.2.12-1jpp set to be updated ---> Package xalan-j2-xsltc.noarch 0:2.7.0-1jpp set to be updated ---> Package castor-demo.noarch 0:0.9.5-2jpp set to be updated ---> Package java_cup-manual.noarch 1:0.10-0.k.2jpp set to be updated ---> Package avalon-framework-javadoc.noarch 0:4.1.5-1jpp set to be updated ---> Package cryptix-asn1.noarch 0:20011119-5jpp set to be updated ---> Package gnu.getopt.noarch 0:1.0.10-1jpp set to be updated ---> Package bsh.noarch 0:1.3.0-6jpp set to be updated ---> Package xalan-j2-javadoc.noarch 0:2.7.0-1jpp set to be updated ---> Package xml-commons-which.noarch 0:1.3.02-2jpp set to be updated ---> Package jakarta-commons-lang-javadoc.noarch 0:2.1-1jpp set to be updated ---> Package xml-commons-resolver.noarch 0:1.1-3jpp set to be updated ---> Package xalan-j2-manual.noarch 0:2.7.0-1jpp set to be updated ---> Package gnu.getopt-javadoc.noarch 0:1.0.10-1jpp set to be updated ---> Package castor-doc.noarch 0:0.9.6-1jpp set to be updated ---> Package jakarta-commons-lang.noarch 0:2.1-1jpp set to be updated ---> Package antlr-javadoc.noarch 0:2.7.6-1jpp set to be updated ---> Package log4j-manual.noarch 0:1.2.12-1jpp set to be updated ---> Package jdepend-javadoc.noarch 0:2.6-3jpp set to be updated ---> Package oro-javadoc.noarch 0:2.0.8-2jpp set to be updated ---> Package jakarta-commons-daemon-javadoc.noarch 1:1.0.1-1jpp set to be updated ---> Package lucene.noarch 0:1.4.3-2jpp set to be updated ---> Package geronimo-specs.noarch 0:1.0-0.M2.3jpp set to be updated ---> Package junit-javadoc.noarch 0:3.8.1-4jpp set to be updated ---> Package avalon-framework.noarch 0:4.1.5-1jpp set to be updated ---> Package java_cup-javadoc.noarch 1:0.10-0.k.2jpp set to be updated ---> Package junit-manual.noarch 0:3.8.1-4jpp set to be updated ---> Package log4j.noarch 0:1.2.12-1jpp set to be updated ---> Package classpathx-mail.noarch 0:1.1-1jpp set to be updated ---> Package bcel-javadoc.noarch 0:5.1-5jpp set to be updated ---> Package lucene-demo.noarch 0:1.4.3-2jpp set to be updated ---> Package java_cup.noarch 1:0.10-0.k.2jpp set to be updated ---> Downloading header for gthumb to pack into transaction set. gthumb-2.7.5.1-1.fc5.1.i3 100% |=========================| 35 kB 00:00 ---> Package gthumb.i386 0:2.7.5.1-1.fc5.1 set to be updated ---> Package antlr-manual.noarch 0:2.7.6-1jpp set to be updated ---> Package castor-javadoc.noarch 0:0.9.6-1jpp set to be updated ---> Package castor-xml.noarch 0:0.9.6-1jpp set to be updated ---> Package xalan-j2.noarch 0:2.7.0-1jpp set to be updated ---> Package castor.noarch 0:0.9.6-1jpp set to be updated ---> Package xml-commons-apis-manual.noarch 0:1.3.02-2jpp set to be updated ---> Package puretls-javadoc.noarch 0:0.9-0.b5.1jpp set to be updated --> Running transaction check --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat --> Processing Dependency: cglib for package: castor --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo --> Processing Dependency: servletapi3 for package: castor-demo --> Processing Dependency: jaxen for package: jdom --> Processing Dependency: xmlbeans for package: geronimo-specs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package jaxen.noarch 0:1.1-0.b7.1jpp set to be updated ---> Package xmlbeans.noarch 0:1.0.4-2jpp set to be updated ---> Package servletapi3.noarch 0:3.3.1-0.a.2jpp set to be updated ---> Package cglib.noarch 0:2.1.3-1jpp set to be updated --> Running transaction check --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat --> Processing Dependency: xom for package: jaxen --> Processing Dependency: aspectwerkz >= 0:1.0 for package: cglib --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo --> Processing Dependency: asm >= 0:1.5.3 for package: cglib --> Processing Dependency: dom4j >= 0:1.6.1 for package: jaxen --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package asm.noarch 0:1.5.3-1jpp set to be updated ---> Package xom.noarch 0:1.0-1jpp set to be updated ---> Package aspectwerkz.noarch 0:2.0-1jpp set to be updated ---> Package dom4j.noarch 0:1.6.1-1jpp set to be updated --> Running transaction check --> Processing Dependency: icu4j for package: xom --> Processing Dependency: stax-bea for package: dom4j --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat --> Processing Dependency: javassist for package: aspectwerkz --> Processing Dependency: qdox for package: aspectwerkz --> Processing Dependency: msv-xsdlib for package: dom4j --> Processing Dependency: relaxngDatatype for package: dom4j --> Processing Dependency: xpp2 for package: dom4j --> Processing Dependency: gnu.trove for package: aspectwerkz --> Processing Dependency: isorelax for package: dom4j --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo --> Processing Dependency: piccolo for package: aspectwerkz --> Processing Dependency: jrexx for package: aspectwerkz --> Processing Dependency: msv-msv for package: dom4j --> Processing Dependency: ws-jaxme for package: dom4j --> Processing Dependency: xpp3 for package: dom4j --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package qdox.noarch 0:1.5-1jpp set to be updated ---> Package javassist.noarch 0:3.0-1jpp set to be updated ---> Package xpp3.noarch 0:1.1.3.4-1.o.1jpp set to be updated ---> Package xpp2.noarch 0:2.1.10-5jpp set to be updated ---> Package gnu.trove.noarch 0:1.0.2-3jpp set to be updated ---> Package msv-xsdlib.noarch 0:1.2-0.20050722.1jpp set to be updated ---> Package ws-jaxme.noarch 0:0.5-1jpp set to be updated ---> Package jrexx.noarch 0:1.1.1-2jpp set to be updated ---> Package msv-msv.noarch 0:1.2-0.20050722.1jpp set to be updated ---> Package piccolo.noarch 0:1.04-1jpp set to be updated ---> Package relaxngDatatype.noarch 0:1.0-2jpp set to be updated ---> Package icu4j.noarch 0:3.2-1jpp set to be updated ---> Package isorelax.noarch 0:0.1-0.20041111.1jpp set to be updated --> Running transaction check --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo --> Processing Dependency: stax-bea for package: dom4j --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat --> Finished Dependency Resolution Error: Missing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc is needed by package geronimo-specs-compat Error: Missing Dependency: castor = 0:0.9.5-2jpp is needed by package castor-demo Error: Missing Dependency: stax-bea is needed by package dom4j Thanks, Dan From jdf.lists at gmail.com Wed Apr 5 23:29:16 2006 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Wed, 5 Apr 2006 16:29:16 -0700 Subject: [fedora-java] Using JPackage Repo In-Reply-To: <1144189894.2967.29.camel@copper.cdkkt.com> References: <1144097604.2887.61.camel@copper.cdkkt.com> <67437bc40604041452m734515f2l791de4036614af7a@mail.gmail.com> <1144189894.2967.29.camel@copper.cdkkt.com> Message-ID: <67437bc40604051629k730ebcbbn1071332c47d59d5d@mail.gmail.com> On 4/4/06, Dan Thurman wrote: > On Tue, 2006-04-04 at 14:52 -0700, Joshua Daniel Franklin wrote: > > On 4/3/06, Dan Thurman wrote: > > > Also to note, that I have been using the [generic] repo version > > > instead of the fedora core version since I could not get this > > > repo to even work. Perhaps the repo does not exist. > > > > I haven't had this specific issue, but you need both the generic > > repo (which is for distribution-independent files) *and* the one > > for your distribution. Hmm, http://www.jpackage.org/jpackage_fedora-5.txt doesn't exist. And from looking at a mirror, neither does the fedora-5 directory. The vast majority is in "generic" so maybe you're OK. But I thought Red Hat people were working on JPackage and would have done the infrastructure. > I tried to run yum update but with jpackage-fc disabled, but generic > enabled and I *still* get dependency problems. Here is the full log: > > [root at copper log]# yum update ... > Error: Missing Dependency: stax-bea is needed by package dom4j Unfortunately, I believe this is a non-free package (like the JVM itself): http://jpackage.org/rebuilding.php From dant at cdkkt.com Sun Apr 9 18:47:34 2006 From: dant at cdkkt.com (Dan Thurman) Date: Sun, 09 Apr 2006 11:47:34 -0700 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! Message-ID: <1144608455.3011.120.camel@copper.cdkkt.com> Folks, I have enabled Jpackage generic repo, ran it, it fails with dependency errors, disabled it again, over and over for over a week and the damn thing still does not work at all. Heck, the Jpackage FC repo does not even exists. What's the point of using JPackages if I cannot use it to update Java components I need and want? Can anyone tell me what is going on and why this mailing list is one of the slowest crawling slugs I have seen - ever - ????? Did Java interest die here or what? HELLO? (echo: Hello, hello, hell, hel, he, h, ..... ) At this time, jpackage repo is disabled. BTW: I tried to exclude the packages one-by-one and I realized the list kept getting bigger and bigger so I gave up. It is much worst than I thought. Following is the results.... ==================================================================== > yum update > Loading "installonlyn" plugin > Setting up Update Process > Setting up repositories > macromedia [1/5] > core [2/5] > updates [3/5] > jpackage-generic [4/5] > extras [5/5] > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for xml-commons-apis-javadoc to pack into transaction set. > xml-commons-apis-javadoc- 100% |=========================| 42 kB 00:01 > ---> Package xml-commons-apis-javadoc.noarch 0:1.3.02-2jpp set to be updated > ---> Downloading header for cryptix to pack into transaction set. > cryptix-3.2.0-5jpp.noarch 100% |=========================| 2.5 kB 00:00 > ---> Package cryptix.noarch 0:3.2.0-5jpp set to be updated > ---> Downloading header for classpathx-mail-javadoc to pack into transaction set. > classpathx-mail-javadoc-1 100% |=========================| 38 kB 00:00 > ---> Package classpathx-mail-javadoc.noarch 0:1.1-1jpp set to be updated > ---> Downloading header for junit to pack into transaction set. > junit-3.8.1-4jpp.noarch.r 100% |=========================| 3.7 kB 00:00 > ---> Package junit.noarch 0:3.8.1-4jpp set to be updated > ---> Downloading header for xml-commons to pack into transaction set. > xml-commons-1.3.02-2jpp.n 100% |=========================| 3.6 kB 00:00 > ---> Package xml-commons.noarch 0:1.3.02-2jpp set to be updated > ---> Downloading header for cryptix-asn1-javadoc to pack into transaction set. > cryptix-asn1-javadoc-2001 100% |=========================| 8.6 kB 00:00 > ---> Package cryptix-asn1-javadoc.noarch 0:20011119-5jpp set to be updated > ---> Downloading header for jdom to pack into transaction set. > jdom-1.0-2jpp.noarch.rpm 100% |=========================| 4.6 kB 00:00 > ---> Package jdom.noarch 0:1.0-2jpp set to be updated > ---> Downloading header for avalon-framework-manual to pack into transaction set. > avalon-framework-manual-4 100% |=========================| 18 kB 00:00 > ---> Package avalon-framework-manual.noarch 0:4.1.5-1jpp set to be updated > ---> Downloading header for adaptx to pack into transaction set. > adaptx-0.9.6-2jpp.noarch. 100% |=========================| 2.6 kB 00:00 > ---> Package adaptx.noarch 0:0.9.6-2jpp set to be updated > ---> Downloading header for junit-demo to pack into transaction set. > junit-demo-3.8.1-4jpp.noa 100% |=========================| 18 kB 00:00 > ---> Package junit-demo.noarch 0:3.8.1-4jpp set to be updated > ---> Downloading header for jdepend to pack into transaction set. > jdepend-2.6-3jpp.noarch.r 100% |=========================| 3.9 kB 00:00 > ---> Package jdepend.noarch 0:2.6-3jpp set to be updated > ---> Package mach.i386 0:0.4.9-1.fc5 set to be updated > ---> Downloading header for antlr to pack into transaction set. > antlr-2.7.6-1jpp.noarch.r 100% |=========================| 5.3 kB 00:00 > ---> Package antlr.noarch 0:2.7.6-1jpp set to be updated > ---> Downloading header for jdepend-demo to pack into transaction set. > jdepend-demo-2.6-3jpp.noa 100% |=========================| 4.9 kB 00:00 > ---> Package jdepend-demo.noarch 0:2.6-3jpp set to be updated > ---> Downloading header for jlex-javadoc to pack into transaction set. > jlex-javadoc-1.2.6-2jpp.n 100% |=========================| 4.6 kB 00:00 > ---> Package jlex-javadoc.noarch 0:1.2.6-2jpp set to be updated > ---> Downloading header for castor-test to pack into transaction set. > castor-test-0.9.6-1jpp.no 100% |=========================| 2.3 kB 00:00 > ---> Package castor-test.noarch 0:0.9.6-1jpp set to be updated > ---> Downloading header for jsch to pack into transaction set. > jsch-0.1.20-1jpp.noarch.r 100% |=========================| 2.6 kB 00:00 > ---> Package jsch.noarch 0:0.1.20-1jpp set to be updated > ---> Downloading header for jakarta-commons-daemon to pack into transaction set.jakarta-commons-daemon-1. 100% |=========================| 5.8 kB 00:00 > ---> Package jakarta-commons-daemon.noarch 1:1.0.1-1jpp set to be updated > ---> Downloading header for jzlib to pack into transaction set. > jzlib-1.0.7-1jpp.noarch.r 100% |=========================| 2.6 kB 00:00 > ---> Package jzlib.noarch 0:1.0.7-1jpp set to be updated > ---> Downloading header for oro to pack into transaction set. > oro-2.0.8-2jpp.noarch.rpm 100% |=========================| 5.0 kB 00:00 > ---> Package oro.noarch 0:2.0.8-2jpp set to be updated > ---> Downloading header for cryptix-javadoc to pack into transaction set. > cryptix-javadoc-3.2.0-5jp 100% |=========================| 30 kB 00:00 > ---> Package cryptix-javadoc.noarch 0:3.2.0-5jpp set to be updated > ---> Downloading header for concurrent to pack into transaction set. > concurrent-1.3.4-1jpp.noa 100% |=========================| 2.5 kB 00:00 > ---> Package concurrent.noarch 0:1.3.4-1jpp set to be updated > ---> Downloading header for concurrent-javadoc to pack into transaction set. > concurrent-javadoc-1.3.4- 100% |=========================| 21 kB 00:00 > ---> Package concurrent-javadoc.noarch 0:1.3.4-1jpp set to be updated > ---> Downloading header for bsf to pack into transaction set. > bsf-2.3.0-8jpp.noarch.rpm 100% |=========================| 5.0 kB 00:00 > ---> Package bsf.noarch 0:2.3.0-8jpp set to be updated > ---> Downloading header for bcel to pack into transaction set. > bcel-5.1-5jpp.noarch.rpm 100% |=========================| 4.4 kB 00:00 > ---> Package bcel.noarch 0:5.1-5jpp set to be updated > ---> Downloading header for xml-commons-apis to pack into transaction set. > xml-commons-apis-1.3.02-2 100% |=========================| 3.3 kB 00:00 > ---> Package xml-commons-apis.noarch 0:1.3.02-2jpp set to be updated > ---> Downloading header for jlex to pack into transaction set. > jlex-1.2.6-2jpp.noarch.rp 100% |=========================| 2.6 kB 00:00 > ---> Package jlex.noarch 0:1.2.6-2jpp set to be updated > ---> Downloading header for xml-commons-resolver-javadoc to pack into transaction set. > xml-commons-resolver-java 100% |=========================| 13 kB 00:00 > ---> Package xml-commons-resolver-javadoc.noarch 0:1.1-3jpp set to be updated > ---> Downloading header for xml-commons-which-javadoc to pack into transaction set. > xml-commons-which-javadoc 100% |=========================| 8.5 kB 00:00 > ---> Package xml-commons-which-javadoc.noarch 0:1.3.02-2jpp set to be updated > ---> Downloading header for log4j-javadoc to pack into transaction set. > log4j-javadoc-1.2.12-1jpp 100% |=========================| 56 kB 00:01 > ---> Package log4j-javadoc.noarch 0:1.2.12-1jpp set to be updated > ---> Downloading header for xalan-j2-xsltc to pack into transaction set. > xalan-j2-xsltc-2.7.0-1jpp 100% |=========================| 6.9 kB 00:00 > ---> Package xalan-j2-xsltc.noarch 0:2.7.0-1jpp set to be updated > ---> Downloading header for castor-demo to pack into transaction set. > castor-demo-0.9.5-2jpp.no 100% |=========================| 7.9 kB 00:00 > ---> Package castor-demo.noarch 0:0.9.5-2jpp set to be updated > ---> Downloading header for java_cup-manual to pack into transaction set. > java_cup-manual-0.10-0.k. 100% |=========================| 2.3 kB 00:00 > ---> Package java_cup-manual.noarch 1:0.10-0.k.2jpp set to be updated > ---> Downloading header for avalon-framework-javadoc to pack into transaction set. > avalon-framework-javadoc- 100% |=========================| 28 kB 00:00 > ---> Package avalon-framework-javadoc.noarch 0:4.1.5-1jpp set to be updated > ---> Downloading header for cryptix-asn1 to pack into transaction set. > cryptix-asn1-20011119-5jp 100% |=========================| 2.5 kB 00:00 > ---> Package cryptix-asn1.noarch 0:20011119-5jpp set to be updated > ---> Downloading header for gnu.getopt to pack into transaction set. > gnu.getopt-1.0.10-1jpp.no 100% |=========================| 3.1 kB 00:00 > ---> Package gnu.getopt.noarch 0:1.0.10-1jpp set to be updated > ---> Downloading header for bsh to pack into transaction set. > bsh-1.3.0-6jpp.noarch.rpm 100% |=========================| 4.8 kB 00:00 > ---> Package bsh.noarch 0:1.3.0-6jpp set to be updated > ---> Downloading header for xalan-j2-javadoc to pack into transaction set. > xalan-j2-javadoc-2.7.0-1j 100% |=========================| 212 kB 00:05 > ---> Package xalan-j2-javadoc.noarch 0:2.7.0-1jpp set to be updated > ---> Downloading header for xml-commons-which to pack into transaction set. > xml-commons-which-1.3.02- 100% |=========================| 3.3 kB 00:00 > ---> Package xml-commons-which.noarch 0:1.3.02-2jpp set to be updated > ---> Downloading header for jakarta-commons-lang-javadoc to pack into transaction set. > jakarta-commons-lang-java 100% |=========================| 31 kB 00:00 > ---> Package jakarta-commons-lang-javadoc.noarch 0:2.1-1jpp set to be updated > ---> Downloading header for xml-commons-resolver to pack into transaction set. > xml-commons-resolver-1.1- 100% |=========================| 3.4 kB 00:00 > ---> Package xml-commons-resolver.noarch 0:1.1-3jpp set to be updated > ---> Downloading header for xalan-j2-manual to pack into transaction set. > xalan-j2-manual-2.7.0-1jp 100% |=========================| 7.0 kB 00:00 > ---> Package xalan-j2-manual.noarch 0:2.7.0-1jpp set to be updated > ---> Downloading header for gnu.getopt-javadoc to pack into transaction set. > gnu.getopt-javadoc-1.0.10 100% |=========================| 4.4 kB 00:00 > ---> Package gnu.getopt-javadoc.noarch 0:1.0.10-1jpp set to be updated > ---> Downloading header for castor-doc to pack into transaction set. > castor-doc-0.9.6-1jpp.noa 100% |=========================| 24 kB 00:00 > ---> Package castor-doc.noarch 0:0.9.6-1jpp set to be updated > ---> Downloading header for jakarta-commons-lang to pack into transaction set. > jakarta-commons-lang-2.1- 100% |=========================| 4.7 kB 00:00 > ---> Package jakarta-commons-lang.noarch 0:2.1-1jpp set to be updated > ---> Downloading header for antlr-javadoc to pack into transaction set. > antlr-javadoc-2.7.6-1jpp. 100% |=========================| 79 kB 00:02 > ---> Package antlr-javadoc.noarch 0:2.7.6-1jpp set to be updated > ---> Downloading header for log4j-manual to pack into transaction set. > log4j-manual-1.2.12-1jpp. 100% |=========================| 23 kB 00:00 > ---> Package log4j-manual.noarch 0:1.2.12-1jpp set to be updated > ---> Downloading header for jdepend-javadoc to pack into transaction set. > jdepend-javadoc-2.6-3jpp. 100% |=========================| 8.0 kB 00:00 > ---> Package jdepend-javadoc.noarch 0:2.6-3jpp set to be updated > ---> Downloading header for oro-javadoc to pack into transaction set. > oro-javadoc-2.0.8-2jpp.no 100% |=========================| 13 kB 00:00 > ---> Package oro-javadoc.noarch 0:2.0.8-2jpp set to be updated > ---> Downloading header for jakarta-commons-daemon-javadoc to pack into transaction set. > jakarta-commons-daemon-ja 100% |=========================| 7.1 kB 00:00 > ---> Package jakarta-commons-daemon-javadoc.noarch 1:1.0.1-1jpp set to be updated > ---> Downloading header for lucene to pack into transaction set. > lucene-1.4.3-2jpp.noarch. 100% |=========================| 3.0 kB 00:00 > ---> Package lucene.noarch 0:1.4.3-2jpp set to be updated > ---> Downloading header for geronimo-specs to pack into transaction set. > geronimo-specs-1.0-0.M2.3 100% |=========================| 5.0 kB 00:00 > ---> Package geronimo-specs.noarch 0:1.0-0.M2.3jpp set to be updated > ---> Downloading header for junit-javadoc to pack into transaction set. > junit-javadoc-3.8.1-4jpp. 100% |=========================| 7.8 kB 00:00 > ---> Package junit-javadoc.noarch 0:3.8.1-4jpp set to be updated > ---> Downloading header for avalon-framework to pack into transaction set. > avalon-framework-4.1.5-1j 100% |=========================| 4.5 kB 00:00 > ---> Package avalon-framework.noarch 0:4.1.5-1jpp set to be updated > ---> Downloading header for java_cup-javadoc to pack into transaction set. > java_cup-javadoc-0.10-0.k 100% |=========================| 14 kB 00:00 > ---> Package java_cup-javadoc.noarch 1:0.10-0.k.2jpp set to be updated > ---> Downloading header for junit-manual to pack into transaction set. > junit-manual-3.8.1-4jpp.n 100% |=========================| 6.0 kB 00:00 > ---> Package junit-manual.noarch 0:3.8.1-4jpp set to be updated > ---> Downloading header for log4j to pack into transaction set. > log4j-1.2.12-1jpp.noarch. 100% |=========================| 8.0 kB 00:00 > ---> Package log4j.noarch 0:1.2.12-1jpp set to be updated > ---> Downloading header for classpathx-mail to pack into transaction set. > classpathx-mail-1.1-1jpp. 100% |=========================| 4.1 kB 00:00 > ---> Package classpathx-mail.noarch 0:1.1-1jpp set to be updated > ---> Downloading header for bcel-javadoc to pack into transaction set. > bcel-javadoc-5.1-5jpp.noa 100% |=========================| 71 kB 00:01 > ---> Package bcel-javadoc.noarch 0:5.1-5jpp set to be updated > ---> Downloading header for lucene-demo to pack into transaction set. > lucene-demo-1.4.3-2jpp.no 100% |=========================| 2.4 kB 00:00 > ---> Package lucene-demo.noarch 0:1.4.3-2jpp set to be updated > ---> Downloading header for java_cup to pack into transaction set. > java_cup-0.10-0.k.2jpp.no 100% |=========================| 2.8 kB 00:00 > ---> Package java_cup.noarch 1:0.10-0.k.2jpp set to be updated > ---> Downloading header for xalan-j2-demo to pack into transaction set. > xalan-j2-demo-2.7.0-1jpp. 100% |=========================| 29 kB 00:00 > ---> Package xalan-j2-demo.noarch 0:2.7.0-1jpp set to be updated > ---> Downloading header for antlr-manual to pack into transaction set. > antlr-manual-2.7.6-1jpp.n 100% |=========================| 8.1 kB 00:00 > ---> Package antlr-manual.noarch 0:2.7.6-1jpp set to be updated > ---> Downloading header for castor-javadoc to pack into transaction set. > castor-javadoc-0.9.6-1jpp 100% |=========================| 115 kB 00:02 > ---> Package castor-javadoc.noarch 0:0.9.6-1jpp set to be updated > ---> Downloading header for castor-xml to pack into transaction set. > castor-xml-0.9.6-1jpp.noa 100% |=========================| 2.3 kB 00:00 > ---> Package castor-xml.noarch 0:0.9.6-1jpp set to be updated > ---> Downloading header for xalan-j2 to pack into transaction set. > xalan-j2-2.7.0-1jpp.noarc 100% |=========================| 8.7 kB 00:00 > ---> Package xalan-j2.noarch 0:2.7.0-1jpp set to be updated > ---> Downloading header for castor to pack into transaction set. > castor-0.9.6-1jpp.noarch. 100% |=========================| 3.2 kB 00:00 > ---> Package castor.noarch 0:0.9.6-1jpp set to be updated > ---> Downloading header for xml-commons-apis-manual to pack into transaction set. > xml-commons-apis-manual-1 100% |=========================| 30 kB 00:00 > ---> Package xml-commons-apis-manual.noarch 0:1.3.02-2jpp set to be updated > ---> Downloading header for puretls-javadoc to pack into transaction set. > puretls-javadoc-0.9-0.b5. 100% |=========================| 24 kB 00:00 > ---> Package puretls-javadoc.noarch 0:0.9-0.b5.1jpp set to be updated > --> Running transaction check > --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat > --> Processing Dependency: cglib for package: castor > --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo > --> Processing Dependency: servletapi3 for package: castor-demo > --> Processing Dependency: jaxen for package: jdom > --> Processing Dependency: xmlbeans for package: geronimo-specs > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for jaxen to pack into transaction set. > jaxen-1.1-0.b7.1jpp.noarc 100% |=========================| 3.0 kB 00:00 > ---> Package jaxen.noarch 0:1.1-0.b7.1jpp set to be updated > ---> Downloading header for xmlbeans to pack into transaction set. > xmlbeans-1.0.4-2jpp.noarc 100% |=========================| 3.8 kB 00:00 > ---> Package xmlbeans.noarch 0:1.0.4-2jpp set to be updated > ---> Downloading header for servletapi3 to pack into transaction set. > servletapi3-3.3.1-0.a.2jp 100% |=========================| 4.8 kB 00:00 > ---> Package servletapi3.noarch 0:3.3.1-0.a.2jpp set to be updated > ---> Downloading header for cglib to pack into transaction set. > cglib-2.1.3-1jpp.noarch.r 100% |=========================| 3.5 kB 00:00 > ---> Package cglib.noarch 0:2.1.3-1jpp set to be updated > --> Running transaction check > --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat > --> Processing Dependency: xom for package: jaxen > --> Processing Dependency: aspectwerkz >= 0:1.0 for package: cglib > --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo > --> Processing Dependency: asm >= 0:1.5.3 for package: cglib > --> Processing Dependency: dom4j >= 0:1.6.1 for package: jaxen > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for asm to pack into transaction set. > asm-1.5.3-1jpp.noarch.rpm 100% |=========================| 4.1 kB 00:00 > ---> Package asm.noarch 0:1.5.3-1jpp set to be updated > ---> Downloading header for dom4j to pack into transaction set. > dom4j-1.6.1-1jpp.noarch.r 100% |=========================| 2.8 kB 00:00 > ---> Package dom4j.noarch 0:1.6.1-1jpp set to be updated > ---> Downloading header for xom to pack into transaction set. > xom-1.0-1jpp.noarch.rpm 100% |=========================| 3.0 kB 00:00 > ---> Package xom.noarch 0:1.0-1jpp set to be updated > ---> Downloading header for aspectwerkz to pack into transaction set. > aspectwerkz-2.0-1jpp.noar 100% |=========================| 5.3 kB 00:00 > ---> Package aspectwerkz.noarch 0:2.0-1jpp set to be updated > --> Running transaction check > --> Processing Dependency: icu4j for package: xom > --> Processing Dependency: jrexx for package: aspectwerkz > --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat > --> Processing Dependency: javassist for package: aspectwerkz > --> Processing Dependency: qdox for package: aspectwerkz > --> Processing Dependency: msv-xsdlib for package: dom4j > --> Processing Dependency: xpp2 for package: dom4j > --> Processing Dependency: relaxngDatatype for package: dom4j > --> Processing Dependency: gnu.trove for package: aspectwerkz > --> Processing Dependency: isorelax for package: dom4j > --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo > --> Processing Dependency: piccolo for package: aspectwerkz > --> Processing Dependency: stax-bea for package: dom4j > --> Processing Dependency: msv-msv for package: dom4j > --> Processing Dependency: ws-jaxme for package: dom4j > --> Processing Dependency: xpp3 for package: dom4j > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for qdox to pack into transaction set. > qdox-1.5-1jpp.noarch.rpm 100% |=========================| 2.6 kB 00:00 > ---> Package qdox.noarch 0:1.5-1jpp set to be updated > ---> Downloading header for javassist to pack into transaction set. > javassist-3.0-1jpp.noarch 100% |=========================| 3.0 kB 00:00 > ---> Package javassist.noarch 0:3.0-1jpp set to be updated > ---> Downloading header for xpp3 to pack into transaction set. > xpp3-1.1.3.4-1.o.1jpp.noa 100% |=========================| 4.2 kB 00:00 > ---> Package xpp3.noarch 0:1.1.3.4-1.o.1jpp set to be updated > ---> Downloading header for xpp2 to pack into transaction set. > xpp2-2.1.10-5jpp.noarch.r 100% |=========================| 3.4 kB 00:00 > ---> Package xpp2.noarch 0:2.1.10-5jpp set to be updated > ---> Downloading header for gnu.trove to pack into transaction set. > gnu.trove-1.0.2-3jpp.noar 100% |=========================| 2.6 kB 00:00 > ---> Package gnu.trove.noarch 0:1.0.2-3jpp set to be updated > ---> Downloading header for msv-xsdlib to pack into transaction set. > msv-xsdlib-1.2-0.20050722 100% |=========================| 2.3 kB 00:00 > ---> Package msv-xsdlib.noarch 0:1.2-0.20050722.1jpp set to be updated > ---> Downloading header for ws-jaxme to pack into transaction set. > ws-jaxme-0.5-1jpp.noarch. 100% |=========================| 5.0 kB 00:00 > ---> Package ws-jaxme.noarch 0:0.5-1jpp set to be updated > ---> Downloading header for jrexx to pack into transaction set. > jrexx-1.1.1-2jpp.noarch.r 100% |=========================| 2.7 kB 00:00 > ---> Package jrexx.noarch 0:1.1.1-2jpp set to be updated > ---> Downloading header for msv-msv to pack into transaction set. > msv-msv-1.2-0.20050722.1j 100% |=========================| 2.4 kB 00:00 > ---> Package msv-msv.noarch 0:1.2-0.20050722.1jpp set to be updated > ---> Downloading header for icu4j to pack into transaction set. > icu4j-3.2-1jpp.noarch.rpm 100% |=========================| 3.1 kB 00:00 > ---> Package icu4j.noarch 0:3.2-1jpp set to be updated > ---> Downloading header for piccolo to pack into transaction set. > piccolo-1.04-1jpp.noarch. 100% |=========================| 2.4 kB 00:00 > ---> Package piccolo.noarch 0:1.04-1jpp set to be updated > ---> Downloading header for relaxngDatatype to pack into transaction set. > relaxngDatatype-1.0-2jpp. 100% |=========================| 2.3 kB 00:00 > ---> Package relaxngDatatype.noarch 0:1.0-2jpp set to be updated > ---> Downloading header for isorelax to pack into transaction set. > isorelax-0.1-0.20041111.1 100% |=========================| 2.8 kB 00:00 > ---> Package isorelax.noarch 0:0.1-0.20041111.1jpp set to be updated > --> Running transaction check > --> Processing Dependency: castor = 0:0.9.5-2jpp for package: castor-demo > --> Processing Dependency: stax-bea for package: dom4j > --> Processing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc for package: geronimo-specs-compat > --> Finished Dependency Resolution > Error: Missing Dependency: geronimo-specs = 1.0-0.M2.2jpp_7fc is needed by package geronimo-specs-compat > Error: Missing Dependency: castor = 0:0.9.5-2jpp is needed by package castor-demo > Error: Missing Dependency: stax-bea is needed by package dom4j > [root at copper ~]# ==================================================================== Note: 1.0-0.M2.2jpp_7fc is installed on my machine currently.... Dan From weiqigao at gmail.com Mon Apr 10 03:33:32 2006 From: weiqigao at gmail.com (Weiqi Gao) Date: Sun, 9 Apr 2006 22:33:32 -0500 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144608455.3011.120.camel@copper.cdkkt.com> References: <1144608455.3011.120.camel@copper.cdkkt.com> Message-ID: <2ee1c2b30604092033w1131df3dwee4289cf9bdd6c2d@mail.gmail.com> On 4/9/06, Dan Thurman wrote: > > I have enabled Jpackage generic repo, ran it, it fails with > dependency errors, disabled it again, over and over for over > a week and the damn thing still does not work at all. Heck, > the Jpackage FC repo does not even exists. Back in the FC3 days, I was able to get all of JPackage installed on my machine (except for NetBeans and Maven) by not installing the Java packages from FC3 and following the instructions on JPackage.org's web site. I have to use two yum repositories from JPackage.org: [jpackage16-generic] and [jpackage16-fc3]. The hardest part is to hand install all the dependent non-free rpms. I have a couple of write ups here: http://www.weiqigao.com/blog/2004/11/23/an_introduction_to_jpackage_org.html http://www.weiqigao.com/blog/2004/12/05/what_jpackage_org_brought_to_my_computer.html Starting with FC4, and now FC5, I simply installed the Java packages from the distribution and never got around to use JPackage.org again. > What's the point of using JPackages if I cannot use it to update > Java components I need and want? My understanding is that to use JPackage.org's rpms, you have to use both the generic repository and a platform specific repository. I just browsed over there, and saw repos for fc1 through fc4. So I guess for the moment, if you are on FC5, you are out of luck. If you are on FC1 through FC4, you should be able to make use of JPackage.org. The FC5 release notes also warns about potential problems if you mix FC5's Java packages and JPackages.org's Java packages. So be careful. > Can anyone tell me what is going on and why this mailing list is > one of the slowest crawling slugs I have seen - ever - ????? The list is alive. I see posts from time to time. > Did Java interest die here or what? Not from my side. -- Weiqi Gao (???) weiqigao at gmail.com http://www.weiqigao.com/blog/ From green at redhat.com Mon Apr 10 14:50:31 2006 From: green at redhat.com (Anthony Green) Date: Mon, 10 Apr 2006 10:50:31 -0400 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144608455.3011.120.camel@copper.cdkkt.com> References: <1144608455.3011.120.camel@copper.cdkkt.com> Message-ID: <1144680632.2558.12.camel@localhost.localdomain> On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > What's the point of using JPackages if I cannot use it to update > Java components I need and want? I don't know. We don't recommend using the JPackages repos directly. AG From dimi at lattica.com Mon Apr 10 17:09:05 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 10 Apr 2006 13:09:05 -0400 Subject: [fedora-java] SVN plugin Message-ID: <1144688945.6382.67.camel@dimi> Hi folks, I have looked around but I couldn't find any packages for FC5 for the subclipse plugin (SVN support): http://subclipse.tigris.org/ Any tips/tricks to get this working with FC5 Native Eclipse? This is the last problem that I need to solve in order to use the Native Eclipse, any help would be greatly appreciated. -- Dimi Paun Lattica, Inc. From dant at cdkkt.com Mon Apr 10 17:11:26 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 10 Apr 2006 10:11:26 -0700 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144680632.2558.12.camel@localhost.localdomain> References: <1144608455.3011.120.camel@copper.cdkkt.com> <1144680632.2558.12.camel@localhost.localdomain> Message-ID: <1144689087.3011.153.camel@copper.cdkkt.com> On Mon, 2006-04-10 at 10:50 -0400, Anthony Green wrote: > On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > > What's the point of using JPackages if I cannot use it to update > > Java components I need and want? > > I don't know. We don't recommend using the JPackages repos directly. > > AG > > I thought I read somewhere that you can add jpackage repo as long as you enable the jpackage-fc5 repo which does not exist! Please tell me what I need to do to keep up to date with java packages. I *thought* via jpackages I would get all the wonderful stuff as in FC4 but apparently FC5 has made a "clean break" from JPackages group? Is this what you are saying? Kind regards, Dan From overholt at redhat.com Mon Apr 10 17:24:09 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 10 Apr 2006 13:24:09 -0400 Subject: [fedora-java] SVN plugin In-Reply-To: <1144688945.6382.67.camel@dimi> References: <1144688945.6382.67.camel@dimi> Message-ID: <20060410172409.GB5417@redhat.com> Hi, * Dimi Paun [2006-04-10 13:09]: > > I have looked around but I couldn't find any packages for FC5 > for the subclipse plugin (SVN support): > http://subclipse.tigris.org/ Yeah, it's high on our list of things to do. > Any tips/tricks to get this working with FC5 Native Eclipse? Does it not work with the update manager? I've tried it and it worked fine. I believe Tom Fitzsimmons and Ben Konrath use it daily. Andrew From jdf.lists at gmail.com Mon Apr 10 17:40:12 2006 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Mon, 10 Apr 2006 10:40:12 -0700 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144680632.2558.12.camel@localhost.localdomain> References: <1144608455.3011.120.camel@copper.cdkkt.com> <1144680632.2558.12.camel@localhost.localdomain> Message-ID: <67437bc40604101040x57024e37n298d9da4cf39f67a@mail.gmail.com> On 4/10/06, Anthony Green wrote: > On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > > What's the point of using JPackages if I cannot use it to update > > Java components I need and want? > > I don't know. We don't recommend using the JPackages repos directly. This is of some concern to me also. We mostly use RHEL (FC for a little testing) so it won't trickle down until RHEL5, but my understanding was that Red Hat was adopting JPackage as the model for Java packages in Fedora Core and Red Hat Enterprise. The official FC5 rpms even have "jpp" in their names, for example ant-1.6.5-1jpp_7fc.i386.rpm . Now, I understand that the "fc" also means that gjc-specific stuff is in the rpm, but one advantage of JPackage is that you can easily switch JVMs. Are you saying that with Red Hat is going to maintain a set of separate packages and if you ever want any JPackages beyond that set you shouldn't be using RHEL or Fedora Core? Dan: I don't know if you saw my earlier email, but you probably just need to build your own stax-bea since it's non-free. From dimi at lattica.com Mon Apr 10 17:45:26 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 10 Apr 2006 13:45:26 -0400 Subject: [fedora-java] SVN plugin In-Reply-To: <20060410172409.GB5417@redhat.com> References: <1144688945.6382.67.camel@dimi> <20060410172409.GB5417@redhat.com> Message-ID: <1144691126.6382.80.camel@dimi> On Mon, 2006-04-10 at 13:24 -0400, Andrew Overholt wrote: > > Any tips/tricks to get this working with FC5 Native Eclipse? > > Does it not work with the update manager? I've tried it and it worked > fine. I believe Tom Fitzsimmons and Ben Konrath use it daily. First thing I've tried, but I picked Help -> Software Updates -> Manage Configuration There there's only the Add -> Extension Location ... under the Context Menu, which is close but not quite.... Which of course gives the impression that you're in the right place but the functionality is not supported! Not a failing of Native Eclipse, but this entire thing is _so_ confusing it's beyond words. WTF designed it? * Why under the Help menu? * Why have "Find and Install..." and "Manage Configuration" * Why can't I manage my configuration (like add stuff) from Manage Configuration? * Why have yet another branch in Find and Install...? It can easily win a "most confusing interface" contest. -- Dimi Paun Lattica, Inc. From dant at cdkkt.com Mon Apr 10 17:54:11 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 10 Apr 2006 10:54:11 -0700 Subject: [JPackage-discuss] [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <67437bc40604101040x57024e37n298d9da4cf39f67a@mail.gmail.com> References: <1144608455.3011.120.camel@copper.cdkkt.com> <1144680632.2558.12.camel@localhost.localdomain> <67437bc40604101040x57024e37n298d9da4cf39f67a@mail.gmail.com> Message-ID: <1144691652.3011.164.camel@copper.cdkkt.com> On Mon, 2006-04-10 at 10:40 -0700, Joshua Daniel Franklin wrote: > On 4/10/06, Anthony Green wrote: > > On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > > > What's the point of using JPackages if I cannot use it to update > > > Java components I need and want? > > > > I don't know. We don't recommend using the JPackages repos directly. > > This is of some concern to me also. We mostly use RHEL (FC for a little > testing) so it won't trickle down until RHEL5, but my understanding was > that Red Hat was adopting JPackage as the model for Java packages > in Fedora Core and Red Hat Enterprise. The official FC5 rpms even > have "jpp" in their names, for example ant-1.6.5-1jpp_7fc.i386.rpm . > Now, I understand that the "fc" also means that gjc-specific stuff is in > the rpm, but one advantage of JPackage is that you can easily switch > JVMs. > > Are you saying that with Red Hat is going to maintain a set of separate > packages and if you ever want any JPackages beyond that set you > shouldn't be using RHEL or Fedora Core? > > Dan: I don't know if you saw my earlier email, but you probably > just need to build your own stax-bea since it's non-free. > _______________________________________________ > JPackage-discuss mailing list > JPackage-discuss at zarb.org > https://www.zarb.org/mailman/listinfo/jpackage-discuss I don't care about 'stax-bea'! This was added on later. I added this to the --exclude list and then there was another dependency. Add that, then another and the list seems long and I gave up after the 5th try because it was expanding into a hive of dependencies! So - in a nutshell... I cannot proceed with the simplest updates! Again, you cannot enable fpackage-fc because it does not exists. Someone wrote that its there for fc1-fc4 but you are out of luck for fc5. So - I disabled that and tried [generic] and now disabled that. So - no updates are possible for me at this time. Kind regards, Dan From dant at cdkkt.com Mon Apr 10 18:18:15 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 10 Apr 2006 11:18:15 -0700 Subject: [fedora-java] SVN plugin In-Reply-To: <1144691126.6382.80.camel@dimi> References: <1144688945.6382.67.camel@dimi> <20060410172409.GB5417@redhat.com> <1144691126.6382.80.camel@dimi> Message-ID: <1144693095.3011.188.camel@copper.cdkkt.com> On Mon, 2006-04-10 at 13:45 -0400, Dimi Paun wrote: > On Mon, 2006-04-10 at 13:24 -0400, Andrew Overholt wrote: > > > Any tips/tricks to get this working with FC5 Native Eclipse? > > > > Does it not work with the update manager? I've tried it and it worked > > fine. I believe Tom Fitzsimmons and Ben Konrath use it daily. > > First thing I've tried, but I picked > Help -> Software Updates -> Manage Configuration > > There there's only the > Add -> Extension Location ... > under the Context Menu, which is close but not quite.... > Which of course gives the impression that you're in the > right place but the functionality is not supported! > > > Not a failing of Native Eclipse, but this entire thing > is _so_ confusing it's beyond words. WTF designed it? > * Why under the Help menu? > * Why have "Find and Install..." and "Manage Configuration" > * Why can't I manage my configuration (like add stuff) > from Manage Configuration? > * Why have yet another branch in Find and Install...? > > It can easily win a "most confusing interface" contest. > > Yes, Eclipse is not always intuitive but with thousands on the planet using it, thousands are not (yet) complaining, just a few tens or hundreds and I am one of those that ranted about it but it does no good to rant about it unless you join the mailing list or the newsgroups and get involved in the process and make suggestive comments. Perhaps you need to add "suggestions" in their bug-list. I am a end-user and not officially associated with Eclipse. Kind regards, Dan From green at redhat.com Mon Apr 10 18:33:14 2006 From: green at redhat.com (Anthony Green) Date: Mon, 10 Apr 2006 14:33:14 -0400 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144689087.3011.153.camel@copper.cdkkt.com> References: <1144608455.3011.120.camel@copper.cdkkt.com> <1144680632.2558.12.camel@localhost.localdomain> <1144689087.3011.153.camel@copper.cdkkt.com> Message-ID: <1144693994.5079.21.camel@localhost.localdomain> On Mon, 2006-04-10 at 10:11 -0700, Dan Thurman wrote: > Please tell me what I need to do to keep up to date with java > packages. It depends what packages you're interested in. If you're talking about packages provided in FC/FE, then just yum and you're done. If you're talking about other packages, then I recommend helping port them to Fedora. > I *thought* via jpackages I would get all the wonderful > stuff as in FC4 but apparently FC5 has made a "clean break" from > JPackages group? Is this what you are saying? JPackage packages many useful programs we feel should be part of the core OS (or Extras). There are two main problems with JPackage usage right now: 1. Dependencies on non-free packages. I believe the JPackage team is working to fix this. I'm not sure what the latest status is. 2. Inability to build (and run) with Free software. We need to be able to build everything in FC/FE with Free Software. Unfortunately, many JPackaged packages cannot be built with Free Software. This used to be because our Free tools and libraries weren't mature, but now mostly it seems due to the Java Trap. Unfortunately, many packages depend on proprietary extensions to the Java platform (sun.*, com.sun.*, etc). The good news is that upstream projects are slowly cleaning up their act. Batik recently removed sun.*/com.sun.* uses so it can be built with Free software. But, due to the high degree of interdependency between Java packages, all we need is one bad package to prevent us from building many others. AG From chris at hubick.com Mon Apr 10 18:33:39 2006 From: chris at hubick.com (Chris Hubick) Date: Mon, 10 Apr 2006 12:33:39 -0600 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144608455.3011.120.camel@copper.cdkkt.com> References: <1144608455.3011.120.camel@copper.cdkkt.com> Message-ID: <1144694019.15597.7.camel@CHWorkstation> On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > Error: Missing Dependency: stax-bea is needed by package dom4j Just download the dom4j RPM and install it manually without stax-bea... First attempt to install the package normally using "rpm -ivf", which will fail because of some list of missing dependencies including stax-bea... then use "yum install" on all the listed dependencies except stax-bea, then finally install the dom4j rpm using "rpm --force --nodeps -ivf" or whatever. You should then be able to continue using yum to install whatever else you want normally. -- Chris Hubick mailto:chris at hubick.com http://www.hubick.com/ From dant at cdkkt.com Mon Apr 10 22:38:05 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 10 Apr 2006 15:38:05 -0700 Subject: [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144694019.15597.7.camel@CHWorkstation> References: <1144608455.3011.120.camel@copper.cdkkt.com> <1144694019.15597.7.camel@CHWorkstation> Message-ID: <1144708686.3011.189.camel@copper.cdkkt.com> On Mon, 2006-04-10 at 12:33 -0600, Chris Hubick wrote: > On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > > Error: Missing Dependency: stax-bea is needed by package dom4j > > Just download the dom4j RPM and install it manually without stax-bea... > > First attempt to install the package normally using "rpm -ivf", which > will fail because of some list of missing dependencies including > stax-bea... then use "yum install" on all the listed dependencies except > stax-bea, then finally install the dom4j rpm using "rpm --force --nodeps > -ivf" or whatever. You should then be able to continue using yum to > install whatever else you want normally. > Oh wow. stax-bea does not exist in jpackage bit bea-stax does! What is the difference? Kind regards, Dan From bkonrath at redhat.com Mon Apr 10 23:22:58 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 10 Apr 2006 19:22:58 -0400 Subject: [fedora-java] SVN plugin In-Reply-To: <1144691126.6382.80.camel@dimi> References: <1144688945.6382.67.camel@dimi> <20060410172409.GB5417@redhat.com> <1144691126.6382.80.camel@dimi> Message-ID: <1144711378.28990.49.camel@toad.toronto.redhat.com> On Mon, 2006-04-10 at 13:45 -0400, Dimi Paun wrote: > On Mon, 2006-04-10 at 13:24 -0400, Andrew Overholt wrote: > > > Any tips/tricks to get this working with FC5 Native Eclipse? > > > > Does it not work with the update manager? I've tried it and it worked > > fine. I believe Tom Fitzsimmons and Ben Konrath use it daily. > > First thing I've tried, but I picked > Help -> Software Updates -> Manage Configuration You should do: Help -> Software Updates -> Find and Install ... Search for new Features to Install -> Next -> New Remote Site ... Add http://subclipse.tigris.org/update_1.0.x and click finish Now select Subclipse and you should be on your way to having subclipse installed. > There there's only the > Add -> Extension Location ... > under the Context Menu, which is close but not quite.... > Which of course gives the impression that you're in the > right place but the functionality is not supported! Actually adding an Extension Location should work if you had an Eclipse Extension. AFAIK, subclipse only releases an update site. If it doesn't work with an Eclipse Extension, please file a bug. Thanks, Ben From dant at cdkkt.com Mon Apr 10 23:34:27 2006 From: dant at cdkkt.com (Dan Thurman) Date: Mon, 10 Apr 2006 16:34:27 -0700 Subject: [JPackage-discuss] [fedora-java] Oh Poo. JPackages has too many depenency problems and it's been over a week! In-Reply-To: <1144691652.3011.164.camel@copper.cdkkt.com> References: <1144608455.3011.120.camel@copper.cdkkt.com> <1144680632.2558.12.camel@localhost.localdomain> <67437bc40604101040x57024e37n298d9da4cf39f67a@mail.gmail.com> <1144691652.3011.164.camel@copper.cdkkt.com> Message-ID: <1144712068.3011.199.camel@copper.cdkkt.com> On Mon, 2006-04-10 at 10:54 -0700, Dan Thurman wrote: > On Mon, 2006-04-10 at 10:40 -0700, Joshua Daniel Franklin wrote: > > On 4/10/06, Anthony Green wrote: > > > On Sun, 2006-04-09 at 11:47 -0700, Dan Thurman wrote: > > > > What's the point of using JPackages if I cannot use it to update > > > > Java components I need and want? > > > > > > I don't know. We don't recommend using the JPackages repos directly. > > > > This is of some concern to me also. We mostly use RHEL (FC for a little > > testing) so it won't trickle down until RHEL5, but my understanding was > > that Red Hat was adopting JPackage as the model for Java packages > > in Fedora Core and Red Hat Enterprise. The official FC5 rpms even > > have "jpp" in their names, for example ant-1.6.5-1jpp_7fc.i386.rpm . > > Now, I understand that the "fc" also means that gjc-specific stuff is in > > the rpm, but one advantage of JPackage is that you can easily switch > > JVMs. > > > > Are you saying that with Red Hat is going to maintain a set of separate > > packages and if you ever want any JPackages beyond that set you > > shouldn't be using RHEL or Fedora Core? > > > > Dan: I don't know if you saw my earlier email, but you probably > > just need to build your own stax-bea since it's non-free. > > _______________________________________________ > > JPackage-discuss mailing list > > JPackage-discuss at zarb.org > > https://www.zarb.org/mailman/listinfo/jpackage-discuss > > I don't care about 'stax-bea'! This was added on later. I > added this to the --exclude list and then there was another > dependency. Add that, then another and the list seems long > and I gave up after the 5th try because it was expanding into > a hive of dependencies! > > So - in a nutshell... I cannot proceed with the simplest > updates! Again, you cannot enable fpackage-fc because it > does not exists. Someone wrote that its there for fc1-fc4 > but you are out of luck for fc5. So - I disabled that and > tried [generic] and now disabled that. So - no updates are > possible for me at this time. > > Kind regards, > Dan > _______________________________________________ > JPackage-discuss mailing list > JPackage-discuss at zarb.org > https://www.zarb.org/mailman/listinfo/jpackage-discuss OK, This is what I have done so far: 1) Downloaded: dom4j-1.6.1-1jpp.rpm forced installed with no dependencies 2) Enabled jpackage repo [generic] yum update --exclude=stax-bea-1.0-2jpp --exclude=castor\* --exclude=geronimo-specs\* Note: 1) In jpackage, there is both a bea-stax and stax-bea - confusing. Cannot install this package no matter what I tried to do. 2) castor-depends is looking for: castor-0.9.6-2jpp and it does not exist. 3) Cannot overwrite fc5's geronimo-specs\* All files are updated except those excluded above. Cheers, Dan From dimi at lattica.com Tue Apr 11 02:29:54 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 10 Apr 2006 22:29:54 -0400 Subject: [fedora-java] SVN plugin In-Reply-To: <1144711378.28990.49.camel@toad.toronto.redhat.com> References: <1144688945.6382.67.camel@dimi> <20060410172409.GB5417@redhat.com> <1144691126.6382.80.camel@dimi> <1144711378.28990.49.camel@toad.toronto.redhat.com> Message-ID: <1144722594.6382.109.camel@dimi> On Mon, 2006-04-10 at 19:22 -0400, Ben Konrath wrote: > Now select Subclipse and you should be on your way to having subclipse > installed. Thank Ben, I figured that out, I should have been more clear.My message was just a frustrated rant about the stupid-evil UI, after I have actually realized that I had been fooled :( There are too many battles to be fought, I can't fight them all -- if you guys have any input on the eclipse ML, please try to get that silly UI design simplified. Maybe just: Help | Manage Configuration and from Manage Configuration you should be able to do everything: add/remove/update plugins/extensions/etc. Thanks for the helping hand! -- Dimi Paun Lattica, Inc. From orion at cora.nwra.com Tue Apr 11 16:33:36 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 11 Apr 2006 10:33:36 -0600 Subject: [fedora-java] eclipse-platform -> javadoc Message-ID: <443BDA60.2060007@cora.nwra.com> Is the requirement of javadoc for eclipse-platform really necessary? javadoc is huge! 235M /usr/share/javadoc/ I'm just looking for a small eclipse CDT install.... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From gareth.foster at siemens.com Wed Apr 12 16:00:58 2006 From: gareth.foster at siemens.com (Foster, Gareth) Date: Wed, 12 Apr 2006 17:00:58 +0100 Subject: [fedora-java] Autotools? Message-ID: Hello list, This is a pretty open ended question really. Autotools plugin? Going in extras for FC5? Only going in FC6? Abandoned? Subject to furious hacking? Picked up code from Kdevelop? They are all questions people would be interested in having the answers to. How about a status update or roadmap? As a reply to this, or maybe as a gnomedesktop.org post? Cheers, Gaz From overholt at redhat.com Wed Apr 12 16:04:45 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 12 Apr 2006 12:04:45 -0400 Subject: [fedora-java] Autotools? In-Reply-To: References: Message-ID: <20060412160445.GJ8703@redhat.com> Hi, * Foster, Gareth [2006-04-12 12:01]: > > This is a pretty open ended question really. Autotools plugin? Going in > extras for FC5? Only going in FC6? Abandoned? Subject to furious hacking? > Picked up code from Kdevelop? It's being worked on. It's still pretty alpha. The current plan is to get things into the CDT. I've spoken with Alexander (of the kde automake Eclipse work) about integrating some of his work. It's still a bit up in the air and I have been busy with some other things. > They are all questions people would be interested in having the answers to. > How about a status update or roadmap? As a reply to this, or maybe as a > gnomedesktop.org post? I'll ask Jeff to post something on sourceware.org/eclipse. Andrew From overholt at redhat.com Wed Apr 12 16:07:06 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 12 Apr 2006 12:07:06 -0400 Subject: [fedora-java] eclipse-platform -> javadoc In-Reply-To: <443BDA60.2060007@cora.nwra.com> References: <443BDA60.2060007@cora.nwra.com> Message-ID: <20060412160706.GK8703@redhat.com> * Orion Poplawski [2006-04-11 12:34]: > Is the requirement of javadoc for eclipse-platform really necessary? > javadoc is huge! What do you mean? You mean you don't want the docs as part of the platform? This is part of the classic debate about whether we split packages into super-small pieces or keep them relatively close to their upstream downloadable counterparts. I've tended to favour the latter but I'm not married to that way of doing things. /usr/share/javadoc isn't relevant here. Andrew From orion at cora.nwra.com Wed Apr 12 16:29:57 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 12 Apr 2006 10:29:57 -0600 Subject: [fedora-java] eclipse-platform -> javadoc In-Reply-To: <20060412160706.GK8703@redhat.com> References: <443BDA60.2060007@cora.nwra.com> <20060412160706.GK8703@redhat.com> Message-ID: <443D2B05.6050205@cora.nwra.com> Andrew Overholt wrote: > * Orion Poplawski [2006-04-11 12:34]: >> Is the requirement of javadoc for eclipse-platform really necessary? >> javadoc is huge! > > What do you mean? You mean you don't want the docs as part of the > platform? This is part of the classic debate about whether we split > packages into super-small pieces or keep them relatively close to their > upstream downloadable counterparts. I've tended to favour the latter but > I'm not married to that way of doing things. > > /usr/share/javadoc isn't relevant here. > > Andrew Well, it is, but I suppose not directly: [root at cynosure ~]# du -sh /usr/share/javadoc/java-1.4.2-gcj-compat-1.4.2.0 235M /usr/share/javadoc/java-1.4.2-gcj-compat-1.4.2.0 [root at cynosure ~]# rpm -e java-1.4.2-gcj-compat-javadoc error: Failed dependencies: java-javadoc is needed by (installed) eclipse-platform-3.1.2-1jpp_13fc.i386 [root at cynosure ~]# rpm -e eclipse-platform error: Failed dependencies: eclipse-platform is needed by (installed) eclipse-cdt-3.0.2-1jpp_2fc.i386 eclipse-platform >= 1:3.1.2 is needed by (installed) eclipse-cdt-3.0.2-1jpp_2fc.i386 eclipse-platform < 1:3.1.3 is needed by (installed) eclipse-cdt-3.0.2-1jpp_2fc.i386 If I'm only going to be programming with eclipse in C/C++/Fortran using the CDT, I don't want a *LOT* (235MB!) of Java API documentation as well. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From overholt at redhat.com Wed Apr 12 16:37:07 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 12 Apr 2006 12:37:07 -0400 Subject: [fedora-java] eclipse-platform -> javadoc In-Reply-To: <443D2B05.6050205@cora.nwra.com> References: <443BDA60.2060007@cora.nwra.com> <20060412160706.GK8703@redhat.com> <443D2B05.6050205@cora.nwra.com> Message-ID: <20060412163707.GM8703@redhat.com> * Orion Poplawski [2006-04-12 12:30]: > > If I'm only going to be programming with eclipse in C/C++/Fortran using > the CDT, I don't want a *LOT* (235MB!) of Java API documentation as well. Okay, I think I have a solution. We need to put the ISV docs into the -devel packages. The user docs don't have the API docs and therefore don't have the java-javadoc (java-1.4.2-gcj-compat-javadoc here) dependency for symlinks. Can you file a bug to track this? Thanks, Andrew From orion at cora.nwra.com Wed Apr 12 16:43:53 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 12 Apr 2006 10:43:53 -0600 Subject: [fedora-java] eclipse-platform -> javadoc In-Reply-To: <20060412163707.GM8703@redhat.com> References: <443BDA60.2060007@cora.nwra.com> <20060412160706.GK8703@redhat.com> <443D2B05.6050205@cora.nwra.com> <20060412163707.GM8703@redhat.com> Message-ID: <443D2E49.6030704@cora.nwra.com> Andrew Overholt wrote: > > Okay, I think I have a solution. We need to put the ISV docs into the > -devel packages. The user docs don't have the API docs and therefore don't > have the java-javadoc (java-1.4.2-gcj-compat-javadoc here) dependency for > symlinks. > > Can you file a bug to track this? > > Thanks, > > Andrew Can I ever! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188724 Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From overholt at redhat.com Wed Apr 12 17:42:47 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 12 Apr 2006 13:42:47 -0400 Subject: [fedora-java] eclipse-platform -> javadoc In-Reply-To: <443D2E49.6030704@cora.nwra.com> References: <443BDA60.2060007@cora.nwra.com> <20060412160706.GK8703@redhat.com> <443D2B05.6050205@cora.nwra.com> <20060412163707.GM8703@redhat.com> <443D2E49.6030704@cora.nwra.com> Message-ID: <20060412174247.GN8703@redhat.com> * Orion Poplawski [2006-04-12 12:44]: > Andrew Overholt wrote: > > > >Okay, I think I have a solution. We need to put the ISV docs into the > >-devel packages. The user docs don't have the API docs and therefore don't > >have the java-javadoc (java-1.4.2-gcj-compat-javadoc here) dependency for > >symlinks. > > > >Can you file a bug to track this? > > Can I ever! > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188724 Giddy-up, thanks. > Thanks! No problem. Andrew From tromey at redhat.com Wed Apr 12 17:41:18 2006 From: tromey at redhat.com (Tom Tromey) Date: 12 Apr 2006 11:41:18 -0600 Subject: [fedora-java] SVN plugin In-Reply-To: <1144722594.6382.109.camel@dimi> References: <1144688945.6382.67.camel@dimi> <20060410172409.GB5417@redhat.com> <1144691126.6382.80.camel@dimi> <1144711378.28990.49.camel@toad.toronto.redhat.com> <1144722594.6382.109.camel@dimi> Message-ID: >>>>> "Dimi" == Dimi Paun writes: Dimi> There are too many battles to be fought, I can't fight them all -- Dimi> if you guys have any input on the eclipse ML, please try to get Dimi> that silly UI design simplified. Maybe just: Dimi> Help | Manage Configuration Dimi> and from Manage Configuration you should be able to do everything: Dimi> add/remove/update plugins/extensions/etc. I've heard a vague rumor or two that the update manager is going to be redone. Anyway, in Eclipse pretty much everything is done via bugzilla. So, file a bug, post the URL here, and we can all vote for it :-) Tom From jjohnstn at redhat.com Wed Apr 12 23:09:09 2006 From: jjohnstn at redhat.com (Jeff Johnston) Date: Wed, 12 Apr 2006 19:09:09 -0400 Subject: [fedora-java] Autotools? Message-ID: <443D8895.9090206@redhat.com> Gareth, The Autotools plugin is very much in its infancy. There are no firm plans regarding how it will be released. Andrew and Ben have discussed the project briefly with the CDT folks at EclipseCon and there is reportedly interest in pushing the work into the CDT. Obviously, that is a preferred strategy. We can make it much leaner and cleaner with the CDT folks' help. I haven't started a serious dialog with the CDT folks yet, but it is certainly on my TODO list. At the moment, the project is a hack with us basing ourselves on a Managed Make project and stodifying pieces of Std Make (e.g. Make target support). This approach was taken mostly because a Managed Make project had an extension for Makefile generation which we matched up with configuration. The Std Make project has Make Target support which is a must-have feature when dealing with all the myriad of existing projects. Our target is existing Open Source C/C++ projects. Complex projects with history behind them. I am the head maintainer of newlib and so my first goal was to get newlib to configure/build/install from within the CDT (done, btw). Newlib has some interesting problems and I am sure there are many other projects out there that will prove to be even more challenging. Short-term has been essentially hacking together a working model which we are building upon and refining. We have not ironed out what the full feature-set will look like and definitely want to solicit requirements. At present, you check out an Open Source project, then in a separate step, you convert it to an Autotools C/C++ project (New..Other). Through project properties, you can set up your configuration options, where the build ends up (currently, defaults to build subdirectory), include path, and various CDT Managed Make options. The include path is required to get the indexing to work properly. Once this is done, you can add Make targets via , which has been added to the project menu. This feature corresponds directly with Create Make Target/Build Make Target for a Std Make project, but we couldn't use that once we had chosen the Managed Make base. Workarounds of this type are things the CDT folks can help us clean up. If you choose the default Rebuild Project, etc.. you are dealing with the standard "all" and "clean" make targets. Configuration is done for you (including autogen support) and the results are stored in a separate console. I just added help docs for the Gnu tools (gcc, binutils, automake, autoconf). There are definitely warts, but it is starting to take shape and you can easily see its potential. Long-term, we would like to see development of C/C++ Open Source projects see some more of the benefits that Java programmers have. One of the key changes I would like to see is live compilation/parsing as you get for Java. If we could eliminate typos, flag missing declarations and illegal operations, or suggest include files, then the CDT ends up being a helpful tool to Open Source C/C++ development. We have had brief discussions with gcc folks here to see what it would take to have the compiler help with sort of thing, but it is large undertaking. Another possibility would be to attack this problem from the indexing side. For all I know, the CDT folks are already examining this. Again, long term, but important to start now. I hope this clarifies things a bit. I will be updating the web-page shortly to provide a lot more details than is presently there. -- Jeff J. From: "Foster, Gareth" > To: fedora-devel-java-list at redhat.com > X-Mailer: Internet Mail Service (5.5.2657.72) > Date: Wed, 12 Apr 2006 17:00:58 +0100 > Subject: [fedora-java] Autotools? > > Hello list, > > This is a pretty open ended question really. Autotools plugin? Going in > extras for FC5? Only going in FC6? Abandoned? Subject to furious hacking? > Picked up code from Kdevelop? > > They are all questions people would be interested in having the answers to. > How about a status update or roadmap? As a reply to this, or maybe as a > gnomedesktop.org post? > > Cheers, > > Gaz > > -- > fedora-devel-java-list mailing list > fedora-devel-java-list at redhat.com > From robert at marcanoonline.com Thu Apr 20 20:11:20 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 20 Apr 2006 16:11:20 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin Message-ID: <1145563881.16534.15.camel@tprobert.intranet.promca.com> Hello everyone on the list.. I have been working on packaging subclipse, the Eclipse Subversion plugin in order to add it to Fedora Extras. After learning how to generate RPMs with the correct gcj compiled libraries, I am nearly ready to finish it, but I am stuck on a problem (see http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/exception.log) The SVNClient class is not found by gij, but when it is ran under Sun JVM, it is found. After fixing this. there are only two things remaining, package ganymed.jar and javasvn.jar as external RPMs and not use the binaries that are on the subclipse repository (why everyone store binaries on their repositories.. yuck :-P) Anyone knows what can be the cause of this problem?. I see that all the classes and classpath references are ok, even the a process is loading the correct shared libraries /usr/lib/gcj/svnClientAdapter/svnClientAdapter-1.0.1.jar.so /usr/share/java/svnClientAdapter-1.0.1.jar /usr/lib/libsvnjavahl-1.so.0.0.0 /usr/lib/svn-javahl/svn-javahl.jar All the packages (SRPMs, RPMS, and spec files) can be downloaded from http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse Thanks in advance ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From bkonrath at redhat.com Thu Apr 20 23:16:26 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 20 Apr 2006 19:16:26 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1145563881.16534.15.camel@tprobert.intranet.promca.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> Message-ID: <1145574986.8984.48.camel@toad.toronto.redhat.com> Hi Robert, On Thu, 2006-04-20 at 16:11 -0400, Robert Marcano wrote: > Hello everyone on the list.. I have been working on packaging subclipse, > the Eclipse Subversion plugin in order to add it to Fedora Extras. That's great! I was planning to look into packaging subclipse tomorrow, but it seems you have a head start on me :) I don't know off hand why your getting that error, but I do have few questions about your general build procedure: First, do you have instructions for generating those source tarballs? Andrew Overholt and I have been putting instructions for generating these in the comments of the spec file. We're hoping that we will be able to share these instructions with other distros and documenting these steps allows others to reproduce the tarball easily. Next, would you consider using the build procedure outlined here?: https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00060.html This would eliminate the need to generate the build.xml's with Eclipse and then add them in as a patch. For small projects, this is not a big deal, but it would get annoying for larger features or if you had to do a lot of packaging. Generating a source tarball would then be a simple as checking out the correct tag from cvs, deleting any jars and compressing it up. Long term I'd like to get the upstream projects to use Eclipse to export source drops that are compatible with this plugin builder when they spin a release. This would avoid problem with projects that don't properly tag cvs. The plugin builder is not quite ready yet. My plan is to fix the last few problems tomorrow and whip up some test rpms early next week. I'll probably start with what you posted if that's ok. If you IRC, I hang out on freenode in #fodora-java and my nick is scsibear. Anyway, I hope we can work together on getting this into Extras. I know the there are a lot of people waiting for this plugin to get packaged up. Cheers, Ben From robert at marcanoonline.com Fri Apr 21 12:54:37 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Fri, 21 Apr 2006 08:54:37 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1145574986.8984.48.camel@toad.toronto.redhat.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> Message-ID: <1145624077.2759.12.camel@tprobert.intranet.promca.com> On Thu, 2006-04-20 at 19:16 -0400, Ben Konrath wrote: > Hi Robert, > > On Thu, 2006-04-20 at 16:11 -0400, Robert Marcano wrote: > > Hello everyone on the list.. I have been working on packaging subclipse, > > the Eclipse Subversion plugin in order to add it to Fedora Extras. > > > That's great! I was planning to look into packaging subclipse tomorrow, > but it seems you have a head start on me :) > > I don't know off hand why your getting that error, but I do have few > questions about your general build procedure: First, do you have > instructions for generating those source tarballs? Andrew Overholt and I > have been putting instructions for generating these in the comments of > the spec file. We're hoping that we will be able to share these > instructions with other distros and documenting these steps allows > others to reproduce the tarball easily. I have uploaded two fetch* scripts one to download svnClientAdapter sources, and the other for subclipse. The scripts also remove a few DLLs that are on the repository because they will not be needed http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/fetch-svnClientAdapter http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/fetch-subclipse I think that they can be added to the SRPMs as unused sources > > Next, would you consider using the build procedure outlined here?: > > https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00060.html no problem... I will try it > > This would eliminate the need to generate the build.xml's with Eclipse > and then add them in as a patch. For small projects, this is not a big > deal, but it would get annoying for larger features or if you had to do > a lot of packaging. Generating a source tarball would then be a simple > as checking out the correct tag from cvs, deleting any jars and > compressing it up. Long term I'd like to get the upstream projects to > use Eclipse to export source drops that are compatible with this plugin > builder when they spin a release. This would avoid problem with projects > that don't properly tag cvs. > > The plugin builder is not quite ready yet. My plan is to fix the last > few problems tomorrow and whip up some test rpms early next week. I'll > probably start with what you posted if that's ok. If you IRC, I hang out > on freenode in #fodora-java and my nick is scsibear. mine is robmv > > Anyway, I hope we can work together on getting this into Extras. I know > the there are a lot of people waiting for this plugin to get packaged > up. > > Cheers, Ben > ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From tromey at redhat.com Fri Apr 21 15:03:35 2006 From: tromey at redhat.com (Tom Tromey) Date: 21 Apr 2006 09:03:35 -0600 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1145563881.16534.15.camel@tprobert.intranet.promca.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> Message-ID: >>>>> "Robert" == Robert Marcano writes: Robert> The SVNClient class is not found by gij, but when it is ran under Sun Robert> JVM, it is found. Do you get a stack trace in the .log file (or elsewhere)? That might help us diagnose the problem. Tom From tromey at redhat.com Fri Apr 21 15:20:56 2006 From: tromey at redhat.com (Tom Tromey) Date: 21 Apr 2006 09:20:56 -0600 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> Message-ID: Robert> The SVNClient class is not found by gij, but when it is ran under Sun Robert> JVM, it is found. Tom> Do you get a stack trace in the .log file (or elsewhere)? Tom> That might help us diagnose the problem. Mark pointed out that you did supply a backtrace and I just didn't see it there in front of me. Sorry about that. This looks strange: java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} ... since it doesn't seem like it should be using the system class loader here. But sometimes these class-not-found traces are odd. I guess I would start by trying to see what class loader is really being used to load this code. If that is wrong things usually go bad; then you'd have to track down why that went wrong. If it is the right loader (and the error message is what is weird) then the problem may be simpler to track down... bad linking or something. Are you BC-compiling this code? You can try interpreting, sometimes that makes link problems go away. In this case there may be some workarounds... Tom From robert at marcanoonline.com Fri Apr 21 15:54:07 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Fri, 21 Apr 2006 11:54:07 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> Message-ID: <1145634847.2759.17.camel@tprobert.intranet.promca.com> On Fri, 2006-04-21 at 09:20 -0600, Tom Tromey wrote: > Robert> The SVNClient class is not found by gij, but when it is ran under Sun > Robert> JVM, it is found. > > Tom> Do you get a stack trace in the .log file (or elsewhere)? > Tom> That might help us diagnose the problem. > > Mark pointed out that you did supply a backtrace and I just didn't > see it there in front of me. Sorry about that. > > This looks strange: > > java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} debugging with (it is an static method) System.out.println(JhlClientAdapter.class.getClassLoader()); showed: org.eclipse.core.runtime.adaptor.EclipseClassLoader at 2d78620 > ... since it doesn't seem like it should be using the system class > loader here. But sometimes these class-not-found traces are odd. > > I guess I would start by trying to see what class loader is really > being used to load this code. If that is wrong things usually go bad; > then you'd have to track down why that went wrong. > > If it is the right loader (and the error message is what is weird) > then the problem may be simpler to track down... bad linking or > something. > > Are you BC-compiling this code? You can try interpreting, sometimes > that makes link problems go away. In this case there may be some > workarounds... I disabled aot-compile-rpm for the svnClientAdapter and subclipse RPMs in order to run with the interpreter, the same problem > > > Tom > ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From tromey at redhat.com Wed Apr 26 00:55:43 2006 From: tromey at redhat.com (Tom Tromey) Date: 25 Apr 2006 18:55:43 -0600 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1145634847.2759.17.camel@tprobert.intranet.promca.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145634847.2759.17.camel@tprobert.intranet.promca.com> Message-ID: >>>>> "Robert" == Robert Marcano writes: Robert> debugging with (it is an static method) Robert> System.out.println(JhlClientAdapter.class.getClassLoader()); Robert> showed: Robert> org.eclipse.core.runtime.adaptor.EclipseClassLoader at 2d78620 Ok. That looks correct enough. >From the stack trace: java.lang.ClassNotFoundException: org.tigris.subversion.javahl.SVNClient not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/eclipse/startup.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass (libgcj.so.7) at java.lang.ClassLoader.loadClass (libgcj.so.7) at java.lang.ClassLoader.loadClass (libgcj.so.7) at org.tigris.subversion.svnclientadapter.javahl.JhlClientAdapter.isAvailable (svnClientAdapter-1.0.1.jar.so) What does JhlClientAdapter.isAvailable() look like? On what class loader is it calling loadClass()? Robert> I disabled aot-compile-rpm for the svnClientAdapter and subclipse RPMs Robert> in order to run with the interpreter, the same problem This rules out most of the linking oddities that might ordinarily cause problems. Offhand I don't know what to suggest :-(. If I were looking into this I would probably start by Tom From dimi at lattica.com Wed Apr 26 03:36:56 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 25 Apr 2006 23:36:56 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145634847.2759.17.camel@tprobert.intranet.promca.com> Message-ID: <1146022616.2624.7.camel@dimi> On Tue, 2006-04-25 at 18:55 -0600, Tom Tromey wrote: > This rules out most of the linking oddities that might ordinarily > cause problems. Offhand I don't know what to suggest :-(. If I were > looking into this I would probably start by > > Tom Oh, come on, finish the sentence, the tension is killing us :) -- Dimi Paun Lattica, Inc. From tromey at redhat.com Wed Apr 26 15:13:11 2006 From: tromey at redhat.com (Tom Tromey) Date: 26 Apr 2006 09:13:11 -0600 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1146022616.2624.7.camel@dimi> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145634847.2759.17.camel@tprobert.intranet.promca.com> <1146022616.2624.7.camel@dimi> Message-ID: >>>>> "Dimi" == Dimi Paun writes: >> This rules out most of the linking oddities that might ordinarily >> cause problems. Offhand I don't know what to suggest :-(. If I were >> looking into this I would probably start by Dimi> Oh, come on, finish the sentence, the tension is killing us :) Oops :-) I meant to say that I would start by BC-compiling the plugin and stepping through isAvailable with gdb, to see what goes wrong. This is kind of a pain to do, though, since gdb doesn't work so well with exceptions, and class loading typically throws several during the normal course of operation. Tom From bkonrath at redhat.com Thu Apr 27 06:15:47 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 27 Apr 2006 02:15:47 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1145624077.2759.12.camel@tprobert.intranet.promca.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> <1145624077.2759.12.camel@tprobert.intranet.promca.com> Message-ID: <1146118547.4235.2.camel@toad.toronto.redhat.com> Hi Robert, I sat down on Friday to fix up the pluginbuilder stuff, but I ended up not liking that solution too much. One of the biggest problems is that it's difficult to display build information during the compilation because Eclipse does the build file generation and the building internally. Obviously displaying this information is important for rpm builds - if there were a problem, there would be no way to figure out what was going on. I could have hacked this in, but I found a different way to do things which is better because we won't have to maintain the pluginbuilder plugin. What I did was create a generic releng plugin that features/plugins can use to hide the details of the Eclipse releng process. The source archive should be a tarred up eclipse project checked directly out of cvs or svn. The source archive could also be a tar.gz or zip exported by eclipse at the same time the features/plugins are exported as a deployable plugin or feature. I'm going to write a little doc that explains how to do this so that we can get upstream people to do this in the future. One of the subclipse developers saw my previous post and said he would be interested in helping out. I updated the subclipse and svn-client-adapter rpms that you posted and and changed a few things: http://people.redhat.com/bkonrath/eclipse/ I may have been a little aggressive with the changes, so feel free to slap me if you don't like anything or if anything is incorrect :) As far as the actual compilation goes, all you have to do is this: java -cp %{eclipse_base}/startup.jar \ -Duser.home=$homedir \ org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -Dtype=feature \ -Did=org.tigris.subversion.subclipse \ -DbaseLocation=%{eclipse_base} \ -Dbuilder=%{_builddir}/package-build \ -DsourceDirectory=$(pwd) \ -f %{eclipse_base}/plugins/org.eclipse.pde.build_3.1.2/scripts/build.xml Just set the type and id, everything else is just template. There's other templated stuff in there, but I think it's relatively straight forward. It's unfortunate that subclipse is a little complicated because it makes things look more confusing than they are. Given a source tarball and a feature id, it's possible to generate a template for these spec files. I'll probably whip something up when I have some time. To test this build method, I packaged up PHPeclipse in about 40mins. Most of the time was spent figuring out how to check out the correct version of the source. Now that's not say things are perfect, but I think this method is the best way to proceed. I'm sure there will be some problems with other plugins, but the pde.build process is very flexible so I think we'll be able to sort out any problems that arise. As far the 'SVNClient class not found problem' goes, I noticed that this only happens when the subversion-javahl rpm is installed. Maybe we can mark the subversion-javahl rpm as a conflicting package for now and carry on with getting this into extras. I think subclipse can work without the javahl jar so we should be ok. If you could file a bug about this in the redhat bugzilla, that would be great. Robert, once we put the generic releng scripts in the SDK rpm, would you be interested in being the subclipse rpm maintainer? If anybody has any questions or comments about what's going on with packaging plugins I would be glad to hear them. Cheers, Ben From robert at marcanoonline.com Thu Apr 27 12:33:05 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 27 Apr 2006 08:33:05 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145634847.2759.17.camel@tprobert.intranet.promca.com> Message-ID: <1146141185.2753.8.camel@tprobert.intranet.promca.com> On Tue, 2006-04-25 at 18:55 -0600, Tom Tromey wrote: > > What does JhlClientAdapter.isAvailable() look like? On what class > loader is it calling loadClass()? The isAvailable method is really a ugly http://subclipse.tigris.org/source/browse/subclipse/tags/subclipse/1.0.1/svnClientAdapter/src/main/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapter.java?rev=2190&view=auto&content-type=text/vnd.viewcvs-markup ignoring the Windows part of the code, this method loads the javahl JNI library. I tried removing it in order to see if the problem is caused by loading two times the same library (I readed somewhere that one JNI library can not be loaded by two different classloaders) but this does not solved the problem > > Robert> I disabled aot-compile-rpm for the svnClientAdapter and subclipse RPMs > Robert> in order to run with the interpreter, the same problem > > This rules out most of the linking oddities that might ordinarily > cause problems. Offhand I don't know what to suggest :-(. If I were > looking into this I would probably start by well, this will take some time for me because i am not an expert debugging with gdb, but this is an excuse to learn it :-). > > Tom ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From overholt at redhat.com Thu Apr 27 12:52:07 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Apr 2006 08:52:07 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1146118547.4235.2.camel@toad.toronto.redhat.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> <1145624077.2759.12.camel@tprobert.intranet.promca.com> <1146118547.4235.2.camel@toad.toronto.redhat.com> Message-ID: <20060427125207.GA4118@redhat.com> Hi Ben, * Ben Konrath [2006-04-27 02:16]: > > [...] but I found a different way to do things which is better because we > won't have to maintain the pluginbuilder plugin. > > What I did was create a generic releng plugin that features/plugins can > use to hide the details of the Eclipse releng process. Nice! Can you post this? Andrew From robert at marcanoonline.com Thu Apr 27 12:51:32 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 27 Apr 2006 08:51:32 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1146118547.4235.2.camel@toad.toronto.redhat.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> <1145624077.2759.12.camel@tprobert.intranet.promca.com> <1146118547.4235.2.camel@toad.toronto.redhat.com> Message-ID: <1146142293.2753.17.camel@tprobert.intranet.promca.com> On Thu, 2006-04-27 at 02:15 -0400, Ben Konrath wrote: > Hi Robert, > > I sat down on Friday to fix up the pluginbuilder stuff, but I ended up > not liking that solution too much. One of the biggest problems is that > it's difficult to display build information during the compilation > because Eclipse does the build file generation and the building > internally. Obviously displaying this information is important for rpm > builds - if there were a problem, there would be no way to figure out > what was going on. I could have hacked this in, but I found a different > way to do things which is better because we won't have to maintain the > pluginbuilder plugin. > > What I did was create a generic releng plugin that features/plugins can > use to hide the details of the Eclipse releng process. The source > archive should be a tarred up eclipse project checked directly out of > cvs or svn. The source archive could also be a tar.gz or zip exported by > eclipse at the same time the features/plugins are exported as a > deployable plugin or feature. I'm going to write a little doc that > explains how to do this so that we can get upstream people to do this in > the future. One of the subclipse developers saw my previous post and > said he would be interested in helping out. Nice.. > > I updated the subclipse and svn-client-adapter rpms that you posted and > and changed a few things: > > http://people.redhat.com/bkonrath/eclipse/ > > I may have been a little aggressive with the changes, so feel free to > slap me if you don't like anything or if anything is incorrect :) no slap for you... the changes are for a better spec file > > As far as the actual compilation goes, all you have to do is this: > > java -cp %{eclipse_base}/startup.jar \ > -Duser.home=$homedir \ > org.eclipse.core.launcher.Main \ > -application org.eclipse.ant.core.antRunner \ > -Dtype=feature \ > -Did=org.tigris.subversion.subclipse \ > -DbaseLocation=%{eclipse_base} \ > -Dbuilder=%{_builddir}/package-build \ > -DsourceDirectory=$(pwd) \ > -f %{eclipse_base}/plugins/org.eclipse.pde.build_3.1.2/scripts/build.xml > > Just set the type and id, everything else is just template. There's > other templated stuff in there, but I think it's relatively straight > forward. > > It's unfortunate that subclipse is a little complicated because it makes > things look more confusing than they are. Given a source tarball and a > feature id, it's possible to generate a template for these spec files. > I'll probably whip something up when I have some time. > > To test this build method, I packaged up PHPeclipse in about 40mins. > Most of the time was spent figuring out how to check out the correct > version of the source. Now that's not say things are perfect, but I > think this method is the best way to proceed. I'm sure there will be > some problems with other plugins, but the pde.build process is very > flexible so I think we'll be able to sort out any problems that arise. > > As far the 'SVNClient class not found problem' goes, I noticed that this > only happens when the subversion-javahl rpm is installed. Maybe we can > mark the subversion-javahl rpm as a conflicting package for now and > carry on with getting this into extras. I think subclipse can work > without the javahl jar so we should be ok. If you could file a bug about > this in the redhat bugzilla, that would be great. ummm interesting, when subversion-javahl is not installed SVNClientAdapter reverts to use the JavaSVN version. I think that a little patch to disable and remove the svnjavahl.jar jar file insode the plugin can do the trick too > > Robert, once we put the generic releng scripts in the SDK rpm, would you > be interested in being the subclipse rpm maintainer? Sure... I will try this changes, complete the TODOs and then submit it to extras > > If anybody has any questions or comments about what's going on with > packaging plugins I would be glad to hear them. > > Cheers, Ben > ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From bkonrath at redhat.com Thu Apr 27 15:21:23 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 27 Apr 2006 11:21:23 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <20060427125207.GA4118@redhat.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> <1145624077.2759.12.camel@tprobert.intranet.promca.com> <1146118547.4235.2.camel@toad.toronto.redhat.com> <20060427125207.GA4118@redhat.com> Message-ID: <1146151284.9734.13.camel@localhost.localdomain> On Thu, 2006-04-27 at 08:52 -0400, Andrew Overholt wrote: > Hi Ben, > > * Ben Konrath [2006-04-27 02:16]: > > > > [...] but I found a different way to do things which is better because we > > won't have to maintain the pluginbuilder plugin. > > > > What I did was create a generic releng plugin that features/plugins can > > use to hide the details of the Eclipse releng process. > > Nice! Can you post this? It's in the subversion srpm in package-build.tar.gz: http://people.redhat.com/bkonrath/eclipse/subclipse-1.0.1-1.src.rpm Ben From bkonrath at redhat.com Fri Apr 28 02:45:06 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Thu, 27 Apr 2006 22:45:06 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1146142293.2753.17.camel@tprobert.intranet.promca.com> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> <1145624077.2759.12.camel@tprobert.intranet.promca.com> <1146118547.4235.2.camel@toad.toronto.redhat.com> <1146142293.2753.17.camel@tprobert.intranet.promca.com> Message-ID: <1146192306.15599.55.camel@localhost.localdomain> On Thu, 2006-04-27 at 08:51 -0400, Robert Marcano wrote: > On Thu, 2006-04-27 at 02:15 -0400, Ben Konrath wrote: > > The source archive could also be a tar.gz or zip exported by > > eclipse at the same time the features/plugins are exported as a > > deployable plugin or feature. I'm going to write a little doc that > > explains how to do this so that we can get upstream people to do this in > > the future. One of the subclipse developers saw my previous post and > > said he would be interested in helping out. OK, here's the doc: http://people.redhat.com/bkonrath/eclipse/exporting-buildable-source-archives.html I just posted a message to the subclipse list asking them to provide a proper source archive and I talked to a phpeclipse developer on irc today who said that he would provide a source archive too. > > I updated the subclipse and svn-client-adapter rpms that you posted and > > and changed a few things: > > > > http://people.redhat.com/bkonrath/eclipse/ > > > > I may have been a little aggressive with the changes, so feel free to > > slap me if you don't like anything or if anything is incorrect :) > > no slap for you... the changes are for a better spec file Phew :) One thing I forgot was to put a 'Provides eclipse-svn'. Do you think this is a good idea? > ummm interesting, when subversion-javahl is not installed > SVNClientAdapter reverts to use the JavaSVN version. I think that a > little patch to disable and remove the svnjavahl.jar jar file insode the > plugin can do the trick too Yeah that would work and it's probably a little better if we're trying to get this into Extras. BTW, can you put me in the CC field of the package review request once it gets going? Thanks. > > Robert, once we put the generic releng scripts in the SDK rpm, would you > > be interested in being the subclipse rpm maintainer? > > Sure... I will try this changes, complete the TODOs and then submit it > to extras Ok, I'll put this package-build stuff into the main SDK and update the Eclipse in FC5. Ben From robert at marcanoonline.com Fri Apr 28 03:57:57 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Thu, 27 Apr 2006 23:57:57 -0400 Subject: [fedora-java] Hello and SVN subclipse plugin In-Reply-To: <1146192306.15599.55.camel@localhost.localdomain> References: <1145563881.16534.15.camel@tprobert.intranet.promca.com> <1145574986.8984.48.camel@toad.toronto.redhat.com> <1145624077.2759.12.camel@tprobert.intranet.promca.com> <1146118547.4235.2.camel@toad.toronto.redhat.com> <1146142293.2753.17.camel@tprobert.intranet.promca.com> <1146192306.15599.55.camel@localhost.localdomain> Message-ID: <1146196677.28750.7.camel@localhost.localdomain> On Thu, 2006-04-27 at 22:45 -0400, Ben Konrath wrote: > I just posted a message to the subclipse list asking them to provide a > proper source archive and I talked to a phpeclipse developer on irc > today who said that he would provide a source archive too. that will be nice, since svnClientAdapter is being marked as version 1.0.1 but this is the version of subclipse, svnClientAdapter is not correctly tagged on the repository since 0.9.4 and currently the build.properties says it is 0.9.35, but I do not trust that value ... > > ummm interesting, when subversion-javahl is not installed > > SVNClientAdapter reverts to use the JavaSVN version. I think that a > > little patch to disable and remove the svnjavahl.jar jar file insode the > > plugin can do the trick too I just finished this part, removing the svnjavahl.jar did not made the trick work. I needed to patch a few lines of subclipse to set javasvn as the default SVN interface. > > Yeah that would work and it's probably a little better if we're trying > to get this into Extras. BTW, can you put me in the CC field of the > package review request once it gets going? Thanks. > > > > Robert, once we put the generic releng scripts in the SDK rpm, would you > > > be interested in being the subclipse rpm maintainer? > > > > Sure... I will try this changes, complete the TODOs and then submit it > > to extras > > Ok, I'll put this package-build stuff into the main SDK and update the > Eclipse in FC5. > > Ben > > ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD