Bug 232719

Briefly looking over this pacakge, I have some concerns with the amount of
sources this package contains. 

m2_jar_repo.tar.gz : fake repository, used for bootstrapping
m2_pom_repo.tar.gz : I am not entirely sure why this tar is needed, shouldn't
the poms for the projects be included with the source?
maven2-maven-site-plugin.tar.gz : maven site plugin code
maven2-plugins-060420-src.tar.gz : source code for various maven plugins
maven2-src.tar.gz : source code for maven2

I can see why the maven2-src.tar.gz and the m2_jar_repo.tar.gz are needed, but
what about plugin sources? Should there be a separate plugin srpm or even an
srpm for each plugin?

m2_pom_repo.tar.gz: This is needed because maven cannot always see the pom.xml
files located within the tree. It expects the items to be in the repository --
the m2_pom_repo.tar.gz has the poms which are dropped into a temporary
repository that we set up.

The plugin sources need to be cut at the time maven was cut. Because the plugins
have a different release cycle, maintaining them separately could invite a host
of copmpatibility issues as one version of a plugin may require one version of
maven, while another requires another version. The current cut of plugins in the
plugins is as close as possible to the time that maven2 2.0.4 was cut.

(In reply to comment #2)
> The plugin sources need to be cut at the time maven was cut. Because the plugins
> have a different release cycle, maintaining them separately could invite a host
> of copmpatibility issues as one version of a plugin may require one version of
> maven, while another requires another version. The current cut of plugins in the
> plugins is as close as possible to the time that maven2 2.0.4 was cut.

So, your argument is that since maven and its plugins constantly update, that
the only way to properly package it is to take a snapshot of everthing at one time? 
I guess in this situation the plugins would no longer be considered separate
projects, but part of the larger maven whole (at that point in time).

I am not entirely confortable with having multiple tarballs in there, but I
guess it this might have to be the case for this situation ...

MUST:
* package is named appropriately
 - match upstream tarball or project name
OK, upstream just calls it Maven, but this pacakge needs to be named differently
due to it being incompatible with the older maven1 project.
 - try to match previous incarnations in other distributions/packagers for
consistency
OK
 - specfile should be %{name}.spec
OK
 - non-numeric characters should only be used in Release (ie. cvs or
   something)
 - for non-numerics (pre-release, CVS snapshots, etc.), see
   http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease
 - if case sensitivity is requested by upstream or you feel it should be
   not just lowercase, do so; otherwise, use all lower case for the name
* is it legal for Fedora to distribute this?
 - OSI-approved
OK, license is Apache
 - not a kernel module
OK
 - not shareware
OK
 - is it covered by patents?
Not that I am aware of
 - it *probably* shouldn't be an emulator
OK
 - no binary firmware
OK

* license field matches the actual license.
OK, it appears that all the sources are Apache licensed
* license is open source-compatible.
 - use acronyms for licences where common
* specfile name matches %{name}
OK
* verify source and patches (md5sum matches upstream, know what the patches do)
 - if upstream doesn't release source drops, put *clear* instructions on
   how to generate the the source drop; ie. 
  # svn export blah/tag blah
  # tar cjf blah-version-src.tar.bz2 blah
X no instructions on how to recreate m2_jar_repo.tar.gz
X no instructions on how to recreate m2_jar_repo.tar.gz

* skim the summary and description for typos, etc.
OK
* correct buildroot
 - should be:
   %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
OK
* if %{?dist} is used, it should be in that form (note the ? and %
locations)
OK
* license text included in package and marked with %doc
X license missing from packages: maven2 and the plugin packages
 
* keep old changelog entries; use judgement when removing (too old?
useless?)
OK

* packages meets FHS (http://www.pathname.com/fhs/)
OK, they seem to put everything in the right places
* rpmlint on <this package>.srpm gives no output

rpmlint maven2-2.0.4-10jpp.3.src.rpm
W: maven2 non-standard-group Development/Build Tools
OK.The group warning can be ignored

* changelog should be in the proper format
OK

* Packager, Vendor, and Distribution tags should not be used
OK
* use License and not Copyright 
OK
* Summary tag should not end in a period
OK
* if possible, replace PreReq with Requires(pre) and/or Requires(post)
OK
* specfile is legible
OK. For the length and complexity, it is very well laid out

* package successfully compiles and builds on at least x86

* BuildRequires are proper
 - builds in mock will flush out problems here
OK, builds in mock
 - the following packages don't need to be listed in BuildRequires:
   bash
   bzip2
   coreutils
   cpio
   diffutils
   fedora-release (and/or redhat-release)
   gcc
   gcc-c++
   gzip
   make
   patch
   perl
   redhat-rpm-config
   rpm-build
   sed
   tar
   unzip
   which
OK
* summary should be a short and concise description of the package
OK
* description expands upon summary (don't include installation
instructions)
X the main package's description does, but the plugins description is just the
summary.

* make sure description lines are <= 80 characters
OK
* specfile written in American English
OK
* make a -doc sub-package if necessary
 - see
  
http://fedoraproject.org/wiki/Packaging/Guidelines#head-9bbfa57478f0460c6160947a6bf795249488182b
OK, javadoc and manual subprojects for main maven2 package. Should there be
javadocs for the plugins?
* packages including libraries should exclude static libraries if possible
* don't use rpath
OK
* config files should usually be marked with %config(noreplace)
X Doesn't maven2 have any config files?

* GUI apps should contain .desktop files
OK, not a GUI app
* should the package contain a -devel sub-package?
OK, I don't think it should have one
* use macros appropriately and consistently
 - ie. %{buildroot} and %{optflags} vs. $RPM_BUILD_ROOT and $RPM_OPT_FLAGS
OK
* don't use %makeinstall
OK
* locale data handling correct (find_lang)
 - if translations included, add BR: gettext and use %find_lang %{name} at the
   end of %install
* consider using cp -p to preserve timestamps
X the -p is not used anywhere in %prep section

* split Requires(pre,post) into two separate lines
OK
* package should probably not be relocatable
OK
* package contains code
 - see http://fedoraproject.org/wiki/Packaging/Guidelines#CodeVsContent
 - in general, there should be no offensive content
OK
* package should own all directories and files
* there should be no %files duplicates
* file permissions should be okay; %defattrs should be present
OK
* %clean should be present
OK
* %doc files should not affect runtime
* if it is a web apps, it should be in /usr/share/%{name} and *not* /var/www
* verify the final provides and requires of the binary RPMs
* run rpmlint on the binary RPMs

maven2-2.0.4-10jpp.3.fc7.x86_64.rpm
W: maven2 non-standard-group Development/Build Tools
Ok, can ignore group warnings

W: maven2 incoherent-version-in-changelog 2.0.4-10jpp.3 0:2.0.4-10jpp.3.fc7
X is this caused by the epoch or the dist?

W: maven2 no-documentation
X Shouldn't there be at least some licensing documentation?

W: maven2 dangling-symlink /usr/share/java/maven2/plugins /usr/share/maven2/plugins
W: maven2 symlink-should-be-relative /usr/share/java/maven2/plugins
/usr/share/maven2/plugins
W: maven2 dangling-symlink /usr/share/maven2/repository/JPP /usr/share/java
W: maven2 symlink-should-be-relative /usr/share/maven2/repository/JPP
/usr/share/java
W: maven2 symlink-should-be-relative /usr/share/java/maven2/poms
/usr/share/maven2/poms
X Can the above symlinks be fixed?

W: maven2 non-conffile-in-etc /etc/maven/fragments/maven2
X this should be marked as a conf file (%conf)

W: maven2 dangerous-command-in-%preun rm
X can this command be removed?

W: maven2 uncompressed-zip /usr/share/java/maven2/empty-dep.jar
I would say this is safe to ignore

maven2-debuginfo-2.0.4-10jpp.3.fc7.x86_64.rpm

maven2-javadoc-2.0.4-10jpp.3.fc7.x86_64.rpm
W: maven2-javadoc non-standard-group Development/Documentation
OK, group warnings can be ignored

maven2-manual-2.0.4-10jpp.3.fc7.x86_64.rpm
W: maven2-manual non-standard-group Development/Documentation
OK, group warnings can be ignored

Due to the large size of the rpmlint output, I will be attaching as a separate
file for the plugins.

Notes of interest:
- the groups warnings can be ignored
- Shouldn't these plugins have license docs somewhere?

SHOULD:
* package should include license text in the package and mark it with %doc
X licenses missing from file set
* package should build on i386
OK
* package should build in mock
OK

Created attachment 150291 [details]
Rpmlint output for the maven2 plugins

>  - if upstream doesn't release source drops, put *clear* instructions on
>    how to generate the the source drop; ie.
>   # svn export blah/tag blah
>   # tar cjf blah-version-src.tar.bz2 blah
> X no instructions on how to recreate m2_jar_repo.tar.gz
> X no instructions on how to recreate m2_jar_repo.tar.gz
>

I have added URL's to the location where I got the poms/jars from. Those files
are onlyused during the bootstrap phase by the way. Once maven is in the root,
those files are no longer required.

> * license text included in package and marked with %doc
> X license missing from packages: maven2 and the plugin packages
>

Added this to the base package

> X the main package's description does, but the plugins description is just the
> summary.
>

Fixed

> * config files should usually be marked with %config(noreplace)
> X Doesn't maven2 have any config files?
>

No. /etc/maven/* files are not strictly config files per se. There is only one
config file (%{_datadir}/%{name}/bin/*.conf) and I have now marked it accordingly

>
> W: maven2 incoherent-version-in-changelog 2.0.4-10jpp.3 0:2.0.4-10jpp.3.fc7
> X is this caused by the epoch or the dist?
>

I believe botth will cause it. However, I have added the epoch to the changelog,
as it needs to be there.

> W: maven2 no-documentation
> X Shouldn't there be at least some licensing documentation?
>

Added this

> W: maven2 dangling-symlink /usr/share/java/maven2/plugins
/usr/share/maven2/plugins
> W: maven2 symlink-should-be-relative /usr/share/java/maven2/plugins
> /usr/share/maven2/plugins
> W: maven2 dangling-symlink /usr/share/maven2/repository/JPP /usr/share/java
> W: maven2 symlink-should-be-relative /usr/share/maven2/repository/JPP
> /usr/share/java
> W: maven2 symlink-should-be-relative /usr/share/java/maven2/poms
> /usr/share/maven2/poms
> X Can the above symlinks be fixed?
>

No. /usr/share/java is owned by jpackage-utils which is a pre-req. That dir
should not be owned by maven.

> W: maven2 non-conffile-in-etc /etc/maven/fragments/maven2
> X this should be marked as a conf file (%conf)
>

It is not strictly a config file. However, after looking through the FHS, /etc/
still seems to be the most logical place for it. This decision can be revisited
later -- but for the time being, I think it is f
ine despite the warning.

> W: maven2 dangerous-command-in-%preun rm
> X can this command be removed?
>

Nope. That command is required to delete items created in %post

> 
> SHOULD:
> * package should include license text in the package and mark it with %doc
> X licenses missing from file set

Added now.

http://people.redhat.com/dbhole/fedora/maven2/maven2.spec
http://people.redhat.com/dbhole/fedora/maven2/maven2-2.0.4-10jpp.3.src.rpm

(In reply to comment #6)
> >  - if upstream doesn't release source drops, put *clear* instructions on
> >    how to generate the the source drop; ie.
> >   # svn export blah/tag blah
> >   # tar cjf blah-version-src.tar.bz2 blah
> > X no instructions on how to recreate m2_jar_repo.tar.gz
> > X no instructions on how to recreate m2_jar_repo.tar.gz
> >
> 
> I have added URL's to the location where I got the poms/jars from. Those files
> are onlyused during the bootstrap phase by the way. Once maven is in the root,
> those files are no longer required.
It would be nice to have actual instructions for how to recreate these tars, but
I guess since the files are autogenerated on the servers (and have since
changed) and its only for bootstrapping, I guess it should be ok.

> 
> > * license text included in package and marked with %doc
> > X license missing from packages: maven2 and the plugin packages
> >
> 
> Added this to the base package
Please also add the appropriate license files for the plugin packages. For
example the following plugins also have license files:
maven-dependency-plugin
maven-repository-plugin
maven-project-info-reports-plugin

> 
> > X the main package's description does, but the plugins description is just the
> > summary.
> >
> 
> Fixed
Thanks

> 
> > * config files should usually be marked with %config(noreplace)
> > X Doesn't maven2 have any config files?
> >
> 
> No. /etc/maven/* files are not strictly config files per se. There is only one
> config file (%{_datadir}/%{name}/bin/*.conf) and I have now marked it accordingly
Ok

> >
> > W: maven2 incoherent-version-in-changelog 2.0.4-10jpp.3 0:2.0.4-10jpp.3.fc7
> > X is this caused by the epoch or the dist?
> >
> 
> I believe botth will cause it. However, I have added the epoch to the changelog,
> as it needs to be there.
> 
> > W: maven2 no-documentation
> > X Shouldn't there be at least some licensing documentation?
> >
> 
> Added this
Please see note above about licenses for plugins

> > W: maven2 dangling-symlink /usr/share/java/maven2/plugins
> /usr/share/maven2/plugins
> > W: maven2 symlink-should-be-relative /usr/share/java/maven2/plugins
> > /usr/share/maven2/plugins
> > W: maven2 dangling-symlink /usr/share/maven2/repository/JPP /usr/share/java
> > W: maven2 symlink-should-be-relative /usr/share/maven2/repository/JPP
> > /usr/share/java
> > W: maven2 symlink-should-be-relative /usr/share/java/maven2/poms
> > /usr/share/maven2/poms
> > X Can the above symlinks be fixed?
> >
> 
> No. /usr/share/java is owned by jpackage-utils which is a pre-req. That dir
> should not be owned by maven.
Ok
> 
> > W: maven2 non-conffile-in-etc /etc/maven/fragments/maven2
> > X this should be marked as a conf file (%conf)
> >
> 
> It is not strictly a config file. However, after looking through the FHS, /etc/
> still seems to be the most logical place for it. This decision can be revisited
> later -- but for the time being, I think it is f
> ine despite the warning.
OK
> 
> > W: maven2 dangerous-command-in-%preun rm
> > X can this command be removed?
> >
> 
> Nope. That command is required to delete items created in %post
OK

> > 
> > SHOULD:
> > * package should include license text in the package and mark it with %doc
> > X licenses missing from file set
> 
> Added now.
> 
> http://people.redhat.com/dbhole/fedora/maven2/maven2.spec
> http://people.redhat.com/dbhole/fedora/maven2/maven2-2.0.4-10jpp.3.src.rpm

A skipped suggestion:
* consider using cp -p to preserve timestamps
X the -p is not used anywhere in %prep section

(In reply to comment #7)
> It would be nice to have actual instructions for how to recreate these tars, but
> I guess since the files are autogenerated on the servers (and have since
> changed) and its only for bootstrapping, I guess it should be ok.
> 

True. It wouldn't be possible to write exact generation commands, as the files
are probably long gone.

> > Added this to the base package
> Please also add the appropriate license files for the plugin packages. For
> example the following plugins also have license files:
> maven-dependency-plugin
> maven-repository-plugin
> maven-project-info-reports-plugin
> 

Added it for dependency and repository plugins. The one in project-info-reports
is in a test directory, and may change in future to something else that is not
applicable to the project.

> Please see note above about licenses for plugins
> 

> A skipped suggestion:
> * consider using cp -p to preserve timestamps
> X the -p is not used anywhere in %prep section
> 

Hmm. At first I figured that -p only needs to be in the %install. But I just
realized that it should be in all sections, because otherwise, even if %install
uses it for that file, the timestamp will be that of the time the cp was done in
%prep.

I have added -p in all places now.

http://people.redhat.com/dbhole/fedora/maven2/maven2.spec
http://people.redhat.com/dbhole/fedora/maven2/maven2-2.0.4-10jpp.3.src.rpm

This looks satisfactory to me, APPROVED

New Package CVS Request
=======================
Package Name: maven2
Short Description: Java project management and project comprehension tool
Owners: dbhole
Branches: devel