building downloads of cleartk for non-maven users

[GoogleCodeExporter]

So, for our last release of cleartk we created a *-plus-dependencies.zip file 
which makes it easy for a non maven user to import all the dependencies 
required of cleartk into a java project.  

My thought is to add the assembly configuration file to the cleartk-examples 
project and have that project depend on all of the other projects so that all 
of the jar files find their way into the zip file.  When wrappers for GPL 
projects come along we can add a separate assembly for those projects.  

One problem with the recent solution is that the rather large zip files that 
are generated are being added to
the svn repository 'repo' folder when the "release:perform" is executed.  This 
seems rather unnecessary.

Original issue reported on code.google.com by pvogren@gmail.com on 14 Jan 2011 at 10:25

[GoogleCodeExporter]

Where is the code for the recent solution? Seems like we should just be 
creating an assembly descriptor with format "zip" and calling that from the top 
level pom. Something like:

http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/modul
e-binary-inclusion-simple.html

Original comment by steven.b...@gmail.com on 23 Jan 2011 at 2:52

[GoogleCodeExporter]

Ok, in r2343 I followed the maven instructions and created a 
cleartk-distribution project which will now create a .zip file with all the 
cleartk-* jars and all the dependencies in a lib/ directory when you run "mvn 
package". Some open issues:

* I don't know what we need in terms of a README, license info, etc. Someone 
who does can add these and fix the distribution by adding an appropriate 
fileSet. See:

http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#bin

* Because this now runs with "mvn package", it's more annoying that we have to 
run "mvn compile package" to compile (because now you have to wait for the 
distribution to be built as well). As a reminder, we have to run "mvn compile 
package" instead of just "mvn compile" because of this bug:

http://jira.codehaus.org/browse/MNG-3559

So either we:

(1) Put up with a slow (2 minutes or more) compile cycle until the bug gets 
fixed (but it's been open for almost 3 years)

(2) Move the distribution out of the normal package phase (which seems 
conceptually wrong - it really is packaging), e.g. by associating it with a 
non-default profile.

(3) Move the "test-jar" bits out of cleartk-token and cleartk-syntax and create 
real modules for these, e.g. cleartk-token-test and cleartk-syntax-test

I vote for the third option, as it would also speed up compilation by skipping 
packaging. But the second option would be less work. Thoughts?

Original comment by steven.b...@gmail.com on 24 Jan 2011 at 1:40

[GoogleCodeExporter]

re (3):  the "test jars" require that packaging occur in order for the projects 
whose tests depend on them to compile.  Is this right?  (it seems obvious now 
that I wrote it)  

(4) Here's a fourth option that I think we should consider.  What I don't like 
about (3) is that we already have a lot of projects and I hate adding two more 
for a very small amount of reuse in test code.  In fact, the only thing that is 
being reused (I think) is TokenTestBase and all that does is set up a 
TokenBuilder with the cleartk-token type system.  The respective *TestBase 
classes that inherit from TokenTestBase could simply inherit from 
CleartkTestBase and set up their own token builder.  

Original comment by phi...@ogren.info on 25 Jan 2011 at 6:04

[GoogleCodeExporter]

So I looked into this a bit more, and I think it's not the bug I pointed to 
above. Instead, I think it's a bug in the interaction between the exec:java 
plugin and the compile plugin. If we don't use the exec:java plugin, "mvn 
compile" runs just fine even with the "test-jar" dependencies. I filed a bug 
report for the exec:java plugin here:

http://jira.codehaus.org/browse/MEXEC-91

So option (5) would be to wait and see if that gets verified as a bug and fixed 
any time soon.

But I like your option (4) - it doesn't seem like it's worth adding the 
dependency for a tiny bit of token builder setup code.

Original comment by steven.b...@gmail.com on 25 Jan 2011 at 6:29

[GoogleCodeExporter]

I have just made the changes for (4) above.  I will make sure things work first 
and then commit after a meeting. 

Original comment by phi...@ogren.info on 3 Feb 2011 at 7:25

[GoogleCodeExporter]

Ok - I have removed all of the test-jar dependencies - so you should be able to 
compile cleartk with 'mvn compile' now.  We are still getting a little bit of 
weird behavior when the file cleartk-distribution-0.5.1-SNAPSHOT-bin.zip is 
created by cleartk-distribution project.  

We get a few hundred [INFO] statements that look like this:

[INFO] cleartk-distribution-0.5.1-SNAPSHOT/lib/stax-1.2.0.jar already added, 
skipping

We also get 20 or so warnings that look like this:

[WARNING] The following patterns were never triggered in this artifact 
exclusion filter:
o  'org.cleartk:cleartk-jcasgen'
o  'org.cleartk:cleartk-ml-grmm'
o  'org.cleartk:cleartk-semantic-roles'
o  'org.cleartk:cleartk-syntax-berkeley'
o  'org.cleartk:cleartk-syntax-dependency-malt'
o  'org.cleartk:cleartk-test-util'
o  'org.cleartk:cleartk-distribution'

Original comment by phi...@ogren.info on 3 Feb 2011 at 9:59

[GoogleCodeExporter]

This is all done via "mvn -Pzip package" package now, and is documented under:

http://code.google.com/p/cleartk/wiki/DeveloperFAQ#How_do_I_make_a_new_official_
ClearTK_release_for_all_modules?

Original comment by steven.b...@gmail.com on 12 Feb 2012 at 5:02

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by steven.b...@gmail.com on 5 Aug 2012 at 8:54

• Added labels: Milestone-1.2
• Removed labels: cleartk-examples