Bug 1006512 - javapackages-tools: Too many packages end up with suprious source JARs
Summary: javapackages-tools: Too many packages end up with suprious source JARs
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: javapackages-tools
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mikolaj Izdebski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1006721 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-10 18:17 UTC by Mikolaj Izdebski
Modified: 2013-10-08 18:19 UTC (History)
5 users (show)

Fixed In Version: 3.3.1-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-08 18:19:02 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Mikolaj Izdebski 2013-09-10 18:17:02 UTC 
Description of problem:
With new javapackages-tools and xmvn too many packages end up with source JARs installed.  I'm not sure if it's good or bad thing, but I'm rather against that.

If we don't want source JARs to be installed by default then perhaps we should add a default XMvn rule to javapackages-tools that would skip installation of sources by default. This rule could be overridden by packages that do want to install sources.

Stano, do we want source JARs installed by default?

Version-Release number of selected component (if applicable):
3.0.2-2
Comment 1 Stanislav Ochotnicky 2013-09-11 10:43:18 UTC 
*** Bug 1006721 has been marked as a duplicate of this bug. ***
Comment 2 Stanislav Ochotnicky 2013-09-11 16:04:55 UTC 
Yeah, most likely disabling source jar installation is best solution at this time. Later we *might* want to create a rule in guidelines that will install them in some agreed-upon directory different from javadir.
Comment 3 Michal Srb 2013-09-13 05:16:05 UTC 
There are also packages which generate not only -sources jar, but also -javadoc and -tests jars (e.g.: httpcomponents-client). Tests might be useful, but javadoc artifacts are IMO not needed.
Comment 4 Mikolaj Izdebski 2013-09-13 09:36:36 UTC 
Maybe we should disable automatic installation of attached artifacts (unless explicitly enabled with %mvn_package)?
Comment 5 Stanislav Ochotnicky 2013-09-13 09:47:28 UTC 
(In reply to Mikolaj Izdebski from comment #4)
> Maybe we should disable automatic installation of attached artifacts (unless
> explicitly enabled with %mvn_package)?

Since we were not installing them in the first place before XMvn 1.0 this might be the best solution. No unexpected changes to existing packages... Or am I missing something?
Comment 6 Mikolaj Izdebski 2013-09-13 10:13:34 UTC 
If by default we skip installation of any artifact with non-empty classifier then
existing packages would not need any changes to keep behavior of XMvn < 1.0.0. Packages that want to install some or all attached artifacts will have to enable them explicitly with %mvn_package.
Comment 7 Mikolaj Izdebski 2013-09-13 11:04:40 UTC 
Fixed upstream in 2b481d9b

I added the following rule:
    <rule>
      <optional>true</optional>
      <artifactGlob>
        <classifier>*?</classifier>
      </artifactGlob>
      <targetPackage>__noinstall</targetPackage>
    </rule>
Comment 8 Mikolaj Izdebski 2013-10-08 18:03:07 UTC 
Fixed in javapackages-tools-3.3.1-1
Comment 9 Mikolaj Izdebski 2013-10-08 18:19:02 UTC 
I believe that this bug is fixed in javapackages-tools-3.3.1-1,
which is available in Fedora Rawhide, so I am closing this bug now.

The build containing the fix can be found at Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=469008
Note You need to log in before you can comment on or make changes to this bug.