Bug 588142

Created attachment 411663 [details]
patch I had to make to get build a bit further

I applied this patch and got it to make it a bit further in the build.  Unfortunately, I'm still not able to build:

1) org.netbeans.lib:cvsclient:jar:20060125

  Try downloading the file manually from the project website.

  Then, install it using the command: 
      mvn install:install-file -DgroupId=org.netbeans.lib -DartifactId=cvsclient -Dversion=20060125 -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
      mvn deploy:deploy-file -DgroupId=org.netbeans.lib -DartifactId=cvsclient -Dversion=20060125 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
  	1) org.apache.maven.release:maven-release-manager:jar:1.0-alpha-5-SNAPSHOT
  	2) org.apache.maven.scm:maven-scm-provider-cvsjava:jar:1.0
  	3) org.netbeans.lib:cvsclient:jar:20060125

Sorry Andrew, i forgot to specify that to build in rawhide this package needs an update of maven-scm (which i own, but havent pushed so far); there is a missing cvsclient.jar symlink to netbeans library to be put in {_javadir}; that AND the cvsclient pom have to be moved to a netbeans subpackage, when work will go further there. For the moment the pom stays in maven-common-poms and the symlink in maven-scm (i dont want to make maven2-common-poms depend on netbeans-ide which is a big package).

Okay, just ping me here when this is ready to be reviewed.

Hello, Guido.
Just FYI, you may substitute %{_datadir}/maven2/poms with %{_mavenpomdir}.

Hi Peter! Good catch.
I also fixed the release tag with a better one.

Updated files here:
http://guidograzioli.fedorapeople.org/packages/maven-release/

I just built in rawhide maven-scm-1.2-6, so this package can be built too (hopefully).

Adding myself as a lurker as apache-commons-jexl 2.0.1 requires maven-release-plugin.

I'm sorry, but I won't be able to review this in a timely manner.

OK, I'll do that

Why do we need to package a trunk snapshot instead of using what's released http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.0/ ?

OK, answer to self - it requires newer maven than what we have

Review:

OK: rpmlint must be run on every package. OUTPUT:

maven-release-manager-javadoc.noarch: W: spelling-error Summary(en_US) Javadocs -> Java docs, Java-docs, Javanese
maven-release-plugin-javadoc.noarch: W: spelling-error Summary(en_US) Javadocs -> Java docs, Java-docs, Javanese
maven-release-manager.noarch: W: spelling-error %description -l en_US plugin -> plug in, plug-in, plugging
maven-release-manager.noarch: W: no-documentation
maven-release.noarch: W: spelling-error %description -l en_US plugin -> plug in, plug-in, plugging
maven-release.noarch: W: non-conffile-in-etc /etc/maven/fragments/maven-release
maven-release-plugin.noarch: W: no-documentation
maven-release.src: W: spelling-error %description -l en_US plugin -> plug in, plug-in, plugging
maven-release.src: W: invalid-url Source0: maven-release-2.0.tar.xz

Not a problem. 

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.
OK: The package MUST successfully compile and build into binary rpms on at
least one primary architecture.
OK: All build dependencies must be listed in BuildRequires, except for any that
are listed in the exceptions section of the Packaging Guidelines ; inclusion of
those as BuildRequires is optional. Apply common sense.
OK: Packages must NOT bundle copies of system libraries.
OK: A package must own all directories that it creates. 
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. 
OK: Each package must consistently use macros.
OK: The package must contain code, or permissable content. 
OK: Large documentation files must go in a -doc subpackage. Javadocs
subpackage.
OK: If a package includes something as %doc, it must not affect the runtime of
the application. 
OK: Packages must not own files or directories already owned by other
packages. 
OK: All filenames in rpm packages must be valid UTF-8.

 
Btw, What is the reason for putting BuildArch:noarch when the main package is noarch already. Plese remove it.

Other than that the package is good.

This package is APPROVED.

> Btw, What is the reason for putting BuildArch:noarch when the main package 
> is noarch already. Plese remove it.

Sure, will do that.

> Why do we need to package a trunk snapshot instead of using what's released?
> it requires newer maven than what we have

Yep i had to rewind in the vcs quite far in the past; other than that, there was an issue for a plugin version (i can provide details if u are interested) for which the version was correct in the pom, but the build hit some NoSuchMethod exceptions: it could be a mismatch in the rpm or in the pom.

As far as i push this version in F-13, will start the work to build maven-release against rawhide-maven221

Thanks for the review

New Package CVS Request
=======================
Package Name: maven-release
Short Description: Release a project updating the POM and tagging in the SCM
Owners: guidograzioli
Branches: F-13

CVS Done

Hi Guido, 
Will you push this in rawhide soon ?

Hi Guido,
We need this for a number of things, please say smth or I'll do the rawhide build on Thursday.
Thanks,
Alex

Sorry for the delay, i've been away from work (and the F project) for a bunch of days; maven-release is now built in rawhide.

Thanks a lot Guido!

Any reason this was never built for F-13?

Hello Orion sorry for the delay again; i'm working to update in rawhide to a more recent version, in order to have maven-release available with all new packaged maven plugins in f14; to build in f13 this package requires a hack in maven-scm, that i only pushed in rawhide atm, that hopefully will not be needed when bug 572165 is fixed. However if there is interest in maven-release for F13, i will build it.

pdfbox-1.2.0 appears to require it (which I am slowly working on packaging), and at some point I'd like to get it into F13.  No hurry though.  Thanks.