Re: Writing 16 Bits Per Sample To Tiff File

[Damjan Jovanovic]

You can make a BufferedImage with TYPE_USHORT_GRAY for 16 bits per sample.

Damjan



On Tue, Jun 5, 2018 at 11:15 AM Juergen Stumpe  wrote:

> Hello,
>
> I need to write grayscale pixels with 16 bits per sample into a Tiff file.
>
> In the provided Apache examples the Imaging.writeImage() method is
> used to write image data into a file. But the image data source has
> always to be a BufferedImage, however BufferedImage handles only 8
> bits per sample, not 16 bits.
>
> Is there an alternative class/method to write image data to a Tiff
> file, supporting 16 bits per sample? Or how can it be done with
> BufferedImage?
>
> Thanks
>
> Juergen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: svn commit: r1781785 - in /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pcx: PcxConstants.java PcxWriter.java

[Damjan Jovanovic]

Thank you.

I have tons of changes I want to make, many of them large and affecting the
API. If we have to make a release soon, maybe a 0.98 would be better?

Regards
Damjan

On Sun, Feb 5, 2017 at 7:09 PM, Benedikt Ritter  wrote:

> Hi Damjan,
>
> It’s nice to see some activity in IMAGING again. Do you think the code
> base is ready for an RC? I’d like to finally push out a release of this
> component.
>
> Regards,
> Benedikt
>
> > Am 05.02.2017 um 18:07 schrieb dam...@apache.org:
> >
> > Author: damjan
> > Date: Sun Feb  5 17:07:51 2017
> > New Revision: 1781785
> >
> > URL: http://svn.apache.org/viewvc?rev=1781785=rev
> > Log:
> > Allow giving PCX a hint as to the number of planes to use, and by
> default,
> > write 16 color images using 4 planes of 1 bit instead of 1 plane of 4
> bits,
> > as GIMP and Apache OpenOffice support the former but not the latter.
> >
> > Patch by: me
> >
> > Modified:
> >commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxConstants.java
> >commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxWriter.java
> >
> > Modified: commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxConstants.java
> > URL: http://svn.apache.org/viewvc/commons/proper/imaging/trunk/
> src/main/java/org/apache/commons/imaging/formats/pcx/
> PcxConstants.java?rev=1781785=1781784=1781785=diff
> > 
> ==
> > --- commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxConstants.java (original)
> > +++ commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxConstants.java Sun Feb  5 17:07:51 2017
> > @@ -22,6 +22,8 @@ public final class PcxConstants {
> >
> > public static final String PARAM_KEY_PCX_BIT_DEPTH = "PCX_BIT_DEPTH";
> >
> > +public static final String PARAM_KEY_PCX_PLANES = "PCX_PLANES";
> > +
> > private PcxConstants() {
> > }
> > }
> >
> > Modified: commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxWriter.java
> > URL: http://svn.apache.org/viewvc/commons/proper/imaging/trunk/
> src/main/java/org/apache/commons/imaging/formats/pcx/
> PcxWriter.java?rev=1781785=1781784=1781785=diff
> > 
> ==
> > --- commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxWriter.java (original)
> > +++ commons/proper/imaging/trunk/src/main/java/org/apache/
> commons/imaging/formats/pcx/PcxWriter.java Sun Feb  5 17:07:51 2017
> > @@ -33,6 +33,7 @@ import org.apache.commons.imaging.palett
> > class PcxWriter {
> > private int encoding;
> > private int bitDepth = -1;
> > +private int planes = -1;
> > private PixelDensity pixelDensity;
> > private final RleWriter rleWriter;
> >
> > @@ -77,6 +78,17 @@ class PcxWriter {
> > bitDepth = ((Number) value).intValue();
> > }
> > }
> > +
> > +if (params.containsKey(PcxConstants.PARAM_KEY_PCX_PLANES)) {
> > +final Object value = params.remove(PcxConstants.
> PARAM_KEY_PCX_PLANES);
> > +if (value != null) {
> > +if (!(value instanceof Number)) {
> > +throw new ImageWriteException(
> > +"Invalid planes parameter: " + value);
> > +}
> > +planes = ((Number) value).intValue();
> > +}
> > +}
> >
> > if (params.containsKey(ImagingConstants.PARAM_KEY_PIXEL_DENSITY))
> {
> > final Object value = params.remove(
> ImagingConstants.PARAM_KEY_PIXEL_DENSITY);
> > @@ -114,7 +126,11 @@ class PcxWriter {
> > } else if (palette.length() > 16 || bitDepth == 8) {
> > write256ColorPCX(src, palette, bos);
> > } else if (palette.length() > 2 || bitDepth == 4) {
> > -write16ColorPCX(src, palette, bos);
> > +if (planes == 1) {
> > +write16ColorPCXIn1Plane(src, palette, bos);
> > +} else {
> > +write16ColorPCXIn4Planes(src, palette, bos);
> > +}
> > } else {
> > boolean onlyBlackAndWhite = true;
> > if (palette.length() >= 1) {
> > @@ -132,7 +148,11 @@ class PcxWriter {
> > if (onlyBlackAndWhite) {
> > writeBlackAndWhitePCX(src, bos);
> > } else {
> > -write16ColorPCX(src, palette, bos);
> > +if (planes == 1) {
> > +write16ColorPCXIn1Plane(src, palette, bos);
> > +} else {
> > +write16ColorPCXIn4Planes(src, palette, bos);
> > +}
> > }
> > }
> > }
> > @@ -264,7 +284,7 @@ class PcxWriter {
> > rleWriter.flush(bos);
> > }
> >
> > -private 

Back to contributing to Commons Imaging

[Damjan Jovanovic]

Hi

I am back to contributing to Commons Imaging.

Will start with some cleanups, like try-with-resources instead of
IoUtils.closeQuietly().

Java and Maven are a heaven send after working in C++ and make with Apache
OpenOffice.

Regards
Damjan

Re: [CRYPTO] Switch from JNI to JNA

[Damjan Jovanovic]

There's also BridJ (https://github.com/nativelibs4java/BridJ), which
claims to be very fast, supports C++ and COM, and JNAerator can
autogenerate code for it from C/C++ headers.

Java 9 will also have vastly enhanced access to native code
(http://openjdk.java.net/projects/panama/).

Damjan

On Sat, Apr 23, 2016 at 12:42 PM, Hendrik Dev  wrote:
> Hi,
>
> i just had a brief look into commons crypto today.
> Maybe its an option to replace JNI by JNA [1]. This would have IHMO
> several advantages like
>
> * No C code needs to be written, compiled, tested and maintained
> * Its easier compared to JNI (this could help attracting more people
> to contribute)
> * Many supported platforms [2], precompiled native binaries available
>
> Disadvantages:
>
> * Introduce a dependency to JNA
> * Performance decrease compared to JNI (direct buffers and direct
> mapping helps minimizing this) [3]
>
> I prepared a demo [4] to show thats its generally working and how a
> implementation could like (although tests are not working and error
> handling is missing).
>
> [1] https://github.com/java-native-access/jna
> [2] https://github.com/java-native-access/jna/tree/master/lib/native
> [3] https://s.apache.org/q5Tl
> [4] https://s.apache.org/DQeD
>
> Wdyt?
>
> Thanks
> Hendrik
>
> --
> Hendrik Saly (salyh, hendrikdev22)
> @hendrikdev22
> PGP: 0x22D7F6EC
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] [POLL] new TLP name

[Damjan Jovanovic]

Apache Math

On Mon, Feb 1, 2016 at 7:06 PM, Phil Steitz  wrote:

> Please select your top choice among the following suggested names
> for the new [math]-based TLP.  All are welcome and encouraged to
> respond.  This POLL will be open for 72 hours, at which time two
> tallies will be presented:  one among those who have volunteered for
> the new PMC and a second among all respondents.  Hopefully, one name
> will emerge as consensus winner.  If not, I will kick off another
> runoff poll among the top choices.   Please respond with your top
> choice for the name.
>
> AjaMa
> Epsilon
> Erdos
> Euclid
> Euler
> Gauss
> JAML
> Math
> MathBlocks
> MathComponents (or Math Components)
> Mathelactica
> MathModules
> Megginson
> modMath
> Nash
> Newton
> Pythagoras
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[COMPRESS] generalize RandomAccessFile in ZipFile and SevenZFile

[Damjan Jovanovic]

Hi

(At least) our ZipFile and SevenZFile use RandomAccessFile to read an
actual file, meaning they cannot operate on file contents in an array,
java.nio channels and buffers, or anything other than an actual file, even
if it is randomly accessible. RandomAccessFile also cannot benefit from
memory-mapped I/O.

RandomAccessFile isn't an interface nor an abstract class, nor can any
constructors be used by subclasses to make it access something other than a
file, thus I've used a design where a general SeekableInputStream is used
by ZipFile and SevenZFile, and subclasses of it implement various
possibilities: SeekableFileInputStream implemented on top of
RandomAccessFile and SeekableByteArrayInputStream on top of byte[]. It
would of course be possible to make a SeekableChannelInputStream etc. The
API is the subset of methods from RandomAccessFile that we currently use.

The patch is attached. Is everyone happy with this design? Can I commit it?

Thank you
Damjan
diff --git 
a/src/main/java/org/apache/commons/compress/archivers/sevenz/BoundedSeekableInputStream.java
 
b/src/main/java/org/apache/commons/compress/archivers/sevenz/BoundedSeekableInputStream.java
index 482bd7a..edd6dbd 100644
--- 
a/src/main/java/org/apache/commons/compress/archivers/sevenz/BoundedSeekableInputStream.java
+++ 
b/src/main/java/org/apache/commons/compress/archivers/sevenz/BoundedSeekableInputStream.java
@@ -19,13 +19,14 @@ package org.apache.commons.compress.archivers.sevenz;
 
 import java.io.IOException;
 import java.io.InputStream;
-import java.io.RandomAccessFile;
 
-class BoundedRandomAccessFileInputStream extends InputStream {
-private final RandomAccessFile file;
+import org.apache.commons.compress.utils.SeekableInputStream;
+
+class BoundedSeekableInputStream extends InputStream {
+private final SeekableInputStream file;
 private long bytesRemaining;
 
-public BoundedRandomAccessFileInputStream(final RandomAccessFile file,
+public BoundedSeekableInputStream(final SeekableInputStream file,
 final long size) {
 this.file = file;
 this.bytesRemaining = size;
diff --git 
a/src/main/java/org/apache/commons/compress/archivers/sevenz/SevenZFile.java 
b/src/main/java/org/apache/commons/compress/archivers/sevenz/SevenZFile.java
index 398783f..8c847bf 100644
--- a/src/main/java/org/apache/commons/compress/archivers/sevenz/SevenZFile.java
+++ b/src/main/java/org/apache/commons/compress/archivers/sevenz/SevenZFile.java
@@ -34,6 +34,8 @@ import org.apache.commons.compress.utils.BoundedInputStream;
 import org.apache.commons.compress.utils.CRC32VerifyingInputStream;
 import org.apache.commons.compress.utils.CharsetNames;
 import org.apache.commons.compress.utils.IOUtils;
+import org.apache.commons.compress.utils.SeekableFileInputStream;
+import org.apache.commons.compress.utils.SeekableInputStream;
 
 /**
  * Reads a 7z file, using RandomAccessFile under
@@ -68,7 +70,7 @@ public class SevenZFile implements Closeable {
 static final int SIGNATURE_HEADER_SIZE = 32;
 
 private final String fileName;
-private RandomAccessFile file;
+private SeekableInputStream file;
 private final Archive archive;
 private int currentEntryIndex = -1;
 private int currentFolderIndex = -1;
@@ -90,9 +92,44 @@ public class SevenZFile implements Closeable {
  * @throws IOException if reading the archive fails
  */
 public SevenZFile(final File filename, final byte[] password) throws 
IOException {
+this(new SeekableFileInputStream(new RandomAccessFile(filename, "r")),
+filename.getAbsolutePath(), password);
+}
+
+/**
+ * Reads a file as unecrypted 7z archive
+ *
+ * @param filename the file to read
+ * @throws IOException if reading the archive fails
+ */
+public SevenZFile(final File filename) throws IOException {
+this(filename, null);
+}
+
+/**
+ * Reads a SeekableInputStream as an unencrypted 7z archive.
+ * 
+ * @param seekableInputStream the stream to read
+ * @throws IOException if reading the archive fails
+ */
+public SevenZFile(final SeekableInputStream seekableInputStream) throws 
IOException {
+this(seekableInputStream, seekableInputStream.toString(), null);
+}
+
+/**
+ * Reads a SeekableInputStream as 7z archive
+ *
+ * @param seekableInputStream the stream to read
+ * @param password optional password if the archive is encrypted -
+ * the byte array is supposed to be the UTF16-LE encoded
+ * representation of the password.
+ * @throws IOException if reading the archive fails
+ */
+public SevenZFile(final SeekableInputStream seekableInputStream,
+final String fileName, final byte[] password) throws IOException {
 boolean succeeded = false;
-this.file = new RandomAccessFile(filename, "r");
-this.fileName = filename.getAbsolutePath();
+this.file = seekableInputStream;
+ 

Re: [VOTE] Move COMPRESS to git

[Damjan Jovanovic]

+1

On Sat, Aug 22, 2015 at 9:29 PM, Stefan Bodewig bode...@apache.org wrote:
 Hi all

 more thann half a year ago I promised to call for a vote for migrating
 to git as soon as 1.10 has been released.  Well that took longer than
 expected :-)

 Anyway, here is the vote:

 +1 Move to git
 -1 Stick with svn

 vote will be open for 72 hours

 Cheers

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] (Internal)LZWInputStream

[Damjan Jovanovic]

Hi

I have a patch waiting to be committed to commons-imaging which uses
the LZW stuff in commons-compress (brief mention of it by me on
IMAGING-126), so it could break with these changes. My hope was to
wait for the next release of compress before committing, so I could
use that version of compress as a dependency.

Also, LZW is a very loose algorithm with many important differences
between implementations in ZIP, Z, TIFF, GIF, etc. It is difficult to
generalize. I was even somewhat against the idea of making a general
LZWInputStream, as opposed to a customized LZW decompressor in every
place where it's needed. Just changing things in the class because of
how it seems to be used in compress, will definitely make more general
use difficult/impossible. IIRC, some code in imaging already did need
to set variables which no code in compress does.

Damjan

On Sun, Feb 1, 2015 at 4:17 PM, Benedikt Ritter benerit...@gmail.com wrote:


 Send from my mobile device

 Am 01.02.2015 um 07:04 schrieb Stefan Bodewig bode...@apache.org:

 Hi

 I'm trying to bring together two separate discussions from two different
 [VOTE]-threads.  It seems as if I should cancel the RC2 vote and before
 I rush another RC maybe we can get consensus on what to do.

 * my experiments show that moving the LZWInputStream class hasn't got as
  big an impact on subclasses of ZCompressorInputStream as I and others
  would have expected.  This likely means we can relax the warning of
  the release notes and site again.  Right?  Is anybody going to perform
  more experiments?

 I think we're safe to asume that the change will not break clients.


 * (Internal)LZWInputStream has a bunch of protected fields that slipped
  through a few releases ago.  We should add getter/setter pairs and
  deprecate using the fields.  Sebb would like to even make the fields
  private assuming the chance of people actually subclassing
  ZCompressorInputStream and using said fields is very small.

 Even creating getters and setters and deprecating the fields is the way to go 
 here, IMHO.


 Any opinions?

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] - Release Date and Production Suitability?

[Damjan Jovanovic]

The completeness and correctness ranges from feature to feature and
file format to file format, eg. I wouldn't recommend it for JPEG
images (as opposed to their metadata):
http://commons.apache.org/proper/commons-imaging/formatsupport.html

You can look through the issues to see what is outstanding/wrong.

I wanted to make major API changes before the 1.0 release, to improve
reading multiple images, better generic metadata handling, etc. But I
wonder if that's better done in version 2.0?

Damjan


On Tue, Nov 18, 2014 at 9:36 PM, Mickley, Joshua R (Genworth)
joshua.mick...@genworth.com wrote:
 Greetings All,

 I am evaluating the use of Commons Imaging for a project involving image 
 conversion and manipulation.

 My question is around a timeline for an official release of Commons Imaging 
 and suitability for use in a Production environment.

 I am currently using the SNAPSHOT version and am curious what bits of 
 functionality are needed prior to releasing the code.  The unit testing I 
 have achieved to date gives me a good impression but I wanted to inquire and 
 gain some additional insight.

 Let me know if there are any specific areas where I can help contribute.

 Thanks!
   -Josh

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] BitInputStream

[Damjan Jovanovic]

On Wed, Nov 12, 2014 at 9:49 PM, Stefan Bodewig bode...@apache.org wrote:
 Apart from EOF handling there also is the byte-order case.

 As it stands I'll get different bits in LITTLE_ENDIAN order if I read
 eight bits twice or sixteen bits at once, this is now what I'd expect.
 Should byte order imply we are always reading bytes in chunks of a given
 number?

 Right now I don't dare touching it as the LZW code is only using the
 LITTLE_ENDIAN branches and I'd need to read up on its expectations
 first.

My yet uncommitted patches to commons-imaging also use BIG_ENDIAN.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] BitInputStream

[Damjan Jovanovic]

On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig bode...@apache.org wrote:

 One thing BitStream and BitInputStream have in common is what happens
 when I request more bits than are available from the underlying stream,
 both will signal an EOF and discard the cached bits.  I.e if there are
 still three bits cached that haven't been read and I request four bits
 I'll get a -1 rather than the three bits, I'm not sure this is the
 correct behavior.

The (badly documented) assumption of readBits(final int count) is that
exactly count bits must be successfully read, or it's a failure. For
compression algorithms, these bits are symbols, and you can't do
anything with half a symbol.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[csv] CSVPrinter ResultSet quoting

[Damjan Jovanovic]

Hi

Is there some reason CSVPrinter.printRecords(final ResultSet
resultSet) retrieves all fields from the ResultSet using
ResultSet.getString(), which makes QuoteMode.NON_NUMERIC quote
numbers?

This seems to work a lot better:

Index: src/main/java/org/apache/commons/csv/CSVPrinter.java
===
--- src/main/java/org/apache/commons/csv/CSVPrinter.java(revision 1635890)
+++ src/main/java/org/apache/commons/csv/CSVPrinter.java(working copy)
@@ -512,7 +512,7 @@
 }
 while (resultSet.next()) {
 for (int i = 1; i = columnCount; i++) {
-print(resultSet.getString(i));
+print(resultSet.getObject(i));
 }
 println();
 }


Can I commit?

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress][imaging] generalise/publicise commons-compress LZW implementation?

[Damjan Jovanovic]

On Thu, Oct 23, 2014 at 5:05 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, Oct 23, 2014 at 12:42 AM, Damjan Jovanovic dam...@apache.org
 wrote:

 Hi

 I've been hoping to steal commons-compress's cleaner and faster LZW
 decompressor, and use it in commons-imaging for TIFF and GIF files,
 and I've finally managed to make a patch to that effect.

 This requires moving LZWInputStream to a
 org.apache.commons.compress.compressors.lzw package and making it
 public. Any objections to this?

 Also imaging would have to depend on a SNAPSHOT of compress to be able
 to import LZWInputStream, at least until the next release. Which is
 when?


 I think it is a good idea make [imaging] depend on [compress].

Do you mean depend in general, or as opposed to the current use of the
maven-shade-plugin to half-depend on it?

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress][imaging] generalise/publicise commons-compress LZW implementation?

[Damjan Jovanovic]

On Thu, Oct 23, 2014 at 2:38 PM, Emmanuel Bourg ebo...@apache.org wrote:
 Le 23/10/2014 06:42, Damjan Jovanovic a écrit :

 I've been hoping to steal commons-compress's cleaner and faster LZW
 decompressor, and use it in commons-imaging for TIFF and GIF files,
 and I've finally managed to make a patch to that effect.

 That's great to be able to share the code, thank you for looking at this.

 This requires moving LZWInputStream to a
 org.apache.commons.compress.compressors.lzw package and making it
 public. Any objections to this?

 I have no objection, but we may want to discuss if BitInputStream should
 belong to this package.

An argument could be made for commons-io, it could be merged with
zip's BitStream, or made package-private.

I am also going to re-examine the 4 LZW implementations and see if
they can be structured better before committing.

 Also imaging would have to depend on a SNAPSHOT of compress to be able
 to import LZWInputStream, at least until the next release. Which is
 when?

 When someone wants to release it :)

 I am attaching patches in case anyone wants to have a look, but I can
 commit them myself if there are no objections.

 It looks good to me. There are just some tabs in BitInputStream and an
 import sun.net.www.content.image.gif in GifImageParser.

Thank you, nice catch. I had tabs everywhere... fixed now :).

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[compress][imaging] generalise/publicise commons-compress LZW implementation?

[Damjan Jovanovic]

Hi

I've been hoping to steal commons-compress's cleaner and faster LZW
decompressor, and use it in commons-imaging for TIFF and GIF files,
and I've finally managed to make a patch to that effect.

This requires moving LZWInputStream to a
org.apache.commons.compress.compressors.lzw package and making it
public. Any objections to this?

Also imaging would have to depend on a SNAPSHOT of compress to be able
to import LZWInputStream, at least until the next release. Which is
when?

I am attaching patches in case anyone wants to have a look, but I can
commit them myself if there are no objections.

Thank you
Damjan
Index: 
src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
===
--- 
src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
 (revision 1632885)
+++ 
src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
 (working copy)
@@ -20,8 +20,9 @@
 
 import java.io.IOException;
 import java.io.InputStream;
+import java.nio.ByteOrder;
 
-import 
org.apache.commons.compress.compressors.z._internal_.InternalLZWInputStream;
+import org.apache.commons.compress.compressors.lzw.LZWInputStream;
 
 /**
  * Input stream that decompresses ZIP method 1 (unshrinking). A variation of 
the LZW algorithm, with some twists.
@@ -28,13 +29,13 @@
  * @NotThreadSafe
  * @since 1.7
  */
-class UnshrinkingInputStream extends InternalLZWInputStream {
+class UnshrinkingInputStream extends LZWInputStream {
 private static final int MAX_CODE_SIZE = 13;
 private static final int MAX_TABLE_SIZE = 1  MAX_CODE_SIZE;
 private final boolean[] isUsed;
 
 public UnshrinkingInputStream(InputStream inputStream) throws IOException {
-super(inputStream);
+super(inputStream, ByteOrder.LITTLE_ENDIAN);
 setClearCode(codeSize);
 initializeTables(MAX_CODE_SIZE);
 isUsed = new boolean[prefixes.length];
Index: 
src/main/java/org/apache/commons/compress/compressors/lzw/BitInputStream.java
===
--- 
src/main/java/org/apache/commons/compress/compressors/lzw/BitInputStream.java   
(revision 0)
+++ 
src/main/java/org/apache/commons/compress/compressors/lzw/BitInputStream.java   
(working copy)
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.commons.compress.compressors.lzw;
+
+import java.io.Closeable;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.ByteOrder;
+
+public class BitInputStream implements Closeable {
+   private final InputStream in;
+   private final ByteOrder byteOrder;
+private int bitsCached = 0;
+private int bitsCachedSize = 0;
+
+public BitInputStream(final InputStream in, final ByteOrder byteOrder) {
+   this.in = in;
+   this.byteOrder = byteOrder;
+}
+
+public void close() throws IOException {
+   in.close();
+}
+
+public void clearBitCache() {
+   bitsCached = 0;
+   bitsCachedSize = 0;
+}
+
+public int readBits(final int count) throws IOException {
+while (bitsCachedSize  count) {
+final int nextByte = in.read();
+if (nextByte  0) {
+return nextByte;
+}
+if (byteOrder == ByteOrder.LITTLE_ENDIAN) {
+   bitsCached |= (nextByte  bitsCachedSize);
+} else {
+   bitsCached = 8;
+   bitsCached |= nextByte;
+}
+bitsCachedSize += 8;
+}
+
+final int mask = (1  count) - 1;
+final int bitsOut;
+if (byteOrder == ByteOrder.LITTLE_ENDIAN) {
+   bitsOut = (bitsCached  mask);
+   bitsCached = count;
+} else {
+   bitsOut = (bitsCached  (bitsCachedSize - count))  mask;
+}
+bitsCachedSize -= count;
+return bitsOut;
+}
+}

Property changes on: 
src/main/java/org/apache/commons/compress/compressors/lzw/BitInputStream.java
___
Added: svn:eol-style
## -0,0 +1 ##
+native

Re: svn commit: r1632210 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java

[Damjan Jovanovic]

Thank you :).

There's lots of issues to close first, and I think 0.98 would be more
appropriate.

The API also needs big, breaking changes, to handle multi-image file
formats, copy/rewrite metadata losslessly, and other things...

Damjan

On Thu, Oct 16, 2014 at 7:01 AM, Gary Gregory garydgreg...@gmail.com wrote:
 Good to see you pop up!

 What are your thoughts on getting to 1.0?

 Gary

 -- Forwarded message --
 From: dam...@apache.org
 Date: Thu, Oct 16, 2014 at 12:49 AM
 Subject: svn commit: r1632210 -
 /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java
 To: comm...@commons.apache.org


 Author: damjan
 Date: Thu Oct 16 04:49:30 2014
 New Revision: 1632210

 URL: http://svn.apache.org/r1632210
 Log:
 Format some comments better.


 Modified:

 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java

 Modified:
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java
 URL:
 http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java?rev=1632210r1=1632209r2=1632210view=diff
 ==
 ---
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java
 (original)
 +++
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/Dct.java
 Thu Oct 16 04:49:30 2014
 @@ -22,10 +22,13 @@ final class Dct {
   * Here's the cost, exluding modified (de)quantization, for
 transforming an
   * 8x8 block:
   *
 - * Algorithm Adds Multiplies RightShifts Total Naive 896 1024 0 1920
 - * Symmetries 448 224 0 672 Vetterli and 464 208 0 672 Ligtenberg
 Arai,
 - * Agui and 464 80 0 544 Nakajima (AAN) Feig 8x8 462 54 6 522 Fused
 mul/add
 - * 416 (a pipe dream)
 + * Algorithm Adds Multiplies RightShifts Total
 + * Naive  896   1024   0  1920
 + * Symmetries   448224   0   672
 + * Vetterli and Ligtenberg464208   0   672
 + * Arai, Agui and Nakajima (AAN) 464 80   0   544
 + * Feig 8x8   462 54   6   522
 + * Fused mul/add (a pipe dream)416
   *
   * IJG's libjpeg, FFmpeg, and a number of others use AAN.
   *
 @@ -33,21 +36,25 @@ final class Dct {
   * are reduced from 80 in AAN to only 54. But in practice:
   *
   * Benchmarks, Intel Core i3 @ 2.93 GHz in long mode, 4 GB RAM Time
 taken to
 - * do 100 million IDCTs (less is better): Rene' Stöckel's Feig, int:
 45.07
 - * seconds My Feig, floating point: 36.252 seconds AAN, unrolled
 loops,
 - * double[][] - double[][]: 25.167 seconds
 + * do 100 million IDCTs (less is better):
 + * Rene' Stöckel's Feig, int: 45.07 seconds
 + * My Feig, floating point: 36.252 seconds
 + * AAN, unrolled loops, double[][] - double[][]: 25.167 seconds
   *
   * Clearly Feig is hopeless. I suspect the performance killer is
 simply the
   * weight of the algorithm: massive number of local variables, large
 code
   * size, and lots of random array accesses.
   *
 - * Also, AAN can be optimized a lot: AAN, rolled loops, double[][] -
 - * double[][]: 21.162 seconds AAN, rolled loops, float[][] -
 float[][]: no
 - * improvement, but at some stage Hotspot might start doing SIMD, so
 let's
 + * Also, AAN can be optimized a lot:
 + * AAN, rolled loops, double[][] - double[][]: 21.162 seconds
 + * AAN, rolled loops, float[][] - float[][]: no improvement,
 + * but at some stage Hotspot might start doing SIMD, so let's
   * use float AAN, rolled loops, float[] - float[][]: 19.979 seconds
 - * apparently 2D arrays are slow! AAN, rolled loops, inlined 1D AAN
 - * transform, float[] transformed in-place: 18.5 seconds AAN, previous
 - * version rewritten in C and compiled with gcc -O3 takes: 8.5
 seconds
 + * apparently 2D arrays are slow!
 + * AAN, rolled loops, inlined 1D AAN
 + * transform, float[] transformed in-place: 18.5 seconds
 + * AAN, previous version rewritten in C and compiled with gcc -O3
 + * takes: 8.5 seconds
   * (probably due to heavy use of SIMD)
   *
   * Other brave attempts: AAN, best float version converted to 16:16
 fixed





 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: [imaging] Multipage in TIFF

[Damjan Jovanovic]

You might be able to write multi-page TIFFs, by adding multiple
TiffOutputDirectories to a TiffOutputSet with directory type root in
order that the pages appear, and manually populating their images.

Regards
Damjan

On Mon, Mar 17, 2014 at 11:55 AM, Jesus Galindo
jesus.gali...@docpath.com wrote:
 Hi,

 is there any way to generate multi page with TIFF format? I test with
 commons-imaging to generate TIFF and is this library is amazing, but I
 didn't see any documentation about to write TIFF multipage.

 Regards.
 --

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] failing JUnit test

[Damjan Jovanovic]

The raw image has the XP TITLE field in IFD0, but the test writes it
into the EXIF IFD and then reads it from any IFD, so it could find it
the wrong one. The search order must be different, but I don't
understand why.

In any case, the whole TIFF package is full of nonsense and in need of
a rewrite...

Damjan

On Thu, Feb 27, 2014 at 4:25 PM, luc l...@spaceroots.org wrote:
 Hi,

 Trying to run the tests for [imaging] on the current development version, I
 keep getting a failing Junit test.

 Failed tests:
   MicrosoftTagTest.testRewrite:77-checkFields:85 expected:[title] but
 was:[WE à l'étang de Blodelsheim]

 Is this failure expected? I am running the tests suite on a Linux computer,
 maybe MicrosoftTagTest is windows-specific?

 best regards,
 Luc

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] 2.0: require Java7?

[Damjan Jovanovic]

On Sun, Jan 26, 2014 at 8:13 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2014-01-25, Damjan Jovanovic wrote:

 On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote:
 On 2013-12-30, Stefan Bodewig wrote:

 Compress 1.x is at Java5, personally I don't think Java6 would give us
 any benefits.  I don't know about the other improvements in NIO2 but the
 java.nio.file package looks useful for compress.

 In the meantime it has been pointed out to me that Android doesn't
 support NIO2.  I can imagine Android apps using Compress so this looks
 like a good reason to hold back requiring Java7.

 It's already possible to use most Java 7 language level features and
 compile to Android (https://github.com/yareally/Java7-on-Android). It
 would also possible to reimplement the needed classes (which is only
 SeekableByteChannel?) in nio2 using some kind of wrapper on top of
 Android's java.nio.

 It would also be a part java.nio.file.attribute, but we can re-invent
 that as well, if needed.  What you suggest could work as long as we are
 careful and never assume FileChannel implements SeekableByteChannel but
 use some custom File = SeekableByteChannel code using Java7 if
 available - I'm just afraid we'll forget to be careful.

Or, during compilation to Android, java.nio.channels.FileChannel could
get renamed to wrapper.FileChannel, which will implement
wrapper.SeekableByteChannel, so there's no problem.

 We could still use Java 7 / nio2 and then make a plan for Android
 releases.

 Thanks for volunteering ;-)

Heh :).

 Stefan


Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] 2.0: require Java7?

[Damjan Jovanovic]

On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote:
 On 2013-12-30, Stefan Bodewig wrote:

 Compress 1.x is at Java5, personally I don't think Java6 would give us
 any benefits.  I don't know about the other improvements in NIO2 but the
 java.nio.file package looks useful for compress.

 In the meantime it has been pointed out to me that Android doesn't
 support NIO2.  I can imagine Android apps using Compress so this looks
 like a good reason to hold back requiring Java7.

 Stefan


It's already possible to use most Java 7 language level features and
compile to Android (https://github.com/yareally/Java7-on-Android). It
would also possible to reimplement the needed classes (which is only
SeekableByteChannel?) in nio2 using some kind of wrapper on top of
Android's java.nio.

We could still use Java 7 / nio2 and then make a plan for Android releases.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] 2.0: Reading and Writing Archives

[Damjan Jovanovic]

On Wed, Jan 8, 2014 at 4:41 PM, Stefan Bodewig bode...@apache.org wrote:
 Hi,

 putting the exact representation of an archive entry aside I've put down
 an idea of the API for reading and writing archives together with a POC
 port of the AR classes for this API.  All is inside
 http://svn.apache.org/repos/asf/commons/proper/compress/branches/compress-2.0/

 The port doesn't look pretty but I wanted to get there quickly and
 change as little as possible, partly to see how much effort porting the
 existing code base would be.  In particular I copied IOUtils into the AR
 package so I don't have to thing about a proper package right now.  I
 also didn't care about Java  7 so far.

 Please have a look (more on the interfaces than the actual
 implementation) and show me how wrong I am :-)

 Some points I'd like to highlight and discuss:

 * ArchiveInput and ArchiveOutput are not Streams (or Channels)
   themselves

   This is unline Archive*Stream in 1.x

   Emmanuel brought this up in a chat between the two of us and I agreed
   with him.  You don't really use them as a stream but rather as a
   stream per entry.

   For Compressor* I'd still wrap streams/channels, different issue.

 * Using Channels rather than Streams

   I'm a bit torn about this.  I did so because I'd prefer to base
   ZipFile and friends on SeekableByteStream rather than RandomAccessFile
   - so it would make the API look more symmetric.

   Drawbacks I've already found

   - no skip in ReadableByteChannel so you are forced to read data even
 if something more efficient could be done.  This smells like another
 IOUtils method.

   - worse, no mark/reset or pushback, this is going to make format
 detection uglier as we have to rewind the channel in a different way

   Another concern might be that Compress 2.0 might get delayed because
   proting effort was bigger - I've deliberately taken the Channels.new*
   route to wrap the existing stream based API in ArArchiveInput and it
   seems to work (although likely is suboptimal).  Going all-in on
   Channels in ArArchiveOutput didn't look much more difficult either,
   but the I/O part of output is simpler anyway.

 * Checked vs Unchecked exceptions

   I would love to make ArchiveInput be an Iterator over the entries but
   can't do so as the things we'd need to do in next() might throw an
   IOException.  One option may be to introduce an unchecked
   ArchiveException and wrap al checked exceptions (and do so throughout
   the API).

Doesn't sound very appealing.

 * RandomAccessArchiveInput as a generalization of ZipFile

   This extends ArchiveInput so if you ask for an ArchiveInput to a file
   and the format doesn't support a stream-like interface (like 7z) you
   can still obtain one.  This is helped a lot by the fact that
   ArchiveInput is not a stream itself.

 * I'm not sure about ArchiveInput#getChannel

   Should next return a Pair of ArchiveEntry and Channel instead?

I don't think so, you might not want to look at an ArchiveEntry's
contents, or it might be empty.

 * tiny change to the contract of ArchiveOutput finish

   finish used to throw an exception if you didn't call closeEntry for
   the last entry while putEntry closes the previous entry.  This looked
   inconsistent and finish now silently closes the entry as well.

 Stefan

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1551026 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress: archivers/zip/UnshrinkingInputStream.java compressors/z/AbstractLZWInputStream.java compressors/

[Damjan Jovanovic]

Very nice.

I am wondering how far this can be taken. TIFF's LZW uses an
end-of-information code after the clear code, allows both
little-endian and big-endian packing of bytes, and increases the code
size one step too early. Is it even possible to generalize LZW (any
further), and would it be a good idea, given how uniquely it's
implemented in each file format?

Damjan

On Sun, Dec 15, 2013 at 5:23 PM,  bode...@apache.org wrote:
 Author: bodewig
 Date: Sun Dec 15 15:23:35 2013
 New Revision: 1551026

 URL: http://svn.apache.org/r1551026
 Log:
 reduce code duplication in the two LZW input streams

 Added:
 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/compressors/z/AbstractLZWInputStream.java
(with props)
 Modified:
 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/compressors/z/ZCompressorInputStream.java

 Modified: 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java?rev=1551026r1=1551025r2=1551026view=diff
 ==
 --- 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
  (original)
 +++ 
 commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/UnshrinkingInputStream.java
  Sun Dec 15 15:23:35 2013
 @@ -21,84 +21,43 @@ package org.apache.commons.compress.arch
  import java.io.IOException;
  import java.io.InputStream;

 -import org.apache.commons.compress.compressors.CompressorInputStream;
 +import org.apache.commons.compress.compressors.z.AbstractLZWInputStream;

  /**
   * Input stream that decompresses ZIP method 1 (unshrinking). A variation of 
 the LZW algorithm, with some twists.
   * @NotThreadSafe
   * @since 1.7
   */
 -class UnshrinkingInputStream extends CompressorInputStream {
 -private final InputStream in;
 -private final int clearCode;
 -private final int MAX_CODE_SIZE = 13;
 -private int codeSize = 9;
 -private int bitsCached = 0;
 -private int bitsCachedSize = 0;
 -private int previousCode = -1;
 -private int tableSize = 0;
 -private final int[] prefixes;
 -private final byte[] characters;
 +class UnshrinkingInputStream extends AbstractLZWInputStream {
 +private static final int MAX_CODE_SIZE = 13;
 +private static final int MAX_TABLE_SIZE = 1  MAX_CODE_SIZE;
  private final boolean[] isUsed;
 -private final byte[] outputStack;
 -private int outputStackLocation;

  public UnshrinkingInputStream(InputStream inputStream) throws 
 IOException {
 -this.in = inputStream;
 -clearCode = (1  (codeSize - 1));
 -final int maxTableSize = 1  MAX_CODE_SIZE;
 -prefixes = new int[maxTableSize];
 -characters = new byte[maxTableSize];
 -isUsed = new boolean[maxTableSize];
 -outputStack = new byte[maxTableSize];
 -outputStackLocation = maxTableSize;
 +super(inputStream);
 +setClearCode(codeSize);
 +initializeTables(MAX_CODE_SIZE);
 +isUsed = new boolean[prefixes.length];
  for (int i = 0; i  (1  8); i++) {
 -prefixes[i] = -1;
 -characters[i] = (byte)i;
  isUsed[i] = true;
  }
  tableSize = clearCode + 1;
  }
 -
 -public void close() throws IOException {
 -in.close();
 -}
 -
 -private int readNextCode() throws IOException {
 -while (bitsCachedSize  codeSize) {
 -final int nextByte = in.read();
 -if (nextByte  0) {
 -return nextByte;
 -}
 -bitsCached |= (nextByte  bitsCachedSize);
 -bitsCachedSize += 8;
 -}
 -final int mask = (1  codeSize) - 1;
 -final int code = (bitsCached  mask);
 -bitsCached = codeSize;
 -bitsCachedSize -= codeSize;
 -return code;
 -}
 -
 -private int addEntry(int previousCode, byte character) throws 
 IOException {
 -final int maxTableSize = 1  MAX_CODE_SIZE;
 -while ((tableSize  maxTableSize)  isUsed[tableSize]) {
 +
 +@Override
 +protected int addEntry(int previousCode, byte character) throws 
 IOException {
 +while ((tableSize  MAX_TABLE_SIZE)  isUsed[tableSize]) {
  tableSize++;
  }
 -if (tableSize  maxTableSize) {
 -final int index = tableSize;
 -prefixes[tableSize] = previousCode;
 -characters[tableSize] = character;
 -isUsed[tableSize] = true;
 -tableSize++;
 -return index;
 -} else {
 -return 

Re: svn commit: r1548677 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ main/java/org/apache/commons/compress/compressors/z/ site/xdoc/

[Damjan Jovanovic]

On Thu, Dec 12, 2013 at 4:11 PM, Emmanuel Bourg ebo...@apache.org wrote:
 Le 06/12/2013 20:20, dam...@apache.org a écrit :

 +public class UnshrinkingInputStream extends CompressorInputStream {

 What about keeping this class package private? I don't think it's
 necessary to make it part of the public API.

Ok.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[compress] ZIP unshrinking support

[Damjan Jovanovic]

Hi

I just committed a patch for decompressing ZIP entries using method 1
(unshrinking), but it's only for ZipFile.

If someone wants to help patch ZipInputStream, please feel free. It
may be worth refactoring decompression in that class, because it will
just keep getting worse as more compression methods are added.

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Imaging 1.0 from RC7

[Damjan Jovanovic]

Vote closed, results were:

+1:
Damjan Jovanovic

No other votes were cast.

Vote fails since majority approval needs at least 3 votes of +1 -
aborting release.

Damjan

On Sun, Nov 24, 2013 at 6:54 PM, Damjan Jovanovic dam...@apache.org wrote:
 Please vote on releasing commons-imaging 1.0 from RC7.

 Last failed vote was for RC5, RC6 had a bust POM. Many improvements
 were made since:
 * PMD configured better and all PMD warnings fixed, the ones remaining
 now are bugs in PMD itself.
 * Test coverage greatly improved in many areas, only a few packages
 now have  50% coverage, and that's due to obscure TIFF photometric
 interpreters and PSD data parsers that require special images to test
 which Imaging can't itself generate, a massive barely used
 semi-obsolete Debug class that drags down coverage for
 org.apache.commons.imaging.util, and areas of code I don't understand
 and so can't easily test (ICC, PSD). While improving test coverage, I
 also found and fixed 2 bugs.
 * Added package-level Javadoc for image formats.
 * RAT exclusions for text-based images, and made a single info.txt
 with image formation for all images and added a license header to it.
 * Fixed Jacoco configuration in the POM and started using it instead
 of that 40+ minute Cobertura nonsense.
 * Fixed website broken links.
 * Also started assembling a list of why making releases is such a
 pain, email coming later :).

 Imaging 1.0 RC7 is available here:
 https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)

 Maven artifacts:
 https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/

 Change log(s):
 https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
 http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
 http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html

 Tag:
 https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
 (SVN revision 1544953)

 Site:
 http://people.apache.org/~damjan/imaging-1.0-RC7/

 KEYS:
 http://www.apache.org/dist/commons/KEYS

 I have tested it with OpenJDK 6 on FreeBSD 9.1.

 Please review and vote. This vote will close no sooner than 72 hours
 from now, on Wednesday 27 November 2013 at 19:00 GMT.

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...

 Thank you!

 Damjan Jovanovic

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1546303 - in /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging: common/ common/bytesource/ common/itu_t4/ common/mylzw/ formats/bmp/pixelparsers/ formats/jpeg/dec

[Damjan Jovanovic]

Why? I've heard initializing fields, even to their defaults, is a good
practice and makes code clearer.

Damjan

On Thu, Nov 28, 2013 at 9:43 AM,  ebo...@apache.org wrote:
 Author: ebourg
 Date: Thu Nov 28 07:43:15 2013
 New Revision: 1546303

 URL: http://svn.apache.org/r1546303
 Log:
 Removed field initializations to the default values

 Modified:
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryFileParser.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryOutputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/FastByteArrayOutputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/bytesource/ByteSourceInputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/itu_t4/BitArrayOutputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/itu_t4/BitInputStreamFlexible.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/MyBitInputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/MyBitOutputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/mylzw/MyLzwDecompressor.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/bmp/pixelparsers/PixelParserBitFields.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegDecoder.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/jpeg/decoder/JpegInputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/pcx/PcxWriter.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/PngCrc.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/tiff/TiffDirectory.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/tiff/TiffReader.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/tiff/datareaders/BitInputStream.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/tiff/datareaders/DataReaderStrips.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/tiff/write/TiffOutputDirectory.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/xpm/XpmImageParser.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/palette/ColorCount.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/palette/ColorGroup.java
 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/util/Debug.java

 Modified: 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryFileParser.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryFileParser.java?rev=1546303r1=1546302r2=1546303view=diff
 ==
 --- 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryFileParser.java
  (original)
 +++ 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryFileParser.java
  Thu Nov 28 07:43:15 2013
 @@ -24,7 +24,7 @@ import java.nio.charset.Charset;
  public class BinaryFileParser {
  // default byte order for Java, many file formats.
  private ByteOrder byteOrder = ByteOrder.BIG_ENDIAN;
 -private boolean debug = false;
 +private boolean debug;

  public BinaryFileParser(final ByteOrder byteOrder) {
  this.byteOrder = byteOrder;

 Modified: 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryOutputStream.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryOutputStream.java?rev=1546303r1=1546302r2=1546303view=diff
 ==
 --- 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryOutputStream.java
  (original)
 +++ 
 commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/common/BinaryOutputStream.java
  Thu Nov 28 07:43:15 2013
 @@ -24,8 +24,8 @@ public class BinaryOutputStream extends
  private final OutputStream os;
  // default byte order for Java, many file formats.
  private ByteOrder byteOrder = ByteOrder.BIG_ENDIAN;
 -private boolean debug = false;
 -private int count = 0;
 +private boolean debug;
 +private int count;

  public final void setDebug(final boolean b) {
  debug = b;

 Modified: 
 

Re: [VOTE] Release Imaging 1.0 from RC7

[Damjan Jovanovic]

On Tue, Nov 26, 2013 at 4:32 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Tue, Nov 26, 2013 at 12:31 AM, Damjan Jovanovic dam...@apache.orgwrote:

 On Mon, Nov 25, 2013 at 1:50 PM, Emmanuel Bourg ebo...@apache.org wrote:
  Hi Damjan,

 Hi Emmanuel

  I reviewed the API, here are my observations:

 Thank you.

 Firstly, we discussed several options before for the 1.0 release, and
 agreed that the contents of trunk would be quickly pushed out as 1.0
 with minimal changes (many/most users are using 1.0-SNAPSHOT), and
 then the big API redesign would be 2.0. I've also been thinking of
 doing a complete rewrite for 2.0 and only pulling in some of the good
 bits we have now. So it's extremely discouraging to be pushed for more
 and more changes, many of which will have no post-1.x value, and don't
 even fit in with what was originally agreed on.

  - Would that make sense to move the LZM implementation to
 commons-compress?

 I think you mean LZW, and let's discuss that on COMPRESS-243.

  - What is the purpose of CachingInputStream and CachingOutputStream,
  there is no Javadoc on these classes. Could they be merged into
 commons-io?

 It looks like CachingInputStream is used by IccProfileParser, and
 appears to be used to store data that has been read from the
 underlying stream so it can be re-read later. You can copy it to
 commons-io, but I'd prefer not having a runtime dependency on it. And
 it's ByteSourceInputStream you really want in commons-io and/or
 commons-compress, a gem that allows seeking over an InputStream.

  - Why is ZLibUtils in org.apache.commons.imaging.common instead of
  org.apache.commons.imaging.util ?

 The whole org.apache.commons.imaging.util package is a bit dated.

  - FastByteArrayOutputStream is only used by PackBits in the same
  package, it could be made package private.

 Yes.

  - BitArrayOutputStream in org.apache.commons.imaging.common is only used
  by classes in org.apache.commons.imaging.common.itu_t4. It could be
  moved into this package and made package private.

 Yes.

  - There are several unused public methods in BinaryInputStream

 Yes.

  - org.apache.commons.imaging.common.Compression is never used

 I imagine the idea was to use it instead of using the different
 compression classes directly, but whoever started writing it never
 finished.

  - RgbBufferedImageFactory is only used in RoundtripTest, should this be
  moved with the test sources?

 Was probably meant to be the way to create all images in the API, but
 again never got finished, and is probably wrong now since some image
 formats produce paletted images.

  - SimpleBufferedImageFactory is only used by ImageParser and could be
  made package private.

 And bears suspiciously high resemblance to RgbBufferedImageFactory.

  - What about replacing org.apache.commons.imaging.common.ByteOrder with
  java.nio.ByteOrder?

 Enum vs public static final, hmm.


 I think the point is that ByteOrder is a JRE provided class, we should not
 reinvent the wheel, unless we need to support middle-endian. Does Java run
 on PDP-11? ;)

You laugh, but the leDOS JVM runs on MS-DOS, and JAmiga on Amigas, so
it might be possible :).

Also by the same analogy, org.omg.CORBA had IntHolder since Java SE
1.2, yet we still have MutableInt in commons-lang. But either way,
Imaging's ByteOrder has already been replaced with java.nio's.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1545710 - in /commons/proper/imaging/trunk: pmd-ruleset.xml pom.xml src/conf/pmd-ruleset.xml src/main/java/org/apache/commons/imaging/ColorTools.java

[Damjan Jovanovic]

On Tue, Nov 26, 2013 at 6:18 PM,  ebo...@apache.org wrote:
 Author: ebourg
 Date: Tue Nov 26 16:18:58 2013
 New Revision: 1545710

 URL: http://svn.apache.org/r1545710
 Log:
 Adjust PMD rules


 Copied: commons/proper/imaging/trunk/src/conf/pmd-ruleset.xml (from r1545174, 
 commons/proper/imaging/trunk/pmd-ruleset.xml)
 URL: 
 http://svn.apache.org/viewvc/commons/proper/imaging/trunk/src/conf/pmd-ruleset.xml?p2=commons/proper/imaging/trunk/src/conf/pmd-ruleset.xmlp1=commons/proper/imaging/trunk/pmd-ruleset.xmlr1=1545174r2=1545710rev=1545710view=diff
 ==
 --- commons/proper/imaging/trunk/pmd-ruleset.xml (original)
 +++ commons/proper/imaging/trunk/src/conf/pmd-ruleset.xml Tue Nov 26 16:18:58 
 2013
 @@ -65,6 +65,8 @@
rule ref=rulesets/java/migrating.xml/
rule ref=rulesets/java/optimizations.xml
  exclude name=AvoidInstantiatingObjectsInLoops/
 +exclude name=LocalVariableCouldBeFinal/
 +exclude name=MethodArgumentCouldBeFinal/
  exclude name=RedundantFieldInitializer/
  exclude name=PrematureDeclaration/
/rule


Why are we excluding those? Final variables are a good thing.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Imaging 1.0 from RC7

[Damjan Jovanovic]

 in ColorConversions into the respective
 Color classes? For example, ColorConversions.convertCIELuvtoXYZ() could
 become ColorCieLuv.toXYZ(). Another idea would be to use a fluent
 interface to perform the conversions. Something like
 ColorConverter.fromRGB(r, g, b).toHSL().

Maybe the former. Some of these conversions are lossy, and there is no
standard canonical color format that fromRGB() could return, so I'm
not sure you want to chain them. Also color conversions are also done
per pixel, so they're performance critical, and 2 method calls, 2
format conversions, and potentially an extra memory allocation in
fromRGB(), are going to be very slow. Already I think those methods
should be made to operate on reusable rewritable pre-allocated objects
they get passed in, not allocate and return a new object per pixel.


 I haven't reviewed everything yet, but I have the feeling the public API
 could be better polished to remove unused or internal stuff that are
 probably not useful for the end users.

Yes, there's plenty more. But users are begging for a 1.0 release, not
higher API standards.

Thank you again for the review - it will all get fixed or replaced at
some stage.

Finally, please remember: 1.0 releases are usually the ones that never work :-).

 Emmanuel Bourg

Damjan

 Le 24/11/2013 17:54, Damjan Jovanovic a écrit :
 Please vote on releasing commons-imaging 1.0 from RC7.

 Last failed vote was for RC5, RC6 had a bust POM. Many improvements
 were made since:
 * PMD configured better and all PMD warnings fixed, the ones remaining
 now are bugs in PMD itself.
 * Test coverage greatly improved in many areas, only a few packages
 now have  50% coverage, and that's due to obscure TIFF photometric
 interpreters and PSD data parsers that require special images to test
 which Imaging can't itself generate, a massive barely used
 semi-obsolete Debug class that drags down coverage for
 org.apache.commons.imaging.util, and areas of code I don't understand
 and so can't easily test (ICC, PSD). While improving test coverage, I
 also found and fixed 2 bugs.
 * Added package-level Javadoc for image formats.
 * RAT exclusions for text-based images, and made a single info.txt
 with image formation for all images and added a license header to it.
 * Fixed Jacoco configuration in the POM and started using it instead
 of that 40+ minute Cobertura nonsense.
 * Fixed website broken links.
 * Also started assembling a list of why making releases is such a
 pain, email coming later :).

 Imaging 1.0 RC7 is available here:
 https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)

 Maven artifacts:
 https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/

 Change log(s):
 https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
 http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
 http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html

 Tag:
 https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
 (SVN revision 1544953)

 Site:
 http://people.apache.org/~damjan/imaging-1.0-RC7/

 KEYS:
 http://www.apache.org/dist/commons/KEYS

 I have tested it with OpenJDK 6 on FreeBSD 9.1.

 Please review and vote. This vote will close no sooner than 72 hours
 from now, on Wednesday 27 November 2013 at 19:00 GMT.

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...

 Thank you!

 Damjan Jovanovic

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Imaging 1.0 from RC7

[Damjan Jovanovic]

Please vote on releasing commons-imaging 1.0 from RC7.

Last failed vote was for RC5, RC6 had a bust POM. Many improvements
were made since:
* PMD configured better and all PMD warnings fixed, the ones remaining
now are bugs in PMD itself.
* Test coverage greatly improved in many areas, only a few packages
now have  50% coverage, and that's due to obscure TIFF photometric
interpreters and PSD data parsers that require special images to test
which Imaging can't itself generate, a massive barely used
semi-obsolete Debug class that drags down coverage for
org.apache.commons.imaging.util, and areas of code I don't understand
and so can't easily test (ICC, PSD). While improving test coverage, I
also found and fixed 2 bugs.
* Added package-level Javadoc for image formats.
* RAT exclusions for text-based images, and made a single info.txt
with image formation for all images and added a license header to it.
* Fixed Jacoco configuration in the POM and started using it instead
of that 40+ minute Cobertura nonsense.
* Fixed website broken links.
* Also started assembling a list of why making releases is such a
pain, email coming later :).

Imaging 1.0 RC7 is available here:
https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)

Maven artifacts:
https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/

Change log(s):
https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html

Tag:
https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
(SVN revision 1544953)

Site:
http://people.apache.org/~damjan/imaging-1.0-RC7/

KEYS:
http://www.apache.org/dist/commons/KEYS

I have tested it with OpenJDK 6 on FreeBSD 9.1.

Please review and vote. This vote will close no sooner than 72 hours
from now, on Wednesday 27 November 2013 at 19:00 GMT.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you!

Damjan Jovanovic

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Imaging 1.0 from RC5

[Damjan Jovanovic]

On Fri, Nov 1, 2013 at 8:24 PM, Gary Gregory garydgreg...@gmail.com wrote:

 Thank you Damjan for cutting another release!

 In the future, please summarize changes from RC to RC in the VOTE email.
 The link to the VOTE thread is too much of a hunt to understand what's
 changed. I might as well look at SVN.

 I admire Damjan's persistence and patience in seeing through another RC
 toward 1.0 :)


Thank you :).


 [X] -0 OK, but really should fix...

 - The RAT report shows 40 Unknown Licenses, either add license headers or
 get RAT to ignore these files.


RAT's Maven plugin doesn't have a setting to ignore files. I've merged the
info.txt files that state where each test image came from into one file and
put a license header in it. XPM/XBM/PAM/PGM are text-based images, so it
may not be possible to comment them.
src/main/resources/org/apache/commons/imaging/formats/xpm/rgb.txt is not
our file - it's an MIT licensed file from the X.org project as stated in
LICENSE.txt, so should we put an MIT header in it?


 - On the References page, all the links to Geocities are broken. Either
 remove the broken links or link to the internet archive wayback machine or
 similar.


Done.


 - Is the to-do list on the site 100% accurate?
 https://people.apache.org/~damjan/imaging-1.0-RC5/todo.html


Fixed it up.


 - I would also change the title of the page from To Do to Roadmap and
 talk about the upcoming 2.0 plan how 1.0 relates to 0.97 (new package).


It's Roadmap now.


 - We need a Migrating from 0.97 to 1.0 and Plans for 2.0 sections, IMO.


Judging by the bug reports, almost everyone is using 1.0-SNAPSHOT. Version
0.97 is a pre-release incubator version, and there's already documentation
about the transition in RELEASE-NOTES.txt and in the History page.


 - For the page Project Status and History, I would just call it
 History. This page is missing versions.


I did. Added the 2 versions that were missing.


 - Javadoc: Most packages are missing a package-level description.


Added it for the main packages.


 - Findbugs reports
 org.apache.commons.imaging.icc.IccProfileParser.issRGB(ICC_Profile) has
 Boolean return type and returns explicit null BAD_PRACTICE (and others like
 it).
 For methods like
 org.apache.commons.imaging.icc.IccProfileParser.issRGB(ICC_Profile), it
 seems to complicate the code a lot more to return a Boolean instead of a
 boolean.
 We should consider changing these APIs to boolean. I've only looks at
 IccProfileParser.issRGB
 and this one case seems OK for change.


The problem was that issRGB had failure states, such as when the input is
null, or when an exception gets thrown (it swallows them all), for which it
returns null. But I've made it return boolean and throw exceptions instead.


 - Checkstyle: We have a lot of 'Useless parentheses', the few I've checked
 seem like they should be removed. This is a lot of work to check one at a
 time and I do not think we should remove them all automatically (like
 Eclipse can do) unless the person most familiar with the code chooses to do
 so.


I am not sure which parentheses you mean, the () around expressions, or the
{} around statements. Which Checkstyle settings are you using?


 - I'm not a fan of using interfaces (instead of classes) to define
 constants, but if this in fact the style we're going forward with, we
 should not redundantly define each constant as public, a fact that is
 implied by being an interface member (and which Checkstyle complains
 about.)


The problem is that there are endless TIFF tags, so they're convenient to
split up into separate classes when implementing, but then difficult for
the user to find the right one. So they've been merged into AllTagConstants
by multi-inheritance, something classes cannot do. But I've deleted public
static final at least, and converted XyzConstants to classes in other
packages.


 - Findbugs: WRT byte arrays and malicious code, it seems safe to ignore
 these since we are working with bytes all the time. I'm not sure if it is
 worth Javadoc'ing this intention or adding some kinds of comment in the
 source Findbugs can use to avoid these warnings. It's probably NOT worth
 doing, but I thought I'd mention it.


There is no source comment. Findbugs can use a filter to not examine
certain files/classes/methods, but I am not a fan - that filter could hide
other bugs in the future.


 Tested with:

 Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17
 11:22:22-0400)
 Maven home: C:\Java\apache-maven-3.1.1\bin\..
 Java version: 1.7.0_45, vendor: Oracle Corporation
 Java home: C:\Program Files\Java\jdk1.7.0_45\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows 7, version: 6.1, arch: amd64, family: windows

 Gary


Damjan



 On Fri, Nov 1, 2013 at 7:57 AM, Damjan Jovanovic dam...@apache.org
 wrote:

  Please vote on releasing commons-imaging 1.0 from RC5.
 
  RC4 and its problems and their fixes were in this thread:
 
 
 http://mail

Re: [VOTE] Release Imaging 1.0 from RC5

[Damjan Jovanovic]

On Sun, Nov 3, 2013 at 1:00 AM, Jörg Schaible joerg.schai...@gmx.de wrote:

 Hi Damjan,

 Damjan Jovanovic wrote:

  Please vote on releasing commons-imaging 1.0 from RC5.
 
  RC4 and its problems and their fixes were in this thread:
 
 http://mail-archives.apache.org/mod_mbox/commons-dev/201209.mbox/%3CCAJm2B-nbnbJwNUKkAtapZuzT5jfFODsk1aXcdsUUeoC%2BxXrDKg%40mail.gmail.com%3E
  There were also many recent discussions on the development list.
 
  Imaging 1.0 RC5 is available here:
  https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision
  3391)
 
  Maven artifacts:
 

 https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-
 imaging/
 
  Change log(s):
  https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
  http://people.apache.org/~damjan/imaging-1.0-RC5/changes-report.html
  http://people.apache.org/~damjan/imaging-1.0-RC5/jira-report.html
 
  Tag:
 

 https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC5
 
 https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC4
 (SVN
  revision 1537825)
 
  Site:
  http://people.apache.org/~damjan/imaging-1.0-RC5/
 http://people.apache.org/%7Edamjan/imaging-1.0rc4/
 
  I have tested it with OpenJDK 6 on FreeBSD 9.1.
 
  Please review and vote. This vote will close no sooner than 72 hours from
  now, on Monday 4 November 2013 at 12:00 GMT.
 
  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...
 
  Thank you!
 
  Damjan Jovanovic

 The following error was some time ago normal, but I haven't seen it for
 some
 time now:

 = % =
 $ tar xf commons-imaging-1.0-src.tar.gz
 tar: Skipping to next header

 gzip: stdin: unexpected end of file
 tar: Child returned status 1
 tar: Error is not recoverable: exiting now
 = % =

 Do you still use an old version of the assembly plugin to build the tar
 balls?


Don't know why you get that. The assembly plugin version - 2.4 - is set by
the parent POM, works fine for everyone in every commons project, and has
worked fine for ages.




 Building from source with Maven I have the same 32 test failures for all my
 JDKs:
 = % =
 Failed tests:
   IcnsReadTest.test:36-IcnsBaseTest.getIcnsImages:45-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   IcoReadTest.test:36-IcoBaseTest.getIcoImages:41-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   RgbeReadTest.test:34-RgbeBaseTest.getRgbeImages:43-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   WbmpReadTest.test:34-WbmpBaseTest.getWbmpImages:37-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   JpegXmpDumpTest.test:33-JpegXmpBaseTest.getImagesWithXmpData:73-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   JpegXmpRewriteTest.testRemoveInsertUpdate:38-
 JpegXmpBaseTest.getImagesWithXmpData:73-ImagingTest.getTestImages:108-
 ImagingTest.getTestImages:168 null


ImagingTest.getTestImages:168 is
assertTrue(images.size()  0);
where images was set to:
final ListFile images = new ArrayListFile();
and then populated with images.
Either your test images aren't being found or something else is broken in
your setup.



   IptcUpdateTest.setUp:46-IptcBaseTest.getImagesWithIptcData:71-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   IptcUpdateTest.setUp:46-IptcBaseTest.getImagesWithIptcData:71-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   IptcUpdateTest.setUp:46-IptcBaseTest.getImagesWithIptcData:71-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   IptcDumpTest.test:34-IptcBaseTest.getImagesWithIptcData:71-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   MicrosoftTagTest.testRewrite:66-ExifBaseTest.getImageWithExifData:73-
 ImagingTest.getTestImage:95-ImagingTest.getTestImages:168 null
   ExifRewriteTest.testRewriteLossless:277-rewrite:177-
 ExifBaseTest.getImagesWithExifData:78-ImagingTest.getTestImages:108-
 ImagingTest.getTestImages:168 null
   ExifRewriteTest.testRewriteLossy:264-rewrite:177-
 ExifBaseTest.getImagesWithExifData:78-ImagingTest.getTestImages:108-
 ImagingTest.getTestImages:168 null
   ExifRewriteTest.testInsert:96-ExifBaseTest.getImagesWithExifData:78-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   ExifRewriteTest.testRemove:55-ExifBaseTest.getImagesWithExifData:78-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   WriteExifMetadataExampleTest.test:36-ExifBaseTest.getJpegImages:91-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null

 WriteExifMetadataExampleTest.testInsert:63-ExifBaseTest.getJpegImages:91-
 ImagingTest.getTestImages:108-ImagingTest.getTestImages:168 null
   AsciiFieldTest.testSingleImage:38-ImagingTest.getTestImageByName:85

Backporting try-with-resources to Java 7 (was: Re: [imaging] Closing stream)

[Damjan Jovanovic]

On Fri, Oct 25, 2013 at 1:52 PM, Matt Benson gudnabr...@gmail.com wrote:

 On Oct 25, 2013 6:30 AM, Damjan Jovanovic damjan@gmail.com wrote:
 
  On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible
  joerg.schai...@scalaris.com wrote:
   Hi Damjan,
  
   Damjan Jovanovic wrote:
  
   [snip]
  
   Thanks for explanation.
  
   We would be able to adapt that for Java  1.7 by swallowing the close
   exception instead of calling addSuppressed() on the primary exception,
   but the show stopper is catching and rethrowing the primary exception
   (Throwable), which javac  1.7 refuses to compile because it doesn't
   do Rethrowing Exceptions with More Inclusive Type Checking
   (

 http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html
 ).
  
   But this would work and always sets succeeded correctly without
   catch/re-throw:
  
   final InputStream is = factoryMethodThatCanThrow();
   boolean succeeded = false;
   try {
   try {
   is.methodThatCanThrow();
   } finally {
   }
   succeeded = true;
   } finally {
   closeSafely(!succeeded, is);
   }
  
   I guess the nested try was unintentionally ;-)
  
   Cheers,
   Jörg
 
  Well that actually won't work, because the succeeded = true; will be
  skipped if there is a return; in the inner try.
 
  Other than a custom Java compiler, I guess there's no clean way of
  doing this in Java  1.7. There's really only option 2 - with being
  careful to always set succeeded correctly on all paths out of the try
  block. Almost like releasing memory in C.
 

 I haven't deeply followed this conversation, but would this be a candidate
 for a [weaver] module?

 Matt



[weaver] I am less sure about, but by playing with Objectweb's ASM I did
manage to compile code with try-with-resources on Java 7, change the class
file version, do some bytecode manipulation to delete calls to
Throwable.addSuppressed(), and get it to work on Java  7.

Made it into a Maven plugin and it works well :). Also verified other Java
7 language features (binary literals, underscores in numeric literals,
strings in switch, diamonds, exception multi-catch and re-throw) work on
Java  7 because they're just syntactic sugar.

It's very small and simple - 143 lines in 1 file. Is it worth adding as a
new commons project? Or do we not host (projects that contain) Maven
plugins?

Damjan

Re: Backporting try-with-resources to Java 7 (was: Re: [imaging] Closing stream)

[Damjan Jovanovic]

For the record, I would only use this for imaging = 2.0.

Weaver looked undocumented and undecipherable to me, but let me look at it
again slowly.

Damjan


On Sun, Nov 3, 2013 at 9:14 PM, Matt Benson gudnabr...@gmail.com wrote:

 I wasn't under the impression this was blocking imaging 1.0. In any case,
 framing Damjan's work as a Weaver module would still use the same work he's
 done with ASM and would really only utilize a standard mechanism for
 triggering the process. It would also avoid proliferation of multiple maven
 plugins with essentially the same mission: post-processing bytecode.

 Matt
 On Nov 3, 2013 10:08 AM, Gary Gregory garydgreg...@gmail.com wrote:

  On Sun, Nov 3, 2013 at 10:56 AM, Matt Benson gudnabr...@gmail.com
 wrote:
 
  Sounds like it would be trivial to frame what you've done here into the
  context of a Weaver module, for which there exist both a maven plugin
 and
  an Antlib, as well as a need for a near-term release. :-)
 
 
  and eating our own dog food :)
 
  We may pushing the limits of Dajman's patience for a 1.0 which is long
  overdue.
 
  I suppose D needs to weigh using ASM or [weaver] vs. adjusting the
 current
  code with Java 5.
 
  Gary
 
 
  Matt
  On Nov 3, 2013 2:30 AM, Damjan Jovanovic dam...@apache.org wrote:
 
   On Fri, Oct 25, 2013 at 1:52 PM, Matt Benson gudnabr...@gmail.com
  wrote:
  
On Oct 25, 2013 6:30 AM, Damjan Jovanovic damjan@gmail.com
   wrote:

 On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible
 joerg.schai...@scalaris.com wrote:
  Hi Damjan,
 
  Damjan Jovanovic wrote:
 
  [snip]
 
  Thanks for explanation.
 
  We would be able to adapt that for Java  1.7 by swallowing the
   close
  exception instead of calling addSuppressed() on the primary
   exception,
  but the show stopper is catching and rethrowing the primary
   exception
  (Throwable), which javac  1.7 refuses to compile because it
  doesn't
  do Rethrowing Exceptions with More Inclusive Type Checking
  (
   
   
  
 
 http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html
).
 
  But this would work and always sets succeeded correctly without
  catch/re-throw:
 
  final InputStream is = factoryMethodThatCanThrow();
  boolean succeeded = false;
  try {
  try {
  is.methodThatCanThrow();
  } finally {
  }
  succeeded = true;
  } finally {
  closeSafely(!succeeded, is);
  }
 
  I guess the nested try was unintentionally ;-)
 
  Cheers,
  Jörg

 Well that actually won't work, because the succeeded = true;
 will
  be
 skipped if there is a return; in the inner try.

 Other than a custom Java compiler, I guess there's no clean way of
 doing this in Java  1.7. There's really only option 2 - with
 being
 careful to always set succeeded correctly on all paths out of the
  try
 block. Almost like releasing memory in C.

   
I haven't deeply followed this conversation, but would this be a
   candidate
for a [weaver] module?
   
Matt
   
   
  
   [weaver] I am less sure about, but by playing with Objectweb's ASM I
 did
   manage to compile code with try-with-resources on Java 7, change the
  class
   file version, do some bytecode manipulation to delete calls to
   Throwable.addSuppressed(), and get it to work on Java  7.
  
   Made it into a Maven plugin and it works well :). Also verified other
  Java
   7 language features (binary literals, underscores in numeric literals,
   strings in switch, diamonds, exception multi-catch and re-throw) work
 on
   Java  7 because they're just syntactic sugar.
  
   It's very small and simple - 143 lines in 1 file. Is it worth adding
 as
  a
   new commons project? Or do we not host (projects that contain) Maven
   plugins?
  
   Damjan
  
 
 
 
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory
 

[VOTE] Release Imaging 1.0 from RC5

[Damjan Jovanovic]

Please vote on releasing commons-imaging 1.0 from RC5.

RC4 and its problems and their fixes were in this thread:
http://mail-archives.apache.org/mod_mbox/commons-dev/201209.mbox/%3CCAJm2B-nbnbJwNUKkAtapZuzT5jfFODsk1aXcdsUUeoC%2BxXrDKg%40mail.gmail.com%3E
There were also many recent discussions on the development list.

Imaging 1.0 RC5 is available here:
https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3391)

Maven artifacts:
https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-
imaging/

Change log(s):
https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
http://people.apache.org/~damjan/imaging-1.0-RC5/changes-report.html
http://people.apache.org/~damjan/imaging-1.0-RC5/jira-report.html

Tag:
https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC5https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC4(SVN
revision 1537825)

Site:
http://people.apache.org/~damjan/imaging-1.0-RC5/http://people.apache.org/%7Edamjan/imaging-1.0rc4/

I have tested it with OpenJDK 6 on FreeBSD 9.1.

Please review and vote. This vote will close no sooner than 72 hours from
now, on Monday 4 November 2013 at 12:00 GMT.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you!

Damjan Jovanovic

Re: [imaging] Closing stream

[Damjan Jovanovic]

For the sake of similarity of 1.0 with 0.x versions, I've stayed with Java
1.5 and in commit 1537238 I've gone with the set flag on every successful
return path + closeQuietly() idea.

It was a mission and broke things (DeflaterOutputStream apparently doesn't
honor flush()). I am moving Imaging to Java 7 as soon as 1.0 is released.

Damjan


On Sun, Oct 27, 2013 at 8:32 PM, Gary Gregory garydgreg...@gmail.comwrote:

 On Sun, Oct 27, 2013 at 1:51 AM, Damjan Jovanovic damjan@gmail.com
 wrote:

   an
 
  On Fri, Oct 25, 2013 at 5:24 PM, Jörg Schaible joerg.schai...@gmx.de
  wrote:
   Hi Damjan,
  
   Damjan Jovanovic wrote:
  
   On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible
   joerg.schai...@scalaris.com wrote:
   Hi Damjan,
  
   Damjan Jovanovic wrote:
  
   [snip]
  
   Thanks for explanation.
  
   We would be able to adapt that for Java  1.7 by swallowing the
 close
   exception instead of calling addSuppressed() on the primary
 exception,
   but the show stopper is catching and rethrowing the primary
 exception
   (Throwable), which javac  1.7 refuses to compile because it doesn't
   do Rethrowing Exceptions with More Inclusive Type Checking
   (
 
 http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html
  ).
  
   But this would work and always sets succeeded correctly without
   catch/re-throw:
  
   final InputStream is = factoryMethodThatCanThrow();
   boolean succeeded = false;
   try {
   try {
   is.methodThatCanThrow();
   } finally {
   }
   succeeded = true;
   } finally {
   closeSafely(!succeeded, is);
   }
  
   I guess the nested try was unintentionally ;-)
  
   Cheers,
   Jörg
  
   Well that actually won't work, because the succeeded = true; will be
   skipped if there is a return; in the inner try.
  
   Well, but this has to be done in our code, so we can either change it
 or
  set
   succedded = true before the return as well.
  
   To mimic Java 7, we could also implement:
  
   = % ===
Throwable t = null;
try {
} (catch IOException e) { t = e; throw e; }
// ... another line for each checked exception
} (catch RuntimeException e) { t = e; throw e; }
} (catch Error e) { t = e; throw e; }
} finally {
  closeSafely(t != null, is);
}
   = % ===
  
   but as commented, we have to add a catch for every checked exception,
   anotehr one for RuntimeException and one for Error. The approach with
 the
   succeeded flag seems easier ...
  
   Other than a custom Java compiler, I guess there's no clean way of
   doing this in Java  1.7. There's really only option 2 - with being
   careful to always set succeeded correctly on all paths out of the try
   block. Almost like releasing memory in C.
  
   Yep.
  
   Cheers,
   Jörg
  
 
  One thing that amuses me to no end, is that while it's at least a
  solved problem in Java 7, exceptions thrown from C#'s Dispose() method
  in a using() block always swallow the original exception, just like an
  uncaught close() exception in Java's finally :)
  (
 
 http://blogs.infosupport.com/the-c-using-statement-and-suppressed-exceptions-compared-to-java-7-try-with/
  ).
 
  Anyway I now think the way forward is Java 7. Java 5 was EOL since 3
  November 2009, and Java 6 was EOL since February 2013 (with a last
  update on 6 March 2013). There are ways of getting Java 7 features
  like try-with-resources on Android
  (https://github.com/yareally/Java7-on-Android) and besides Imaging's
  use of java.awt.* packages is a bigger barrier there. Applications and
  JVMs will eventually support Java 7 anyway, and even if they don't, a
  special compiler could produce binaries for earlier versions of Java.
 
  Can I just go change the POM to Java 7 or do we need a vote?
 

 I do not think you need a vote. Since the 0.x version is used in the wild,
 you might want to poll the user base as to their JRE requirements.

 For me, moving to Java 6 is fine. Java 7 is a little more adventurous, a
 good thing in general since no [commons] component has made Java 7 a
 minimum yet. Might as well test the waters.

 Gary



 
  Damjan
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 


 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: [imaging] Closing stream

[Damjan Jovanovic]

 an

On Fri, Oct 25, 2013 at 5:24 PM, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi Damjan,

 Damjan Jovanovic wrote:

 On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible
 joerg.schai...@scalaris.com wrote:
 Hi Damjan,

 Damjan Jovanovic wrote:

 [snip]

 Thanks for explanation.

 We would be able to adapt that for Java  1.7 by swallowing the close
 exception instead of calling addSuppressed() on the primary exception,
 but the show stopper is catching and rethrowing the primary exception
 (Throwable), which javac  1.7 refuses to compile because it doesn't
 do Rethrowing Exceptions with More Inclusive Type Checking
 (http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html).

 But this would work and always sets succeeded correctly without
 catch/re-throw:

 final InputStream is = factoryMethodThatCanThrow();
 boolean succeeded = false;
 try {
 try {
 is.methodThatCanThrow();
 } finally {
 }
 succeeded = true;
 } finally {
 closeSafely(!succeeded, is);
 }

 I guess the nested try was unintentionally ;-)

 Cheers,
 Jörg

 Well that actually won't work, because the succeeded = true; will be
 skipped if there is a return; in the inner try.

 Well, but this has to be done in our code, so we can either change it or set
 succedded = true before the return as well.

 To mimic Java 7, we could also implement:

 = % ===
  Throwable t = null;
  try {
  } (catch IOException e) { t = e; throw e; }
  // ... another line for each checked exception
  } (catch RuntimeException e) { t = e; throw e; }
  } (catch Error e) { t = e; throw e; }
  } finally {
closeSafely(t != null, is);
  }
 = % ===

 but as commented, we have to add a catch for every checked exception,
 anotehr one for RuntimeException and one for Error. The approach with the
 succeeded flag seems easier ...

 Other than a custom Java compiler, I guess there's no clean way of
 doing this in Java  1.7. There's really only option 2 - with being
 careful to always set succeeded correctly on all paths out of the try
 block. Almost like releasing memory in C.

 Yep.

 Cheers,
 Jörg


One thing that amuses me to no end, is that while it's at least a
solved problem in Java 7, exceptions thrown from C#'s Dispose() method
in a using() block always swallow the original exception, just like an
uncaught close() exception in Java's finally :)
(http://blogs.infosupport.com/the-c-using-statement-and-suppressed-exceptions-compared-to-java-7-try-with/).

Anyway I now think the way forward is Java 7. Java 5 was EOL since 3
November 2009, and Java 6 was EOL since February 2013 (with a last
update on 6 March 2013). There are ways of getting Java 7 features
like try-with-resources on Android
(https://github.com/yareally/Java7-on-Android) and besides Imaging's
use of java.awt.* packages is a bigger barrier there. Applications and
JVMs will eventually support Java 7 anyway, and even if they don't, a
special compiler could produce binaries for earlier versions of Java.

Can I just go change the POM to Java 7 or do we need a vote?

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] Closing stream

[Damjan Jovanovic]

On Fri, Oct 25, 2013 at 9:01 AM, Jörg Schaible
joerg.schai...@scalaris.com wrote:
 Hi Damjan,

 Damjan Jovanovic wrote:

 On Thu, Oct 24, 2013 at 11:29 PM, Gary Gregory garydgreg...@gmail.com
 wrote:
 On Thu, Oct 24, 2013 at 4:31 PM, Jörg Schaible
 joerg.schai...@gmx.dewrote:

 Hi Damjan,

 Damjan Jovanovic wrote:

  As one of the perpetrators of the problem, I have now fixed it. The
  reasons I swallowed exceptions were simple:

 [snip]

  * when an exception is thrown and close() then throws another
  exception, the close() exception is propagated and the original
  exception - which could reveal the cause of the problem - swallowed

 [snip]

 And this *is* a real problem. And it is exactly why the IOException of
 close() are normally ignored. While I don't like
 IOUtils.closeQietly(closeable), I use normally a method
 IO.closeLogged(closeable) resp. IO.closeLogged(closeable, logger).

 If e.g. an image is corrupted and later on an additional exception
 occurs closing any resource, you will simply *never* learn about the
 corrupted image that caused the problem in first case. The original
 exception must never be swallowed!


 Nest'em!

 G

 What's the way forward though?

 1. Catching both exceptions and nesting with setCause():

 InputStream is = null;
 Exception ex = null;
 try {
 is = factoryMethodThatCanThrow();
 is.methodThatCanThrow();
 } catch (Exception exx) {
 ex = exx;
 } finally {
 if (is != null) {
 try {
 is.close();
 } catch (IOException closeEx) {
 if (ex != null) {
 closeEx.setCause(ex);
 }
 throw closeEx;
 }
 }
 }

 which only gets worse, as each type of exception has to be separately
 caught and rethrown...


 Right, you could have got even an OOME reading an image ... :-/

And setCause() isn't really appropriate since the exception thrown by
close() can be causally unrelated to the original exception.

 2. Swallowing close() exceptions when a succeeded flag at the end of
 the try wasn't set:

 InputStream is = null;
 boolean succeeded = false;
 try {
 is = factoryMethodThatCanThrow();
 is.methodThatCanThrow();
 succeeded = true;
 } finally {
 if (is != null) {
 try {
 is.close();
 } catch (IOException closeEx) {
 if (succeeded) {
 throw closeEx;
 }
 }
 }
 }

 which now also requires making sure you don't return; before the end
 of the try...


 IMHO this is the best approach so far. Maybe we can introduce a utility
 method somewhere to avoid the boilerplate copies:

 === % ==
  public static void closeSafely(boolean mayThrow, Closeable... closeables)
 throws IOException {
IOException ioex = null;
for(Closeable closeable : closeables) {
  if (closeable != null) {
try {
  closeable.close();
} catch (IOException ex) {
  ioex = ex; // keep first or last ?!?
}
  }
}
if (mayThrow  ioex != null) {
   throw ioex;
}
  }
 === % ==

I like that method, but I'd rather we always set succeeded correctly. Read on.

 3. Java 7 + try-with-resources, which will cripple portability to
 Android...

 I would first write a unit test to see what Java 7 actually does with
 multiple open resources in the different error cases.

 Cheers,
 Jörg

Java 7 compiles:

try (InputStream is = factoryMethodThatCanThrow()) {
is.methodThatCanThrow();
}

into:

final InputStream is = factoryMethodThatCanThrow();
Throwable primaryException = null;
try {
is.methodThatCanThrow();
} catch (Throwable t) {
primaryException = t;
throw t;
} finally {
if (is != null) {
if (primaryException != null) {
try {
is.close();
} catch (Throwable t) {
primaryException.addSuppressed(t);
}
} else {
is.close();
}
}
}

When try-with-resources has a catch and/or finally, it compiles into 2
nested try blocks, this being the inner, and the one with
catch/finally being the outer. When multiple resources are being
managed by a try-with-resources block, each resource compiles into its
own try-finally block as above, nested in the previous resource's try
body. The innermost try body contains the body of the original
try-with-resources block. For examples see
http://stackoverflow.com/questions/7860137/what-is-the-java-7-try-with-resources-bytecode-equivalent-using-try-catch-finall

We would be able to adapt that for Java  1.7 by swallowing the close
exception instead of calling addSuppressed() on the primary exception,
but the show stopper is catching and rethrowing the primary exception
(Throwable), which javac  1.7 refuses to compile because it doesn't
do Rethrowing Exceptions with More Inclusive Type Checking
(http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html

Re: [imaging] Closing stream

[Damjan Jovanovic]

On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible
joerg.schai...@scalaris.com wrote:
 Hi Damjan,

 Damjan Jovanovic wrote:

 [snip]

 Thanks for explanation.

 We would be able to adapt that for Java  1.7 by swallowing the close
 exception instead of calling addSuppressed() on the primary exception,
 but the show stopper is catching and rethrowing the primary exception
 (Throwable), which javac  1.7 refuses to compile because it doesn't
 do Rethrowing Exceptions with More Inclusive Type Checking
 (http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html).

 But this would work and always sets succeeded correctly without
 catch/re-throw:

 final InputStream is = factoryMethodThatCanThrow();
 boolean succeeded = false;
 try {
 try {
 is.methodThatCanThrow();
 } finally {
 }
 succeeded = true;
 } finally {
 closeSafely(!succeeded, is);
 }

 I guess the nested try was unintentionally ;-)

 Cheers,
 Jörg

Well that actually won't work, because the succeeded = true; will be
skipped if there is a return; in the inner try.

Other than a custom Java compiler, I guess there's no clean way of
doing this in Java  1.7. There's really only option 2 - with being
careful to always set succeeded correctly on all paths out of the try
block. Almost like releasing memory in C.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] Closing stream

[Damjan Jovanovic]

As one of the perpetrators of the problem, I have now fixed it. The
reasons I swallowed exceptions were simple:
* when multiple resources need to be closed, earlier exceptions in
finally cause later close() methods to get skipped and those resources
to leak
* when an exception is thrown and close() then throws another
exception, the close() exception is propagated and the original
exception - which could reveal the cause of the problem - swallowed

Anyway we now propagate close() exceptions instead of logging and/or
catching, which has shrunk the jar by about 0.5%. The non-leaking with
multiple resources has been preserved but is much uglier:
} finally {
IOException closeException = null;
if (srcChannel != null) {
try {
srcChannel.close();
} catch (final IOException ioException) {
closeException = ioException;
}
}
if (dstChannel != null) {
try {
dstChannel.close();
} catch (final IOException ioException) {
closeException = ioException;
}
}
if (closeException != null) {
throw closeException;
}
}
and original exception propagation benefit will now be lost, but only
Java 7's try-with-resources takes care of all those problems cleanly
anyway (eg. building up a list of all suppressed exceptions inside the
original exception), so you can't have it all.

Damjan

On Thu, Oct 24, 2013 at 3:49 AM, Gary Gregory garydgreg...@gmail.com wrote:
 On Wed, Oct 23, 2013 at 9:38 PM, sebb seb...@gmail.com wrote:

 On 24 October 2013 01:16, Gary Gregory garydgreg...@gmail.com wrote:
  Hi All:
 
  I see a log of this pattern:
 
  try {
  if (outputStream != null) {
  outputStream.close();
  }
  } catch (final Exception e) {
  Debug.debug(e);
  }
 
  for example in org.apache.commons.imaging.Imaging:
 
  public static void writeImage(final BufferedImage src, final File
 file,
  final ImageFormat format, final MapString,Object params)
  throws ImageWriteException,
  IOException {
  OutputStream os = null;
 
  try {
  os = new FileOutputStream(file);
  os = new BufferedOutputStream(os);
 
  writeImage(src, os, format, params);
  } finally {
  try {
  if (os != null) {
  os.close();
  }
  } catch (final Exception e) {
  Debug.debug(e);
  }
  }
  }
 
  Which seems wrong to me. If I get an IOE while writing, we throw, but if
 we
  get one when flushing and closing the file (which may also write), we
  swallow it. Why? It seems the IOE from close should percolate up and not
 be
  swallowed.

 I agree that's bad practice - not only because of swallowing the Exception.
 The catch block should catch IOException not Exception.


 I do not think we should even catch the IOE, it should percolate up, just
 like the writeImage call. Why not simply:

 {
 final OutputStream os = new BufferedOutputStream(new
 FileOutputStream(file));
 try {
 writeImage(src, os, format, params);
 } finally {
 os.close();
 }
 }

 Or if your are really paranoid:

 {
 OutputStream os = new FileOutputStream(file);
 try {
 os = new BufferedOutputStream(os);
 writeImage(src, os, format, params);
 } finally {
 os.close();
 }
  }

 I'm looking for a pattern we can apply throughout [imaging] before 1.0.

 Gary


  All of this is moot in Java 7 with try-with-resources blocks but we are
 not
  ready for Java 7 here I imagine.
 
  Gary
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: 

Re: [imaging] Closing stream

[Damjan Jovanovic]

On Thu, Oct 24, 2013 at 11:29 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, Oct 24, 2013 at 4:31 PM, Jörg Schaible joerg.schai...@gmx.dewrote:

 Hi Damjan,

 Damjan Jovanovic wrote:

  As one of the perpetrators of the problem, I have now fixed it. The
  reasons I swallowed exceptions were simple:

 [snip]

  * when an exception is thrown and close() then throws another
  exception, the close() exception is propagated and the original
  exception - which could reveal the cause of the problem - swallowed

 [snip]

 And this *is* a real problem. And it is exactly why the IOException of
 close() are normally ignored. While I don't like
 IOUtils.closeQietly(closeable), I use normally a method
 IO.closeLogged(closeable) resp. IO.closeLogged(closeable, logger).

 If e.g. an image is corrupted and later on an additional exception occurs
 closing any resource, you will simply *never* learn about the corrupted
 image that caused the problem in first case. The original exception must
 never be swallowed!


 Nest'em!

 G

What's the way forward though?

1. Catching both exceptions and nesting with setCause():

InputStream is = null;
Exception ex = null;
try {
is = factoryMethodThatCanThrow();
is.methodThatCanThrow();
} catch (Exception exx) {
ex = exx;
} finally {
if (is != null) {
try {
is.close();
} catch (IOException closeEx) {
if (ex != null) {
closeEx.setCause(ex);
}
throw closeEx;
}
}
}

which only gets worse, as each type of exception has to be separately
caught and rethrown...

2. Swallowing close() exceptions when a succeeded flag at the end of
the try wasn't set:

InputStream is = null;
boolean succeeded = false;
try {
is = factoryMethodThatCanThrow();
is.methodThatCanThrow();
succeeded = true;
} finally {
if (is != null) {
try {
is.close();
} catch (IOException closeEx) {
if (succeeded) {
throw closeEx;
}
}
}
}

which now also requires making sure you don't return; before the end
of the try...

3. Java 7 + try-with-resources, which will cripple portability to Android...

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] Closing stream

[Damjan Jovanovic]

On Thu, Oct 24, 2013 at 4:34 AM, Bernd Eckenfels e...@zusammenkunft.net wrote:
 Am 24.10.2013, 02:16 Uhr, schrieb Gary Gregory garydgreg...@gmail.com:

 try {
 if (outputStream != null) {
 outputStream.close();
 }
 } catch (final Exception e) {
 Debug.debug(e);
 }


 this calls for a helper or a private method as soon as the code happens more
 than one time in a class IMHO.


 All of this is moot in Java 7 with try-with-resources blocks but we are
 not
 ready for Java 7 here I imagine.


 No, t-w-r is similiar broken to manually closing output streams in catch.
 both syntax constructs need a close (flush is optional) inside the try. Some
 filesystems and abstractions layers do nearly all work or error reporting in
 the close only (nfs, quota, webdav, ...)


Wait, what are you saying is wrong with Java 7's try-with-resources?


 Gruss
 Bernd
 --
 http://www.zusammenkunft.net


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Imaging 1.0 from RC4

[Damjan Jovanovic]

On Tue, Sep 25, 2012 at 3:22 PM, Gary Gregory garydgreg...@gmail.com wrote:
 Hi All,

 I happy to see another RC come along! :) This is large code base so I
 appreciate that the reports generate a lot of potential work.

I planned to send this email out just over a year ago, shortly after
yours, but since we might actually get to release this time let me
send it out now for reference.

 -1: Unapproved license:

 src/main/java/org/apache/commons/imaging/formats/jpeg/segments/App14Segment.java

Fixed.

 Fix obvious FindBugs (to me only?):

 - Possible NPE with
 NP_IMMEDIATE_DEREFERENCE_OF_READLINEhttp://findbugs.sourceforge.net/bugDescriptions.html#NP_IMMEDIATE_DEREFERENCE_OF_READLINE@
 https://people.apache.org/~damjan/imaging-1.0rc4/xref/org/apache/commons/imaging/formats/rgbe/RgbeInfo.html#103

Findbugs false positive: it believes every method named readLine()
behaves like BufferedReader's. I've renamed it to readNextLine().

 - Is this useless or an incomplete impl?: Useless control flow in
 org.apache.commons.imaging.palette.PaletteFactory.makePaletteFancy(BufferedImage)
 STYLE 
 UCF_USELESS_CONTROL_FLOWhttp://findbugs.sourceforge.net/bugDescriptions.html#UCF_USELESS_CONTROL_FLOW
 54https://people.apache.org/%7Edamjan/imaging-1.0rc4/xref/org/apache/commons/imaging/palette/PaletteFactory.html#54

Incomplete impl, fixed now.

 -
 If we want non-standard class name (starts with a lower case, then Javadoc
 would be nice to understand why this is justified:
   public static class tEXt extends PngText
   public static class zTXt extends PngText
   public static class iTXt extends PngText

Because that's the case used for PNG field markers. Converted to
standard names anyway.

 - What about the
 RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUEhttp://findbugs.sourceforge.net/bugDescriptions.html#RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE?

The only reason that value is not null, is because the method
providing it hasn't been overridden - and that method is neither
private nor final so it can be overridden. Fixed anyway.

 - What about the
 FE_FLOATING_POINT_EQUALITYhttp://findbugs.sourceforge.net/bugDescriptions.html#FE_FLOATING_POINT_EQUALITY?

Probably a false positive (comparison of variables to the maximum
amongst themselves) but I worked around it.

 - IIRC, the 
 EI_EXPOSE_REPhttp://findbugs.sourceforge.net/bugDescriptions.html#EI_EXPOSE_REPissues
 are just a normal by-product of the design? Please confirm.

Yes they are.

 - PMD
   - do the easy clean ups of Unnecessary final modifier in final class.

Done.

   - Avoid empty catch blocks: Add a comment as to why the block is empty,
 for example This exception cannot be thrown because This is important
 for anyone who tries to grok the code.

The name I give to the exception variable (ignore, cannotHappen)
should make it obvious.

   - Avoid unused method/fields/etc: Is this unimplemented code or cruft?
 If cruft, it should be removed before we give ourselves unneeded BC
 headaches.

 - CDP: lots of those but I do not know the code base enough to tell how
 easy it would be to refactor duplications and if refactoring is justified.

 - Code coverage: overall, is not great.

 These packages have 0%.code coverage.
   - org.apache.commons.imaging.formats.transparencyfilters
   - org.apache.commons.imaging.formats.psd.dataparsers
   - org.apache.commons.imaging.formats.psd.datareaders
   - org.apache.commons.imaging.icc

 Oddly org.apache.commons.imaging.util has only 17% which I would think
 would be higher since it is a util package.

Even to get that low test coverage, it already takes 40+ minutes to
run mvn site due to Corbertura. I've added some tests so it's  0
now. The real util package is org.apache.commons.imaging.common.

 - Process

 This might be a case of RM process but when I RM I set the release date in
 changes.xml to the date I cut the RC. If the RC passes, then you are done,
 otherwise you edit it again for the next RC.

Ok thank you.

 - Javadoc

 Only 3 out of ~40 packages have comments, which makes it harder to find
 your way around.

Added a few more package comments, but the API is largely designed to
be used from the org.apache.commons.imaging.Imaging class alone.

 - Checkstyle is not strict enough
   - IMO should always complain about missing { } in blocks.

I thought there was no official coding style for commons? But I've
added it anyway.

 There also a lot of generics warnings (in Eclipse, any IDE will tell you
 these days.)

Upgrades from Java 1.4 are never fun. These were largely fixed in
code, but tests might have a few.

 Sorry to make it a long laundry list, but there is only one 1.0 ;)

You should see what was already fixed :).

 There is probably more of course, but I have to go now...

 Gary

Thank you very much
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CHALLENGE] Move All of Commons to the Dormant

[Damjan Jovanovic]

I agree. The only reason [imaging] has been dormant for so long is
that I am busy making large changes that have taken many months to
write, so it's not really that dormant after all.

I understand the desire to do something about the current state of
Commons, but please don't make things harder for those of us that are
doing something productive.

With the 3 year rule, I would be forced to do a 0.98 release which
breaks the API, and another release after that which breaks the API
again in an even worse way. IIRC, I've already tried to do a release 4
times - unsuccessfully.

Damjan

On Tue, Oct 15, 2013 at 3:59 PM, Paul Benedict pbened...@apache.org wrote:
 I don't like the idea of putting inactive components in the attic -- unless
 there is some unreasonable length of time that goes by without any
 development (3 years?). People who want to get things out of the attic are
 usually a sole passionate fellow. Can a sole fellow unilaterally get a
 component out of the attic? I wouldn't think so ... but if I am wrong, I
 would drop my objection.


 On Tue, Oct 15, 2013 at 7:59 AM, Emmanuel Bourg ebo...@apache.org wrote:

 Le 15/10/2013 14:35, Gary Gregory a écrit :

  the web site can say last released on -mm-dd, no new
  releases planned.

 I like this idea, but unless you automate the site update it adds an
 extra manual step to the release process.

 Emmanuel Bourg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 Cheers,
 Paul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Move Apache Commons to Git for SCM...

[Damjan Jovanovic]

-1 (binding), it's a big change, so let's try Mark's idea of one
component first.



On Thu, Oct 10, 2013 at 5:06 PM, Mark Thomas ma...@apache.org wrote:
 On 10/10/2013 15:50, James Carman wrote:
 All,

 We have had some great discussions about moving our SCM to Git.  I
 think it's time to put it to a vote.  So, here we go:

 +1 - yes, move to Git
 -1 - no, do not move to Git

 The vote will be left open for 72 hours.  Go!

 -1. I'm not convinced that the implications have been fully thought
 through (the web site has to remain on svn for example) nor that this
 migration will solve the problems it aims to solve.

 I'd be much happier with doing a trial with one component first before
 starting a wholesale migration.

 Mark


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Do we want 7z Archive*Stream-like classes

[Damjan Jovanovic]

On Tue, Oct 1, 2013 at 6:09 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2013-09-30, Benedikt Ritter wrote:

 2013/9/30 Stefan Bodewig bode...@apache.org

 I'm in no way as familiar with the format as Damian is but IMHO it is
 feasible - but likely pretty memory hungry.  Even more so for the
 writing side.  Similar to zip some information is stored in a central
 place but in this case at the front of the archive.

 just out of curiosity: is this memory problem related to Java or to 7z in
 general?

 What Bernd said.

 Reading may be simpler, here you can store the meta-information from the
 start of the file in memory and then read entries as you go, ZipFile
 inside the zip package does something like this.

From what I remember:

The meta-information can be anywhere in the file, as can the
compressed files themselves. The 7zip tool seems to write the
meta-information at the end of the 7z file when multi-file archives
are created. Compressed file codecs, positions, lengths, and solid
compression details are only stored in the meta-information, so it's
not possible to write a streaming reader without O(n) memory in the
worst case.

 When you consider writing you'll have to write metadata about all
 entries before you even start to write the first bytes of the first
 entry.  Either you build up everything in memory or you use a temporary
 output.  This is not without precedent in Compress, pack200 allows users
 to chose between two strategies that provide exactly those two options.

Writing also requires seeking or O(n) memory, as the initial header at
the beginning of the file contains the offset to the next header, and
we only know the size/contents/location of the next header once all
the files have been written.

Since we now have multiple archivers that require seeking, I suggest
we add a SeekableStream class or something along those lines. The
Commons Imaging project also has the same problem to solve for images,
and it uses ByteSources, which can be arrays, files, or an InputStream
wrapper that caches what has been read (so seeking is efficient, while
it only reads as much from the InputStream as is necessary).

 Stefan


Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] release 1.0 state?

[Damjan Jovanovic]

There's a few last patches I want to add while we can still break the API,
but I am away this week, and only fully available for anything the week
after next.

Damjan


On Fri, Aug 23, 2013 at 8:02 AM, Andreas Lehmkuehler andr...@lehmi.dewrote:

 Hi,

 Am 22.08.2013 22:01, schrieb Gary Gregory:

  Hi all (Damjan),

 What state is the code in WRT a 1.0 release?

 I'm also interested to get the release done.

 I had a quick look at JIRA and couldn't find any big blockers. Are there
 any
 issues with the build? Any other unsolved TODOs?

 I'm with the Apache PDFBox project and acted as release manage for most of
 our
 releases, so maybe I can help to get this further.

  Gary


 BR
 Andreas Lehmkühler


 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Detecting LZMA standalone files

[Damjan Jovanovic]

On Mon, Jun 10, 2013 at 6:25 AM, Stefan Bodewig bode...@apache.org wrote:
 Hi,

 when I added support for decompressing .lzma files I left out matches()
 and you can only get an LZMACompressorInputStream from
 CompressorStreamFactory if you use the version that explicitly specifies
 the format.

 The reason is that the old .lzma format doesn't have any sort of
 signature at all.  I've been told that if you'd try to unlzma a plain
 text file the most likely outcome is an OutOfMemoryError.

 The native XZUtil which is used for xz as well as lzma contains some
 heuristic that allows the xz command to guess the input format.  It
 first checks whether the input is xz and if not whether the settings
 that would make up the start of an LZMA stream don't look to strange.

 We could do something similar by placing the LZMA check at the end in
 the CompressorStreamFactory's autodetect method and perform the same
 plausibility checks on the input.  This would still run the risk of
 false positives and - maybe less likely - false negatives.  Do we want
 to do something like this?

 Stefan

The problem is not unique to LZMA, and since LZMA can contain almost
any bytes at the beginning, it could also be misdetected as another
compression format.

If we can't autodetect all compression formats from the file contents,
then shouldn't we only try to autodetect them from the file extension
or MIME type? Or not do autodetection at all?

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [COMPRESS] SevenZFile - fix debug so boxing is eliminated?

[Damjan Jovanovic]

On Tue, May 14, 2013 at 2:36 AM, sebb seb...@gmail.com wrote:
 The private debug method requires an array of Objects to be passed to
 System.out.format.

 Any primitive parameters will be autoboxed.

 However, the boxing will be performed regardless of whether DEBUG is
 true or not.
 This is a bit wasteful as DEBUG is false by default.

 It may be better to inline the debug method calls.


Autoboxing into Object varargs which are never used is still cheaper
than conversions and concatenations into a single String that's never
used, which is why slf4j and log4j2 provide it. But either way, a good
compiler should be able to inline debug(), then eliminate the dead
logging code because private static final boolean DEBUG is hardcoded
to false, then optimize all the variables and expressions out of
existence (since they never get read). Even if Hotspot doesn't
optimize that well (and I think it does since assert() supposedly
costs 0 when -ea is absent), the performance-critical path of
decompressing file contents doesn't log.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1482203 - /commons/proper/compress/trunk/pom.xml

[Damjan Jovanovic]

On Tue, May 14, 2013 at 1:00 PM, sebb seb...@gmail.com wrote:
 On 14 May 2013 06:01,  dam...@apache.org wrote:
 Author: damjan
 Date: Tue May 14 05:01:35 2013
 New Revision: 1482203

 URL: http://svn.apache.org/r1482203
 Log:
 Verify conformance to the Java 1.5 API using the animal-sniffer plugin.

 -1

 Does not appear to work properly on Maven 2.2.1. or Maven 3.0.4.
 Although it generates an error when there is an invalid reference, the
 error is in the plugin, and does not identify the source.
 For example:

 [INFO] Checking unresolved references to 
 org.codehaus.mojo.signature:java15:1.0
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 1:49.531s
 [INFO] Finished at: Tue May 14 11:48:50 BST 2013
 [INFO] Final Memory: 13M/47M
 [INFO] 
 
 [ERROR] Failed to execute goal
 org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check
 (check-java-api) on project commons-compress: Execution check-java-api
 of
  goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed:
 An API incompatibility was encountered while executing
 org.codehaus.mojo:animal-sniffer-ma
 ven-plugin:1.9:check: java.lang.NoSuchMethodError:
 java.nio.CharBuffer.subSequence(II)Ljava/nio/CharBuffer;
 [ERROR] -
 [ERROR] realm =pluginorg.codehaus.mojo:animal-sniffer-maven-plugin:1.9
 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
 [ERROR] urls[0] =
 file:/D:/repository/org/codehaus/mojo/animal-sniffer-maven-plugin/1.9/animal-sniffer-maven-plugin-1.9.jar
 [ERROR] urls[1] =
 file:/D:/repository/org/codehaus/mojo/animal-sniffer/1.9/animal-sniffer-1.9.jar
 [ERROR] urls[2] = file:/D:/repository/org/ow2/asm/asm-all/4.0/asm-all-4.0.jar
 [ERROR] urls[3] =
 file:/D:/repository/org/codehaus/mojo/java-boot-classpath-detector/1.9/java-boot-classpath-detector-1.9.jar
 [ERROR] urls[4] =
 file:/D:/repository/org/apache/maven/reporting/maven-reporting-api/2.0.1/maven-reporting-api-2.0.1.jar
 [ERROR] urls[5] =
 file:/D:/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-6/doxia-sink-api-1.0-alpha-6.jar
 [ERROR] urls[6] =
 file:/D:/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar
 [ERROR] urls[7] =
 file:/D:/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
 [ERROR] urls[8] =
 file:/D:/repository/org/apache/maven/shared/maven-common-artifact-filters/1.2/maven-common-artifact-filters-1.2.jar
 [ERROR] urls[9] =
 file:/D:/repository/org/apache/maven/shared/maven-plugin-testing-harness/1.1/maven-plugin-testing-harness-1.1.jar
 [ERROR] urls[10] =
 file:/D:/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar
 [ERROR] urls[11] =
 file:/D:/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
 [ERROR] Number of foreign imports: 1
 [ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
 [ERROR]

 The above error was caused by using new IOException(String, Throwable).

 Also, the check does not work for mvn compile, nor does it run if a
 test fails.

 And of course the check adds extra time to every build, even those run
 using Java 1.5.0

 What I do is I ensure that Eclipse is set up to use the appropriate JVM.
 This catches errors at edit time.


Ok I've removed animal-sniffer for now, but believe that the wrong
output bug and poor performance should rather be fixed in the plugin.

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Ok to commit 7zip support patch?

[Damjan Jovanovic]

On Tue, May 7, 2013 at 6:09 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2013-05-06, Damjan Jovanovic wrote:

 I've been hacking on a patch that adds support for reading 7zip archives.

 COMPRESS-54 is the most popular issue so you'd make quite a few people
 happy.

I doubt it - without LZMA support, only 7z archives created with
special options can be read.

Additionally 7z archives require seeking, so there's only SevenZFile,
no SevenZArchiveInputStream.

 You are talking about read-only suppport, right?

Yes - even that was painful enough for now :).

 AFAIR there've been either legal/license or technical hurdles to
 straddle when using external libraries.

Yes, so I started from scratch, worked only from the 7zFormat.txt
file, and when that wasn't enough, ported bits of the LZMA SDK's C/C++
7z code in the public domain to Java, and have given attribution as
per LEGAL-72.

 Can I go ahead and commit it, or would you like to review it first?

 I'd be fine with reviewing progress in svn and tracking progress on
 COMPRESS-54.

It's committed now :). I tried to use Jira issue key: COMPRESS-54 in
the commit message but nothing in Jira happened?

 Stefan

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[compress] Ok to commit 7zip support patch?

[Damjan Jovanovic]

Hi

I've been hacking on a patch that adds support for reading 7zip archives.
Can I go ahead and commit it, or would you like to review it first?

Regards
Damjan

[all] logging practices in Commons components?

[Damjan Jovanovic]

Hi

I see few Commons components do any logging, and net, io and csv don't
even have any dependencies. Is this a recommended practice?

Imaging prints to System.out (!!) instead of logging, and I am
wondering if I should add slf4j or log4j2 instead?

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Sanselan][Imaging] Snapshot release.

[Damjan Jovanovic]

Sorry about the release situation, the latest nightly build is here:
https://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-imaging/1.0-SNAPSHOT/



On Sat, Dec 15, 2012 at 12:33 PM, Jan-Paul Bultmann
janpaulbultm...@me.com wrote:
 Hey,
 Is there a chance for a SNAPSHOT release of commons-imaging to a maven repo?
 I'm building a Clojure library with it as a dependency, but pointing people 
 to the download page seems a bit cumbersome.
 Especially because of the current name mangling, which can cause a lot of 
 confusion :D,
 for example the Github page is out of sync with the project as it still 
 points to Sanselan.

 If there is no hope for such, would it be ok if I put a jar on the 
 clojars.org repo in a non-conflicting namespace with a link to the project 
 page?
 e.g. org.clojars.ticking/commons-imaging 1.0-SNAPSHOT

 Cheers,
 Jan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Binary file manipulation tool?

[Damjan Jovanovic]

Hi

You wouldn't believe it, but one of the most invaluable testing tools
for commons-imaging I've discovered has been an x86 assembler :-).

Why? Because images are binary files which often use internal offsets
to portions of the image. An assembler lets you easily calculate and
insert offsets at compile-time. See
https://svn.apache.org/repos/asf/commons/proper/imaging/trunk/src/test/data/images/bmp/4/rle8.asm
as an example.

However it makes me uncomfortable to have both images and the assembly
in my tests when the images can be generated from the assembly, or
require nasm to compile tests. Also nasm is all good for little-endian
files, but it will never support big-endian. Is there some other
binary file manipulation tool you guys know of that I can use instead,
preferably one written in Java and ideally with a Maven plugin?

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] bz2 archive format - can it be dropped?

[Damjan Jovanovic]

+1 to getting rid of it then (binding)

On Fri, Sep 28, 2012 at 10:44 PM, sebb seb...@gmail.com wrote:
 The assembly descriptors are currently set up to create bz2 archives
 in addition to the standard tar.gz and zip ones.

 Is the bz2 format really needed?
 It's larger than the tar.gz, at least for sanselan.
 And it's not as well supported on Windows.

 Note that the Commons Build Plugin does not currently support bz2, so
 the download page would need to be manually editted after generation.
 [In fact the existing download page does not link to the bz2 archives.]

 Or someone needs to enhance the Build plugin.

 Should not be too difficult to add support for a property to define
 the archive suffixes, but is there any point?
 Sanselan is the only commons component using bz2 currently.

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Imaging 1.0 from RC4

[Damjan Jovanovic]

Please vote on releasing commons-imaging 1.0 from RC4.

A number of things were changed from RC2: dead local store warnings in
Findbugs were fixed, missing ASL headers were added to Javadoc files,
developers and contributors were populated into pom.xml, a few
last-minute bugs were also fixed, and the build was deployed to Nexus
this time. But I am unsure whether the SCM is set correctly in pom.xml
- should it be tags/IMAGING_1_0_RC4 for a release? Also is
commons.rc.version correct?

Tag:
https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC4

Site:
http://people.apache.org/~damjan/imaging-1.0rc4/

Binaries:
https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/

Votes, please.  This vote will close in 72 hours, Friday 28 September 2012
at 04:33 GMT.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you!

Damjan Jovanovic

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: UTF8 filename issue with TarOutputStream

[Damjan Jovanovic]

The test on http://jira.codehaus.org/browse/MASSEMBLY-515
Succeeds with ?'s instead of non-ASCII characters on commons-compress-1.0
Succeeds with the correct characters on commons-compress-1.4.1

Why is there 2 projects? Why don't Maven and Ant use commons-compress?

Damjan

On Sun, Sep 2, 2012 at 1:45 PM, Gary Gregory ggreg...@rocketsoftware.comwrote:

 I wonder if [compress] has the same issue?

 Gary

 Begin forwarded message:

 From: falcon sheep falcon.sh...@gmail.commailto:falcon.sh...@gmail.com
 Date: September 2, 2012 5:26:07 EDT
 To: u...@ant.apache.orgmailto:u...@ant.apache.org
 Subject: UTF8 filename issue with TarOutputStream
 Reply-To: Ant Users List u...@ant.apache.orgmailto:u...@ant.apache.org

 Hi,

 I have raised a bug with TarOutputStream when a TAR file is being written,
 and:
 1. One or more filenames are so long that they require GNU mode
 2. The platform encoding is UTF-8
 3. Any character in a long filename results in a multibyte UTF-8 sequence

 an exception is thrown:
 Problem creating TAR: request to write 'xxx' bytes exceeds size in header
 of 'xxx' bytes

 the same has been discussed and solved in:
 http://jira.codehaus.org/browse/PLXCOMP-195

 with the patch applied as well

 bug id:
 https://issues.apache.org/bugzilla/show_bug.cgi?id=53811

 is there any chance of solving them in the next release.

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: My vote for release

[Damjan Jovanovic]

On Wed, Aug 1, 2012 at 7:00 PM, Gary Lucas gwlu...@sonalysts.com wrote:

 Damjan,

 I just saw that you were soliciting votes for release.   I think you've done 
 an outstanding job and I'm all for it.   I would vote twice if I could :-)

 I saw that some of the folks on the Apache page were complaining about some 
 of the code-checking issues. I've never looked at these myself, but I suppose 
 that many of them are not worth fixing.

 For example, somebody complained that a class shouldn't have a publically 
 scoped array.  Let's say a programmer tried to address that.  If he writes a 
 get method that is a simple pass-through returning a reference to the 
 internal array, has he really added any security (meaning protection against 
 accidental misuse)?  Of course not.  Suppose, instead, that he writes a 
 method that makes a copy of the array before returning it.  Now he's improved 
 security, but degraded the performance of the overall code... maybe 
 seriously. And in imaging processing, performance trumps security almost 
 every time.

 Anyway, if there are specific areas in the TIFF tree or elsewhere that you 
 would like me to review, please let me know and I'll be glad to take a look 
 at them.

 Gary

Thank you. I've fixed the worst problems, and I plan on trying to
release RC3 in a few days.

I doubt those public array scoping will stop the release, and I plan
on making big changes to the whole API for Imaging version 2.0 so
we'll see then.

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Imaging 1.0 based on RC2

[Damjan Jovanovic]

On Thu, Jul 26, 2012 at 2:00 PM, sebb seb...@gmail.com wrote:
 On 24 July 2012 02:18, Damjan Jovanovic dam...@apache.org wrote:
 It's been 3 years since Imaging 0.97 was released,
 and many bugs have been fixed and many features added,
 so I would like to release a long overdue Imaging 1.0.

 Imaging 1.0, RC2 is available for review here:
   http://people.apache.org/~damjan/imaging-1.0-RC2/

 Maven artifacts are here:
   http://people.apache.org/~damjan/imaging-1.0-RC2/maven

 Commons components must use Nexus for staging Maven artifacts (and can
 use it for non-Maven as well)


I use the release instructions on
http://commons.apache.org/releases/prepare.html
Are they wrong?
Why are they still the official instructions?

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Imaging 1.0 based on RC2

[Damjan Jovanovic]

On Tue, Jul 24, 2012 at 5:47 AM, Gary Gregory garydgreg...@gmail.com wrote:
 On Jul 23, 2012, at 21:19, Damjan Jovanovic dam...@apache.org wrote:

 It's been 3 years since Imaging 0.97 was released,
 and many bugs have been fixed and many features added,
 so I would like to release a long overdue Imaging 1.0.

 Imaging 1.0, RC2 is available for review here:
  http://people.apache.org/~damjan/imaging-1.0-RC2/

 Maven artifacts are here:
  http://people.apache.org/~damjan/imaging-1.0-RC2/maven

 Details of changes since 0.97 are in the release notes:
  http://people.apache.org/~damjan/imaging-1.0-RC2/RELEASE-NOTES.txt
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/changes-report.html

 I have tested this with JDK 1.6 using maven2.

 The tag is here:
  http://svn.apache.org/viewvc/commons/proper/imaging/tags/IMAGING_1_0_RC2/

 Site:
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/

 Clirr Report is irrelevant - there is no source/binary/semantic
 compatibility with 0.97.

 Since this is 1.0, I am more concerned with getting the API right than
 compatibility with a sandbox version. My question therefore is: are
 you happy with the API?

 I am traveling ATM and cannot dig into my IDE.

 I took a peek at the reports and there are a lot of issues reported by
 FindBugs, PMD and so on. What is the plan there?

The API is fine for now. It could use some improvements, but that's
something I'd rather leave for version 2.0.

I've already fixed all the FindBugs problems that are worth fixing,
the rest are non-issues. The issues PMD finds (final modifiers in
final classes, empty catch blocks, unused parameters) are things I
consider normal.

 Gary


 RAT Report:
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/rat-report.html

 Votes, please.  This vote will close in 72 hours, Friday 27 July 2012
 at 02:00 GMT.

 [ ] +1 Release these artifacts
 [ ] +0 OK, but...
 [ ] -0 OK, but really should fix...
 [ ] -1 I oppose this release because...

 Thank you!

 Damjan Jovanovic

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Release Imaging 1.0 based on RC2

[Damjan Jovanovic]

On Tue, Jul 24, 2012 at 5:44 PM, Matt Benson gudnabr...@gmail.com wrote:
 On Tue, Jul 24, 2012 at 1:31 AM, Damjan Jovanovic damjan@gmail.com 
 wrote:
 On Tue, Jul 24, 2012 at 5:47 AM, Gary Gregory garydgreg...@gmail.com wrote:
 On Jul 23, 2012, at 21:19, Damjan Jovanovic dam...@apache.org wrote:

 It's been 3 years since Imaging 0.97 was released,
 and many bugs have been fixed and many features added,
 so I would like to release a long overdue Imaging 1.0.

 Imaging 1.0, RC2 is available for review here:
  http://people.apache.org/~damjan/imaging-1.0-RC2/

 Maven artifacts are here:
  http://people.apache.org/~damjan/imaging-1.0-RC2/maven

 Details of changes since 0.97 are in the release notes:
  http://people.apache.org/~damjan/imaging-1.0-RC2/RELEASE-NOTES.txt
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/changes-report.html

 I have tested this with JDK 1.6 using maven2.

 The tag is here:
  http://svn.apache.org/viewvc/commons/proper/imaging/tags/IMAGING_1_0_RC2/

 Site:
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/

 Clirr Report is irrelevant - there is no source/binary/semantic
 compatibility with 0.97.

 Since this is 1.0, I am more concerned with getting the API right than
 compatibility with a sandbox version. My question therefore is: are
 you happy with the API?

 I am traveling ATM and cannot dig into my IDE.

 I took a peek at the reports and there are a lot of issues reported by
 FindBugs, PMD and so on. What is the plan there?

 The API is fine for now. It could use some improvements, but that's
 something I'd rather leave for version 2.0.

 In that case, what timeframe are you thinking of for [imaging] v2?


Not long, maybe by the end of the year.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Imaging 1.0 based on RC2

[Damjan Jovanovic]

It's been 3 years since Imaging 0.97 was released,
and many bugs have been fixed and many features added,
so I would like to release a long overdue Imaging 1.0.

Imaging 1.0, RC2 is available for review here:
  http://people.apache.org/~damjan/imaging-1.0-RC2/

Maven artifacts are here:
  http://people.apache.org/~damjan/imaging-1.0-RC2/maven

Details of changes since 0.97 are in the release notes:
  http://people.apache.org/~damjan/imaging-1.0-RC2/RELEASE-NOTES.txt
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/changes-report.html

I have tested this with JDK 1.6 using maven2.

The tag is here:
  http://svn.apache.org/viewvc/commons/proper/imaging/tags/IMAGING_1_0_RC2/

Site:
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/

Clirr Report is irrelevant - there is no source/binary/semantic
compatibility with 0.97.

RAT Report:
  http://people.apache.org/~damjan/imaging-1.0-RC2/site/rat-report.html

Votes, please.  This vote will close in 72 hours, Friday 27 July 2012
at 02:00 GMT.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you!

Damjan Jovanovic

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

There's also http://xmlgraphics.apache.org/commons/ which does TIFF
and PNG parsing among other things.

I'll have to investigate all of those after the 1.0 release.

Regards
Damjan

On Tue, Jul 10, 2012 at 10:55 AM, Ray Gauss II ray.ga...@alfresco.com wrote:
 In case you're not aware, much has been done around EXIF, IPTC, and XMP in 
 Apache Tika which uses the Drew Noakes library [1] for some of its work and 
 there's a parser which wraps ExifTool [2].

 Perhaps there's some opportunity to combine efforts?

 Regards,

 Ray

 [1] http://www.drewnoakes.com/code/exif/
 [2] https://github.com/Alfresco/tika-exiftool


 On Jul 8, 2012, at 8:59 PM, Farrukh Najmi wrote:


 There are two specs:

 1. IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
   IPTC Extension Specification Version 1.0
   Document Revision 2
   
 http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf
   (IPTC-PhotoMetadata-2008 spec)
 2. IPTC - NAA Information Interchange Model Version 4
   http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf (IIM spec)


 The IPTC-PhotoMetadata-2008 spec suprecedes the IIM spec from what I have 
 read. We should therefor be implementing the IPTC-PhotoMetadata-2008 (the 
 spec) and not the IIM spec.

 The TODO comment is about the properties that are in IIM spec but not in 
 IPTC-PhotoMetadata-2008. I have chosen to leave them there for now. All the 
 IptcTypes.name field values are aligned with the XMP property id values from 
 the spec. That was the main change in the patch. I think we should change 
 IptcTypes.name field to IptcTypes.propertyId field and perhaps later add a 
 name field that aligns with the Name field values from the spec. BTW, I 
 would be happy to have a skype (skype id: farrukh_najmi) call to discuss 
 this if you would like.


 On 07/08/2012 11:34 AM, Damjan Jovanovic wrote:
 You ask TODO: What to do about properties not seen in
 IPTC-PhotoMetadata-2008 (e.g. Record Version))

 Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
 Scroll down to IPTC ApplicationRecord Tags
 Those names seem to resemble what is in
 http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
 onwards.

 The names in your patch differ from that list.

 ?

 On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:
 Oops. Here is the correct file this time.


 On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:
 Hi Farrukh

 Your patch is just an empty file.

 Regards
 Damjan

 On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:
 Hi Damjan,

 Attached is the patch for implementing the proposed change outlined in
 bullets below.
 Please review and then commit if satisfied or discuss further. Thanks.


 On 07/06/2012 02:29 PM, Farrukh Najmi wrote:

 An example of a metadata property that has no IIM mapping defined is
 Name:
 Scene Code, XMP property id: Scene (page 15 of 55 in spec)


 On 07/06/2012 02:25 PM, Farrukh Najmi wrote:
 Hi Damjan,

 Thanks for the +1. As I started on this patch I made some observations
 in
 the IPTC-PhotoMetadata-2008.pdfspec:

* Not all metadata properties have an IIM mapping defined. For these
  we will have to invent a type code. I propose we assign codes
  starting at 1 arbitrarily in such cases
* Every field does have an XMP property id at present. I am not sure
  if there is any guarantee that future fields will have an XMP
  property id. I think we should continue with XMP property id for
  IptcTypes.name field but if in future versions there is no XMP
  property id then the backup would be to use the Name field from
  the spec

 The only other alternative I can think of for IptcTypes.name field
 issue
 is to use the Name field from the spec which is guaranteed to be
 present,
 will never be translated but has the issue that it has white space in
 its
 content. My preference is to do what is proposed in bullets above.

 Comments? Thanks.




 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

You ask TODO: What to do about properties not seen in
IPTC-PhotoMetadata-2008 (e.g. Record Version))

Look at http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/IPTC.html
Scroll down to IPTC ApplicationRecord Tags
Those names seem to resemble what is in
http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf page 24
onwards.

The names in your patch differ from that list.

?

On Sat, Jul 7, 2012 at 3:55 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:

 Oops. Here is the correct file this time.


 On 07/07/2012 01:39 AM, Damjan Jovanovic wrote:

 Hi Farrukh

 Your patch is just an empty file.

 Regards
 Damjan

 On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Hi Damjan,

 Attached is the patch for implementing the proposed change outlined in
 bullets below.
 Please review and then commit if satisfied or discuss further. Thanks.


 On 07/06/2012 02:29 PM, Farrukh Najmi wrote:


 An example of a metadata property that has no IIM mapping defined is
 Name:
 Scene Code, XMP property id: Scene (page 15 of 55 in spec)


 On 07/06/2012 02:25 PM, Farrukh Najmi wrote:

 Hi Damjan,

 Thanks for the +1. As I started on this patch I made some observations
 in
 the IPTC-PhotoMetadata-2008.pdfspec:

* Not all metadata properties have an IIM mapping defined. For these
  we will have to invent a type code. I propose we assign codes
  starting at 1 arbitrarily in such cases
* Every field does have an XMP property id at present. I am not sure
  if there is any guarantee that future fields will have an XMP
  property id. I think we should continue with XMP property id for
  IptcTypes.name field but if in future versions there is no XMP
  property id then the backup would be to use the Name field from
  the spec

 The only other alternative I can think of for IptcTypes.name field
 issue
 is to use the Name field from the spec which is guaranteed to be
 present,
 will never be translated but has the issue that it has white space in
 its
 content. My preference is to do what is proposed in bullets above.

 Comments? Thanks.




 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

Hi Farrukh

Your patch is just an empty file.

Regards
Damjan

On Fri, Jul 6, 2012 at 9:23 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:
 Hi Damjan,

 Attached is the patch for implementing the proposed change outlined in
 bullets below.
 Please review and then commit if satisfied or discuss further. Thanks.


 On 07/06/2012 02:29 PM, Farrukh Najmi wrote:


 An example of a metadata property that has no IIM mapping defined is Name:
 Scene Code, XMP property id: Scene (page 15 of 55 in spec)


 On 07/06/2012 02:25 PM, Farrukh Najmi wrote:

 Hi Damjan,

 Thanks for the +1. As I started on this patch I made some observations in
 the IPTC-PhotoMetadata-2008.pdfspec:

   * Not all metadata properties have an IIM mapping defined. For these
 we will have to invent a type code. I propose we assign codes
 starting at 1 arbitrarily in such cases
   * Every field does have an XMP property id at present. I am not sure
 if there is any guarantee that future fields will have an XMP
 property id. I think we should continue with XMP property id for
 IptcTypes.name field but if in future versions there is no XMP
 property id then the backup would be to use the Name field from
 the spec

 The only other alternative I can think of for IptcTypes.name field issue
 is to use the Name field from the spec which is guaranteed to be present,
 will never be translated but has the issue that it has white space in its
 content. My preference is to do what is proposed in bullets above.

 Comments? Thanks.







 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

I have no idea. I never wrote any of the IPTC code.

On Thu, Jul 5, 2012 at 3:10 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:
 BTW, I had thus far been assuming the IPTC spec to use was:

 IPTC Standard Photo Metadata 2008 IPTC Core Specification Version 1.1
 IPTC Extension Specification Version 1.0
 Document Revision 2
 http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf

 But then I was looking for some missing constants and came across:

 IPTC - NAA Information Interchange Model Version 4
 http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf (IIM)

 Which is the spec that we should be using? How are they related?

 The IIM spec does not have the XMP Property Id (which I incorrectly referred
 to as XML Property Id) as does the IPTC Core spec.

 Sorry for my confusion.


 On 07/05/2012 08:52 AM, Farrukh Najmi wrote:


 A similar change needs to be made IMHO to
 org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java

 so that the enum string value is XML Property Id value instead of the IIM
 mapping value.

 As an example:

 COUNTRY_PRIMARY_LOCATION_NAME(
 101, Country/Primary Location Name),



 would become:

 COUNTRY_PRIMARY_LOCATION_NAME(
 101, Country),


 I can do this patch for you once I get a +1 to do it. Until the +1 I will
 hold off as the work is tedious and time consuming.

 Please let me know. Thanks.

 On 07/05/2012 06:56 AM, Farrukh Najmi wrote:


 Hi Damjan,

 Confirming that your recent fix for supporting Exif FieldName looks good
 great. Thank you!

 When do you think you may be able to commit the changes to support the
 following metadata format-specific methods so I can provide feedback:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()



 On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:

 I just committed new TIFF tag names to SVN, let me know how they work
 for you.

 The best time to add the new metadata methods is before the 1.0
 release, since changing binary compatibility later will be harder.

 On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 +1 on having the methods:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 It is is a good idea so one can access metadata-format-specific
 metadata in
 a metadata-format-specific way and handling all special needs of
 specific
 metadata formats. These methods should work on any image resource and
 throw
 something like MissingFeatureException for when a metadata format is
 not yet
 supported for an image format or throw something like an
 InvalidRequestException when a metadata format is invalid for a image
 format.

 That said, there may still be some value to having a metadata-format
 netrual
 getMetadata() interface along the lines of the patch I submitted. For
 now,
 we could simply log an issue and defer it and insteda focus on your
 suggestion above. That would meet my needs just fine.

 Question is do we do these changes after a formal 1.0 release or
 before? May
 be it is better to get stable code under current API out as 1.0 and
 then
 work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
 backward compatible and are in fact major). Or is it better to do these
 changes for the 1.0 release so consumers of the project do not get
 exposed
 to a big API change?

 If we can do the proposed change without a long delay then I suggest we
 do
 it for 1.0. If it means a long delay then I suggest we defer to 2.0.

 Thoughts?



 On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:

 I've also considered the metadata interfaces we use, and I am not sure
 the current approaches are any good.

 Most metadata formats are designed in a way specific to that format,
 eg. some have arbitrary levels of nesting, others have a flat
 structure, etc. But most are designed to be stored in any image
 format.

 So instead of a Imaging.getMetadata() method that tries to unify all
 metadata into one common interface - and does so badly, because eg.
 EXIF can have nested subdirectories and this information is lost -
 maybe we should have:
 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 Regards
 Damjan

 On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Updated proposed patch with following new changes:

 Add getValue() method to nested class IImageMetadataItem. These
 return
 the
 value of the item as an Object allowing for values of various types
 to be
 returned.


 On 07/03/2012 11:01 AM, Farrukh Najmi wrote:

 Moving this thread to dev list as it seems to be more appropriate
 there

 Attached is a patch to the IImageMetadata.java that reflects my
 revised
 proposal thinking this through in conjunction with the proposed
 solution
 in
 another thread...

 Add a getMetadataSpecification() method to IImageMetadata so we can
 manage
 the metadata specification that defines the metadata
 Add

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

Hi Farrukh

Pleasure :).

I am not sure about the API we should be using, and want to
investigate what other image frameworks do first.

Regards
Damjan


On Thu, Jul 5, 2012 at 12:56 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:

 Hi Damjan,

 Confirming that your recent fix for supporting Exif FieldName looks good
 great. Thank you!

 When do you think you may be able to commit the changes to support the
 following metadata format-specific methods so I can provide feedback:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()




 On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:

 I just committed new TIFF tag names to SVN, let me know how they work for
 you.

 The best time to add the new metadata methods is before the 1.0
 release, since changing binary compatibility later will be harder.

 On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 +1 on having the methods:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 It is is a good idea so one can access metadata-format-specific metadata
 in
 a metadata-format-specific way and handling all special needs of specific
 metadata formats. These methods should work on any image resource and
 throw
 something like MissingFeatureException for when a metadata format is not
 yet
 supported for an image format or throw something like an
 InvalidRequestException when a metadata format is invalid for a image
 format.

 That said, there may still be some value to having a metadata-format
 netrual
 getMetadata() interface along the lines of the patch I submitted. For
 now,
 we could simply log an issue and defer it and insteda focus on your
 suggestion above. That would meet my needs just fine.

 Question is do we do these changes after a formal 1.0 release or before?
 May
 be it is better to get stable code under current API out as 1.0 and then
 work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
 backward compatible and are in fact major). Or is it better to do these
 changes for the 1.0 release so consumers of the project do not get
 exposed
 to a big API change?

 If we can do the proposed change without a long delay then I suggest we
 do
 it for 1.0. If it means a long delay then I suggest we defer to 2.0.

 Thoughts?



 On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:

 I've also considered the metadata interfaces we use, and I am not sure
 the current approaches are any good.

 Most metadata formats are designed in a way specific to that format,
 eg. some have arbitrary levels of nesting, others have a flat
 structure, etc. But most are designed to be stored in any image
 format.

 So instead of a Imaging.getMetadata() method that tries to unify all
 metadata into one common interface - and does so badly, because eg.
 EXIF can have nested subdirectories and this information is lost -
 maybe we should have:
 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 Regards
 Damjan

 On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Updated proposed patch with following new changes:

 Add getValue() method to nested class IImageMetadataItem. These return
 the
 value of the item as an Object allowing for values of various types to
 be
 returned.


 On 07/03/2012 11:01 AM, Farrukh Najmi wrote:

 Moving this thread to dev list as it seems to be more appropriate
 there

 Attached is a patch to the IImageMetadata.java that reflects my revised
 proposal thinking this through in conjunction with the proposed
 solution
 in
 another thread...

 Add a getMetadataSpecification() method to IImageMetadata so we can
 manage
 the metadata specification that defines the metadata
 Add getMetadata() to nested class IImageMetadataItem to get back at the
 parent IImageMetadata instance so we can access the metadata
 specification
 information managed from an IImageMetadata instance
 Add getId(), getName(), getDescription() methods to nested class
 IImageMetadataItem. These are the key triplet of info about the
 metadata
 item that is needed in my experience

 Of course implementations of these two interfaces would need to also be
 updated to support the new methods according to proposed semantics. I
 would
 be happy to contribute in any way that I can and as requested.

 Dev team colleagues, please weigh in on the proposal. Thanks for your
 awesome work to create this project and for considering this proposal.




 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

I'll have a look later and let you know.

On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:

 A similar change needs to be made IMHO to
 org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java

 so that the enum string value is XML Property Id value instead of the IIM
 mapping value.

 As an example:

 COUNTRY_PRIMARY_LOCATION_NAME(
 101, Country/Primary Location Name),



 would become:

 COUNTRY_PRIMARY_LOCATION_NAME(
 101, Country),


 I can do this patch for you once I get a +1 to do it. Until the +1 I will
 hold off as the work is tedious and time consuming.

 Please let me know. Thanks.


 On 07/05/2012 06:56 AM, Farrukh Najmi wrote:


 Hi Damjan,

 Confirming that your recent fix for supporting Exif FieldName looks good
 great. Thank you!

 When do you think you may be able to commit the changes to support the
 following metadata format-specific methods so I can provide feedback:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()



 On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:

 I just committed new TIFF tag names to SVN, let me know how they work for
 you.

 The best time to add the new metadata methods is before the 1.0
 release, since changing binary compatibility later will be harder.

 On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 +1 on having the methods:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 It is is a good idea so one can access metadata-format-specific metadata
 in
 a metadata-format-specific way and handling all special needs of
 specific
 metadata formats. These methods should work on any image resource and
 throw
 something like MissingFeatureException for when a metadata format is not
 yet
 supported for an image format or throw something like an
 InvalidRequestException when a metadata format is invalid for a image
 format.

 That said, there may still be some value to having a metadata-format
 netrual
 getMetadata() interface along the lines of the patch I submitted. For
 now,
 we could simply log an issue and defer it and insteda focus on your
 suggestion above. That would meet my needs just fine.

 Question is do we do these changes after a formal 1.0 release or before?
 May
 be it is better to get stable code under current API out as 1.0 and then
 work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
 backward compatible and are in fact major). Or is it better to do these
 changes for the 1.0 release so consumers of the project do not get
 exposed
 to a big API change?

 If we can do the proposed change without a long delay then I suggest we
 do
 it for 1.0. If it means a long delay then I suggest we defer to 2.0.

 Thoughts?



 On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:

 I've also considered the metadata interfaces we use, and I am not sure
 the current approaches are any good.

 Most metadata formats are designed in a way specific to that format,
 eg. some have arbitrary levels of nesting, others have a flat
 structure, etc. But most are designed to be stored in any image
 format.

 So instead of a Imaging.getMetadata() method that tries to unify all
 metadata into one common interface - and does so badly, because eg.
 EXIF can have nested subdirectories and this information is lost -
 maybe we should have:
 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 Regards
 Damjan

 On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Updated proposed patch with following new changes:

 Add getValue() method to nested class IImageMetadataItem. These return
 the
 value of the item as an Object allowing for values of various types to
 be
 returned.


 On 07/03/2012 11:01 AM, Farrukh Najmi wrote:

 Moving this thread to dev list as it seems to be more appropriate
 there

 Attached is a patch to the IImageMetadata.java that reflects my
 revised
 proposal thinking this through in conjunction with the proposed
 solution
 in
 another thread...

 Add a getMetadataSpecification() method to IImageMetadata so we can
 manage
 the metadata specification that defines the metadata
 Add getMetadata() to nested class IImageMetadataItem to get back at
 the
 parent IImageMetadata instance so we can access the metadata
 specification
 information managed from an IImageMetadata instance
 Add getId(), getName(), getDescription() methods to nested class
 IImageMetadataItem. These are the key triplet of info about the
 metadata
 item that is needed in my experience

 Of course implementations of these two interfaces would need to also
 be
 updated to support the new methods according to proposed semantics. I
 would
 be happy to contribute in any way that I can and as requested.

 Dev team colleagues, please weigh in on the proposal. Thanks for your
 awesome work to create this project and for considering this proposal

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

Hi Farrukh

+1

Thank you
Damjan

On Thu, Jul 5, 2012 at 3:34 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:
 Hi Damjan,

 Just looked here:

 http://www.iptc.org/site/Photo_Metadata/IIM/

 This suggests that IIM is older and the IPTC standard is the IPTC Core +
 Extensions spec
 http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf.
 So my proposal is still valid that we use the XMP Property Id from the IPTC
 Core + Extensions spec
 http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf
 for the string value of enum in
 org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java.

 Again I am awaiting a +1 from you before working on a tedious patch to
 implement the propose change.


 On 07/05/2012 09:28 AM, Farrukh Najmi wrote:


 The change I proposed for IPTC is contingent upon identifying what IPTC
 spec we are using. I am surprised that the IPTC IIM spec which is more
 recent makes no reference to the IPTC Core spec. I think we need to
 determine the correct spec before looking at my proposed change for IPTC
 support.

 On 07/05/2012 09:16 AM, Damjan Jovanovic wrote:

 I'll have a look later and let you know.

 On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 A similar change needs to be made IMHO to
 org.apache.commons.imaging.formats.jpeg.iptc.IptcTypes.java

 so that the enum string value is XML Property Id value instead of the
 IIM
 mapping value.

 As an example:

  COUNTRY_PRIMARY_LOCATION_NAME(
  101, Country/Primary Location Name),



 would become:

  COUNTRY_PRIMARY_LOCATION_NAME(
  101, Country),


 I can do this patch for you once I get a +1 to do it. Until the +1 I
 will
 hold off as the work is tedious and time consuming.

 Please let me know. Thanks.


 On 07/05/2012 06:56 AM, Farrukh Najmi wrote:


 Hi Damjan,

 Confirming that your recent fix for supporting Exif FieldName looks
 good
 great. Thank you!

 When do you think you may be able to commit the changes to support the
 following metadata format-specific methods so I can provide feedback:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()



 On 07/04/2012 12:38 AM, Damjan Jovanovic wrote:

 I just committed new TIFF tag names to SVN, let me know how they work
 for
 you.

 The best time to add the new metadata methods is before the 1.0
 release, since changing binary compatibility later will be harder.

 On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 +1 on having the methods:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 It is is a good idea so one can access metadata-format-specific
 metadata
 in
 a metadata-format-specific way and handling all special needs of
 specific
 metadata formats. These methods should work on any image resource and
 throw
 something like MissingFeatureException for when a metadata format is
 not
 yet
 supported for an image format or throw something like an
 InvalidRequestException when a metadata format is invalid for a image
 format.

 That said, there may still be some value to having a metadata-format
 netrual
 getMetadata() interface along the lines of the patch I submitted. For
 now,
 we could simply log an issue and defer it and insteda focus on your
 suggestion above. That would meet my needs just fine.

 Question is do we do these changes after a formal 1.0 release or
 before?
 May
 be it is better to get stable code under current API out as 1.0 and
 then
 work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are
 not
 backward compatible and are in fact major). Or is it better to do
 these
 changes for the 1.0 release so consumers of the project do not get
 exposed
 to a big API change?

 If we can do the proposed change without a long delay then I suggest
 we
 do
 it for 1.0. If it means a long delay then I suggest we defer to 2.0.

 Thoughts?



 On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:

 I've also considered the metadata interfaces we use, and I am not
 sure
 the current approaches are any good.

 Most metadata formats are designed in a way specific to that format,
 eg. some have arbitrary levels of nesting, others have a flat
 structure, etc. But most are designed to be stored in any image
 format.

 So instead of a Imaging.getMetadata() method that tries to unify all
 metadata into one common interface - and does so badly, because eg.
 EXIF can have nested subdirectories and this information is lost -
 maybe we should have:
 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 Regards
 Damjan

 On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Updated proposed patch with following new changes:

 Add getValue() method to nested class IImageMetadataItem. These
 return
 the
 value of the item as an Object allowing for values of various types
 to
 be
 returned.


 On 07

Re: svn commit: r1356580 - in /commons/proper/imaging/trunk: pom.xml src/changes/ src/changes/changes.xml src/changes/release-notes.vm

[Damjan Jovanovic]

On Tue, Jul 3, 2012 at 4:54 PM, sebb seb...@gmail.com wrote:
 On 3 July 2012 07:45,  dam...@apache.org wrote:
 Author: damjan
 Date: Tue Jul  3 06:45:40 2012
 New Revision: 1356580

 URL: http://svn.apache.org/viewvc?rev=1356580view=rev
 Log:
 Add a changelog for the maven-changes-plugin
 and populate it with all commits for the next release.


 Added:
 commons/proper/imaging/trunk/src/changes/
 commons/proper/imaging/trunk/src/changes/changes.xml   (with props)
 commons/proper/imaging/trunk/src/changes/release-notes.vm   (with props)
 Modified:
 commons/proper/imaging/trunk/pom.xml

 Modified: commons/proper/imaging/trunk/pom.xml
 URL: 
 http://svn.apache.org/viewvc/commons/proper/imaging/trunk/pom.xml?rev=1356580r1=1356579r2=1356580view=diff
 ==
 --- commons/proper/imaging/trunk/pom.xml (original)
 +++ commons/proper/imaging/trunk/pom.xml Tue Jul  3 06:45:40 2012
 @@ -217,6 +217,8 @@
  version${commons.changes.version}/version
  configuration
issueLinkTemplate%URL%/%ISSUE%/issueLinkTemplate
 +  templaterelease-notes.vm/template
 +  templateDirectorysrc/changes/templateDirectory
  /configuration

 I think the above is done by Commons Parent.


Thank you, I took it out.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] TagInfo and distinction between TagName and FieldName

[Damjan Jovanovic]

On Tue, Jul 3, 2012 at 3:48 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:
 On 07/02/2012 11:22 PM, Damjan Jovanovic wrote:

 On Mon, Jul 2, 2012 at 11:33 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Hi Guys,

 I am new to the project so forgive me if the answer is obvious...

 I am working with latest svn bits and the
 org.apache.commons.imaging.formats.tiff.taginfos.TagInfo class seems to
 only
 support the TagName column of Table 3 TIFF Rev. 6.0 Attribute Information
 Used in Exif in the Exif spec http://www.exif.org/Exif2-2.PDF. I need
 access to FieldName as it seems more suitable as a human-friendly
 identifier
 for the tag.

 I think it would be ideal if TagInfo supports both TagName and FieldName.
 What does the dev team think? If there are not many -1s then I will file
 in
 RFE in JIRA.

 Thanks for your input.

 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com

 Hi Farrukh

 The TIFF6 specification Appendix A only has a TagName, which is
 similar to Exif 2.2's FieldName. Other TIFF tag specifications (DNG,
 TIFFPM6, RFC 2301) also only give a name and a description.

 Maybe what we need is:
 Use TagInfo's name field for the name taken verbatim from those
 specs (eg. use ImageWidth instead of Image Width)
 Add a description field to TagInfo with a long description (eg.
 Image width, the number of columns in the image)

 What do you think?


 Hi Damjan,

 +1 on your proposed solution for using TagInfo.name for the Exif 2.2's
 Field Name and for adding a TagInfo.description for Exif 2.2's Tag Name.
 This is what I was thinking as well. That in conjunction with existing
 TagInfo.tag (the numeric id) completes the identification, naming and
 description of the tag and makes for a clean model.

 What do dev team members http://commons.apache.org/imaging/team-list.html
 think about this proposal?

 As an aside, this matches very well with ebXML RegRep's Registry Information
 Model which is what I am trying to map photo metadata to. My eventual goal
 is to define a standard specification to manage image content and metadata
 in an ebXML Registry and Repository.


 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com


Those dev teams members are no longer around, it's mostly just me :).

description is going to be difficult, as only EXIF provides it. But
I'll start doing the name.

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] TagInfo and distinction between TagName and FieldName

[Damjan Jovanovic]

On Tue, Jul 3, 2012 at 9:03 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:
 On 07/03/2012 01:56 PM, Damjan Jovanovic wrote:

 On Tue, Jul 3, 2012 at 3:48 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 On 07/02/2012 11:22 PM, Damjan Jovanovic wrote:

 On Mon, Jul 2, 2012 at 11:33 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Hi Guys,

 I am new to the project so forgive me if the answer is obvious...

 I am working with latest svn bits and the
 org.apache.commons.imaging.formats.tiff.taginfos.TagInfo class seems to
 only
 support the TagName column of Table 3 TIFF Rev. 6.0 Attribute
 Information
 Used in Exif in the Exif spec http://www.exif.org/Exif2-2.PDF. I need
 access to FieldName as it seems more suitable as a human-friendly
 identifier
 for the tag.

 I think it would be ideal if TagInfo supports both TagName and
 FieldName.
 What does the dev team think? If there are not many -1s then I will
 file
 in
 RFE in JIRA.

 Thanks for your input.

 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com

 Hi Farrukh

 The TIFF6 specification Appendix A only has a TagName, which is
 similar to Exif 2.2's FieldName. Other TIFF tag specifications (DNG,
 TIFFPM6, RFC 2301) also only give a name and a description.

 Maybe what we need is:
 Use TagInfo's name field for the name taken verbatim from those
 specs (eg. use ImageWidth instead of Image Width)
 Add a description field to TagInfo with a long description (eg.
 Image width, the number of columns in the image)

 What do you think?


 Hi Damjan,

 +1 on your proposed solution for using TagInfo.name for the Exif 2.2's
 Field Name and for adding a TagInfo.description for Exif 2.2's Tag
 Name.
 This is what I was thinking as well. That in conjunction with existing
 TagInfo.tag (the numeric id) completes the identification, naming and
 description of the tag and makes for a clean model.

 What do dev team members
 http://commons.apache.org/imaging/team-list.html
 think about this proposal?

 As an aside, this matches very well with ebXML RegRep's Registry
 Information
 Model which is what I am trying to map photo metadata to. My eventual
 goal
 is to define a standard specification to manage image content and
 metadata
 in an ebXML Registry and Repository.


 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com

 Those dev teams members are no longer around, it's mostly just me :).

 description is going to be difficult, as only EXIF provides it. But
 I'll start doing the name.


 Hi Damjan,

 Please see the patch I submitted for thread:

 http://mail-archives.apache.org/mod_mbox/commons-dev/201207.mbox/browser

 Above thread seems quite related to this one.

 I think IPTC provides description too.

 If a metadata format other than EXIF or IPTC (which are others btw?) does
 not support description then we can simply return null for that.

The only other metadata format is XMP, but at the moment it's read by
a separate method and returned as a string of XML.


 BTW, ok if I start a JIRA issue (or should it be two?) to track both
 threads' issues?

Of course, go ahead.


 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

I've also considered the metadata interfaces we use, and I am not sure
the current approaches are any good.

Most metadata formats are designed in a way specific to that format,
eg. some have arbitrary levels of nesting, others have a flat
structure, etc. But most are designed to be stored in any image
format.

So instead of a Imaging.getMetadata() method that tries to unify all
metadata into one common interface - and does so badly, because eg.
EXIF can have nested subdirectories and this information is lost -
maybe we should have:
Imaging.getExifMetadata()
Imaging.getIptcMetadata()
Imaging.getXmpMetadata()

Regards
Damjan

On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:

 Updated proposed patch with following new changes:

 Add getValue() method to nested class IImageMetadataItem. These return the
 value of the item as an Object allowing for values of various types to be
 returned.


 On 07/03/2012 11:01 AM, Farrukh Najmi wrote:

 Moving this thread to dev list as it seems to be more appropriate there

 Attached is a patch to the IImageMetadata.java that reflects my revised
 proposal thinking this through in conjunction with the proposed solution in
 another thread...

 Add a getMetadataSpecification() method to IImageMetadata so we can manage
 the metadata specification that defines the metadata
 Add getMetadata() to nested class IImageMetadataItem to get back at the
 parent IImageMetadata instance so we can access the metadata specification
 information managed from an IImageMetadata instance
 Add getId(), getName(), getDescription() methods to nested class
 IImageMetadataItem. These are the key triplet of info about the metadata
 item that is needed in my experience

 Of course implementations of these two interfaces would need to also be
 updated to support the new methods according to proposed semantics. I would
 be happy to contribute in any way that I can and as requested.

 Dev team colleagues, please weigh in on the proposal. Thanks for your
 awesome work to create this project and for considering this proposal.

 On 07/02/2012 07:12 PM, Farrukh Najmi wrote:


 Here is a proposed change to the API that would help my scenario...

 Modify the org.apache.commons.imaging.common.ImageMetadata$Item class to
 have the following additional methods:

 getMetadataSpecification() method that returns a constant String such as
 IPTC:1.1, EXIF:2.1, EXIF:2.2
 getId() method that returns a unique id as follows:

 For EXIF return the Field Name as in Table 3 TIFF Rev. 6.0 Attribute
 Information Used in Exif in the Exif spec.
 For IPTC return the IptcRecord..iptcType.getType()

 This would allow the first code pattern below to identify each item based on
 a specific metadata field defined by a specific specification.

 Thoughts?

 On 07/02/2012 06:18 PM, Farrukh Najmi wrote:


 Hi Guys,

 I am trying to use commons-imaging latest svn bits to write a program that
 will read standard metadata such as Exif and IPTC from images in a variety
 of image formats using code that is as image format neutral as possible. The
 goal is to store each class of metadata (e.g. Exif, IPTC, ...) in a separate
 Map where the key ide


 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

 ntifies a metadata attribute identifier defined by the standard and a value
 that is the metadata attribute's value.

 Here are two patterns I have identified for reading the metadata by looking
 at test programs and code

 1. Read metadata items without considering image format or metadata
 standard.

 IImageMetadata metadata = Imaging.getMetadata(is, Oregon
 Scientific DS6639 - DSC_0307 - iptc added with irfanview.jpg);
 List? extends IImageMetadata.IImageMetadataItem items =
 metadata.getItems();

 int i=0;
 for (IImageMetadata.IImageMetadataItem iitem : items) {
 ImageMetadata.Item item = (ImageMetadata.Item)iitem;
 System.err.println(Index:  + i +  Key:  +
 item.getKeyword() +  Value:  + item.getText() +  class:  +
 iitem.getClass());   //common.ImageMetadata$Item, Tiff.TiffImageMetadata
 i++;
 }


 This is closest to what I want. The EXIF metadata is represented by
 org.apache.commons.imaging.formats.tiff.TiffImageMetadata$Item and I can get
 at the TiffField and its tagName and value (good). However, IPTC metadata is
 represented by org.apache.commons.imaging.common.ImageMetadata$Item. This
 class seems to have no link back to the
 org.apache.commons.imaging.formats.jpeg.iptc.IptcRecord and thus I cannot
 find a way to get the attribute defined by the IPTC spec under the IIM
 mapping rows.


 2. Read Exif and IPTC separately using following metadata and image format
 specific  patterns as 

Re: [IMAGING] Getting EXIF and IPTC metadata using metadata and image format neutral code

[Damjan Jovanovic]

I just committed new TIFF tag names to SVN, let me know how they work for you.

The best time to add the new metadata methods is before the 1.0
release, since changing binary compatibility later will be harder.

On Tue, Jul 3, 2012 at 10:16 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:
 +1 on having the methods:

 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 It is is a good idea so one can access metadata-format-specific metadata in
 a metadata-format-specific way and handling all special needs of specific
 metadata formats. These methods should work on any image resource and throw
 something like MissingFeatureException for when a metadata format is not yet
 supported for an image format or throw something like an
 InvalidRequestException when a metadata format is invalid for a image
 format.

 That said, there may still be some value to having a metadata-format netrual
 getMetadata() interface along the lines of the patch I submitted. For now,
 we could simply log an issue and defer it and insteda focus on your
 suggestion above. That would meet my needs just fine.

 Question is do we do these changes after a formal 1.0 release or before? May
 be it is better to get stable code under current API out as 1.0 and then
 work on a 2.0-SNAPSHOT (as opposed to 1.1 since the API changes are not
 backward compatible and are in fact major). Or is it better to do these
 changes for the 1.0 release so consumers of the project do not get exposed
 to a big API change?

 If we can do the proposed change without a long delay then I suggest we do
 it for 1.0. If it means a long delay then I suggest we defer to 2.0.

 Thoughts?



 On 07/03/2012 03:58 PM, Damjan Jovanovic wrote:

 I've also considered the metadata interfaces we use, and I am not sure
 the current approaches are any good.

 Most metadata formats are designed in a way specific to that format,
 eg. some have arbitrary levels of nesting, others have a flat
 structure, etc. But most are designed to be stored in any image
 format.

 So instead of a Imaging.getMetadata() method that tries to unify all
 metadata into one common interface - and does so badly, because eg.
 EXIF can have nested subdirectories and this information is lost -
 maybe we should have:
 Imaging.getExifMetadata()
 Imaging.getIptcMetadata()
 Imaging.getXmpMetadata()

 Regards
 Damjan

 On Tue, Jul 3, 2012 at 9:19 PM, Farrukh Najmi
 farr...@wellfleetsoftware.com wrote:

 Updated proposed patch with following new changes:

 Add getValue() method to nested class IImageMetadataItem. These return
 the
 value of the item as an Object allowing for values of various types to be
 returned.


 On 07/03/2012 11:01 AM, Farrukh Najmi wrote:

 Moving this thread to dev list as it seems to be more appropriate
 there

 Attached is a patch to the IImageMetadata.java that reflects my revised
 proposal thinking this through in conjunction with the proposed solution
 in
 another thread...

 Add a getMetadataSpecification() method to IImageMetadata so we can
 manage
 the metadata specification that defines the metadata
 Add getMetadata() to nested class IImageMetadataItem to get back at the
 parent IImageMetadata instance so we can access the metadata
 specification
 information managed from an IImageMetadata instance
 Add getId(), getName(), getDescription() methods to nested class
 IImageMetadataItem. These are the key triplet of info about the metadata
 item that is needed in my experience

 Of course implementations of these two interfaces would need to also be
 updated to support the new methods according to proposed semantics. I
 would
 be happy to contribute in any way that I can and as requested.

 Dev team colleagues, please weigh in on the proposal. Thanks for your
 awesome work to create this project and for considering this proposal.



 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING] TagInfo and distinction between TagName and FieldName

[Damjan Jovanovic]

On Mon, Jul 2, 2012 at 11:33 PM, Farrukh Najmi
farr...@wellfleetsoftware.com wrote:

 Hi Guys,

 I am new to the project so forgive me if the answer is obvious...

 I am working with latest svn bits and the
 org.apache.commons.imaging.formats.tiff.taginfos.TagInfo class seems to only
 support the TagName column of Table 3 TIFF Rev. 6.0 Attribute Information
 Used in Exif in the Exif spec http://www.exif.org/Exif2-2.PDF. I need
 access to FieldName as it seems more suitable as a human-friendly identifier
 for the tag.

 I think it would be ideal if TagInfo supports both TagName and FieldName.
 What does the dev team think? If there are not many -1s then I will file in
 RFE in JIRA.

 Thanks for your input.

 --
 Regards,
 Farrukh

 Web: http://www.wellfleetsoftware.com


Hi Farrukh

The TIFF6 specification Appendix A only has a TagName, which is
similar to Exif 2.2's FieldName. Other TIFF tag specifications (DNG,
TIFFPM6, RFC 2301) also only give a name and a description.

Maybe what we need is:
Use TagInfo's name field for the name taken verbatim from those
specs (eg. use ImageWidth instead of Image Width)
Add a description field to TagInfo with a long description (eg.
Image width, the number of columns in the image)

What do you think?

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1307494 - in /commons/proper/sanselan/trunk/src/test/data/images/jpg/2: 2008-07-27+-+Photo+216+-+WE+a+l'etang+de+Blodelsheim.jpg 2008-07-27+-+Photo+216+-+WE+à+l'étang+de+Blodelsheim.j

[Damjan Jovanovic]

On Fri, Mar 30, 2012 at 5:56 PM,  s...@apache.org wrote:
 Author: sebb
 Date: Fri Mar 30 15:56:36 2012
 New Revision: 1307494

 URL: http://svn.apache.org/viewvc?rev=1307494view=rev
 Log:
 Accented name causes problems for some CI systems, so remove the accents
 They are not relevant to the test cases.

 Added:
    
 commons/proper/sanselan/trunk/src/test/data/images/jpg/2/2008-07-27+-+Photo+216+-+WE+a+l'etang+de+Blodelsheim.jpg
      - copied unchanged from r1298153, 
 commons/proper/sanselan/trunk/src/test/data/images/jpg/2/2008-07-27+-+Photo+216+-+WE+à+l'étang+de+Blodelsheim.jpg
 Removed:
    
 commons/proper/sanselan/trunk/src/test/data/images/jpg/2/2008-07-27+-+Photo+216+-+WE+à+l'étang+de+Blodelsheim.jpg


Which CI systems don't work with Unicode filenames? They should also be fixed.

Damjan Jovanovic

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IMAGING]/[SANSELAN] JIRA error

[Damjan Jovanovic]

On Wed, Jun 27, 2012 at 1:50 AM, sebb seb...@gmail.com wrote:
 On 26 June 2012 22:50, sebb seb...@gmail.com wrote:
 Some new SANSELAN JIRAs have just been raised, however the JIRA was
 renamed to IMAGING.

 Looks like something is wrong with JIRA; I'll raise an Infra issue.

 https://issues.apache.org/jira/browse/INFRA-4970

 Looks like it was our fault ... infra can fix things, but want us to
 confirm that we definitely no longer want SANSELAN as a JIRA project.

 So please reply to this mail to say

[X] OK to delete SANSELAN JIRA project
[ ] NO, let's keep it (please say why?)

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging][csv][configuration][net] mvn -Prc install doesn't generate zip/tar.gz/tar.bz2 files?

[Damjan Jovanovic]

On Sun, Jun 3, 2012 at 7:07 PM, Oliver Heger
oliver.he...@oliver-heger.de wrote:
 Am 03.06.2012 15:56, schrieb Gary Gregory:

 I use http://wiki.apache.org/commons/UsingNexus

 Gary

 On Jun 3, 2012, at 4:25, Damjan Jovanovicdam...@apache.org  wrote:

 Hi

 I am trying to make an RC release of Commons Imaging, and according to
 http://commons.apache.org/releases/prepare.html the command which is
 meant to generate the release artifacts is:
 mvn -Prc -DcreateChecksum=true install

 However this only generates .jar/javadoc.jar/sources.jar files, not
 the bin/src .zip, .tar.gz or .tar.bz2.

 I've tried it on several other Commons projects:
 csv - command fails because assembly descriptors are missing
 configuration - also only generates .jar files
 net - also only generates .jar files

 Is that web page wrong? Is there some other command that is meant to
 be used? Or is there some kind of problem in all these projects?


 For [configuration] I used to follow the instructions on this page. The full
 distribution is created by the shell script in the section Create the
 Release Candidate Website. This worked for me.

 Oliver


The command mvn -Prc -DcreateChecksum=true install is taken verbatim
from that very Create the Release Candidate Website page, and
neither it, nor that entire script, are working, for either Imaging or
Configuration from the latest SVN trunk.

According to http://www.mail-archive.com/dev@commons.apache.org/msg23476.html
this is a known regression in the maven-assembly-plugin.
A bit of searching finds http://jira.codehaus.org/browse/MASSEMBLY-553
which appears to be the problem.

Workaround (taken from
http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?revision=1169875view=markup):

build
pluginManagement
  plugins
plugin
  artifactIdmaven-assembly-plugin/artifactId
  version2.2-beta-5/version
/plugin
  /plugins
/pluginManagement
/build

Please add that to the website (or how can I add it?). Also if Plexus
is the current official way of releasing Commons components, why isn't
that documented?

This is now the 3rd build-breaking bug in Maven plugins I've found in
my casual usage...

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[imaging][csv][configuration][net] mvn -Prc install doesn't generate zip/tar.gz/tar.bz2 files?

[Damjan Jovanovic]

Hi

I am trying to make an RC release of Commons Imaging, and according to
http://commons.apache.org/releases/prepare.html the command which is
meant to generate the release artifacts is:
mvn -Prc -DcreateChecksum=true install

However this only generates .jar/javadoc.jar/sources.jar files, not
the bin/src .zip, .tar.gz or .tar.bz2.

I've tried it on several other Commons projects:
csv - command fails because assembly descriptors are missing
configuration - also only generates .jar files
net - also only generates .jar files

Is that web page wrong? Is there some other command that is meant to
be used? Or is there some kind of problem in all these projects?

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?

[Damjan Jovanovic]

On Thu, Apr 26, 2012 at 2:16 PM, Gary Lucas gwlu...@sonalysts.com wrote:

 Since we're on the subject, another question.  In encoding data, I was 
 constructing field types and coding the information.  But it looks like 
 you've got some static declarations for doing the same thing.  Could you 
 verify that the following is your intended approach

    public TiffOutputField encodeASCII(TagInfo tInfo, String string)
            throws ImageWriteException,  ImageWriteException
    {
        //      previous approach:
        //        FieldType fType = new FieldTypeAscii(2, ASCII);
        //        byte bytes[] = fType.writeData(string, byteOrder);

        byte bytes[] = FieldType.FIELD_TYPE_ASCII.writeData(string, byteOrder);

        TiffOutputField tiffOutputField =
                new TiffOutputField(
                tInfo.tag,
                tInfo,
                FieldType.FIELD_TYPE_ASCII,
                bytes.length,
                bytes);
        return tiffOutputField;
    }

Do your emails keep getting cut short?

The easiest way, for a known tag type, is:

tiffOutputDirectory.add(TiffTagConstants.TIFF_TAG_DATE_TIME,
2012-04-25 01:23:45);

which supports IDE code completion, and automatically overloads to the
correct method based on the tag type.

For an unknown tag type, I think you have to use the old way where you
construct a TiffOutputField yourself.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?

[Damjan Jovanovic]

Not your last one, the one before. It ends with:
One question.  When I
and there's nothing after it.

On Thu, Apr 26, 2012 at 2:31 PM, Gary Lucas gwlu...@sonalysts.com wrote:
 Excellent again!   Much better.

 I'm not sure how that last email got cut short, but you've answered my 
 question.  So thanks.



 g.



 -Original Message-
 From: Damjan Jovanovic [mailto:damjan@gmail.com]
 Sent: Thursday, April 26, 2012 8:26 AM
 To: Commons Developers List
 Subject: Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?

 On Thu, Apr 26, 2012 at 2:16 PM, Gary Lucas gwlu...@sonalysts.com wrote:

 Since we're on the subject, another question.  In encoding data, I was
 constructing field types and coding the information.  But it looks
 like you've got some static declarations for doing the same thing.
 Could you verify that the following is your intended approach

    public TiffOutputField encodeASCII(TagInfo tInfo, String string)
            throws ImageWriteException,  ImageWriteException
    {
        //      previous approach:
        //        FieldType fType = new FieldTypeAscii(2, ASCII);
        //        byte bytes[] = fType.writeData(string, byteOrder);

        byte bytes[] = FieldType.FIELD_TYPE_ASCII.writeData(string,
 byteOrder);

        TiffOutputField tiffOutputField =
                new TiffOutputField(
                tInfo.tag,
                tInfo,
                FieldType.FIELD_TYPE_ASCII,
                bytes.length,
                bytes);
        return tiffOutputField;
    }

 Do your emails keep getting cut short?

 The easiest way, for a known tag type, is:

 tiffOutputDirectory.add(TiffTagConstants.TIFF_TAG_DATE_TIME,
 2012-04-25 01:23:45);

 which supports IDE code completion, and automatically overloads to the 
 correct method based on the tag type.

 For an unknown tag type, I think you have to use the old way where you 
 construct a TiffOutputField yourself.

 Damjan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] maven: Problem with clirr

[Damjan Jovanovic]

On Tue, Apr 24, 2012 at 11:19 PM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
 Hi.

 Clirr now fails the build on error:
 ---CUT---
 [ERROR] Unable to find information in class 
 org.apache.commons.math3.linear.SymmLQ referring back to nested class 
 org.apache.commons.math3.linear.SymmLQ$SymmLQEvent
 [ERROR] Unable to find information in class 
 org.apache.commons.math3.optimization.direct.PowellOptimizer referring back 
 to nested class 
 org.apache.commons.math3.optimization.direct.PowellOptimizer$SimpleValueChecker
 ---CUT---

 Since I don't know what causes those errors, I'd like to be able to skip
 the clirr check altogether.

It seems you got lucky, that error used to break the build until very
recently (http://jira.codehaus.org/browse/MCLIRR-36).

Clirr is old, and I think it only works properly with Java 1.4, it
can't handle some aspects of the new .class file format from later
versions.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [sanselan] EXIF_TAG_MODIFY_DATE removed from new imaging package?

[Damjan Jovanovic]

On Wed, Apr 25, 2012 at 10:30 PM, Gary Lucas gwlu...@sonalysts.com wrote:
 I'm taking a stab at transitioning from Sanselan to the new Apache Imaging.   
 One thing I've noticed is that one of the EXIF tags my existing software uses 
 seems to have been removed from imaging:

  public static final TagInfo EXIF_TAG_MODIFY_DATE = new TagInfo(
            Modify Date, 0x0132, FIELD_TYPE_ASCII, 1, EXIF_DIRECTORY_IFD0);


 I'm not familiar with the details behind this tag.   Was it removed because 
 it is obsolete or non-standard?    An oversight?

 Thanks.

 Gary

One of the recent changes was deduplication of TIFF tags, and grouping
of tags by specification.

Tag 0x0132 is defined in the TIFF6 specification, so it is now under
TiffTagConstants, and known as TIFF_TAG_DATE_TIME.

Also I am considering replacing the EXIF_ prefix with TIFF_ for all tags.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Promote [csv] to Commons proper

[Damjan Jovanovic]

On Tue, Mar 6, 2012 at 7:42 PM, Emmanuel Bourg ebo...@apache.org wrote:
 Commons CSV is approaching a releasable state. Considering the general
 interest in this component I think it's time to promote it to Commons
 proper.

 There are a few points I'd like to address before a release:
 - Handle CSV headers, a CSV API looks incomplete to me without this
 - Examine the feasibility of adding a simple bean mapping feature
 - Extract the unicode unescaping feature as an implementation of
 java.io.Reader, and maybe contribute it to Commons IO
 - Improve the documentation


 [ ] +1 Promote it!
 [ ] -1 Let it crawl in the sandbox because...

 Emmanuel Bourg


+1
Would be nice to see all of the above features, and some annotations
with the bean mapping if possible, but release what you can.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Maven bugs when building Sanselan

[Damjan Jovanovic]

On Thu, Mar 1, 2012 at 9:25 PM, Dennis Lundberg denn...@apache.org wrote:
 On 2012-03-01 06:23, Damjan Jovanovic wrote:
 On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org wrote:
 On 2012-02-29 19:00, Damjan Jovanovic wrote:
 Hi

 As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
 having showstopper problems with Maven.

 The first problem, now fixed, was that mvn assembly:assembly failed
 due to the Maven Assembly plugin failing to add a non-ASCII filename
 to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
 because Plexus Archiver had a bug that wrongly assumed number of chars
 = number of bytes, an assumption that quickly fails on UTF-8 locales
 (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
 Plexus Archiver, they quickly included that patch in the next release,
 and Maven Assembly then made a 2.3 release which unknowingly pulled in
 that new release of Plexus Archiver. So by increasing the needed
 version of Maven Assembly to 2.3, I got that working now :). I see
 someone recently patched the Commons parent POM with the same version
 change - even better.

 The second is that mvn site fails because Clirr can't compare some
 inner classes properly, and the Maven Clirr plugin doesn't properly
 count and delete classes that can't be compared, leading to
 ArrayIndexOutOfBoundsException
 (http://jira.codehaus.org/browse/MCLIRR-36 and probably
 http://jira.codehaus.org/browse/MCLIRR-25 and
 http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
 working patch to that bug, but there's been no response yet and the
 project seems dead :(.

 I'll take a look at the patch and see if I can push for a release of the
 Clirr plugin.


 Great, thank you!

 Damjan

 Hi

 I had some trouble building Sanselan locally with Java 5, so I added
 Sanselan to our Continuum CI server. The first build gives the same
 result as I got locally, which is a compilation failure. The full report
 is here:

 http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556projectId=251

 The error message is:

 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure
 /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
 cannot find symbol
 symbol  : method copyOfRange(byte[],int,int)
 location: class java.util.Arrays

 That seems to be a Java 6 method. Someone should have a look at that.

 I'll continue chasing Clirr-bugs using Java 6 for the time being.


 --
 Dennis Lundberg

Sorry about that. In commit 1295763 I've added the
animal-sniffer-maven-plugin to the POM, configured it to check for
Java 1.5 compatibility, and taken out the Arrays.copyOfRange().

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Maven bugs when building Sanselan

[Damjan Jovanovic]

On Thu, Mar 1, 2012 at 11:37 PM, Dennis Lundberg denn...@apache.org wrote:
 On 2012-02-29 19:00, Damjan Jovanovic wrote:
 Hi

 As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
 having showstopper problems with Maven.

 The first problem, now fixed, was that mvn assembly:assembly failed
 due to the Maven Assembly plugin failing to add a non-ASCII filename
 to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
 because Plexus Archiver had a bug that wrongly assumed number of chars
 = number of bytes, an assumption that quickly fails on UTF-8 locales
 (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
 Plexus Archiver, they quickly included that patch in the next release,
 and Maven Assembly then made a 2.3 release which unknowingly pulled in
 that new release of Plexus Archiver. So by increasing the needed
 version of Maven Assembly to 2.3, I got that working now :). I see
 someone recently patched the Commons parent POM with the same version
 change - even better.

 The second is that mvn site fails because Clirr can't compare some
 inner classes properly, and the Maven Clirr plugin doesn't properly
 count and delete classes that can't be compared, leading to
 ArrayIndexOutOfBoundsException
 (http://jira.codehaus.org/browse/MCLIRR-36 and probably
 http://jira.codehaus.org/browse/MCLIRR-25 and
 http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
 working patch to that bug, but there's been no response yet and the
 project seems dead :(.

 I am unable to reproduce this error using current trunk of Sanselan. Are
 you using some local modifications to your pom.xml that specifies which
 artifact Clirr should compare against?

 All I get is this:

 [INFO] Unable to find a previous version of the project in the repository
 [INFO] Not generating Clirr report as there is no previous version of
 the library to compare against


Clirr doesn't find the 0.97 release because the groupId and artifactId
for it were different.
It breaks for me because I somehow have Sanselan 0.98 (a version that
was never released) in my ~/.m2 directory.
But there is still a Clirr bug here which will affect future releases
even if it doesn't affect this one.

I will attach the minimum set of Sanselan 0.98 files needed to
reproduce this bug to the bug report.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Maven bugs when building Sanselan

[Damjan Jovanovic]

Hi

As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
having showstopper problems with Maven.

The first problem, now fixed, was that mvn assembly:assembly failed
due to the Maven Assembly plugin failing to add a non-ASCII filename
to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
because Plexus Archiver had a bug that wrongly assumed number of chars
= number of bytes, an assumption that quickly fails on UTF-8 locales
(http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
Plexus Archiver, they quickly included that patch in the next release,
and Maven Assembly then made a 2.3 release which unknowingly pulled in
that new release of Plexus Archiver. So by increasing the needed
version of Maven Assembly to 2.3, I got that working now :). I see
someone recently patched the Commons parent POM with the same version
change - even better.

The second is that mvn site fails because Clirr can't compare some
inner classes properly, and the Maven Clirr plugin doesn't properly
count and delete classes that can't be compared, leading to
ArrayIndexOutOfBoundsException
(http://jira.codehaus.org/browse/MCLIRR-36 and probably
http://jira.codehaus.org/browse/MCLIRR-25 and
http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
working patch to that bug, but there's been no response yet and the
project seems dead :(.

Otherwise, what is the procedure for renaming the project to Apache
Commons Imaging?

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Maven bugs when building Sanselan

[Damjan Jovanovic]

On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org wrote:
 On 2012-02-29 19:00, Damjan Jovanovic wrote:
 Hi

 As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
 having showstopper problems with Maven.

 The first problem, now fixed, was that mvn assembly:assembly failed
 due to the Maven Assembly plugin failing to add a non-ASCII filename
 to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
 because Plexus Archiver had a bug that wrongly assumed number of chars
 = number of bytes, an assumption that quickly fails on UTF-8 locales
 (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
 Plexus Archiver, they quickly included that patch in the next release,
 and Maven Assembly then made a 2.3 release which unknowingly pulled in
 that new release of Plexus Archiver. So by increasing the needed
 version of Maven Assembly to 2.3, I got that working now :). I see
 someone recently patched the Commons parent POM with the same version
 change - even better.

 The second is that mvn site fails because Clirr can't compare some
 inner classes properly, and the Maven Clirr plugin doesn't properly
 count and delete classes that can't be compared, leading to
 ArrayIndexOutOfBoundsException
 (http://jira.codehaus.org/browse/MCLIRR-36 and probably
 http://jira.codehaus.org/browse/MCLIRR-25 and
 http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
 working patch to that bug, but there's been no response yet and the
 project seems dead :(.

 I'll take a look at the patch and see if I can push for a release of the
 Clirr plugin.


Great, thank you!

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [sanselan]:1.0 Release

[Damjan Jovanovic]

On Fri, Feb 3, 2012 at 4:10 PM, Shashank Gupta shgu...@adobe.com wrote:
 Hi,
 We have been using sanselan incubator 0.97 release which has performance 
 issues on .tif format. I hope that the next 1.0 release version contains 
 fixes around performance. When this big-bang release is scheduled?

 Also I checked the trunk source code and it seems that performance 
 fixes(SANSELAN-56 to 58)  are not there in trunk. Any reason why this is the 
 case?

 Thanks in advance,
 Shashank

Hi

As for those performance fixes:
* SANSELAN-56: ImagePrep is a good idea, but I'd rather integrate it
into all the image formats, not just TIFF. Also, there is an even
faster way to use the DataBuffer classes: that DataBufferInt
constructor used is incompatible with some performance optimizations,
like caching the image in video memory (see the Java 7 API for it).
This will take time.
* SANSELAN-57: this isn't a performance fix, but I do want to improve
writing TIFF metadata before the 1.0 release. Several bugs in Jira are
begging for it.
* SANSELAN-58: the real solution here would be to rewrite the bit
extractor so performance is improved in all cases, not just those few.

I plan to include many patches in 1.0, including as many of those
performance patches as possible. At this stage I don't know when it
will be ready; hopefully in a few weeks.

Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL][VOTE] Rename Commons Sanselan to Commons Image

[Damjan Jovanovic]

On Thu, Dec 22, 2011 at 1:54 PM, Christian Grobmeier grobme...@gmail.comwrote:

 On Thu, Dec 22, 2011 at 12:32 PM, Mark Thomas ma...@apache.org wrote:
  On 19/12/2011 14:54, Gary Gregory wrote:
  This is a VOTE to [ALL] to rename Commons Sanselan to Commons Image.
 
  The drive is to have a meaningful obvious name like [Lang], [IO], [Net],
  and so on.
 
  This VOTE is open until December 22, 10AM EST.
 
  -1.
 
  The naming decision was made by the community when Sanselan joined
  Commons 2.5 years ago [1] and I see no reason to revisit that decision.
  I am rather disappointed to see this being rehashed after the issue has
  already been resolved.

 I think every decision can be revisited at any time, if the
 participants of this project feel the need to do so. There is no
 decision carved in stone and I am pretty surprised you are
 disappointed just because something is discussed again - after all,
 2.5 years are a long time. Actually I think revisiting old decisions
 from time to time is the key for the progress of a project.

  Not all Commons components have functional names. If the Sanselan
  community wants to use that name then I have no problem with that.

 I agree, even when I like Commons Image (et al) better. I have not
 seen Charles speaking up on this matter, I hope he is still around.

 Anyway it should be the Commons Community and the Sanselan Component.

 Looking at this: http://bit.ly/tZc8Tf
 Most people participating on Sanselan are discussing the rename change.

 Cheers
 Christian


Your biggest participant on Sanselan in terms of functional code (ie. image
stuff) in the past year is me, and I haven't said anything until now :).

A rose by any other name would smell as sweet, and I am neither
particularly for nor against a rename. But if we do rename Sanselan, I
would most like the new name to be Imaging.

Damjan

Re: [sanselan] ImageReadException and ImageWriteException

[Damjan Jovanovic]

On Wed, Dec 21, 2011 at 10:27 AM, Jörg Schaible joerg.schai...@scalaris.com
 wrote:

 Gary Gregory wrote:

  WRT ImageReadException and ImageWriteException
 
  Would IOException be better for this?

 javax.imageio.IIOException ?

 - Jörg


I'd rather require as little as possible of the javax.* packages, to make
porting to Android easier. The missing java.awt.* packages are already
tough enough.

On the other hand making Sanselan a javax.imageio provider would be an
interesting project.

Damjan

Re: [sanselan] JIRA administration

[Damjan Jovanovic]

Hi

When I had similar permission issues with JIRA, I fixed it by contacting
INFRA.

Damjan

On Tue, Dec 20, 2011 at 11:29 AM, Emmanuel Bourg ebo...@apache.org wrote:

 Hi,

 I wanted to create new versions for Sanselan in JIRA but it seems I do not
 have access to the administration panel:

 https://issues.apache.org/**jira/plugins/servlet/project-**config/SANSELANhttps://issues.apache.org/jira/plugins/servlet/project-config/SANSELAN

 Can this be fixed by someone here (Phil?) or do we have to ask INFRA for
 help?

 Emmanuel Bourg

Re: [sanselan] Comments on next release

[Damjan Jovanovic]

On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas gwlu...@sonalysts.com wrote:

 I see there's some discussion about the next release of Sanselan between
 Damjan Jovanovic, Gary Gregory (I'm the other Gary) and some of the Apache
 community leaders.  My name was even mentioned... so I thought I'd chime in.

 First off, Damjan posted a note to the issue tracker that my submitted
 patches for performance enhancements aren't going to make it into the 1.0
 release.  While I'm naturally disappointed about that, I can understand the
 perspective that it is probably the best choice at this time. Also, a delay
 would give us more time to refine the concept before we start applying it
 to other areas of the code.  The only point I would add here is that I
 think Sanselan does have problems with performance and that those problems
 are really unnecessary.  Java is plenty fast nowadays and there's nothing
 wrong with the Sanselan code per se, just a rather an unlucky choice on
 which API element to use for setting pixel values in an image.  I think
 that the kind of changes proposed for one small area of the code base (TIFF
 images) would have applicability to other parts of the code.  I also think
 that performance is probably one of the issues might keep Sanselan from
 reaching a broader user base.  So I'd encourage everyone interested in
 Sanselan development to keep that in mind for future releases.


No, I never said your patches wouldn't make it into the 1.0 release. I said
they wouldn't make it into the next release, which at the time I was
thinking would be 0.98, and would be released within days. Things have
changed since then, the next release will be 1.0, and it's due later, so
maybe your patches will make it.

Also I care very much about performance - in fact right now I am optimizing
my TIFF CCITT T.4 and T.6 compression algorithms that I will commit later -
but premature optimization is said to be the root of all evil, and the
state of Sanselan's TIFF parser strikes me as very premature (eg. TIFF is
fundamentally a multi-image file format, but there was no support for
reading multiple images from TIFF files until my patch yesterday).

In terms of renaming the project from Sanselan to Image or something
 like that.  Well, I think the key issue here is that the change in name
 would signal a much more ambitious concept of what the project is for.  To
 me, the name Sanselan says I'm a small and unassuming software package
 focused on a particular niche application.  The name Image or something
 like that says I'm gunning for the JAI, and it's high time somebody did it
 too.  I wonder if the reason that the original authors chose the obscure
 name was that their intentions were fairly modest, though with the amount
 of work that went into Sanselan it seems a shame not to promote it.   So
 I'm strictly on the fence about the whole name change thing.


Sanselan seems to have started as an image metadata extraction/manipulation
project. For example the TIFF image support is flaky, but the parts of TIFF
used for JPEG EXIF metadata are excellent.


 Finally, I wanted to ask if there would be any problems  in changing the
 compiler targets in the pom.xml to 1.5 for release 1.0.   The current
 compiler targets are set up to compile with Java 1.4 features, but I just
 switched them to 1.5 and everything build and tested without errors.   I'm
 not proposing that anyone go make code changes to Sanselan so that it uses
 generics or other 1.5 fixtures.   Just compile the current code to
 accommodate 1.5 rather than being stuck in the 1.4 feature set.  By
 switching release 1.0 to Java 1.5 does have the advantage that in any new
 work, coders will be able to use 1.5 without compatibility issues.


I was hoping for several small releases with incremental changes, but since
we seem to be going the route of a big bang release with many changes, we
might as well do the 1.5 upgrade too.


 Gary




 Computer Programming is the Art of the Possible
 Gary W. Lucas
 Sonalysts, Inc.
 215 Parkway North
 Waterford, CT 06385



Damjan

Re: [sanselan] how to build a release

[Damjan Jovanovic]

On Sat, Dec 17, 2011 at 1:35 AM, Gary Gregory garydgreg...@gmail.comwrote:

 On Fri, Dec 16, 2011 at 5:54 PM, sebb seb...@gmail.com wrote:

  On 16 December 2011 20:49, Gary Gregory garydgreg...@gmail.com wrote:
   On Fri, Dec 16, 2011 at 1:43 PM, sebb seb...@gmail.com wrote:
  
   On 16 December 2011 17:27, Simone Tripodi simonetrip...@apache.org
   wrote:
AH yes, that's because Sanselan came from the Incubator and hasn't
been updated yet :P
  
   Yes - that's good (as it happens).
  
   The previous (incubator) Maven release was under the groupId
   org.apache.sanselan, and the package was also o.a.sanselan
  
   The package name has been changed already, so we can change the Maven
   groupId to o.a.commons, which will automatically give Nexus access.
  
  
   I see package org.apache.sanselan all over in
   https://svn.apache.org/repos/asf/commons/proper/sanselan/trunk
  
   Do I have the right project checked out?
 
  Oops!  Yes, you do.
 
  Sorry, got that wrong - I thought I had checked the current package.
 
  In which case, we either need to
  * keep the package name  make another release under the old Maven
 coords,
  or
  * change the package to o.a.c and make a release under Maven o.a.c.
 

  IMO change the package to o.a.c, should be done now.

 I'll could it unless you or anyone gets to it first, or makes other kinds
 of noises.


If a 1.0 release is necessary, I'd like to make other changes too before
that.

As for the Java 1.5 update, that would make a Java ME port harder to do,
but I'd rather have an Android port anyway.

Damjan

[sanselan] how to build a release

[Damjan Jovanovic]

Hi

I promised to start the Sanselan release process early this week, but I've
been having problem after problem:

1. The instructions on http://commons.apache.org/releases/prepare.html say
that you run a variation of mvn install to build the release... but this
only generates the .jar files, not the src/bin zip/tar.gz/tar.bz2 files.

2. Running mvn assembly:assembly fails because my UTF-8 platform locale
causes a multibyte bug in Plexus Archiver when writing a German sounding
filename into the src tar file. I reported this 3 year old bug and
submitted a patch (http://jira.codehaus.org/browse/PLXCOMP-195). How did
you build Sanselan without this patch before?

3. Running mvn assembly:assembly with a manually patched Plexus Archiver
(and what a mission it was to figure out which of the 5 versions of Plexus
Archiver in my Maven repository is the one used...) does generate those
other files, but doesn't sign them.

4. My attempts to manually sign the .jar file, or its md5 or sha1 hash,
with gpg, generate different checksums than those generated by Maven. Thus
I cannot manually sign the zip/tar files. How is signing supposed to work,
what gets signed and how?

5. mvn release is so badly documented that I am scared to use it. When I
run it with -DdryRun=true, it hangs on [gpg:sign {execution:
sign-artifacts}]. The child process launched by mvn release:prepare is
launched without this parameter, and strace shows it stuck in read() on fd
0 (stdin). Typing the passphrase and pressing enter does nothing.
Redirecting stdin from a file with the passphrase also does nothing.
Attempts to use -Dgpg.passphrase=... also do nothing, whether passed to
directly mvn or quoted inside the -Darguments or both, and ps fax shows
that it isn't passed to the child process.

Please help?

Thank you
Damjan

Re: [sanselan] how to build a release

[Damjan Jovanovic]

On Thu, Dec 15, 2011 at 7:33 PM, sebb seb...@gmail.com wrote:

 On 15 December 2011 17:10, sebb seb...@gmail.com wrote:
  On 15 December 2011 16:58, Damjan Jovanovic damjan@gmail.com
 wrote:
  Hi
 
  I promised to start the Sanselan release process early this week, but
 I've
  been having problem after problem:
 
  1. The instructions on http://commons.apache.org/releases/prepare.htmlsay
  that you run a variation of mvn install to build the release... but
 this
  only generates the .jar files, not the src/bin zip/tar.gz/tar.bz2 files.
 
  Probably need to run package as well, but it's hard work doing it that
 way.
 
  2. Running mvn assembly:assembly fails because my UTF-8 platform
 locale
  causes a multibyte bug in Plexus Archiver when writing a German sounding
  filename into the src tar file. I reported this 3 year old bug and
  submitted a patch (http://jira.codehaus.org/browse/PLXCOMP-195). How
 did
  you build Sanselan without this patch before?
 

 I just tried assembly:assembly (and single) with no issues.

 What is your platform locale?
 Java version?
 Maven version?

 Can you not use MAVEN_OPTS to override the locale?


I am using Linux, Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200),
with locale of en_ZA.UTF-8.

You're probably on Windows, which uses a different locale, which doesn't
generate any multi-byte characters, so everything's fine.

Alternatively, perhaps the oddly-named files should be renamed to omit
 the accents etc.
 They may well cause unnecessary grief for others...

 Are the actual names an essential part of the test suite, or is it
 just the contents that matter?


Just the contents, and I can rename it for now, but somebody should really
fix Plexus Archiver and make Maven use the new version, otherwise this will
just happen again in a different project.

Re: [sanselan] how to build a release

[Damjan Jovanovic]

Thank you, this seems like what I needed. It turns out gpg-agent has to be
used to sign.

Unfortunately the Internet bandwidth required to upload all the files is
vast, so a Sanselan release is probably only going to happen in January.

In the meanwhile, does my key have to linked into the web of trust before I
can make a release?

Damjan

On Thu, Dec 15, 2011 at 7:05 PM, Simone Tripodi simonetrip...@apache.orgwrote:

 Hi Damjan!

 I suggest you approaching the wiki page[1] first to see how components
 are released in commons, at least the described method is the one I
 follow when proposing RCs.

 HTH, have a nice day!
 -Simo

 [1] http://wiki.apache.org/commons/CreatingReleases

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/



 On Thu, Dec 15, 2011 at 5:58 PM, Damjan Jovanovic damjan@gmail.com
 wrote:
  Hi
 
  I promised to start the Sanselan release process early this week, but
 I've
  been having problem after problem:
 
  1. The instructions on http://commons.apache.org/releases/prepare.htmlsay
  that you run a variation of mvn install to build the release... but
 this
  only generates the .jar files, not the src/bin zip/tar.gz/tar.bz2 files.
 
  2. Running mvn assembly:assembly fails because my UTF-8 platform locale
  causes a multibyte bug in Plexus Archiver when writing a German sounding
  filename into the src tar file. I reported this 3 year old bug and
  submitted a patch (http://jira.codehaus.org/browse/PLXCOMP-195). How did
  you build Sanselan without this patch before?
 
  3. Running mvn assembly:assembly with a manually patched Plexus
 Archiver
  (and what a mission it was to figure out which of the 5 versions of
 Plexus
  Archiver in my Maven repository is the one used...) does generate those
  other files, but doesn't sign them.
 
  4. My attempts to manually sign the .jar file, or its md5 or sha1 hash,
  with gpg, generate different checksums than those generated by Maven.
 Thus
  I cannot manually sign the zip/tar files. How is signing supposed to
 work,
  what gets signed and how?
 
  5. mvn release is so badly documented that I am scared to use it. When
 I
  run it with -DdryRun=true, it hangs on [gpg:sign {execution:
  sign-artifacts}]. The child process launched by mvn release:prepare is
  launched without this parameter, and strace shows it stuck in read() on
 fd
  0 (stdin). Typing the passphrase and pressing enter does nothing.
  Redirecting stdin from a file with the passphrase also does nothing.
  Attempts to use -Dgpg.passphrase=... also do nothing, whether passed to
  directly mvn or quoted inside the -Darguments or both, and ps fax
 shows
  that it isn't passed to the child process.
 
  Please help?
 
  Thank you
  Damjan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Sanselan] release plan?

[Damjan Jovanovic]

Hi

Yes, it's time for a release. All tests now pass, and most of the serious
issues are now fixed.

However I did promise a few people their patches would get attention, so
first I would like to review and apply the TIFF performance enhancement
patches by Gary Lucas (SANSELAN-56 to 58), and the TIFF G.3 and G.4
compression patches (SANSELAN-48). Then after that, which is hopefully
early next week, I'll start the release process.

Regards
Damjan

On Fri, Dec 9, 2011 at 1:20 PM, Gary Gregory garydgreg...@gmail.com wrote:

 Hi all,

 I've a lot of commit activity here recently which is quite welcome.
 What are thoughts on releasing? Can anyone comment on the state of the
 component?

 Than you,

 Gary

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Sanselan: commit access?

[Damjan Jovanovic]

Hi

My large patch to Sanselan
(https://issues.apache.org/jira/browse/SANSELAN-49) has been sitting
in Jira for 6 weeks with no comment. With it,  50% of all image
formats in Sanselan will have been written by me, and I've been
practically the only contributor of late, so can I please have commit
access?

Thank you
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org