On 04/03/2013 08:29 PM, sebb wrote:
On 3 April 2013 11:19, Mladen Turk wrote:
Anyhow, gpg sign fails for commons-parent #28. #27 and earlier work.
First I've heard of that.
CP 28 has been used successfully elsewhere AFAIK.
It doesn't work in interactive mode. However supplying -Dgpg.pass
On 04/03/2013 08:29 PM, sebb wrote:
On 3 April 2013 11:19, Mladen Turk wrote:
Unfortunately that also detaches the archives from the hash generation
process.
So you need to add code (e.g. antrun) to create the hashes.
That's fine. I know how to use md5sum and gpg. No need for ant :)
The
On 3 April 2013 11:12, Mladen Turk wrote:
> On 04/03/2013 11:48 AM, sebb wrote:
>
>> On 3 April 2013 06:56, Mladen Turk wrote:
>>
>>>
> So building from the tag should be equivalent to building from the
source
archive.
Not necessary. Source distribution might have
On 3 April 2013 11:19, Mladen Turk wrote:
> On 04/03/2013 11:56 AM, sebb wrote:
>
>> On 3 April 2013 10:49, Mladen Turk wrote:
>>
>> On 04/03/2013 10:02 AM, Simone Tripodi wrote:
>>>
>>> Hi Mladen!
artifacts produced by the assembly-plugin can be detached from the
project
b
Same results as for the last RC, i.e. I see two test failures when
building with Java 1.5, but the build with Java 1.7 succeeds.
+1
One very minor nit: In the release notes, there are some not so nice
line breaks which make reading with a plain text editor harder as necessary.
Oliver
Am 02.
Hi,
thanks for the added tests, I could not help the last days as I am still on
Easter vacation.
Thomas
On Tue, Apr 2, 2013 at 4:21 PM, Luc Maisonobe wrote:
> Le 02/04/2013 15:55, Gilles a écrit :
> > Hello.
>
> Hi Gilles,
>
> >
> >>>
> >
> >>
> >> Votes, please.
> >> This vot
Le 03/04/2013 12:48, Mladen Turk a écrit :
> See the point?
> Third part will always use our official source distribution. Never SVN tag.
The Debian packages are usually built from the source distribution, but
sometimes a SVN tag/revision is used instead. This happens for projects
that do not rel
On 04/03/2013 12:56 PM, Rainer Jung wrote:
From reading this thread my understanding is that the only *minor*
annoyance here is, that the current build procedure includes a metadata
(manifest) entry, that *looks* broken when building not from an svn
checkout but instead from an export or an ext
On 03.04.2013 12:14, Jörg Schaible wrote:
> Hi Sebb,
>
> sebb wrote:
>
>> On 3 April 2013 06:56, Mladen Turk wrote:
>>
>>> On 04/03/2013 02:21 AM, sebb wrote:
>>>
On 2 April 2013 16:25, Mladen Turk wrote:
On 04/02/2013 05:06 PM, Jörg Schaible wrote:
>
> Mladen Turk wrot
On 04/03/2013 12:14 PM, Jörg Schaible wrote:
Hi Sebb,
This is the point: They cannot be identical, since the manifest contains
also stuff like build time, user name, JDK version (snipped):
== %<
$ catmf commons-configuration-1.8.jar
Created-By: Apache Maven Bundle P
On Wed, 03 Apr 2013 12:37:21 +0200, Gilles wrote:
On Wed, 3 Apr 2013 11:00:55 +0100, sebb wrote:
On 3 April 2013 10:23, Gilles wrote:
> Changed: luc @ Tue 2 Apr 2013 19:17:20 +
> Comment: Preparing RC5 for release 3.2.
> Files changed:
> /commons/proper/math/trunk/**pom.xml ( 1463703 )
On Wed, 3 Apr 2013 11:00:55 +0100, sebb wrote:
On 3 April 2013 10:23, Gilles wrote:
> Changed: luc @ Tue 2 Apr 2013 19:17:20 +
> Comment: Preparing RC5 for release 3.2.
> Files changed:
> /commons/proper/math/trunk/**pom.xml ( 1463703 )
It seems continuum tried to build just during the
On 04/03/2013 11:56 AM, sebb wrote:
On 3 April 2013 10:49, Mladen Turk wrote:
On 04/03/2013 10:02 AM, Simone Tripodi wrote:
Hi Mladen!
artifacts produced by the assembly-plugin can be detached from the project
by setting to `false` the `attach`[1] property.
In that way, -(src|bin)\.(zip|tar
Hi Sebb,
sebb wrote:
> On 3 April 2013 06:56, Mladen Turk wrote:
>
>> On 04/03/2013 02:21 AM, sebb wrote:
>>
>>> On 2 April 2013 16:25, Mladen Turk wrote:
>>>
>>> On 04/02/2013 05:06 PM, Jörg Schaible wrote:
Mladen Turk wrote:
>
> And BTW, build number can use multiple sou
On 04/03/2013 11:48 AM, sebb wrote:
On 3 April 2013 06:56, Mladen Turk wrote:
So building from the tag should be equivalent to building from the source
archive.
Not necessary. Source distribution might have some pre-generated code.
Many projects work like that and some even require manual
On 3 April 2013 10:23, Gilles wrote:
> > Changed: luc @ Tue 2 Apr 2013 19:17:20 +
>>> > Comment: Preparing RC5 for release 3.2.
>>> > Files changed:
>>> > /commons/proper/math/trunk/**pom.xml ( 1463703 )
>>>
>>> It seems continuum tried to build just during the few minutes the
>>> version w
On 3 April 2013 10:49, Mladen Turk wrote:
> On 04/03/2013 10:02 AM, Simone Tripodi wrote:
>
>> Hi Mladen!
>>
>> artifacts produced by the assembly-plugin can be detached from the project
>> by setting to `false` the `attach`[1] property.
>> In that way, -(src|bin)\.(zip|tar\.gz) artifacts won't b
On 04/03/2013 10:02 AM, Simone Tripodi wrote:
Hi Mladen!
artifacts produced by the assembly-plugin can be detached from the project
by setting to `false` the `attach`[1] property.
In that way, -(src|bin)\.(zip|tar\.gz) artifacts won't be deployed.
Seems exactly what I was looking for. Thanks!
On 3 April 2013 06:56, Mladen Turk wrote:
> On 04/03/2013 02:21 AM, sebb wrote:
>
>> On 2 April 2013 16:25, Mladen Turk wrote:
>>
>> On 04/02/2013 05:06 PM, Jörg Schaible wrote:
>>>
>>> Mladen Turk wrote:
And BTW, build number can use multiple sources and its primary usage
> is
> Changed: luc @ Tue 2 Apr 2013 19:17:20 +
> Comment: Preparing RC5 for release 3.2.
> Files changed:
> /commons/proper/math/trunk/pom.xml ( 1463703 )
It seems continuum tried to build just during the few minutes the
version was set to 3.2 (for doing the tag). The tag was revert to
3.2-SNPA
Hi Mladen!
artifacts produced by the assembly-plugin can be detached from the project
by setting to `false` the `attach`[1] property.
In that way, -(src|bin)\.(zip|tar\.gz) artifacts won't be deployed.
HTH!
-Simo
[1]
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach
Hi,
There's been a discussion about not deploying certain type of artifacts
to Maven repository (upon which I totally agree).
However how can this be done. Except from manually cleaning up open staging
repo of course.
It would be nice to have some sort of list which types of artifact gets deploy
The Apache Commons Daemon team is pleased to announce the commons-daemon-1.0.15
release!
Version 1.0.15 is bug fix release fixing various issues and regressions
found in 1.0.14 and previous releases.
List of fixed issues can be seen on:
https://issues.apache.org/jira/browse/DAEMON/fixforversion
23 matches
Mail list logo
