[Bug 456280] Review Request: ini4j - Java API for handling files in Windows .ini format

Fri Aug 22 11:56:48 UTC 2008

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

--- Comment #4 from Victor G. Vasilyev <victor.vasilyev at sun.com>  2008-08-22 07:56:46 EDT ---
The third release is prepared for review.
Spec URL: http://www.netbeans.org/files/documents/210/2046/ini4j.spec
SRPM URL:
http://nbi.netbeans.org/files/documents/210/2145/ini4j-0.3.2-3.fc10.src.rpm

FYI a page with all resources related to the NetBeans here:
http://nbi.netbeans.org/servlets/ProjectDocumentList?folderID=267

(In reply to comment #3)
> I'm having trouble understanding why this package uses alternatives at all.
- Ability to switch on the alternative implementations is removed.
I agree. Probability to have an alternative implementation of the ini4j on the
Fedora platform is very low if only somebody won't recompile the project
sources via GCJ. 

> I have to say, the amount of macro use in this spec is... well... let's just
> say it makes things pretty hard to read.
- All macroses reflecting a folders layout of the project are removed.
I agree it was noise in this case. Now, there are no user-defined macroses in
the spec. I hope the spec is readable now.

> ... you need to be be consistent and use %{__install} as well.
- The %%{__install} macro is used everywhere instead of the install command.

> You do not need to have explicit scriptlet dependencies for /bin/sh.
- Explicit scriptlet dependencies for /bin/sh are removed.

> You shouldn't own /etc/maven/fragments or /usr/share/maven2/poms; they are
> owned by jpackage-utils.
- Owning of /etc/maven/fragments/ini4j is removed.
But, now the rpmlint shows a warning:
------------
$ rpmlint ini4j-0.3.2-3.fc10.noarch.rpm
ini4j.noarch: W: non-conffile-in-etc /etc/maven/fragments/ini4j
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
------------

And, I can't remove owning of /usr/share/maven2/poms due to
RPM build errors:
  Installed (but unpackaged) file(s) found:
  /usr/share/maven2/poms/JPP-ini4j.pom

BTW, the example http://fedoraproject.org/wiki/Packaging/Java#maven_2
recommends to have this owning.

> Is it not possible to run the tests at build time in a %check section?
Yeah, it will be better to have the tests, but it requires a set of extra
packages. I guess,  it will be serious overhead if the these packages will only
provided to test the ini4j package. Please note, only the junit package in fc10
is meet with the project requirements.

Also, please note, that the ini4j package doesn't have any patches against the
original Java code. Therefore, there is no need to have the tests for
investigating any regressions.

Nevertheless, to be sure that all is OK I've done a test to proofing of
assumption that content of the target JAR generated in the scope of the package
is byte-to-byte the same as  content of original JAR -
http://downloads.sourceforge.net/ini4j/ini4j-0.3.2-bin.zip

The test has shown only expected differences in the following files:
* META-INF/MANIFEST.MF - some informational values are changed
* META-INF/maven/org.ini4j/ini4j/pom.properties - the build date is different
* META-INF/maven/org.ini4j/ini4j/pom.xml - some lines are commented out
according to the specified patch
* org/ini4j/PreferencesBean$1.class and org/ini4j/PreferencesBean.class -
the JDK 1.6.0_03 has been used in the original project, but it has a bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6520152
On the other hand,  the OpenJDK 1.6.0 will be used to compile the classes in
the scope of the package and the OpenJDK is free from this bug.

So, I can say that the JAR files are the same, and, moreover, from viewpoint of
the Java specifications the JAR file for Fedora is better than original one.
:-)
Also, I think, we can rely on the unit test results obtained in the scope of
the project. 

> I see a bunch of commented out dependencies which suggest runtime dependencies
> for the unit tests, which confuses me since generally tests have no impact on
> the final packages.
There are several solutions to provide the tests, including a separate
subpackage that will have these dependencies at the run time.
Such solution lets to test an implementation after installation into the real
run-time environment.
I've provided the info about dependencies only to show what will be need if
somebody decide to turn on the tests, but if you feel that it is redundant or
misleading info then I can remove it at all.

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