On 10/22/2010 3:21 PM, Marshall Schor wrote:
>> Hi,
>>
>> On Fri, Oct 22, 2010 at 7:44 PM, Marshall Schor <[email protected]> wrote:
>>> We could copy the build tooling stuff into each project we release (say, the
>>> uimaj SDK, the uima-as add-on, and our Add-ons). Then each would be
>>> independent. But we would have 3 (maybe more) copies of common build
>>> tooling to
>>> keep in sync.
>> Yeah, that's obviously not a good idea. One way to make this work
>> would be to use svn:externals settings, but that's a bit hacky.
>>
>>> Or, we could keep the build tooling separate and shared, like it is now, but
>>> impose a requirement that it be checked out and put in a particular relative
>>> path with respect to the other projects' checkout, so we could use Maven's
>>> <relativePath> element to help find the parent poms, etc. We had this
>>> approach
>>> before, but it caused problems because of the necessity to have these
>>> checkouts
>>> be in a particular relative path relationship.
>> I wouldn't use relativePath for that, simply instruct people that they
>> need to have a reasonably fresh checkouts and builds of any the
>> upstream projects.
>>
>> Using Tika as an example (even though it's a lot smaller than UIMA),
>> the tika-site component we use for managing the Tika web site has a
>> SNAPSHOT dependency to Tika trunk. Anyone working on the web site is
>> simply instructed to have a recent trunk build whenever changing the
>> site.
>>
>> Note that the Apache parent POM also sets up a snapshot repository
>> reference to repository.apache.org, so any SNAPSHOTs posted there will
>> automatically be available to all projects that inherit from that POM
>> without the need for modifying local Maven settings.
> I noticed that, but it doesn't help for initial builds on new machines, unless
> you build your build tooling, of course.
> Which you do for small projects - just have everything together :-) ...
>
> I changed our website instructions for building from trunk to reflect the two
> approaches:
> either:
>
> 1) check-out and build the build tooling (no need to fiddle settings.xml for
> Apache snapshots, because our poms use the Apache parent pom, as you note). or
>
> 2) fiddle your settings.xml to include the Apache snapshots, in which case,
> your
> build will find our projects (shared) build artifacts there.
>
> Thanks for your help. I'm now off working on getting the README to go into
> the
> right place in the source build for our top project parent pom. Looks like I
> need a build plugin step to copy it into where the source assembly wants to
> find
> the stuff that goes at the top of the source zip... so I'm adding something
> like
> this:
>
> (I show this, in case I'm doing something silly, and there's an easier / more
> obvious way to do this)
This was silly. Just putting the README at the top level was enough to get it
copied into the
source-release.zip by the assembly process, when using -Papache-release profile.
-Marshall
> <!-- to copy README files -->
> <plugin>
> <artifactId>maven-resources-plugin</artifactId>
> <executions>
> <execution>
> <id>copyReadme</id>
> <inherited>false</inherited> <!-- only run at top level -->
> <phase>process-resources</phase>
> <goals><goal>copy-resources</goal></goals>
> <configuration>
> <!-- this is where the source assembly configuration gets
> its
> files to put at the top level -->
>
> <outputDirectory>${project.build.directory}/maven-shared-archive-resources/META-INF</outputDirectory>
> <resources>
> <resource>
> <directory>./</directory>
> <includes><include>README.*</include></includes>
> </resource>
> </resources>
> </configuration>
> </execution>
> </executions>
>
> </plugin>
>
> I tried this and it seems to work...
>
> -Marshall
>>> Maybe there are other approaches too - please post suggestions :-)
>> The easy option would be to simply have all of UIMA under the same
>> trunk. That would mean a single release cycle for UIMA. But I guess
>> there are good reasons not to do that.
>>
>> BR,
>>
>> Jukka Zitting
>>
>>
>
