On 1/25/2013 1:28 PM, Marshall Schor wrote:
> Source-release - we use the configuration from the apache-wide pom for this.
>
> It has this bit in the assembly:
>
>     <!-- license, readme, etc. calculated at build time -->
>     <fileSet>
>      
> <directory>${project.build.directory}/maven-shared-archive-resources/META-INF</directory>
>       <outputDirectory>/</outputDirectory>
>     </fileSet>
>
> So, if your build at the top level creates the right LICENSE NOTICE files and
> puts them into the .../target/maven-shared-archive-resources/META-INF spot, 
> they
> should be copied to the top level in the source assembly zip.

But as I noted in another part of this thread, the source release is unlikely to
need any customized files, so the standard ones ought to work (because the
source-release is unlikely to have anything in it other than the sources, of
course).

-Marshall
>
> -M
>
>
> On 1/25/2013 12:59 PM, Peter Klügl wrote:
>> The binaries and the top level (release) sources look fine now, but I have a
>> problem with the individual sources.
>>
>> Can someone give me a hint how to get a customized LICENSE file into the
>> sources in our build?
>> Or, a pointer how the LICENSE file is included by the maven-source-plugin.
>> Anything I did was either ignored or overridden.
>>
>> Peter
>>
>> On 25.01.2013 16:35, Marshall Schor wrote:
>>> hi - I'm digging into this.
>>>
>>> Here's what I've found so far (taking the uimaj-ep-configurator project as a
>>> sample).
>>>
>>> The build process chain includes early on the maven-remote-resources plugin.
>>> This fetches "standard" things from a standard place for the license and 
>>> notice
>>> files, puts them into
>>> .../target/maven-shared-archive-resources.
>>>
>>> The maven-remote-resources plugin runs "velocity" macro expansion; this 
>>> allows
>>> inserting at build time extra stuff.  Our Notice template (in
>>> build/trunk/uima-build-resources/src/main/resources/META-INF/NOTICE.vm) is a
>>> slight modification from the Apache-wide Notice template, in that it has an
>>> extra bit at the bottom that says, if the maven property
>>> "project.properties.postNoticeText" is set, then insert it.  We use this to
>>> modify the Notice file for things which originally had IBM copyrights which 
>>> were
>>> moved to the notice file.
>>>
>>> The documentation for the maven-remote-resources plugin says the goal we're
>>> using ("process") after running the velocity macro expansion on the 
>>> resources,
>>> they "are injected into the current (in-memory) Maven project, making them
>>> available to the process-resources phase."
>>>
>>> What you have to know to have this make sense, is that if you have
>>> (subsequently) an invocation of the maven-resources-plugin with the 
>>> "resources"
>>> goal, running in the "process-resources" phase, then that will copy the 
>>> files in
>>> .../target/maven-shared-archive-resources into the .../target/classes spot 
>>> - so
>>> the eventual JAR plugin will package these (it Jars up everything it finds 
>>> in
>>> the .../target/classes directory).
>>>
>>> So, that's how the files get to the right spot in the Jar.
>>>
>>> I think our current build process is lacking the ability to do 
>>> customization of
>>> the LICENSE file prototype.  We could modify that, to work just like the 
>>> Notice
>>> file works, to allow extending the standard LICENSE with arbitrary text.  We
>>> might want to do something different, though, in the case of large 
>>> modifications
>>> to the standard LICENSE / NOTICE files.  One thing that would probably work 
>>> is
>>> to use a copy-resources kind of step to replace/override the "standard"
>>> LICENSE/NOTICE files in ...target/classes/MEAT-INF with the custom ones from
>>> some standard spot (I would suggest using the same spot as you already 
>>> used).
>>>
>>> =====================
>>>
>>> I think the reason this hasn't come up before, is that the JARs we built 
>>> did not
>>> (normally) contain other Jars that needed special LICENSE/NOTICE files.  The
>>> things that did have that need were normally zip and tar assemblies of JARs,
>>> where we used the assembly plugin to do this packaging.
>>>
>>> I haven't looked to see what the case is with your packaging - if you're 
>>> using
>>> Assembly, then there are other conventions involving the instructions you 
>>> were
>>> following.  My guess is that you're not using assembly, so those 
>>> instructions
>>> don't help.
>>>
>>> =====================
>>>
>>> Let me know if you need help in doing something like this...
>>>
>>> -Marshall
>>>
>>> On 1/25/2013 8:40 AM, Peter Klügl wrote:
>>>> On 25.01.2013 14:02, Jörn Kottmann wrote:
>>>>> On 01/25/2013 01:13 PM, Peter Klügl wrote:
>>>>>> If I undestand that correctly, then I have to remove ANTLR and htmlparser
>>>>>> from the NOTICE/LICENSE in the top level project since they are both not
>>>>>> part of the source release. Then, I have to add NOTICE/LICENSE files 
>>>>>> (with
>>>>>> ANTLR and htmlparser) to src/main/readme/ in the top level project and to
>>>>>> the uimaj-ep-textmarker-engine project since those two binaries will 
>>>>>> contain
>>>>>> the third party libraries. The other plugins also need their own
>>>>>> NOTICE/LICENSE files in src/main/readme/ since they contain the icons. Is
>>>>>> that correct? Is there a shortcut, something that influences maven what 
>>>>>> to
>>>>>> put in those files, or which file to copy?
>>>>> +1, sounds good.
>>>> Unfortunately, this did not work. I added individual LICENSE/NOTICE files 
>>>> to
>>>> src/main/readme in uimaj-ep-textmarker-engine but the binary just contains 
>>>> the
>>>> default files and additionally files with ".txt" extension and the same
>>>> content. The -sources jar contains also only the default files.
>>>>
>>>> Any ideas?
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>>> Jörn
>>
>

Reply via email to