Error building Maven web app package in Rawhide
by Simone Caronni
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/
9 years, 3 months
Linking against the JVM
by Omair Majid
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
9 years, 3 months
[Fwd: [ACTION REQUIRED] Retiring packages for Fedora 21 v3]
by Mark Wielaard
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.
9 years, 3 months
Maven 3.2.2 is available in rawhide
by Mikolaj Izdebski
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
9 years, 3 months
What's new in javapackages-tools 4.1.0
by Michal Srb
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_mac...
Thanks to all contributors.
Regards,
Michal
9 years, 3 months
guava update in rawhide
by Mikolaj Izdebski
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
9 years, 3 months
xmvn/jp-tools bug?
by Peter MacKinnon
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
9 years, 3 months
What's new in javapackages-tools 4.0.0
by Michal Srb
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
9 years, 3 months
