You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2012/07/09 11:46:58 UTC
[DISCUSS] Re: Release Apache Jackrabbit OCM 2.0.0
Hi,
[forking a separate discuss thread]
On Mon, Jul 9, 2012 at 11:30 AM, Ard Schrijvers
<a....@onehippo.com> wrote:
> On Mon, Jul 9, 2012 at 10:51 AM, Bart van der Schans
> <b....@onehippo.com> 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.
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 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.
> 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.
BR,
Jukka Zitting
Re: [DISCUSS] Re: Release Apache Jackrabbit OCM 2.0.0
Posted by Ard Schrijvers <a....@onehippo.com>.
Hello,
On Mon, Jul 9, 2012 at 11:46 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> [forking a separate discuss thread]
>
> On Mon, Jul 9, 2012 at 11:30 AM, Ard Schrijvers
> <a....@onehippo.com> wrote:
>> On Mon, Jul 9, 2012 at 10:51 AM, Bart van der Schans
>> <b....@onehippo.com> 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