[Bug 596125] Review Request: maven-skins - Maven Skins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=596125

--- Comment #3 from Alexander Kurtakov <akurtako@xxxxxxxxxx> 2010-05-26 09:41:32 EDT ---
(In reply to comment #2)
> OK: rpmlint must be run on every package. The output should be posted in the
> review.
> maven-skins.src: W: invalid-url Source0: maven-skins-5.tar.xz
> maven-skins.noarch: W: no-documentation
> maven-skins.noarch: W: non-conffile-in-etc /etc/maven/fragments/maven-skins
> 2 packages and 0 specfiles checked; 0 errors, 3 warnings.
> 
> It might be nice to actually describe why it's needed to use
> repository. I assume it's because it's not packaged separately from maven. That
> is also why there is no separate documentation. Am I correct?
Maven projects rarely have any documentation suitable for inclusion in RPM as a
%doc. Most projects are generating their documentation from  a intermediate
representation. See http://maven.apache.org/doxia/references/index.html for
details.
Sources are fetched from svn because maven projects are not producing source
tarballs.

> 
> OK: The package must be named according to the Package Naming Guidelines .
> OK: The spec file name must match the base package %{name}, in the format
> %{name}.spec unless your package has an exemption.  .
> OK: The package must meet the Packaging Guidelines .
> OK: The package must be licensed with a Fedora approved license and meet the
> Licensing Guidelines .
> OK: The License field in the package spec file must match the actual license. 
> OK: The spec file must be written in American English. 
> OK: The spec file for the package MUST be legible. 
> OK: The sources used to build the package must match the upstream source, as
> provided in the spec URL. Reviewers should use md5sum for this task. If no
> upstream URL can be specified for this package, please see the Source URL
> Guidelines for how to deal with this.
> OK(koji): The package MUST successfully compile and build into binary rpms on
> at least one primary architecture. 
> OK: A package must own all directories that it creates. If it does not create a
> directory that it uses, then it should require a package which does create that
> directory. 
> OK: A Fedora package must not list a file more than once in the spec file's
> %files listings. 
> OK: Permissions on files must be set properly. Executables should be set with
> executable permissions, for example. Every %files section must include a
> %defattr(...) line. 
> OK: Each package must consistently use macros. 
> OK: The package must contain code, or permissable content. 
> OK: Packages must not own files or directories already owned by other packages.
> The rule of thumb here is that the first package to be installed should own the
> files or directories that other packages may rely upon. This means, for
> example, that no package in Fedora should ever share ownership with any of the
> files or directories owned by the filesystem or man package. If you feel that
> you have a good reason to own a file or directory that another package owns,
> then please present that at package review time. 
> OK: All filenames in rpm packages must be valid UTF-8.
> 
> 
> Other:
> you have: 
> > install -pm 644 maven-application-skin/pom.xml \
> >    %{buildroot}%{_mavenpomdir}/JPP.%{name}-maven-application-skin.pom
> 
> and then
> > %add_to_maven_depmap org.apache.maven.skins maven-application-skin %{version} JPP/maven-skins maven-application-skin
> 
> Is this going to work? You install for example
> /usr/share/maven2/poms/JPP.maven-skins-maven-application-skin.pom
> and then tell maven that it's JPP/maven-skins groupID and
> maven-application-skin artifactId. Shouldn't last argument to
> add_to_maven_depmap be: %{name}-maven-application-skin ? Or alternatively
> change install and leave add_to_maven_depmap be?
Yes this is working perfectly well. The JPP.(dot) notation tells maven to look
for a subdirectory and so is %add_to_maven_depmap
e.g. 
%add_to_maven_depmap org.apache.maven.skins maven-application-skin %{version}
JPP/maven-skins maven-application-skin will make it look for
/usr/share/java/maven-skins/maven-application-skin.jar 
while what you suggested 
%add_to_maven_depmap org.apache.maven.skins maven-application-skin %{version}
JPP/maven-skins %{name}-maven-application-skin will make it look for 
/usr/share/java/maven-skins/maven-skins-maven-application-skin.jar 

> 
> So please just explain this thing and why you used SVN and I can approve this
> package, because otherwise it's OK.    


P.S. Wherever I've written maven projects I ment projects that are part of
maven.apache.org not every project that is using maven as a build system.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review


[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]