Bug 1006512

Summary:	javapackages-tools: Too many packages end up with suprious source JARs
Product:	[Fedora] Fedora	Reporter:	Mikolaj Izdebski <mizdebsk>
Component:	javapackages-tools	Assignee:	Mikolaj Izdebski <mizdebsk>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	java-sig-commits, mattias.ellert, mizdebsk, msrb, sochotni
Target Milestone:	---	Keywords:	FutureFeature, Upstream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	3.3.1-1	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-08 18:19:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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