Bug 1106919 - maven-fragments != maven-metadata
Summary: maven-fragments != maven-metadata
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: javapackages-tools
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Mikolaj Izdebski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-09 18:26 UTC by Jerry James
Modified: 2014-06-23 11:44 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-06-23 11:44:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jerry James 2014-06-09 18:26:49 UTC
Description of problem:

One of my packages (jinput) failed the Rawhide rebuild because:
- https://fedorahosted.org/released/javapackages/doc/#_add_maven_depmap_macro says that projects built with ant that provides POMs should use the %add_maven_depmap macro, then own the files in %{_mavendepmapfragdir}.
- the javapackages-tools package provides /usr/lib/rpm/macros.d/macros.jpackage, which defines %{_mavendepmapfragdir} to be %{_datadir}/maven-fragments
- the javapackages-tools package also provides /usr/lib/rpm/macros.d/macros.fjava, which defines %add_maven_depmap as dumping files into %{_datadir}/maven-metadata

May I suggest that macros.fjava should not be using an explicit path there, but should be using a macro that expands to the path (whether it be %{_mnavendepmapfragdir} or something else), and that macro should be the same one described in the fedorahosted docs?

Version-Release number of selected component (if applicable):
javapackages-tools-4.0.0-5.fc21.noarch

How reproducible:
Always

Steps to Reproduce:
1. Try to build jinput in mock
2.
3.

Actual results:
The build fails because of the path mismatch noted above.

Expected results:
Successful build.

Additional info:

Comment 1 Mikolaj Izdebski 2014-06-09 18:52:50 UTC
The migration from depmaps to metadata was intentional.  Documentation probably needs to be revised.

Comment 2 David Tardon 2014-06-10 07:22:44 UTC
(In reply to Mikolaj Izdebski from comment #1)
> The migration from depmaps to metadata was intentional.  Documentation
> probably needs to be revised.

Since this change actually breaks packages, maybe an announcement to fedora-devel would not be out of place?

Comment 3 Mat Booth 2014-06-10 07:58:36 UTC
(In reply to David Tardon from comment #2)
> (In reply to Mikolaj Izdebski from comment #1)
> > The migration from depmaps to metadata was intentional.  Documentation
> > probably needs to be revised.
> 
> Since this change actually breaks packages, maybe an announcement to
> fedora-devel would not be out of place?

Mikolaj formally announced this change in May, I believe:

https://lists.fedoraproject.org/pipermail/java-devel/2014-May/005243.html
https://lists.fedoraproject.org/pipermail/java-devel/2014-May/005248.html

Comment 4 David Tardon 2014-06-10 08:16:46 UTC
(In reply to Mat Booth from comment #3)
> Mikolaj formally announced this change in May, I believe:
> 
> https://lists.fedoraproject.org/pipermail/java-devel/2014-May/005243.html
> https://lists.fedoraproject.org/pipermail/java-devel/2014-May/005248.html

I was talking about fedora-devel. Not all package maintainers read java-devel.

Comment 5 Mikolaj Izdebski 2014-06-18 07:49:28 UTC
This was a problem with our release script which wasn't uploading the documentation due to a problem with group permissions at fedorahosted.org [1], which has just been fixed.

I have uploaded the new documentation.  It doesn't recommend using %{_mavendepmapfragdir} and it contains a section [2] describing migration from the legacy %{_mavendepmapfragdir} directory.

Closing as NOTABUG as this wasn't a bug in the package, but a problem with website.

[1] https://fedorahosted.org/fedora-infrastructure/ticket/4410
[2]
https://fedorahosted.org/released/javapackages/doc/#_add_maven_depmap_macro_2


Note You need to log in before you can comment on or make changes to this bug.