Name: maven2 Version-Release: 2.0.4-10jpp.3 Summary: Java project management and project comprehension tool Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. http://people.redhat.com/dbhole/fedora/maven2/maven2.spec http://people.redhat.com/dbhole/fedora/maven2/maven2-2.0.4-10jpp.3.src.rpm
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