< Changes
Improved Ivy Packaging
Summary
This change aims at improving the way of packaging Java software, which uses Apache Ivy to manage build dependencies.
Owner
- Name: Mikolaj Izdebski
- Email: mizdebsk@redhat.com
- Release notes owner: Simon Clark (sclark)
Current status
Detailed Description
Currently packages which use Apache Ivy as dependency manager are packaged in manual way. Dependencies must be symlinked manually, all files have to be explicitly installed, there are no auto-requires.
This change aims at simplifying Ivy packaging in a similar way as it was done with Maven packaging.
In particular, the following changes will be implemented:
- automatic resolution of Ivy artifacts,
- integration with system Maven repository,
- automatic installation of Ivy artifact metadata,
- auto requires.
Benefit to Fedora
Fedora includes a number of Java packages built using Apache Ivy and that number still increases. Automated packaging of Ivy artifacts will increase software quality and improve packager productivity.
This change also will have positive effect on Scala ecosystem in Fedora, allowing Scala packages to be simplified.
Scope
- Proposal owners:
- Implement code to resolve and publish Ivy artifacts in XMvn upstream
- Package new upstream version XMvn in Fedora or backport Ivy changes to current XMvn version
- Implement necessary macros in Javapackages Tools upstream
- Package new upstream version Javapackages Tools in Fedora or backport necessary changes to current Javapackages Tools version
- Prepare draft of Java packaging guidelines change and submit to FPC
- Other developers:
- Maintainers of packages using Apache Ivy during build or installing Ivy artifacts can optionally update their packages to use the new packaging techniques, but that's not absolutely required as existing ways of packaging Ivy artifacts will continue to work.
- Release engineering:
- No action required.
- Policies and guidelines:
- Java packaging guidelines will have to be updated to include the new way of packaging Ivy artifacts.
Upgrade/compatibility impact
N/A (not a System Wide Change)
How To Test
N/A (not a System Wide Change)
User Experience
N/A (not a System Wide Change)
Dependencies
None
Contingency Plan
- Contingency mechanism: N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? No
- Blocks product? None
Documentation
N/A (not a System Wide Change)
Release Notes
TBA