[VOTE] Apache Tika 0.5 release candidate #1

[Mattmann, Chris A (388J)]

Hi Folks,

I have posted a candidate for the Apache Tika 0.5 release. The source code
is at:

http://people.apache.org/~mattmann/apache-tika-0.5/rc1/

See the included CHANGES.txt file for details on release contents and latest
changes. The release was made using the Maven2 release plugin, according to
Jukka Zitting's notes:

http://tinyurl.com/yz2cqls

This plugin creates a Tika 0.5 tag at:

http://svn.apache.org/repos/asf/lucene/tika/tags/0.5/

And a staged M2 repository at repository.apache.org, here:

https://repository.apache.org/content/repositories/orgapachetika-006/

Please vote on releasing these packages as Apache Tika 0.5. The vote is open
for the next 72 hours. Only votes from Lucene PMC are binding, but everyone
is welcome to check the release candidate and voice their approval or
disapproval. The vote passes if at least three binding +1 votes are cast.

[ ] +1 Release the packages as Apache Tika 0.5.

[ ] -1 Do not release the packages because...

Thanks!

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Karl Heinz Marbaise]

Hi there,

> See the included CHANGES.txt file for details on release contents and latest
> changes. The release was made using the Maven2 release plugin, according to

I have downloaded and unpacked the archive...checked the md5
sum...ok...tried to build via "mvn install" works fine...

Some notes:

Inside the archive there are artifacts from a mvn release:prepare
run...like release.properties etc. ?

Question:
Why is the usual "assembly" part of a profile instead of the usual
lifecylce so you can simply call "mvn package" to produce a zip archive...

Why is the assembly.xml descriptor not in src/main/assembly folder ?


On the other hand the version entries of the following plugin's are not
finalzed (no version given):

maven-deploy-plugin (defined by apache parent)
maven-javadoc-plugin (define by apache parent)
maven-site-plugin (defined by apache parent)
maven-assembly-plugin !
maven-jxr-plugin !
maven-pmd-plugin !
maven-surefire-report-plugin !

Could someone check this ?

> disapproval. The vote passes if at least three binding +1 votes are cast.
>
> [ ] +1 Release the packages as Apache Tika 0.5.
>
> [ ] -1 Do not release the packages because...
[-1]
    - Missing plugin fixing of the versions
    - May be moving the assembly.xml descriptor to the "default" folder
      src/main/assembly (based on the doc of the assembly plugin..)

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: [phone] / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise        ICQ#: 135949029
Hauptstrasse 177                         USt.IdNr: DE191347579
52146 Würselen                           http://www.soebes.de

[Jukka Zitting]

Hi,

[x] +1 Release the packages as Apache Tika 0.5.

The only issue I see with the release are the temporary Maven release
plugin files found in the source archive. Did you take the package
from target/ or from target/checkout/target/ after mvn
release:perform? The latter location should contain a clean build from
a fresh checkout of the svn tag, and thus should not contain the extra
files. Alternatively we need to fix the release assembly to avoid the
extra files. Anyway, I don't see this as a blocker, just something to
sort out before Tika 0.6.

BR,

Jukka Zitting

[Jukka Zitting]

Hi,

On Sun, Nov 15, 2009 at 6:56 PM, Karl Heinz Marbaise <khmarbaise@...> wrote:
> Why is the usual "assembly" part of a profile instead of the usual lifecylce
> so you can simply call "mvn package" to produce a zip archive...

We only need to create the release package when cutting a release
candidate. There's little benefit of building the release package when
you've already downloaded it. The normal package lifecycle is for
building the sources and packaging the resulting binaries.

> Why is the assembly.xml descriptor not in src/main/assembly folder ?

I dislike having folders with just a single file in them, and there
does not seem to be any benefit (less configuration, better IDE/build
integration, etc.) to putting the file in src/main/assembly.

Note that for Tika 0.6 we may want to look at using the new Apache
source release assembly descriptor that was recently released by
Maven, see http://markmail.org/message/aeblw44n6qam23lp.

> On the other hand the version entries of the following plugin's are not
> finalzed (no version given):
>
> maven-deploy-plugin (defined by apache parent)
> maven-javadoc-plugin (define by apache parent)
> maven-site-plugin (defined by apache parent)

There's no need to specify these plugin versions since they're
inherited from the parent.

> maven-assembly-plugin !
> maven-jxr-plugin !
> maven-pmd-plugin !
> maven-surefire-report-plugin !

Yep, we probably should fix these plugin versions.

> [-1]
>   - Missing plugin fixing of the versions
>   - May be moving the assembly.xml descriptor to the "default" folder
>     src/main/assembly (based on the doc of the assembly plugin..)

Do you see these as blockers for the release? I wouldn't mind if Chris
wanted to do a second release candidate to fix these issues, but I'd
be equally happy to see these issues fixed in time for Tika 0.6 as
neither seems to be too critical.

BR,

Jukka Zitting

[Karl Heinz Marbaise]

Hi,

> We only need to create the release package when cutting a release
> candidate. There's little benefit of building the release package when
> you've already downloaded it. The normal package lifecycle is for
> building the sources and packaging the resulting binaries.
Ok not a real problem...just a note of mine...or question..thanks for the explanation.

>
> > Why is the assembly.xml descriptor not in src/main/assembly folder ?
>
> I dislike having folders with just a single file in them, and there
> does not seem to be any benefit (less configuration, better IDE/build
> integration, etc.) to putting the file in src/main/assembly.
Hm...i like the Maven way so i would prefer to put it into src/main/assembly...may be add files later...it's a little bit unusual to have files in the root of the project ...

BTW: What about a .tar.gz ?

> > maven-deploy-plugin (defined by apache parent)
> > maven-javadoc-plugin (define by apache parent)
> > maven-site-plugin (defined by apache parent)
> There's no need to specify these plugin versions since they're
> inherited from the parent.
Yeah...as written defined by apache parent ;-) Ok...

>
> > maven-assembly-plugin !
> > maven-jxr-plugin !
> > maven-pmd-plugin !
> > maven-surefire-report-plugin !
>
> Yep, we probably should fix these plugin versions.
>
> > [-1]
> >   - Missing plugin fixing of the versions
> >   - May be moving the assembly.xml descriptor to the "default" folder
> >     src/main/assembly (based on the doc of the assembly plugin..)
>
> Do you see these as blockers for the release? I wouldn't mind if Chris
> wanted to do a second release candidate to fix these issues, but I'd
> be equally happy to see these issues fixed in time for Tika 0.6 as
> neither seems to be too critical.

These issues are not critical...but i would suggest to fix at least the fixing versions for the plugins...for the 0.5 Release...

Thanks for the good Framework...

Kind regards
Karl Heinz Marbaise
--
MfG
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: [phone] / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise        ICQ#: 135949029
Hauptstrasse 177                     USt.IdNr: DE191347579
52146 Würselen                           http://www.soebes.de

[Grant Ingersoll-6]

On Nov 14, 2009, at 2:27 PM, Mattmann, Chris A (388J) wrote:

> Hi Folks,
>
> I have posted a candidate for the Apache Tika 0.5 release. The source code
> is at:
>
> http://people.apache.org/~mattmann/apache-tika-0.5/rc1/
>
> See the included CHANGES.txt file for details on release contents and latest
> changes. The release was made using the Maven2 release plugin, according to
> Jukka Zitting's notes:
>
> http://tinyurl.com/yz2cqls
>
> This plugin creates a Tika 0.5 tag at:
>
> http://svn.apache.org/repos/asf/lucene/tika/tags/0.5/
>
> And a staged M2 repository at repository.apache.org, here:
>
> https://repository.apache.org/content/repositories/orgapachetika-006/
>
> Please vote on releasing these packages as Apache Tika 0.5. The vote is open
> for the next 72 hours. Only votes from Lucene PMC are binding, but everyone
> is welcome to check the release candidate and voice their approval or
> disapproval. The vote passes if at least three binding +1 votes are cast.
>
> [x ] +1 Release the packages as Apache Tika 0.5.

I verified the signatures (note, Chris, you should upgrade to a 4096 bit key, see http://www.apache.org/dev/release-signing.html).

I also brought the libraries over to Solr Cell and ran the tests.

[Mattmann, Chris A (388J)]

Hey Jukka,

>
> The only issue I see with the release are the temporary Maven release
> plugin files found in the source archive. Did you take the package
> from target/ or from target/checkout/target/ after mvn
> release:perform?

I took the zip archive from target, oops! Sorry about that -- my first time
with the new release process. I'll be sure to document the updates on the
Tika wiki.

> The latter location should contain a clean build from
> a fresh checkout of the svn tag, and thus should not contain the extra
> files. Alternatively we need to fix the release assembly to avoid the
> extra files. Anyway, I don't see this as a blocker, just something to
> sort out before Tika 0.6.

+1, I agree. When 0.6 comes around, if I'm the RM, I'll be sure to use the
right zip archive next time ;)

[ X ] +1 Release the packages as Apache Tika 0.5.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Mattmann, Chris A (388J)]

Hi All,

The vote passes. Here are the result tallies:

PMC Votes:

+1 Jukka Zitting
+1 Grant Ignersoll
+1 Chris Mattmann

Non-binding votes:

-1 Karl Heinz Marbaise

Yuan-Fang Li mentioned on TIKA-309 that he is still seeing the behavior,
even after the patch. However, I don't see the behavior after the patch and
commit. Jukka, did the behavior go away for you? I'll hold off slightly on
pushing the release out to the mirrors until I hear back from Yuan-Fang Li,
and others. Yuang-Fang, and all, I'll wait for 48 hours, so if you see the
behavior, voice your opinion between now and then, otherwise, I'll push out
the release based on the above tallies.

Thanks!

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Julien Nioche-4]

Could we fix https://issues.apache.org/jira/browse/TIKA-271 before the
release? I can't reopen the issue but have added a comment on it
Thanks

Julien
--
DigitalPebble Ltd
http://www.digitalpebble.com


2009/11/20 Mattmann, Chris A (388J) <chris.a.mattmann@...>

> Hi All,
>
> The vote passes. Here are the result tallies:
>
> PMC Votes:
>
> +1 Jukka Zitting
> +1 Grant Ignersoll
> +1 Chris Mattmann
>
> Non-binding votes:
>
> -1 Karl Heinz Marbaise
>
> Yuan-Fang Li mentioned on TIKA-309 that he is still seeing the behavior,
> even after the patch. However, I don't see the behavior after the patch and
> commit. Jukka, did the behavior go away for you? I'll hold off slightly on
> pushing the release out to the mirrors until I hear back from Yuan-Fang Li,
> and others. Yuang-Fang, and all, I'll wait for 48 hours, so if you see the
> behavior, voice your opinion between now and then, otherwise, I'll push out
> the release based on the above tallies.
>
> Thanks!
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@...
> WWW:   http://sunset.usc.edu/~mattmann/<http://sunset.usc.edu/%7Emattmann/>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>

[Jukka Zitting]

Hi,

On Fri, Nov 20, 2009 at 3:53 AM, Mattmann, Chris A (388J)
<chris.a.mattmann@...> wrote:
> Yuan-Fang Li mentioned on TIKA-309 that he is still seeing the behavior,
> even after the patch. However, I don't see the behavior after the patch and
> commit. Jukka, did the behavior go away for you?

The test case works, so as far as I'm concerned the issue is fixed.

I'd keep TIKA-309 closed for Tika 0.5. We can file a new issue for 0.6
with a new test case if there still is something to be fixed.

BR,

Jukka Zitting

[Jukka Zitting]

Hi,

On Fri, Nov 20, 2009 at 10:38 AM, Julien Nioche
<lists.digitalpebble@...> wrote:
> Could we fix https://issues.apache.org/jira/browse/TIKA-271 before the
> release? I can't reopen the issue but have added a comment on it

Can you file the OpenDocumentParser problem as a separate issue
targeted for Tika 0.6? We can make the 0.6 release already next week
if this fix is needed urgently, but I'd rather not reopen the 0.5
release for that.

BR,

Jukka Zitting