java-devel July 2013

java-devel@lists.fedoraproject.org

15 participants
13 discussions

Apache TomEE rpms
by David Blevins 12 Feb '16

12 Feb '16

Hello Fedora/Java people, First post to the list, so hello! We've crafted up some RPMs for Apache TomEE and are looking to contribute them to Fedora if at all possible. * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-jaxrs-1.5.2-1.noarc… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-webprofile-1.5.2-1.… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-plus-1.5.2-1.noarch… I haven't much of an idea on what the process for this might be. Dan Allen (RedHat) pointed us this way. Hoping someone here might have insight, even if that is some other list. -David

5 5

Why no Class-Path manifest attribute?
by Florian Weimer 06 Feb '14

06 Feb '14

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 23

Maven upgrade to version 3.1.0
by Mikolaj Izdebski 23 Jul '13

23 Jul '13

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

3 5

XMvn 0.5.1 release notes
by Mikolaj Izdebski 22 Jul '13

22 Jul '13

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.

2 4

Java Packages Tools 2.0.0 released
by Mikolaj Izdebski 22 Jul '13

22 Jul '13

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

3 5

Re: [fedora-java] ★ ¡Lee tu mensaje antes de que sea borrado!
by Fernando Cassia 21 Jul '13

21 Jul '13

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

1 0

Upcoming changes in JPackage Utilities
by Mikolaj Izdebski 18 Jul '13

18 Jul '13

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

2 1

Assembly ID error with mvn-rpmbuild
by Simone Caronni 18 Jul '13

18 Jul '13

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/

2 4

New Member (Looking For Package Sponsor)
by mray271 16 Jul '13

16 Jul '13

Hello, I am the upstream author of Myrtle http://sourceforge.net/projects/myrtle It is a simple programmable spreadsheet specifically designed for learning introductory statistics. It is written in pure Java+Swing and implements its scripting feature using Groovy. This is my first formal Fedora package and so I am looking for a package sponsor. The SRPM and SPEC may be downloaded at the following URLs and have already built successfully on Koji (ref: https://bugzilla.redhat.com/show_bug.cgi?id=983784#c10) SRPM: http://www.mockturtlesolutions.com/RPMS/myrtle-1.8-2.fc18.src.rpm SPEC: http://www.mockturtlesolutions.com/RPMS/myrtle.spec There is also now a Windows executable (.exe) available on Myrtle's sourceforge created with Launch4j. Sincerely, Dan Dougherty P.S. More about me: I am interested in improving Fedora's package offerings in mathematics, statistics, and computation (especially through Java) and, more generally, in cross-platform Java packaging issues.

1 0

Why doesn't mvn-build accept -D options?
by Orion Poplawski 15 Jul '13

15 Jul '13

Why doesn't mvn-build accept -D options? -- 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

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2013