On 10/25/2010 2:06 PM, Marshall Schor wrote:
>
> 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.
>
So, well, this isn't quite correct. Things placed here get copied into the top
of the top project, not the top level of the archive.
That is, if the archive contains a top project TOP, the archive would have:
Archive-name
TOP
files-copied-to-top-of-the-top-project
...
LICENSE
NOTICE
etc - files at the top of the archive.
To get files to go here, using standard Apache source-release build conventions,
the files need to be placed in the
${project.build.directory}/maven-shared-archive-resources/META-INF, or a list of
files that should be copied from the project's top level to the archive top
level needs to be added to the assembly instructions.
I'll do this latter, I think.
-Marshall
> -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
>>>
>>>
>
