Shipping of binaries in jar files
by Orion Poplawski
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
10 years, 1 month
Any dependancy resolution tricks?
by Troy Dawson
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
10 years, 1 month
Ant provides cleanup
by Aleksandar Kurtakov
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
10 years, 1 month
Re: [fedora-java] Join "Maven FOSS Repository Extension " for GSOC 2013
by Mikolaj Izdebski
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
10 years, 1 month
Eclipse WTP problems...
by Gerard Ryan
-----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-----
10 years, 1 month
Re: [fedora-java] Eclipse WTP problems...
by Gerard Ryan
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!
10 years, 1 month
where can I find jaxws-tools.jar in fedora18 repository?
by Chen, Wei D
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
10 years, 1 month
Build errors finding javax.annotation on rawhide
by Orion Poplawski
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
10 years, 1 month
Re: [fedora-java] [Fedora-packaging] Could and how we use jpackage repository to packaging?
by Stanislav Ochotnicky
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
10 years, 1 month
