[Bug 594414] Review Request: ezmorph - Object transformation library for Java

bugzilla at redhat.com bugzilla at redhat.com
Fri Jul 9 09:02:18 UTC 2010


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=594414

--- Comment #7 from Lubomir Rintel <lkundrak at v3.sk> 2010-07-09 05:02:16 EDT ---
(In reply to comment #6)
> rpmlint was mostly OK (package is missing any LICENSE file though...not a fatal
> error but should be fixed with upstream).
> 
> There are a few issues though:
>  * Please provide real reason for using CVS instead of release tarball. It
> might be funny, but once someone else starts maintaining this they will not
> know why it's there...

Well, it exactly states what's the reason. The package could really be just
rebuilt with "find -name \*.java |xargs javac", but we're choosing to use maven
instead.

Nevertheless, I'll attempt to improve by commend (removing possible personal
bias):

# A plain jarball with the source is provided by upstream.  We could use
# it, but we choose to build with maven for the sake of consistency.
# Therefore we pull the tree with maven metadata from VCS.

I'll not spin a new package just for a comment change now, and delay it until
full review is done or more issues are found that need a change in a package.

>  * Why are you patching pom.xml? The package builds fine without that patch1

Are you sure? At the very least I would have to add more BUildRequires; I've
decided to keep the build dependency chain thin.

>  * Package seems to be missing log4j as a Requires (see
> http://ezmorph.sourceforge.net/dependencies.html)

There are classes which are usable without the dependency shipped with the
package. It's been my understanding that as long as you've not providing
anything like an executable launcher script that would construct a class path
from another packages it does not make any sense to pull in dependencies.

>  * There was recent discussion on requiring javadoc subpackage to pull in main
> package as well (perhaps someone wants just the docs?). This is of course
> totally up to you, but you might consider replacing dependency on name =
> version with jpackage-utils.    

Well, my usual motivation is pulling it the main package so I can ensure that
user has the %doc file with license text installed and avoiding putting it into
multiple packages. However it's not the case here, here it's mostly for the
sake of consistency.

I'll prefer to keep it as it is until a guideline is made, and then I (or
someone else) will eventually adjust all other packages.

-- 
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.



More information about the package-review mailing list