java-devel June 2014

java-devel@lists.fedoraproject.org

17 participants
17 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

Error building Maven web app package in Rawhide
by Simone Caronni 27 Jun '14

27 Jun '14

Hello, I have a problem with Maven building in Fedora rawhide. The same package builds fine in Fedora 19/20. There are no errors in the build log, just warnings; so the build should not fail. I'm not sure where the bug is. Maybe it's related to maven-war-plugin or a bug in Maven: [ERROR] Failed to execute goal org.apache.maven.plugins: maven-war-plugin:2.4:war (default-war) on project guacamole: Mark invalid -> [Help 1] I'm not a Java expert, can someone help me shed some light on this? Here is the failed build.log: http://koji.fedoraproject.org/koji/taskinfo?taskID=6925854 I have a zipped archive of the build.log with "%mvn_build -- -X" for debugging but is too big for fpaste or to be shipped to this mailing list. 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/ http://negativo17.org/

2 4

Linking against the JVM
by Omair Majid 27 Jun '14

27 Jun '14

Hi, I recently ran across a few bugs having to do with packages linking against the JVM. Basically, packages are trying to link directly against a JVM (libjvm.so) and are filing bugs when appropriate LD_FLAGS to do that are not obvious: - https://bugzilla.redhat.com/show_bug.cgi?id=449456 - https://bugzilla.redhat.com/show_bug.cgi?id=740762 - https://bugzilla.redhat.com/show_bug.cgi?id=1112012 Fedora (and JPackage) guidelines try to makes it easy for users to use alternate JVMs. They can use alternatives and/or environment variables to control which JVM is used. This linking directly against a libjvm.so runs counter to that. I talked to Mikolaj who thinks that ignoring the user-specified JVM (either through alternatives or JAVA_HOME) is a bug and can lead to surprises where an application is not using the JVM you may think it's using. This linking will also cause things to break when Java versions are bumped and we go from java-1.x.0-openjdk to java-1.y.0-openjdk or even if the OpenJDK directory changes name. However, others, including Andrew Haley have suggested that it may lead to broken programs (and other surprises) when applications end up with a JVM that's different from what they expected. Mikolaj thinks it would be better if the packages did one of the following (in order of preference): 1. Fix upstream - convince them to respect $JAVA_HOME and use dlopen(3) 2. Maintain Fedora-specific patch for dlopen(3) 3. App should use its own linker magic depending on java home (eg, shell script checks $JAVA_HOME and sets LD_PRELOAD) 4. Fail if $JAVA_HOME is set And he prefers to avoid: 1. Java .so in default linker paths 2. Linker tricks to avoid depending on Java home (these are just workarounds for Java .so not being in default linker paths) 3. rpath What do others think about this? If there is some sort of consensus about this, should the packaging guidelines be amended to make this explicit? I also talked to Mikolaj about making some sort of mini-library to make it easier to implement fedora-specific patch to make it easier to dlopen(3) and use a libjvm.so. Is this something that others will find useful? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681

3 3

[Fwd: [ACTION REQUIRED] Retiring packages for Fedora 21 v3]
by Mark Wielaard 26 Jun '14

26 Jun '14

This message accidentally got rejected by the list. Could one of the (other) admins make sure non-subscribers can post to java-devel (I don't know the list admin password). Please take a look at the java packages to be retired for F21.

4 5

Bug in latest apache-ivy for xmvn support
by Peter MacKinnon 25 Jun '14

25 Jun '14

Just filed https://bugzilla.redhat.com/show_bug.cgi?id=1113275 Basically, /etc/ant.d/apache-ivy wasn't updated to the new jar path, assuming that is the correct and desired path. \Pete -- Peter MacKinnon CTO Office: Big Data Red Hat Inc. Raleigh, NC

1 0

Maven 3.2.2 is available in rawhide
by Mikolaj Izdebski 25 Jun '14

25 Jun '14

I've just tagged maven-3.2.2-1.fc21 to f21. I don't expect many problems, but in case you encounter one you can let me know. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk

1 0

What's new in javapackages-tools 4.1.0
by Michal Srb 23 Jun '14

23 Jun '14

What's new in javapackages-tools 4.1.0: * %mvn_artifact macro now supports auto-requires This means that packages which don't use Maven to build can now have automatically generated Requires. The only condition is that upstream provides POM files with all necessary information (i.e.: "dependencies" section). The macro can handle parent POMs, DependencyManagement sections and interpolation of properties. This new functionality can be disabled with "--skip-dependencies" option, if needed. * ABRT support for Java packages in distribution (contributed by Jakub Filak) * OSGi Requires generator can now generate requires for dir-shaped OSGi bundles (contributed by Mat Booth) * a lot of bugs have been fixed since 4.0.0 * big refactoring/code cleanup was performed Note there is also a migration guide from %add_maven_depmap to %mvn_artifact (written by Mikolaj Izdebski): https://fedorahosted.org/released/javapackages/doc/#_add_maven_depmap_macro… Thanks to all contributors. Regards, Michal

1 0

guava update in rawhide
by Mikolaj Izdebski 23 Jun '14

23 Jun '14

I am going to update guava in rawhide from version 15.0 to version 17.0. See https://bugzilla.redhat.com/show_bug.cgi?id=1109442 The list of packages which depend on guava and therefore are possibly affected by the update follows. aether-connector-okhttp ambari bookkeeper checkstyle closure-compiler curator eclipse-checkstyle eclipse-m2e-core eclipse-mylyn eucalyptus findbugs-contrib gooddata-cl google-guice hadoop hbase hive hppc htrace jberet jenkins jsilver jython leveldb-java maven maven-shade-plugin maven-stapler-plugin owasp-java-html-sanitizer plexus-containers randomizedtesting solr solr3 spark stapler takari-local-repository weld-core wildfly zanata-client zanata-common -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk

1 2

xmvn/jp-tools bug?
by Peter MacKinnon 23 Jun '14

23 Jun '14

After updating to jline-2.10-14.fc21.noarch, I found this: $ repoquery -f 'mvn(jline:jline)' jline-0:2.10-14.fc21.noarch $ repoquery -f 'mvn(jline:jline:1)' jline1-0:1.0-7.fc21.noarch $ repoquery -f 'mvn(jline:jline:1.0)' jline1-0:1.0-7.fc21.noarch $ xmvn-resolve jline:jline:1.0 /usr/share/java/jline/jline.jar $ xmvn-resolve jline:jline:1 /usr/share/java/jline/jline.jar $ rpm -qf /usr/share/java/jline/jline.jar jline-2.10-14.fc21.noarch $ rpm -q ivy-local ivy-local-4.0.0-8.fc21.noarch The difference from the previous version of jline (-13) is this provides decl: mvn(jline:jline:pom:) = 2.10 -- Peter MacKinnon CTO Office: Big Data Red Hat Inc. Raleigh, NC

4 3

What's new in javapackages-tools 4.0.0
by Michal Srb 12 Jun '14

12 Jun '14

Hello, Better late than never. Here comes quick summary of most important changes in latest javapackages-tools release: - changes in %pom_* macros (contributed by Michael Simacek, thanks!): - new macro %pom_change_dep for changing dependencies in Maven POM files or Ivy modules - see man pom_change_dep for more details - macros %pom_change_dep, %pom_remove_dep, %pom_remove_plugin, %pom_xpath_remove and %pom_xpath_replace now support recursive mode - see corresponding man pages for more details - Requires generator now generates auto-requires instead of XMvn when (sub)packages contain only POM artifacts - this change shouldn't be visible to end users - new subpackage javapackages-local - %mvn_* macros (except %mvn_build) were moved to this subpackage - no changes to existing spec files shouldn't be needed. This subpackage is useful when you don't build your package with xmvn, but you still want to use the rest of the %mvn_ macros (e.g. %mvn_install). Latest javapackages-tools release internally works with new metadata and no longer produce old fragments/depmaps. This can cause "error: File not found: ... /usr/share/maven-fragments/%{name}" build failure. For more information on this topic see my "how to fix..." email [1]. Michal [1]: https://lists.fedoraproject.org/pipermail/java-devel/2014-June/005269.html

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel June 2014