Hello,
On Mon, Jul 9, 2012 at 11:46 AM, Jukka Zitting <[email protected]> wrote:
> Hi,
>
> [forking a separate discuss thread]
>
> On Mon, Jul 9, 2012 at 11:30 AM, Ard Schrijvers
> <[email protected]> wrote:
>> On Mon, Jul 9, 2012 at 10:51 AM, Bart van der Schans
>> <[email protected]> wrote:
>>> The src zip now contains a NOTICE.txt and NOTICE file as well as a
>>> LICENSE.txt as a LICENSE file.
>
> That's a consequence of using the source-release zip generated by the
> release profile as the release artifact. Even though it meets the
> formal Apache release guidelines, I'm not entirely happy with the way
> it's produced.
Well, I took a look at some other Apache project, took a look at
Jackrabbit and Oak, and thought I have the simplest project ever (just
a jar), so I thought that should be covered by the apache release
profile. Apparently not completely :)
>
> Instead, if you look at the main Jackrabbit or Oak trunk builds, there
> we have a custom assembly plugin configuration specified in the
> release profile:
>
> <plugin>
> <artifactId>maven-assembly-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>single</goal>
> </goals>
> <phase>package</phase>
> <configuration>
> <descriptors>
> <descriptor>assembly.xml</descriptor>
> </descriptors>
> </configuration>
> </execution>
> <execution>
> <id>source-release-assembly</id>
> <configuration>
> <skipAssembly>true</skipAssembly>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> Basically this overrides the default source-release assembly
> (skipAssembly=true) defined in the Apache parent POM, and replaces it
> with a custom one defined in the assembly.xml descriptor that looks
> like this:
>
> <assembly>
> <id>src</id>
> <formats>
> <format>zip</format>
> </formats>
> <fileSets>
> <fileSet>
> <directory>${project.basedir}</directory>
> <outputDirectory></outputDirectory>
> <excludes>
> <exclude>**/target/**</exclude>
> <exclude>**/.*/**</exclude>
> </excludes>
> </fileSet>
> </fileSets>
> </assembly>
>
> The idea here is to copy everything in the current checkout, excluding
> generated files, so that the source archive ends up containing an
> exact copy of the sources that were used to generate the rest of the
> release. This is IMHO a better approach than the default
> source-release assembly that treats the source archive as another
> generated artifact that'll then get to include the autogenerated
> LICENSE/NOTICE/DEPENDENCIES files, a process that was originally
> designed just for binary artifacts..
I took a look at the Jackrabbit pom but thought that one was mainly
overriding the default source-release assembly because of sources
like the jackrabbit-standalone, jackrabbit-webapp, etc. Apparently
misunderstood that part.
>
>> I am not sure how to fix this. Should I remove the LICENCE.txt and
>> NOTICE.txt from svn? Or rename them to LICENCE and NOTICE?
>>
>> Also not sure about the DEPENDENCIES. Anybody?
>
> For now I'd just leave them in. For the next release I'd recommend
> going with the separate src assembly approach described above, as
> that'll take care of this.
I will do so, see [1]
>
>> Ah, that stupid derby.log file. I already explicitly ignored it in the
>> 'pedantic' profile. Not sure what the best way is to get rid of the
>> annoying derby.log file.. ideas are welcome
>
> The best solution to the derby.log file is to add the following
> configuration setting to the maven-surefire-plugin:
>
> <configuration>
> <systemProperties>
> <property>
> <name>derby.stream.error.file</name>
> <value>target/derby.log</value>
> </property>
> </systemProperties>
> </configuration>
>
> That way the derby.log file goes into target/ and won't clutter the
> rest of the checkout.
I great, thanks for the tip! See [2]
Regards Ard
[1] https://issues.apache.org/jira/browse/OCM-62
[2] https://issues.apache.org/jira/browse/OCM-63
>
> BR,
>
> Jukka Zitting
