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
10 years, 3 months
Maven upgrade to version 3.1.0
by Mikolaj Izdebski
Version 3.1.0 of Apache Maven was recently released. It is a
long-awaited release which brings numerous new features and fixes many
bugs. A full list is available in Maven 3.1.0 release notes [1].
I think it's important for Fedora to switch to new Maven as soon as
possible. Unfortunately there are signifficant incompatibilities
between Maven 3.1.0 and 3.0.5 which make this process non-trivial.
Maven 3.1.0 switched from Sonatype Aether to Eclipse Aether and from
Sonatype Sisu to Eclipse Sisu. Plugins that directly depend on Aether
or Sisu may no longer work with Maven 3.1.0. Upstream lists [2] some
plugins that were or need to be updated to work with Maven 3.1.0.
I have created a tracker bug [3] which is intended to lists tasks
needed to be done in order to migrate to Maven 3.1.0 as well as any
bugs related to the migration. I have populated the tracker with all
changes needed that I am aware of at the moment, but feel free to add
more bugs if you find them.
This is fairly complicated process as there are circular package
dependencies because of which several packages need to be updated at the
same time. I will ask release engineering to create a dedicated Koji
tag in order not to break rawhide during the process.
[1] http://maven.apache.org/docs/3.1.0/release-notes.html
[2] http://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound
[3] http://bugzilla.redhat.com/985674
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
10 years, 10 months
XMvn 0.5.1 release notes
by Mikolaj Izdebski
Version 0.5.1 of XMvn has just been released.
The only change in XMvn 0.5.1 is added support for Apache Maven 3.1.0
and Eclipse Aether. It will not work with Maven 3.0.x any longer.
In a minor version XMvn broke compatibility - that is intentional.
0.5.0 and 0.5.1 are functionally equivalent and the only difference is
Maven version support. O.5.0 works with Maven < 3.1.0, XMvn 0.5.1 works
with Maven >= 3.1.0.
10 years, 10 months
Java Packages Tools 2.0.0 released
by Mikolaj Izdebski
A new major version (2.0.0) of Java Packages Tools (javapackages) has
just been released. Java Packages Tools is a collection of all kind
tools, script and macros to support packaging Java.
Starting from version 2.0.0 Java Packages Tools includes functionality
of JPackage Utilities (jpackage-utils) that is useful for Fedora. This
will allow jpackage-utils package to be obsoleted and provided by
javapackages-tools (see below for more detailed explanation).
%add_maven_depmap macro now injects pom.properties to every JAR file it
processes. This will allow XMVn Subst to be used to replace any JAR
files that are in system Maven repository, not only those built with
Maven. It will allow xmvn-subst to be effectively used to replace
bundled JARs with symlinks after package built, which will allow
simplification of packages containing complex symlinking in %install
sections (for example jboss-as) as well as many Eclipse plugins.
%add_to_maven_depmap and %update_maven_depmap macros were removed.
These macros have been obsolete for long time. Their usage was
preventing Fedora from implementing some features related to Maven
metadata. Packages using these macros will have to be ported to use
%add_maven_depmap or they will fail to build.
maven2jpp-mapdeps.xsl template has been removed. This template wasn't
been used. XMvn has its own way of mapping dependencies. To best of my
knowledge nothing in Fedora used this template.
Macros related to installation of icons and desktop files were removed.
These legacy macros were out of scope of Java Packages Tools --
standard Fedora macros should be used instead.
14 new manual pages were added. These manpages document RPM macros
(such ad %pom_* macros) and commands related to packaging Java. More
manual pages are planned in future.
Documentation specific to JPackage and irrelevant to fedora was removed.
Most notably this requires Jpackage policy -- in Fedora packaging
guidelines should be followed instead.
Reasons for merging jpackage-utils into javapackages-tools
----------------------------------------------------------
In Fedora jpackage-utils was based on old version (year 2006) coming
from JPackage. It included a number of fedora-specific patches which
weren't accepted by upstream. Java Packages Tools was a project founded
by Fedora developers to maintain Fedora-specific macros and various
helper scripts. The most important reasons for merging them follow:
1) These two packages had the same purpose and were strong components --
jpackage-utils required javapackages-tools and vice versa.
2) jpackage-utils contained some legacy code which was preventing Fedora
from implementing new features. This code couldn't be removed because
heavy diversion from upstream is discouraged.
3) jpackage-utils didn't have update to new upstream version for 7 years
-- it was de-facto maintained by Fedora developers. Removing custom
patchsets from our packages allows for better separation of upstream
code from RPM packaging and simplifies overall maintenance.
The new Java Package Tools haven't yet been built for rawhide, but I am
going to do this today. The new jpackage-utils is going to obsolete and
provide jpackage-utils.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
10 years, 10 months
Re: [fedora-java] ★ ¡Lee tu mensaje antes de que sea borrado!
by Fernando Cassia
2013/7/21 Badoo <noreply+2501607262(a)badoo.com>
>
> See this email in English, Deutsch, Français, Italiano, Português or 37 other languages.
> ¡Lee el mensaje de Rene Bon Ciric antes de que sea borrado!
>
>
> Lee tu mensaje
> Este email es parte de nuestro sistema de envío del mensaje fue enviado por Rene Bon Ciric. Si usted recibe este email por error, por favor ignórelo. El mensaje será eliminado pronto ..
> Más personas de tu zona que están en Badoo
>
>
>
>
>
>
> ¡Diviértete!
> El Equipo de Badoo
> Has recibido este email de Badoo Trading Limited (dirección postal a continuación). Si no deseas recibir más comunicaciones de Badoo, por favor haz clic aquí.
> Badoo Trading Limited es una sociedad de responsabilidad limitada registrada en Inglaterra y Gales con número 7540255 y domicilio en Media Village, 131 - 151 Great Titchfield Street, Londres, W1W 5BB.
>
> --
> java-devel mailing list
> java-devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
Dear list admins,
Can we get spam off this list Please?
Thanks in advance.
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell
10 years, 10 months
Upcoming changes in JPackage Utilities
by Mikolaj Izdebski
There are some backwards-incompatible changes in jpackage-utils that I
have planned to implement in Fedora 20. Fedora 19 and older won't be
affected. If you don't agree with the any of the changes or have any
comments, please speak up.
%add_to_maven_depmap and %update_maven_depmap macros will be removed.
These macros have been obsolete for long time. Their usage prevents
Fedora from implementing some features related to Maven metadata.
Packages using these macros will have to be ported to use
%add_maven_depmap or they will fail to build.
maven2jpp-mapdeps.xsl template will be removed. This template hasn't
been used for long time. XMvn has its own way of mapping dependencies.
To best of my knowledge nothing in Fedora uses this template.
Macros related to installation of icons and desktop files will be
removed. They are out of scope of jpackage-utils -- standard Fedora
macros should be used instead. As far as I know these macros are rarely
used (if used at all), so I don't expect this to be a problem.
--
Mikolaj Izdebski
IRC: mizdebsk
10 years, 10 months
Assembly ID error with mvn-rpmbuild
by Simone Caronni
Hello,
I'm experiencing differences between "mvn" and "mvn-rpmbuild". With "mvn"
the project builds fine; while I have the following error when using
"mvn-rpmbuild":
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Building guacamole-common-js 0.7.3
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO]
DEBUG: [INFO] --- maven-assembly-plugin:2.4:attached (make-zip) @
guacamole-common-js ---
DEBUG: [INFO] Reading assembly descriptor: static.xml
DEBUG:
[INFO]
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Skipping guacamole-client
DEBUG: [INFO] This project has been banned from the build due to previous
failures.
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Reactor Summary:
DEBUG: [INFO]
DEBUG: [INFO] guacamole-common .................................. SUCCESS
[6.322s]
DEBUG: [INFO] guacamole-ext ..................................... SUCCESS
[0.992s]
DEBUG: [INFO] guacamole-common-js ............................... FAILURE
[1.208s]
DEBUG: [INFO] guacamole ......................................... SKIPPED
DEBUG: [INFO] guacamole-client .................................. SKIPPED
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] BUILD FAILURE
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Total time: 12.590s
DEBUG: [INFO] Finished at: Wed Jul 17 21:19:17 CEST 2013
DEBUG: [INFO] Final Memory: 25M/224M
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:attached (make-zip) on
project guacamole-common-js: Assembly is incorrectly configured: null:
Assembly is incorrectly configured: null:
DEBUG: [ERROR] Assembly: null is not configured correctly: Assembly ID must
be present and non-empty.
The project submodule contains the correct Assembly ID:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>static.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>make-zip</id>
<phase>package</phase>
<goals>
<goal>attached</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
The only way I've found so far to build the project is to patch away the
guacamole-common-js module from the build. Can someone explain me what
should I do?
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
10 years, 10 months
