Why no Class-Path manifest attribute?
by Florian Weimer
It seems that a significant number of JAR files under /usr/share/java do
not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included
with the final link (typically, in the -classpath argument to
/usr/bin/java). This is mightily inconvenient and leaks implementation
details across Java RPM package boundaries. (I don't think
%jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
--
Florian Weimer / Red Hat Product Security Team
9 years, 10 months
XMvn 1.1.0 release notes
by Mikolaj Izdebski
What's new in XMvn 1.1.0
* Major bugfixes
* Dangling symlinks
Version 1.1.0 fixes a bug that caused relative symbolic links
creted by XMvn to be incorrect in many cases.
* Minor features
* Improved debugging messages
XMvn 1.1.0 tries to better describe reasons of build failure.
Some new logging messages were introduced. New useful data was
added to some other messages. Effective packaging rules are
printed even for skipped artifacts.
* Strict mode of XMvn Subst
XMvn Subst 1.1.0 introduced a new option -- strict mode. In
this mode XMvn Subst will fail if there are any artifacts that
were unable to replace with symbolic links.
* Dry run mode of XMvn Subst
XMvn Subst 1.1.0 supports dru run. In this mode it will fail
not replace any artifacts, but report what would be normally
done.
* Skipped artifacts
Metadata generated by XMvn 1.1.0 and later versions includes
information about artifacts which were part of Maven reactor,
but were not installed. This information will be used by Java
Packages Tools for performing better sanity checks on built
packages.
* Compressed metadata files
XMvn 1.1.0 can read metadata files compressed with GNU zip. For
bigger files this will allow them to be stored entirely in
i-nodes and therefore improve performance and decrease disk
usage.
10 years, 2 months
Unable to retrieve create maven project
by John W. Himpel
Good afternoon,
When I attempt to do New->Project->Maven->Maven Project, I get the
following message in the resulting dialog box:
Problem Opening Wizard
The selected wizard could not be started.
Details:
The selected wizard could not be started.
Plug-in org.eclipse-m2e.core.ui was unable to load class
org.eclipse.m2e.core.ui.internals.wizards.MavenProjectWizard.
An error occurred while automatically activating bundle
org.eclipse.m2e.core.ui
I am running Rawhide of Sep 25th, 2013.
yum list \*maven\*
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
buildnumber-maven-plugin.noarch 1.2-6.fc21 @rawhide
exec-maven-plugin.noarch 1.2.1-12.fc20 @rawhide
jarjar-maven-plugin.noarch 1.4-4.fc21 @rawhide
javacc-maven-plugin.noarch 2.6-15.fc20 @rawhide
maven.noarch 3.1.0-9.fc21 @rawhide
maven-anno-plugin.noarch 1.4.1-7.fc20 @rawhide
maven-antrun-plugin.noarch 1.7-6.fc21 @rawhide
maven-archetype.noarch 2.2-3.fc20 @rawhide
maven-archetype-catalog.noarch 2.2-3.fc20 @rawhide
maven-archetype-common.noarch 2.2-3.fc20 @rawhide
maven-archetype-descriptor.noarch 2.2-3.fc20 @rawhide
maven-archetype-packaging.noarch 2.2-3.fc20 @rawhide
maven-archetype-plugin.noarch 2.2-3.fc20 @rawhide
maven-archetype-registry.noarch 2.2-3.fc20 @rawhide
maven-archiver.noarch 2.5-8.fc20 @rawhide
maven-artifact.noarch 2.2.1-46.fc20 @rawhide
maven-artifact-manager.noarch 2.2.1-46.fc20 @rawhide
maven-artifact-resolver.noarch 1:1.0-9.fc20 @rawwhide/19
maven-assembly-plugin.noarch 2.4-7.fc20 @rawhide
maven-clean-plugin.noarch 2.5-7.fc20 @rawhide
maven-common-artifact-filters.noarch 1.4-11.fc21 @rawhide
maven-compiler-plugin.noarch 3.1-3.fc20 @rawhide
maven-dependency-analyzer.noarch 1.4-2.fc20 @rawhide
maven-dependency-plugin.noarch 2.8-1.fc20 @rawhide
maven-dependency-tree.noarch 2.1-2.fc20 @rawhide
maven-downloader.noarch 1:1.1-5.fc20 @rawhide
maven-doxia-core.noarch 1.4-2.fc20 @rawhide
maven-doxia-logging-api.noarch 1.4-2.fc20 @rawhide
maven-doxia-module-apt.noarch 1.4-2.fc20 @rawhide
maven-doxia-module-fml.noarch 1.4-2.fc20 @rawhide
maven-doxia-module-fo.noarch 1.4-2.fc20 @rawhide
maven-doxia-module-markdown.noarch 1.4-2.fc20 @rawhide
maven-doxia-module-xdoc.noarch 1.4-2.fc20 @rawhide
maven-doxia-module-xhtml.noarch 1.4-2.fc20 @rawhide
maven-doxia-sink-api.noarch 1.4-2.fc20 @rawhide
maven-doxia-sitetools.noarch 1.4-2.fc20 @rawhide
maven-doxia-tools.noarch 1.4-12.fc20 @rawhide
maven-eclipse-plugin.noarch 2.9-9.fc21 installed
maven-enforcer.noarch 1.3.1-1.fc21 @rawhide
maven-enforcer-api.noarch 1.3.1-1.fc21 @rawhide
maven-enforcer-plugin.noarch 1.3.1-1.fc21 @rawhide
maven-enforcer-rules.noarch 1.3.1-1.fc21 @rawhide
maven-error-diagnostics.noarch 2.2.1-46.fc20 @rawhide
maven-failsafe-plugin.noarch 2.16-1.fc20 @rawhide
maven-file-management.noarch 1:1.2.1-7.fc20 @rawhide
maven-filtering.noarch 1.1-2.fc20 @rawhide
maven-gpg-plugin.noarch 1.4-10.fc20 @rawhide
maven-help-plugin.noarch 2.2-2.fc20 @rawhide
maven-indexer.noarch 5.1.1-4.fc21 @rawhide
maven-install-plugin.noarch 2.5-1.fc21 @rawhide
maven-invoker.noarch 2.1.1-10.fc21 @rawhide
maven-jar-plugin.noarch 2.4-7.fc21 @rawhide
maven-javadoc-plugin.noarch 2.9.1-2.fc20 @rawhide
maven-local.noarch 3.2.2-1.fc21 @rawhide
maven-model.noarch 2.2.1-46.fc20 @rawhide
maven-monitor.noarch 2.2.1-46.fc20 @rawhide
maven-native.noarch 1.0-0.5.alpha.7.fc20 @rawhide
maven-native-components.noarch 1.0-0.5.alpha.7.fc20 @rawhide
maven-osgi.noarch 1:0.2.0-6.fc20 @rawhide
maven-parent.noarch 20-6.fc21 @rawhide
maven-plugin-annotations.noarch 3.1-16.fc21 @rawhide
maven-plugin-build-helper.noarch 1.8-2.fc20 @rawhide/19
maven-plugin-bundle.noarch 2.3.7-10.fc20 @rawhide
maven-plugin-descriptor.noarch 2.2.1-46.fc20 @rawhide
maven-plugin-plugin.noarch 3.1-16.fc21 @rawhide
maven-plugin-registry.noarch 2.2.1-46.fc20 @rawhide
maven-plugin-testing-harness.noarch 2.1-9.fc20 @rawhide
maven-plugin-tools.noarch 3.1-16.fc21 @rawhide
maven-plugin-tools-annotations.noarch 3.1-16.fc21 @rawhide
maven-plugin-tools-api.noarch 3.1-16.fc21 @rawhide
maven-plugin-tools-beanshell.noarch 3.1-16.fc21 @rawhide
maven-plugin-tools-generators.noarch 3.1-16.fc21 @rawhide
maven-plugin-tools-java.noarch 3.1-16.fc21 @rawhide
maven-plugin-tools-model.noarch 3.1-16.fc21 @rawhide
maven-plugins-pom.noarch 23-7.fc20 @rawhide
maven-profile.noarch 2.2.1-46.fc20 @rawhide
maven-project.noarch 2.2.1-46.fc20 @rawhide
maven-release-manager.noarch 2.2.1-9.fc20 @rawhide
maven-release-plugin.noarch 2.2.1-9.fc20 @rawhide
maven-remote-resources-plugin.noarch 1.4-5.fc20 @rawhide
maven-reporting-api.noarch 1:3.0-4.fc20 @rawhide
maven-reporting-exec.noarch 1.1-5.fc20 @rawhide
maven-reporting-impl.noarch 2.2-7.fc20 @rawhide
maven-repository-builder.noarch 1:1.0-0.5.alpha2.fc21 @rawhide
maven-resources-plugin.noarch 2.6-6.fc20 @rawhide
maven-scm.noarch 1.8.1-2.fc21 @rawhide
maven-script-interpreter.noarch 1.1-2.fc21 @rawhide
maven-settings.noarch 2.2.1-46.fc20 @rawhide
maven-shade-plugin.noarch 2.1-1.fc20 @rawhide
maven-shared.noarch 19-4.fc20 @rawhide
maven-shared-incremental.noarch 1.1-5.fc20 @rawhide
maven-shared-io.noarch 1:1.1-7.fc21 @rawhide
maven-shared-jar.noarch 1:1.1-5.fc20 @rawhide
maven-shared-utils.noarch 0.4-2.fc20 @rawhide
maven-site-plugin.noarch 3.3-2.fc20 @rawhide
maven-source-plugin.noarch 2.2.1-6.fc20 @rawhide
maven-surefire.noarch 2.16-1.fc20 @rawhide
maven-surefire-plugin.noarch 2.16-1.fc20 @rawhide
maven-surefire-provider-junit.noarch 2.16-1.fc20 @rawhide
maven-surefire-provider-testng.noarch 2.16-1.fc20 @rawhide
maven-timestamp-plugin.noarch 1.1-9.fc20 @rawhide
maven-toolchain.noarch 2.2.1-46.fc20 @rawhide/19
maven-toolchains-plugin.noarch 1.0-9.fc20 @rawhide
maven-wagon.noarch 2.5-2.fc21 @rawhide
maven-wagon-ahc.noarch 1.2.1-9.fc20 @rawhide
port-allocator-maven-plugin.noarch 1.2-6.fc20 @rawhide
properties-maven-plugin.noarch 1.0-0.6.alpha2.fc20 @rawhide
#
yum list \*m2e\*
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
eclipse-m2e-core.noarch 1.4.0-4.fc21 @rawhide
I suspect that I may have a missing package or a conflicting package.
Any suggestions would be greatly appreciated.
10 years, 2 months
aether-ant-tasks and XMvn
by Mikolaj Izdebski
Aether Ant Tasks in Fedora are now able to resolve artifacts from system
repository using XMvn. This makes it easier to maintain packages built
with Ant without the need to use build-classpath or build-jar-repository.
A big advantage of Aether Ant Tasks is that they support transitive
dependencies. This means that if package is using Aether Ant Tasks to
build then it doesn't need to be updated when a transitive dependency is
added or removed.
Let me follow with self explanatory example:
$ cat build.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:aether="antlib:org.eclipse.aether.ant" default="test">
<taskdef uri="antlib:org.eclipse.aether.ant"
resource="org/eclipse/aether/ant/antlib.xml"/>
<aether:dependencies id="my-dep">
<dependency groupid="junit" artifactid="junit" version="SYSTEM"/>
</aether:dependencies>
<target name="test">
<aether:resolve dependenciesref="my-dep">
<path refid="cp" classpath="compile"/>
</aether:resolve>
<!-- Display what's the resulting classpath -->
<property name="mycp" refid="cp"/>
<echo message="${mycp}"/>
</target>
</project>
$ ant -Dxmvn.ant.enable=true
Buildfile: /build.xml
test:
[aether:resolve] Resolving artifacts
[echo] /usr/share/java/junit.jar:/usr/share/java/hamcrest/core.jar
As we can see project dependency with all *transitive dependencies* was
resolved correctly by Ant. I had to do two things: add <taskdef>
defining Aether tasks (basically a single line of boilerplate) and set
property "xmvn.ant.enable" (this property is needed only for now as this
feature is still experimental).
Because XMvn requires Maven, "local mode" of aether-ant-tasks will work
only if maven-local is installed. This can be changed in future, but
would require additional work, which I'd rather avoid unless people find
this feature useful and start using it.
Let me know if you have any comments.
--
Mikolaj Izdebski
IRC: mizdebsk
10 years, 2 months
Can't maintain Bouncycastle
by Juan Hernandez
Hello all,
Some time ago I took ownership of the Bouncycastle packages with the
intention to maintain them alive. But truth is that I didn't do it and I
won't be able to do it in the future either, so I am giving up
ownership. Does someone want to take them?
Regards,
Juan Hernandez
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
10 years, 2 months
RFC: Updating to XMvn 1.0.x and javapackages-3.x to F20
by Stanislav Ochotnicky
I am planning to start update of our Maven build support in F20 to latest. We
added several useful features in past 2 months as was mentioned in release notes
and it would be better to allow maintainers to keep identical spec files across
at least latest release & rawhide.
I will start doing builds tomorrow and putting them into buildroot overrides.
Approximately 10 packages will need a rebuild due to classifier support, after
that I am going to create an update in bodhi.
If you have any outstanding serious issues in current rawhide versions let us
know. Other than that...enjoy
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
10 years, 2 months
Unit tests in packages built with Ant
by Mikolaj Izdebski
Currently I am working on enabling and fixing unit tests in a few
packages and I noticed that some Ant build scripts succeed despite test
failures. I think that's now what we want in Fedora packages.
What I am doing is patching build.xml to actually fail the build on test
failures (OFC I'll try to upstream these patches).
My current approach is modifying all JUnit tasks to be ran with
failureproperty="test.fail" and then running fail task:
<fail message="There are test failures." if="test.fail"/>
I just thought I would share this observation so that you have in mind
that your packages may be silently ignoring test failures.
--
Mikolaj Izdebski
IRC: mizdebsk
10 years, 2 months
XMvn 1.0.2 release notes
by Mikolaj Izdebski
What's new in XMvn 1.0.2
* Major bugfixes
* Missing requires on parent POM artifacts
Version 1.0.0 introduced a regression -- automatic dependencies
on parent POM packages were no longer generated. Version 1.0.2
fixes this regression.
* Minor bugfixes
* Missing sanity checks for missing models
In version 1.0.2 more strict sanity checks were added for cases
when artifacts were installed with missing model (POM) files.
10 years, 2 months
javapackages-tools 3.1.0 released - support for artifacts in build-classpath family
by Stanislav Ochotnicky
As the subject mentions the main feature in new javapackages-tools is
improvement of build-classpath, build-jar-repository and related functions to
support Maven artifacts in form of:
groupId:artifactId[:extension[:classifier]][:version]
You can also mix and match so this is valid:
build-classpath junit:junit commons-lang
For Maven artifacts the dependencies are added transitively. This obviously
requires XMvn, but it's a soft requirement. As long as you don't use Maven
artifacts in the scripts that is...
Other things:
* Support for SCLs in macros, scrips etc which needed serious rework so bugs
may be present bug backward compatibility should be preserved
* Man pages for RPM macros (also in previous release, just forgot to mention it)
* 230 tests for pom_ macros, provides/requires generators, backend library,
mvn_* scripts. More to come
rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5954475
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
10 years, 2 months
