Development and maintainership of freemind in fedora
by Johannes Lips
Hi all,
I am currently maintaining freeminda and various other related dependencies
in fedora.
I am now working full-time and not a student any more, so the time I could
devote to work on packaging is reduced a lot.
This is not a problem with packages where you have an easy upstream, which
is not the case for most of my Java packages.
Therefore I am not going to have the time, to put enough effort into
packaging up the new version of freemind and adopt all the changes upstream
made to plugins and various other parts of the package.
This is why I am looking for someone who would like to take over these
packages and work on them. I am not going to orphan them straight away but
if I am not able to update to the latest stable upstream version there's
not a lot of sense in keeping it in fedora.
I hope someone will help me to keep freemind in fedora,
Johannes
11 years
Tomcat docs for a fedora install
by Paul Campbell
On Fedora 17, I did a yum install of tomcat-7.0.33-2.fc17.noarch
Is there a document that outlines the admin/setup that might be
required/suggested due to Fedora Packaging?
I am familiar with Tomcat setup when I download the tar from
http://tomcat.apache.org/
At a minimum, I expect I need to use sysctl
11 years, 3 months
Yet more dependency issues in rawhide
by John W. Himpel
Good afternoon,
When attempting to update to Rawhide of 12/13, I get dependency issues
with:
maven-failsafe-plugin
maven-project-info-reports-plugin
maven-shared
maven-shared-dependency-analyzer
maven-shared-downloader
maven-shared-file-management
maven-shared-invoker
maven-shared-io
maven-shared-jar
maven-shared-monitor
maven-shared-osgi
maven-shared-reporting-api
maven-shared reporting-impl
maven-shared-repository-builder
maven-shared-verifier
maven-surefire
maven-surefire-plusin
maven-surefire-provider-junit
maven-surefire-provider-junit4
maven-surefire-report-plugin
xbean
Should I putting these types of issues in bugzilla (I can't determine
what component to use) or should I continue to post these types of
issues to the list?
Thanks.
11 years, 4 months
Creating a wrapper for a application in /usr/share/%{name}
by Orion Poplawski
I'm trying to create a wrapper for a java application (kmttg). I need
to have the application jar file and helper files/scripts in
/usr/share/kmttg.
I've tried:
%jpackage_script com.tivo.kmttg.main.kmttg
'-Djava.net.preferIPv4Stack=true' '-Xmx256m'
Chart2D:jmdns:swingx:%{_datadir}/%{name}/%{name}.jar %{name} true
But that doesn't work because build-classpath can't handle full paths to
jars. Is their a better way to achieve this? The application appears
to look for its helper files in the directory relative to its jar file.
I suppose I could install into /usr/share/java/kmttg, but that doesn't
feel quite right.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
11 years, 4 months
Incomplete push of cxf rpms?
by John W. Himpel
Good evening,
It seems as though some of the sub packages from the cxf source rpm in
rawhide are at 2.7.0-1 and some are at 2.6.3-1. It looks like some of
the resulting binary rpms got pushed to rawhide with others did not.
cxf.2.7.0-1 seems to have been pushed to rawhide and delivered on Nov
20.
Or do I have something amiss with my repositories?
Thanks
11 years, 4 months
[IMPORTANT] News about Fedora Maven
by Mikolaj Izdebski
Hello all,
Maven in Fedora is currently undergoing quite big changes, which are
intended to make packaging of Maven artifacts simpler and less
error-prone. Some of the features are already implemented and
considered stable, so you can start using them straight away. Some of
them are implemented or partly implemented, but not yet intended to be
used widely because they may be changed in near future.
1) jpackage-utils requires generator
Any package that contains Maven fragments in %{_mavendepmapfragdir}
doesn't need to explicitly specify "Requires: jpackage-utils" any
longer -- this dependency will be generated automatically by rpmbuild
on build time. The same applies to javadoc packages (packages that
install any files in %{_javadocdir}). For these kind of packages you
can remove Requires: jpackage-utils lines form your spec files. This
feature is implemented in Rawhide and will be backported to Fedora 17
and 18.
2) Java compiler source and target configuration
In Rawhide Maven Compiler Plugin is now forced to enable source
compatibility of at least Java 1.5 and target not older than
source. This means that Java sources will be compiled as Java 1.5,
even if POM files specify source format older than 1.5. It also means
that JSR-14-like bugs will no longer exist because target format will
never be older than source format.
3) maven package split
Currently maven package is a monolithic package with a big dependency
chain. It contains upstream Maven as well as Fedora-specific
customizations (like mvn-rpmbuild script). Users that just want to use
Maven don't need to have all the Fedora-specific extensions
installed. Because of that maven package will be split into two parts:
a) maven. This package will contain only upstream Maven, without any
extensions or customizations. In other words, maven package will ship
upstream-like maven.
b) maven-local. This package will contain Fedora extensions for Maven
and tools useful in building RPM packages containing Maven
artifacts. This package will depend on maven and may also depend on
certain Maven plugins and POM files. If you are building RPM packages
using Maven you want to depend on maven-local.
This means that all Java packages that use "BuildRequires: maven" will
have to migrate to "BuildRequires: maven-local". You can (but you
don't have to) start migrating them straight away. Packages that
build-require maven will be migrated automatically in future (during a
mass-rebuild).
4) Simplified %files sections
During build Maven generates a number of files prefixed ".mfiles" that
contain lists of installed files. You can use .mfiles* as an argument
to -f option of %files macro instead of manually listing all files
installed in a subpackage. Note that .mfiles* contain only files
recognized by maven (such as pom, jar and fragment files), so any
other files, such as documentation, still need to be listed explicitly.
The above features (1-4) are already implemented and ready for
use. There are some future features that are under development or
testing. Let me describe them briefly:
5) Automatic requires generator - packages don't need to explicitly
list dependencies on other maven artifacts, appropriate requires will
be generated automatically from POM files.
6) Simplified %build and %install sections of spec files (these
sections can be one-liners, %mvn_build and %mvn_install,
respectively).
Features 5 and 6 are under development. They are currently used by a
small number of packages (as a form of testing in production). If you
want to have impact on future of Fedora Java packaging you can take a
look at example packages, report any bugs found and share your
feedback. You can find out which packages use features 5 and 6 with
repoquery:
repoquery --qf %{name} --repoid rawhide-source --arch src --whatrequires xmvn
--
Mikolaj Izdebski
11 years, 4 months
Problem with maven-antrun-plugin task being run with the jre rather than the jdk
by Orion Poplawski
seem to be facing a classic issue with a maven-antrun-plugin task being run
with the jre rather than the jdk and not finding the compiler. Haven't yet
found the proper fix though. Any ideas?
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.7:run (rdt-remote-jars) on
project org.eclipse.ptp.rdt.core.remotejars: An Ant BuildException has
occured: The following error occurred while executing this line:
[[ERROR]
/export/home/orion/fedora/eclipse-ptp/eclipse-ptp-6.0.2/org.eclipse.ptp-PTP_6_0_2/rdt/org.eclipse.ptp.rdt.core.remotejars/build.xml:152:
Unable to find a javac compiler;
[ERROR] com.sun.tools.javac.Main is not on the classpath.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
11 years, 4 months
