cobertura-maven-plugin circular dependency?
by Simone Caronni
Hello,
I'm trying to build a Java package to be submitted for review for Fedora
17, 18 and 19/rawhide.
The project currently has cobertura-maven-plugin as a dependency. I've
tried to rebuild version 2.5.2-2 which does not yet contain the new Java
packaging guidelines.
By adding maven-checkstyle-plugin as a BuildRequires I can reach the point
where all dependencies are met and the package can be built. However, it
seems to have a dependency on itself:
[...]
DEBUG: [INFO] Scanning for projects...
DEBUG: [WARNING] The POM for
org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:2.1 is invalid,
transitive dependencies (if any) will not be available, enable debug
logging for more details
DEBUG: [WARNING] The POM for
org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.1 is missing, no
dependency information available
DEBUG: [WARNING] Failed to retrieve plugin descriptor for
org.codehaus.mojo:cobertura-maven-plugin:2.5.1: Plugin
org.codehaus.mojo:cobertura-maven-plugin:2.5.1 or one of its dependencies
could not be resolved: Failed to read artifact descriptor for
org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.1
DEBUG:
[INFO]
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Building Mojo's Maven plugin for Cobertura 2.5.2
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [WARNING] The POM for
org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.1 is missing, no
dependency information available
DEBUG:
[INFO]
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Skipping Mojo's Maven plugin for Cobertura
DEBUG: [INFO] This project has been banned from the build due to previous
failures.
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] BUILD FAILURE
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [INFO] Total time: 1.893s
DEBUG: [INFO] Finished at: Fri Mar 29 17:29:09 CET 2013
DEBUG: [INFO] Final Memory: 10M/166M
DEBUG: [INFO]
------------------------------------------------------------------------
DEBUG: [ERROR] Plugin org.codehaus.mojo:cobertura-maven-plugin:2.5.1 or one
of its dependencies could not be resolved: Failed to read artifact
descriptor for org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.1: The
repository system is offline but the artifact
org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.1 is not available in the
local repository. -> [Help 1]
DEBUG: [ERROR]
[...]
Is it normal behaviour and I'm missing something (I'm rather new to this)
or is it a bug?
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
11 years, 2 months
Java builds have stopped working in Koji since java-1.7.0-openjdk-1.7.0.17-2.3.8.2 was built
by Mat Booth
Seems like it is failing to install the latest java-1.7.0-openjdk
package. Taken from a build's root.log:
DEBUG util.py:264: opendir: No such file or directory
DEBUG util.py:264: Error unpacking rpm package
1:java-1.7.0-openjdk-1.7.0.17-2.3.8.2.fc19.i686
DEBUG util.py:264: error: unpacking of archive failed on file
/usr/lib/jvm/jre-1.7.0-openjdk: cpio: rename failed - Is a directory
Scratch builds were working for me earlier today when they were
installing 1:java-1.7.0-openjdk-devel-1.7.0.9-2.3.8.0.fc19.i686, so it
looks to me like this has just been introduced with
1:java-1.7.0-openjdk-1.7.0.17-2.3.8.2.fc19.i686
Anyone have any ideas?
--
Mat Booth
http://fedoraproject.org/get-fedora
11 years, 2 months
XMvn 0.4.1 release notes
by Mikolaj Izdebski
What's new in XMvn 0.4.1
* Minor bugfixes
* Read configuration files in sorted order
In previous versions configuration files were read in in the
system default order. This was causing unpredictable results in
cases where the order of configurationd did matter.
* Correctly handle conflicts between explicit packaging rules and
implicit singleton packaging rule
Previously it was unspecified which of rules would take
precedence. Since version 0.4.1 the first rule encountered will
be used.
* Don't set scope of optional compile dependencies to <provided>
The code that was setting scope of optional dependencies to
<provided> was removed. This code was meant to be used for
testing only and it was never supposed to make into a stable
release.
11 years, 3 months
Development and maintainership of freemind in fedora
by Johannes Lips
Hi all,
I am currently maintaining freeminda and various other related dependencies
in fedora.
I am now working full-time and not a student any more, so the time I could
devote to work on packaging is reduced a lot.
This is not a problem with packages where you have an easy upstream, which
is not the case for most of my Java packages.
Therefore I am not going to have the time, to put enough effort into
packaging up the new version of freemind and adopt all the changes upstream
made to plugins and various other parts of the package.
This is why I am looking for someone who would like to take over these
packages and work on them. I am not going to orphan them straight away but
if I am not able to update to the latest stable upstream version there's
not a lot of sense in keeping it in fedora.
I hope someone will help me to keep freemind in fedora,
Johannes
11 years, 3 months
Debugging information in .class files
by Mikolaj Izdebski
I would like to propose an addition to Java packaging guidelines that
would recommend including line number information in .class files.
Line numbers are already included in majority of .class files installed
as part of Fedora packages (most of compilers include them by default),
but some packages install "optimized" or even obfuscated class files
which don't contain line numbers. Lack of line numbers makes stack
traces less useful and therefore debugging more difficult.
In Java we don't have separate debuginfo packages that would carry basic
debugging information. Line numbers themselves have very low impact on
performance or installation size, so in my opinion they should be
included in all class files installed in Fedora, perhaps with exception
for classes not compiled from Java source, but generated by other means
(for example RMI compile).
What do you think about that? Do you agree with my proposal?
--
Mikolaj Izdebski
11 years, 3 months
XMvn 0.4.0 released
by Mikolaj Izdebski
XMvn 0.4.0 was released. Because some of you expressed an interest in seeing release notes on this list, I am posting them now.
What's new in XMvn 0.4.0
* Major features
* Improved configuration
Starting from version 0.4.0 XMvn is configured using XML configuration files instead of environmental variables. The configuration model was built using Modello and it's fully documented. The XML model supports new configuration options, it's more flexible and has new features, such as inheritance of different configuration files.
* Improved bootstrapping
Prior to version 0.4.0 XMvn used to be bootstrapped using a custom launcher code. In version 0.4.0 XMvn Launcher module was dropped and bootstrapping process was migrated to standard Classworlds launcher. Now the bootstrap process can be controlled with standard m2.conf file.
* New site
Now XMvn site is created from XMvn POM using Maven Site Plugin. It contains much more detailed information about the project, including release notes, Javadocs, source cross-reference and much more.
* Major bugfixes
* XMvn installation now uses standard Maven directory layout, which improves integration with other Maven components and fixes problems with Maven Invoker.
* Minor features
* Improved support for Fedora Software Collections
* Enchanced artifact blacklist
* Improved logging
* Added m2eclipse configuration to POM
* Javadocs use API diagrams generated with Graphviz
* Minor bugfixes
* Many minor bugfixes, see git log for a full list
11 years, 3 months
Support for more Maven packaging types
by Mikolaj Izdebski
So far %mvn_install macro supports installation of only
basic Maven packaging types ("bundle", "ejb", "jar",
"maven-plugin", "pom").
If you are interested in support for additional packaging
types (I think that Tycho[1] and WAR would be worth adding)
then you can read the short tutorial[2] I have just written
and which explains how to create extensions for XMvn.
If you prepare the necessary code to support some new
packaging type then you can either contribute it to XMvn
or package and maintain separately. In either case you can
count on help from my side.
Especially to maintainers of Eclipse and related packages
(features, plugins etc.): I believe that writing code to
support Tycho packaging types could help you a lot.
I haven't written support for them myself because I don't
know all details of packaging Eclipse bundles and best
practices of doing so, but you can count on my cooperation
if you would like to give XMvn a try.
--
Mikolaj Izdebski
[1] http://wiki.eclipse.org/Tycho/Packaging_Types
[2] http://mizdebsk.fedorapeople.org/xmvn/site/howto/extend.html
11 years, 3 months
