java-devel April 2013

java-devel@lists.fedoraproject.org

16 participants
13 discussions

Shipping of binaries in jar files
by Orion Poplawski 03 May '13

03 May '13

The eclipse PTP project that I package is starting to ship an executable in one of its plugins. The executable is packed into a jar file. This prevents debuginfo creation for the executable. I started taking a look at how this might be handled elsewhere and found: /usr/lib64/eclipse/dropins/cdt/eclipse/plugins/org.eclipse.cdt.core.linux.x86_64_5.2.0.201302132326.jar: 13327 Defl:X 3624 73% 02-13-2013 23:21 326488c7 os/linux/x86_64/libpty.so 23720 Defl:X 7151 70% 02-13-2013 23:21 c26c2c94 os/linux/x86_64/libspawner.so but no debuginfo package. Thoughts, comments? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

8 13

Any dependancy resolution tricks?
by Troy Dawson 26 Apr '13

26 Apr '13

Hi, I've been trying to get activemq to build on F19. Although it built on F19 originally, it no longer does. Without changing the package, all the dependencies have changed. (And the %build section, but that was the simple fix.) It's taken me several days of trial and error to get through one section of building, and I think I'm on my last, but I just cannot figure out what provides the following dependancies. [ERROR] Failed to execute goal on project activemq-core: Could not resolve dependencies for project org.apache.activemq:activemq-core:bundle:5.6.0: The following artifacts could not be resolved: org.springframework:spring-test:jar:SYSTEM, commons-primitives:commons-primitives:jar:1.0, axion:axion:jar:1.0-M3-dev, org.apache.ftpserver:ftpserver-core:jar:1.0.0: The repository system is offline but the artifact org.springframework:spring-test:jar:SYSTEM is not available in the local repository. -> [Help 1] Is there a java/maven/rpm/yum trick for figuring out which packages I need install to resolve those dependencies? Troy

3 2

Ant provides cleanup
by Aleksandar Kurtakov 22 Apr '13

22 Apr '13

Ant was shipping with virtual provides for certain dead subpackages for few years already. As software collections are more and more common nowadays it was high time to drop them so collections don't interfere with base platform. The two most problems packages might see FTBFS due to no longer available ant-trax and/or ant-nodeps - both were merged into main ant.jar since version 1.8.2 (December 27th, 2010). If your package built just fine up to now but fails due to these changes the fix should be just replacing BuildRequires: ant-[nodeps,trax] with BuildRequires: ant. P.S. If you see a problem but you don't have the time or power to change it - let me know and I'll use my proven packager to fix it. Alexander Kurtakov Red Hat Eclipse team

4 5

Re: [fedora-java] Join "Maven FOSS Repository Extension " for GSOC 2013
by Mikolaj Izdebski 22 Apr '13

22 Apr '13

Hi Carlo and Malintha, I am CCing java-devel so that this information can be easily pointed to in future, if needed. > Mikolaj has asked to be co-mentor on this one. He is the author of xmvn, > which is a similar tool. > Before we move on, we need to establish the scope of fmvn vs xmvn. If > there is no differentiation then there is no need to work on fmvn. :-) > For one I still see the main goal for xmvn to be 'simplifying packaging > on Fedora' vs fmvn's 'build from a sanctioned repository'. I think that there are many similarities. But first let me introduce XMvn. XMvn is a project with similar, but wider scope than Maven FOSS Repository Extension (FRE). You can see its Maven-generated website [1], git repository [2] and github mirror [3]. I have never used FRE before, but I looked briefly at the code. From what I suppose XMvn can do all that FRE can. A short comparison follows. Scope FRE seems to have a very precise goal: resolve all dependencies from local repository. XMvn goes beyond that. Besides doing what FRE does XMvn also: * allows to blacklist some artifacts (whenever they are used as dependency or plugin they are removed from POM during validation); this is especially useful for plugins (for eg. you don't want to use bugreport plugin to build Fedora packages, so it's best to ban it) * provides MOJO to create JPP-style repository from artifacts in reactor (it creates layout that follows Fedora packaging guidelines, creating JPP depmap files and so on) * provides information for building RPMs (like outputing list of files so they can be used in RPM %files section, or list of direct dependency artifacts that can be used to generate BuildRequires) * enforce other rules when building projects (for example force minimal Java source format; older formats are not supported with newer JDKs) * provides other useful tools (xmvn-resolve, xmvn-bisect) Implementation details Both FRE and XMvn are pure-Java implementations. They both provide Plexus components that override default Maven components and this way can redefine standard Maven behaviour. To ease maintenance XMvn tries to redefine as few Plexus components as possible and delegate real work to default Maven components. Configuration FRE is configured by defining environmental variables and system properties. Configuration of XMvn 0.4.0 and later is specified in XML format [4]. System-interdependence Both XMvn and FRE are system-independent. They can be successfully used on non-Fedora systems. (For example I use XMvn on Debian.) Licensing XMvn is licensed under ASL 2.0 license, which is exactly the same as upstream Maven. FRE is licensed under BSD license. Although both licenses are good, in my opinion it's better to keep the same licensing as Maven itself (i.e. ASL 2.0). Code style XMvn uses maven coding guidelines, FRE uses different style. In my opinion Maven coding style should be followed when developing extensions for Maven. XMvn is already packaged for Fedora (currently F-19+, but could be easily added to F-17 and later). It is behind the implementation of mvn-rpmbuild and mvn-local scripts as well as %mvn_build macro. All Maven packages in Fedora 19 and later are built with XMvn. I think that FRE and XMvn have a lot of similarities. Instead of developing and maintaining separate projects we should combine our efforts. I am open for discussion, suggestions, RFEs and contributions. Because XMvn has more generic approach and it's already packaged and used in Fedora, I think that any future development should rather focus on XMvn. Please let me know what you think and correct me if I'm wrong somewhere about FRE. I have never used it before so thanks for understanding. -- Mikolaj Izdebski IRC: mizdebsk [1] http://mizdebsk.fedorapeople.org/xmvn/ [2] http://git.fedorahosted.org/git/xmvn.git [3] http://github.com/mizdebsk/xmvn [4] http://mizdebsk.fedorapeople.org/xmvn/site/xmvn-core/config.html

1 0

Eclipse WTP problems...
by Gerard Ryan 19 Apr '13

19 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ...there are many :/ Hi java folk, None of the Eclipse WTP stack is currently built on f19, and most of it needs to be updated, and upstream has moved from cvs to git. I'm going to focus as much of my time-available-to-spend-on-fedora as I can, to rectifying that, but I'm running into some issues that I'll need help with: 1. eclipse-wtp-common has been bundling a jar for a long time[0], and I tried to fix that, by deleting and rebuilding that jar using javac/jar commands. Problem is I was using %{_libdir} to add a jar from eclipse-platform to the classpath, and eclipse-platform is archfull but this package is noarch. Is there a better solution? It's not my package, so I don't want to do something like make it archfull if that's not necessary. 2. I've proposed a patch for eclipse-wtp-servertools[1] a while back that hasn't seen any activity. Eclipse WTP packages in Fedora basically need to be build in the order: common, servertools, sourceediting, webservices (I can't remember what's after that, but the rest are mostly my packages, so I'll figure that out when I get that far). The problem here is that the first three are not mine, and the maintainer for servertools/sourceediting doesn't seem to be very active at the moment, and I'm not going to try to update sourceediting and propose a patch until I can build it against common and servertools without having to hack unmerged packages into mock. I've applied for acls on both in pkgdb, and I'm happy to spend time whipping them into shape, since a significant percentage of my packages depend on them directly. There are other problems with WTP packages, but these are the most immediate ones, and the others escape me right now. If anybody can propose solutions to the above, or move things along in any way, I'd really appreciate it! Thanks, Gerard. [0] https://bugzilla.redhat.com/show_bug.cgi?id=922452 [1] https://bugzilla.redhat.com/show_bug.cgi?id=927023 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRcPWHAAoJEG7cfkpivEoVNAUP/3laSOwQTBDGTYuEP3cvbQm4 XqbHrMq6s0yHeXmDLE+2SwM6+JZ/1il69p4jVWwqi9hlB1ESUMP8v0w1pCRG0GRL rZSYrGhxOLg1IYZMjGY8Ov+L6Q84N53mCZJIcUW9Henc32CGoPdWTojvYiu+fCXW o/eQd0ILxyaqrcom4kIGzNlnmurc0p40NmBNHL4d51wjTUjz6Vt17pXPBvMfXjnK v3x3Jza4usE2YOYR4FD9sLISZEoBNSkkPsedIqYTwoZ/VwSB0bDrwQkDSJ6HVqGd iHbfomxNf5SrCu4dybAsrai/RFhv8fhGeFm5VpBE6b+6hfi5aEaKUZaCL9ZlCSOE ZUAmQ6PqJ7BYoyXMCMDRFVr55JXZCR73oQ9APdqCsM12IAzQqHP3bmmhV0iRpqEr LezK438iU8PlcLAA9m1g/XSwfzQi7+av5oV1mVddzIwBsZu2M8bKcGdH3w3XoG4I TBmfMSZo1HBjEdFWKPpTJ/X0LYUkRkXbWqOGvlsYFqVg/Zh424LYI9yi0Pkqpc5G OobhT3bCJ3SpDiKYPBGH7dSM6lCN1N5cUy5w2pWhlejpoUhnHqXRlvdr621tMwKN o9KskhVXZxCdQFgHANY7d6/mXofmYQxDtDc1t+dEA4DWsa6hP8GBV0TUeEQxx2Rm nDZ/CrDLItHYX92mINFL =KoBh -----END PGP SIGNATURE-----

4 4

Re: [fedora-java] Eclipse WTP problems...
by Gerard Ryan 19 Apr '13

19 Apr '13

On Fri, Apr 19, 2013 at 9:48 AM, Mary Ellen Foster <mefoster(a)gmail.com> wrote: > > On 19 April 2013 09:13, Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote: >> >> If %_libdir is used only to build the jar then I don't see any problem >> with using %_libdir in the spec file, even in noarch package. > > > It used to be the case that, when building a noarch package in koji, you > might get a ppc64 build host -- where %{_libdir} is "/usr/lib" but eclipse > is installed in "/usr/lib64". See > https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00022.html > > The above might not be true any more; I haven't checked for a while ... > > MEF That (or similar) might be what happened to all of the scratch builds that I've tried so far. It's probably unlikely that all 3 of the builds that I've tried were on a ppc64 host (unless we have a lot of those for some reason?). %_libdir expanded to /usr/lib on all when it was f19 x86_64. I can't link to any of the scratch builds right now, because I'm at work with access to very little. Being at work is also forcing me to use the gmail web interface, so if this mail comes out as some horrible travesty, I'm terribly sorry!

1 0

where can I find jaxws-tools.jar in fedora18 repository?
by Chen, Wei D 17 Apr '13

17 Apr '13

Hi, My current project just need some classes, these classes would be obtained from jaxws-tools.jar, webservices-tools.jar, webservices-osgi-aix.jar or webservices-osgi.jar. Anyone of these binaries is okay from my current view but I have no idea if there is any rpm packages in fedora official repo that include these binaries? I mean, after installing these rpm packages, these binary could be found in the directory like "/usr/share/java/". Any clue is big appreciated. Best Regards, Dave Chen

2 1

Build errors finding javax.annotation on rawhide
by Orion Poplawski 16 Apr '13

16 Apr '13

Trying to build a new version of eclipse-ptp on rawhide, I'm getting: [INFO] Cannot complete the request. Generating details. [INFO] {osgi.ws=gtk, osgi.os=linux, osgi.arch=x86_64, org.eclipse.update.install.features=true} [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: org.eclipse.ptp.rcp.sysmon.feature.group 7.0.0.qualifier [ERROR] Missing requirement: org.eclipse.ptp.rcp.sysmon.feature.group 7.0.0.qualifier requires 'javax.annotation 0.0.0' but it could not be found [ERROR] [ERROR] Internal error: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.eclipse.ptp.rcp.sysmon.feature.group 7.0.0.qualifier to javax.annotation 0.0.0.", "Unable to satisfy dependency from org.eclipse.ptp.rcp.sysmon.feature.group 7.0.0.qualifier to org.eclipse.cdt.debug.core.source 0.0.0.", "Unable to satisfy dependency from org.eclipse.ptp.rcp.sysmon.feature.group 7.0.0.qualifier to org.eclipse.ui.views.log 0.0.0.", "Unable to satisfy dependency from org.eclipse.ptp.rcp.sysmon.feature.group 7.0.0.qualifier to org.w3c.dom.smil 0.0.0.", "No solution found because the problem is unsatisfiable."] -> [Help 1] Seems like javax.annotation is in /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/rt.jar, so what's up? 678 Stored 678 0% 04-04-2013 11:41 08912a39 javax/annotation/Generated.class 436 Stored 436 0% 04-04-2013 11:41 effb84b2 javax/annotation/PostConstruct.class ..... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

4 15

Re: [fedora-java] [Fedora-packaging] Could and how we use jpackage repository to packaging?
by Stanislav Ochotnicky 12 Apr '13

12 Apr '13

Moving to java-devel ML since this is a java specific question. Quoting Chen, Wei D (2013-04-12 11:01:50) > Hi, > > Our project is working on package our source code to follow redhat package > standard, we want the rpm package we built could be accepted by fedora > repository. Therefore all dependencies of your project have to be *in* Fedora repositories... > One critical issue we found is some dependent binary (such as > jaxws-tools.jar, jaxws-rt.jar and streambuffer.jar) cannot find relevant rpm > package from fedora18 repository. Because as far as I know these are not packaged in Fedora. It would be better to talk in terms of Maven groupId:artifactId to be sure though... > Our source code cannot be built successfully > without these binary, something weird is, we can find these jar binary from > JPackage repository, and located in > "glassfish-jaxws-repolib-2.1.3-8.jpp6.noarch.rpm" or " > glassfish-jaxws-2.1.3-8.jpp6.noarch.rpm". JPackage and Fedora are different projects. Those RPMs are not in Fedora repositories > So, my question is can we use > JPackage repository in our rpm building process? How to use? Does this violate > package standard? No you can't use JPackage repository during build of Fedora packages. Nor can you use any other binary parts that were not build in Fedora buildsystem (koji). > Why glassfish-jaxws related rpm package has been removed > from fedora official repository? They were never packaged for Fedora so they were not removed :-) > Is there any substitute solution? Great > thanks for any of your suggestion. Yes, packaging glassfish-jaxws (or perhaps some other implementation) in Fedora. I assume you will need to go through packager sponsorship process[1] [1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

2 1

Hopefully quick review needed
by Orion Poplawski 11 Apr '13

11 Apr '13

https://bugzilla.redhat.com/show_bug.cgi?id=950786 This is a splitting out of the eclipse-photran component out of the eclipse-ptp package. Should be pretty straight forward. TIA, Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel April 2013