That's great! +1 from me!

This makes the development from trunk match up with the distributed binary
release! Each module will match up with a jar file in the binary release
(compared to the old releases where the binary release's structure was
very different).

Thanks Pei!

Matt


On 2012-10-17 15:34 , "Chen, Pei" <[email protected]> wrote:

>I added the first pass at the ctakes-distribution module now.  To clarify
>exactly what it will do:
>In an automated fashion, it will:
>- assemble all of ctakes module binaries (jars) into /lib (I believe this
>was the hybrid approach that was agreed upon)
>- assemble all of ctakes' transitive dependencies binaries(jars) into /lib
>- assemble the various startctakesCVD/CPE*.sh/.bat  scripts into bin
>- assemble the various README, LICENSE, RELEASE_NOTES into root /
>- assemble the various xml Descriptors into /desc
>- zip all of the above into a single
>/target/apache-ctakes-{version}-.bin.zip/tar.gz for distribution
>- zip all of the above source files into a single
>/target/apache-ctakes-{version}-.src.zip/tar.gz for distribution
>- verify the package MD5 and SHA1 signatures
>
>Note: This should be no different than what was done in the past.  It's
>just written up so that we could accomplish it with a single command line
>such as "mvn package" now.
>I believe one of the ASF requirements is that a user must be able to
>download the src files and be able to recreate the above binaries easily.
>
>Please: If you feel that this is completely off track and in the wrong
>direction, please let us know.
>
>--Pei
>
>> -----Original Message-----
>> From: Bleeker, Troy C. [mailto:[email protected]]
>> Sent: Tuesday, October 16, 2012 10:59 AM
>> To: [email protected]
>> Subject: RE: latest build instructions
>> 
>> > Let's add a ctakes-distribution module that will assemble all of the
>> individual jars, and startup scripts into a single zip and -src.zip
>>(we'll have to
>> do this as part of the Apache release anyway).  Users can probably try
>>that
>> first.
>> 
>> So you're proposing an uber JAR and also an uber ZIP? What's the
>> difference? ZIP has the source? Anything else? I'd like it not to get
>>confusing
>> with too many options. I'd also like to make sure that the contents of
>>the ZIP
>> and JAR are in the same structure as a checkout from SVN. We had
>>divergent
>> deliverables for the same release in the past between the source
>>repository
>> and the binaries.
>> 
>> Thanks
>> Troy
>> 
>> -----Original Message-----
>> From: ctakes-dev-return-628-
>> [email protected] [mailto:ctakes-dev-return-
>> [email protected]] On Behalf Of Steven
>> Bethard
>> Sent: Tuesday, October 16, 2012 9:02 AM
>> To: [email protected]
>> Subject: Re: latest build instructions
>> 
>> On Oct 16, 2012, at 1:21 AM, "Chen, Pei"
>><[email protected]>
>> wrote:
>> > I think I was pushing the boundaries with Maven in the exec scripts
>>(even
>> though it would be a cool- will have to revisit it).
>> 
>> Actually I think what you were doing is fine. It's just that anything
>>that needs
>> the jars from all the modules should be in the root pom.xml, not in a
>>sub-
>> module pom.xml.
>> 
>> Steve
>> 
>> 
>> >
>> > Let's add a ctakes-distribution module that will assemble all of the
>> individual jars, and startup scripts into a single zip and -src.zip
>>(we'll have to
>> do this as part of the Apache release anyway).  Users can probably try
>>that
>> first.
>> >
>> > --Pei
>> > ________________________________________
>> > From: Steven Bethard [[email protected]]
>> > Sent: Monday, October 15, 2012 10:09 PM
>> > To: [email protected]
>> > Subject: Re: latest build instructions
>> >
>> > On Oct 15, 2012, at 7:09 PM, "Chen, Pei"
>> <[email protected]> wrote:
>> >> We can Make the runCVD mvn install optional as the exec scripts needs
>> the jars and its dependencies to be installed somewhere in order for it
>>to
>> work.
>> >
>> > That's because at the moment it's in the
>>ctakes-clinical-pipeline/pom.xml. If
>> you put it in the root pom.xml, then all the SNAPSHOT jars will be
>>resolved in
>> their normal places (assuming you run it at a late enough phase).
>> >
>> > Steve
>

Reply via email to