Tika 0.2 Release Plan

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Tika 0.2 Release Plan

David Meikle
Hi,
I am planning to create the release branch for 0.2 shortly and based on my
0.2 Release thread with Jukka I plan to do the following:

   - Based on Jukka's review of PDFBox for compliance with Apache policies
   (see https://issues.apache.org/jira/browse/PDFBOX-366) I was planning to
   remove the standalone version for the release
   - I am planning to add binary releases for this release
   - Update the formats page of the website to update some of the missing
   details.

Cheers,
Dave
Reply | Threaded
Open this post in threaded view
|

Re: Tika 0.2 Release Plan

David Meikle
Hi,

2008/11/16 Dave Meikle <[hidden email]>

>
>
>    - Based on Jukka's review of PDFBox for compliance with Apache policies
>    (see https://issues.apache.org/jira/browse/PDFBOX-366) I was planning
>    to remove the standalone version for the release
>    - I am planning to add binary releases for this release
>    - Update the formats page of the website to update some of the missing
>    details.
>
> I meant to add that I notice that there is now once outstanding JIRA Issue
TIKA-168 (https://issues.apache.org/jira/browse/TIKA-168). Looking at this I
agree with Grant that it would be better placed as a Lucene contrib, as such
I was looking to change the fix version to allow the release to progress and
further discussion to take place.
Cheers,
Dave
Reply | Threaded
Open this post in threaded view
|

Re: Tika 0.2 Release Plan

Jukka Zitting
Hi,

On Sun, Nov 16, 2008, Dave Meikle <[hidden email]> wrote:
>    - Based on Jukka's review of PDFBox for compliance with Apache policies
>    (see https://issues.apache.org/jira/browse/PDFBOX-366) I was planning
>    to remove the standalone version for the release

That's probably the best approach for now.

>    - I am planning to add binary releases for this release

Good. I guess the jar artifact generated by the Maven build would be
good enough as a released binary, or did you plan to do a more
extensive -bin packaging?

It would be nice to have the release deployed also to the central
Maven repository. Are you familiar with the way
http://people.apache.org/repo/m2-ibiblio-rsync-repository/ works?

>    - Update the formats page of the website to update some of the missing
>    details.

Excellent, thanks! No need to aim for perfection though, we can always
keep refining the documentation after the release.

> I meant to add that I notice that there is now once outstanding JIRA Issue
> TIKA-168 (https://issues.apache.org/jira/browse/TIKA-168). Looking at this I
> agree with Grant that it would be better placed as a Lucene contrib, as such
> I was looking to change the fix version to allow the release to progress and
> further discussion to take place.

Yeah, let's postpone TIKA-168 to after 0.2.

BR,

Jukka Zitting
Reply | Threaded
Open this post in threaded view
|

Re: Tika 0.2 Release Plan

David Meikle
Hi Jukka,

2008/11/17 Jukka Zitting <[hidden email]>

> Hi,
>


> >    - I am planning to add binary releases for this release
>
> Good. I guess the jar artifact generated by the Maven build would be
> good enough as a released binary, or did you plan to do a more
> extensive -bin packaging?


I was planning to add assembly descriptors for -src and -bin packages. See
diff below.


>
> It would be nice to have the release deployed also to the central
> Maven repository. Are you familiar with the way
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ works?


I am not I am afraid. I take it this is where releases get placed after they
have passed the PMC vote for release to the world.

>
> > I meant to add that I notice that there is now once outstanding JIRA
> Issue
> > TIKA-168 (https://issues.apache.org/jira/browse/TIKA-168). Looking at
> this I
> > agree with Grant that it would be better placed as a Lucene contrib, as
> such
> > I was looking to change the fix version to allow the release to progress
> and
> > further discussion to take place.
>
> Yeah, let's postpone TIKA-168 to after 0.2.
>

Done.

Cheers,
Dave

Index: src/main/assembly/src.xml
===================================================================
--- src/main/assembly/src.xml    (revision 0)
+++ src/main/assembly/src.xml    (revision 0)
@@ -0,0 +1,40 @@
+<!--
+ 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.
+-->
+<assembly>
+    <id>src</id>
+    <formats>
+        <format>tar.gz</format>
+        <format>zip</format>
+    </formats>
+
<baseDirectory>${project.artifactId}-${project.version}-src</baseDirectory>
+    <fileSets>
+        <fileSet>
+            <includes>
+                <include>LICENSE.txt</include>
+                <include>NOTICE.txt</include>
+                <include>pom.xml</include>
+                <include>HEADER.txt</include>
+                <include>README.txt</include>
+                <include>CHANGES.txt</include>
+            </includes>
+        </fileSet>
+        <fileSet>
+            <directory>src</directory>
+        </fileSet>
+    </fileSets>
+</assembly>
+

Property changes on: src/main/assembly/src.xml
___________________________________________________________________
Added: svn:eol-style
   + native

Index: src/main/assembly/bin.xml
===================================================================
--- src/main/assembly/bin.xml    (revision 0)
+++ src/main/assembly/bin.xml    (revision 0)
@@ -0,0 +1,52 @@
+<!--
+ 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.
+-->
+<assembly>
+    <id>bin</id>
+    <formats>
+        <format>tar.gz</format>
+        <format>zip</format>
+    </formats>
+    <includeSiteDirectory>false</includeSiteDirectory>
+    <fileSets>
+        <fileSet>
+            <includes>
+                <include>CHANGES.txt</include>
+        <include>README.txt</include>
+            </includes>
+        </fileSet>
+        <fileSet>
+          <directory>src/main/assembly</directory>
+          <outputDirectory></outputDirectory>
+          <includes>
+            <include>LICENSE.txt</include>
+            <include>NOTICE.txt</include>
+          </includes>
+        </fileSet>
+        <fileSet>
+            <directory>target</directory>
+            <outputDirectory></outputDirectory>
+            <includes>
+                <include>*.jar</include>
+            </includes>
+        </fileSet>
+        <fileSet>
+            <directory>target/site/apidocs</directory>
+            <outputDirectory>apidocs</outputDirectory>
+        </fileSet>
+    </fileSets>
+</assembly>
+

Property changes on: src/main/assembly/bin.xml
___________________________________________________________________
Added: svn:eol-style
   + native

Index: pom.xml
===================================================================
--- pom.xml    (revision 718403)
+++ pom.xml    (working copy)
@@ -271,27 +271,14 @@
         </configuration>
       </plugin>
       <plugin>
-        <groupId>org.apache.maven.plugins</groupId>
-        <artifactId>maven-assembly-plugin</artifactId>
-        <version>2.2-beta-2</version>
-        <configuration>
-          <descriptors>
-            <descriptor>src/main/assembly/standalone.xml</descriptor>
-          </descriptors>
-          <archive>
-            <manifest>
-              <mainClass>org.apache.tika.cli.TikaCLI</mainClass>
-            </manifest>
-          </archive>
-        </configuration>
-        <executions>
-          <execution>
-            <phase>package</phase>
-            <goals>
-              <goal>single</goal>
-            </goals>
-          </execution>
-        </executions>
+       <artifactId>maven-assembly-plugin</artifactId>
+       <configuration>
+         <descriptors>
+           <descriptor>src/main/assembly/bin.xml</descriptor>
+           <descriptor>src/main/assembly/src.xml</descriptor>
+         </descriptors>
+         <tarLongFileMode>gnu</tarLongFileMode>
+       </configuration>
       </plugin>
     </plugins>
   </build>
Reply | Threaded
Open this post in threaded view
|

Re: Tika 0.2 Release Plan

Jukka Zitting
Hi,

On Mon, Nov 17, 2008 at 11:31 PM, Dave Meikle <[hidden email]> wrote:
> 2008/11/17 Jukka Zitting <[hidden email]>
>> Good. I guess the jar artifact generated by the Maven build would be
>> good enough as a released binary, or did you plan to do a more
>> extensive -bin packaging?
>
> I was planning to add assembly descriptors for -src and -bin packages.

OK, that's fine as well.

Personally I'd just go for a packaged svn export as the source release
and the normal Maven build artifact (tika-0.2.jar) as the binary
artifact. This way the source we release would be the bits that we
have worked on and tagged in SVN instead of a build artifact, however
similar those may be in practice.

See [1] for my message on this from last year. More generally you may
want to review the threads [2] and [3] that discuss the 0.1 release.

[1] http://markmail.org/message/jnthn2q4pghqxjlc
[2] http://markmail.org/message/r3bmiwlv2vql33pe
[3] http://markmail.org/message/ks2rancq4ahd3k6z

>> It would be nice to have the release deployed also to the central
>> Maven repository. Are you familiar with the way
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ works?
>
> I am not I am afraid. I take it this is where releases get placed after they
> have passed the PMC vote for release to the world.

No, that would be /www/www.apache.org/dist/lucene/tika (I just created
the directory).

The m2-ibiblio-rsync-repository is a way for us to publish release
artifacts to the central Maven repository. There are a few ways to
handle publishing of Maven release artifacts; one way is to "mvn
deploy" the release candidate to an empty staging repository for
review during the release vote. Once the vote has passed, the staged
artifacts can then be copied to
/www/people.apache.org/repo/m2-ibiblio-rsync-repository on
people.apache.org, from where they will be automatically synced to the
central Maven repository.

See [4] and [5] for more background.

[4] http://www.apache.org/dev/release-publishing.html
[5] http://www.apache.org/dev/repository-faq.html

BR,

Jukka Zitting
Reply | Threaded
Open this post in threaded view
|

Re: Tika 0.2 Release Plan

David Meikle
2008/11/17 Jukka Zitting <[hidden email]>

> Personally I'd just go for a packaged svn export as the source release
> and the normal Maven build artifact (tika-0.2.jar) as the binary
> artifact. This way the source we release would be the bits that we
> have worked on and tagged in SVN instead of a build artifact, however
> similar those may be in practice.


Looking at this, I think I prefer the way you have described as well.


> No, that would be /www/www.apache.org/dist/lucene/tika (I just created
> the directory).
>
> The m2-ibiblio-rsync-repository is a way for us to publish release
> artifacts to the central Maven repository. There are a few ways to
> handle publishing of Maven release artifacts; one way is to "mvn
> deploy" the release candidate to an empty staging repository for
> review during the release vote. Once the vote has passed, the staged
> artifacts can then be copied to
> /www/people.apache.org/repo/m2-ibiblio-rsync-repository on
> people.apache.org, from where they will be automatically synced to the
> central Maven repository.
>

Excellent, thanks for this.

Cheers,
Dave