You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mladen Turk <mt...@apache.org> on 2013/03/28 14:12:21 UTC

[VOTE] Release Apache Commons Daemon 1.0.15

Apache Commons Daemon 1.0.15 based on RC1 is ready.
This is bug fix release fixing both bugs and regressions
found in previous release(s).

Binaries and sources for testing are at [1], dist layout is at [2],
generated site can be found at [3]. Tag is [4] which will be renamed to
COMMONS_DAEMON_1_0_15 if voted.

Please vote (vote will remain open for at least 72 hours).

Apache Commons Daemon 1.0.15 is
   [ ] +1 Release
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...


[1] https://repository.apache.org/content/repositories/orgapachecommons-027/
[2] http://people.apache.org/~mturk/daemon-1.0.15/
[3] http://people.apache.org/~mturk/daemon-1.0.15-site/
[4] https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15_RC1/


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
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 extracted source archive. It
> does not influence the source distribution nor the functionality of the
> build.
>

Yes, I agree. This metadata entry (as Phil also said) is of no real concern.
However I'm concerned because some here said that they will refuse to vote
on such artefacts in the future. So we need to resolve this situation somehow.
I'd hate to spend useless hours on something that will be rejected in advance.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Rainer Jung <ra...@kippdata.de>.
On 03.04.2013 12:14, Jörg Schaible wrote:
> Hi Sebb,
> 
> sebb wrote:
> 
>> On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> wrote:
>>
>>> On 04/03/2013 02:21 AM, sebb wrote:
>>>
>>>> On 2 April 2013 16:25, Mladen Turk <mt...@apache.org> 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 with continuous integration. Our release version is build number
>>>>>>> in this case.
>>>>>>>
>>>>>>>
>>>>>> We configured the build to take it from the current svn number to
>>>>>> reflect
>>>>>> the unique state of the repository. An entry like
>>>>>>
>>>>>> =========== %< =============
>>>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>>>>> =========== %< =============
>>>>>>
>>>>>> will give the immediate impression, that something did go wrong with
>>>>>> the build. I'd rather drop the entry completely.
>>>>>>
>>>>>>
>>>>>>  I mean ASF is all about releasing sources. That's our primary
>>>>>>  product.
>>>>>
>>>>>
>>>> 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 handcraft from
>>> release manager.
>>>
>>>
>> It should still be possible to start from a workspace checkout of the tag,
>> rather than an unpack of the source archive.
>> The two should be identical except for the SVN files (and perhaps FOAF etc
>> that only belong in SVN).
> 
> 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 Plugin
> Built-By: oheger
> Build-Jdk: 1.6.0_30
> Implementation-Build: tags/CONFIGURATION_1_8RC1@r1236874; 2012-01-27 2
>  1:39:19+0100
> Bnd-LastModified: 1327696771177
> ============== %< ================
> 
> Either we have such information and ensure that it is proper for a released 
> jar or we drop it and ensure that someone else can reproduce the *same* 
> artifacts (hashes are equal).
> 
> [snip]

Corect. Builds are typically not binary identical. In the C world
compilers often include the compile timestamp in the binaries. In the
Java world, if you bundle Javadoc in the builds they also contain
timestamps.

So it suffices if binaries are identical except for such expected minor
differences that do not influence functionality. It might be even seen
as a good thing if a binary contains an info about its origin as shown
above.

>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 extracted source archive. It
does not influence the source distribution nor the functionality of the
build.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Emmanuel Bourg <eb...@apache.org>.
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 release a source tarball, or for projects that were never
officially released (Commons OpenPGP for example).

Btw, Commons Daemon 1.0.15 is already heading to the Debian repository :)

http://mentors.debian.net/package/commons-daemon

Emmanuel Bourg



Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
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 Plugin
> Built-By: oheger
> Build-Jdk: 1.6.0_30
> Implementation-Build: tags/CONFIGURATION_1_8RC1@r1236874; 2012-01-27 2
>   1:39:19+0100
> Bnd-LastModified: 1327696771177
> ============== %< ================
>
> Either we have such information and ensure that it is proper for a released
> jar or we drop it and ensure that someone else can reproduce the *same*
> artifacts (hashes are equal).
>

And here is the same manifest from Fedora's .rpm
(You can check any commons component. Same stuff)

Implementation-Title: Commons Configuration
Built-By: mockbuild
Tool: Bnd-1.50.0
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
....
Specification-Version: 1.9
Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-02-13 21:27:51+0000
Archiver-Version: Plexus Archiver

See the point?
Third part will always use our official source distribution. Never SVN tag.
All you guys say that users should use SVN if they don't wish crap in manifiest.
Ain't gonna happen. Sometimes they even cannot, because those automated build
tools a deep behind corporate firewalls etc.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Sebb,

sebb wrote:

> On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> wrote:
> 
>> On 04/03/2013 02:21 AM, sebb wrote:
>>
>>> On 2 April 2013 16:25, Mladen Turk <mt...@apache.org> 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 with continuous integration. Our release version is build number
>>>>>> in this case.
>>>>>>
>>>>>>
>>>>> We configured the build to take it from the current svn number to
>>>>> reflect
>>>>> the unique state of the repository. An entry like
>>>>>
>>>>> =========== %< =============
>>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>>>> =========== %< =============
>>>>>
>>>>> will give the immediate impression, that something did go wrong with
>>>>> the build. I'd rather drop the entry completely.
>>>>>
>>>>>
>>>>>  I mean ASF is all about releasing sources. That's our primary
>>>>>  product.
>>>>
>>>>
>>> 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 handcraft from
>> release manager.
>>
>>
> It should still be possible to start from a workspace checkout of the tag,
> rather than an unpack of the source archive.
> The two should be identical except for the SVN files (and perhaps FOAF etc
> that only belong in SVN).

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 Plugin
Built-By: oheger
Build-Jdk: 1.6.0_30
Implementation-Build: tags/CONFIGURATION_1_8RC1@r1236874; 2012-01-27 2
 1:39:19+0100
Bnd-LastModified: 1327696771177
============== %< ================

Either we have such information and ensure that it is proper for a released 
jar or we drop it and ensure that someone else can reproduce the *same* 
artifacts (hashes are equal).

[snip]

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi,

sebb wrote:

> On 3 April 2013 11:12, Mladen Turk <mt...@apache.org> wrote:
> 
>> On 04/03/2013 11:48 AM, sebb wrote:
>>
>>> On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> 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 handcraft
>>>> from release manager.
>>>>
>>>>
>>>>  The two should be identical except for the SVN files (and perhaps FOAF
>>> etc
>>> that only belong in SVN).
>>>
>>>
>> Says who? Take a look at APR, Httpd, Tomcat (those are the one I know)
>>
> 
> It's true of all Commons components, and JMeter and HttpComponents.
> 
> 
>>
>>  Third parties need to be able to build from the tag if they wish.
>>>
>>>
>> You said earlier:
>>
>> "building from the tag should be equivalent to building from the source
>> archive"
>>
>> This is clearly not the case with our products.
>>
> 
> It is true for the projects I am familiar with.
> 
> 
>> I'm sure infrastructure team would very pleased with the idea that our
>> main distribution media is SVN rather then maintaining all those
>> mirroring around the world ;)
>>
> 
> That's irrelevant; it does not mean that 3rd parties have to build from
> the SVN tag.
> Merely that it should be possible to do so.
> 
> Indeed that's what the CI systems (Buildr, Continuum, Jenkins) do.
> Well, they don't use a tag, but they still build from SVN.
> Which is another reason why having the SVN details is useful - it's
> possible to track the source of a snapshot build.

However, it is more than unfortunate that the manifest entry simply contains 
nonsense if it is not build from a checkout. Best would be an automated 
profile.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by sebb <se...@gmail.com>.
On 3 April 2013 11:12, Mladen Turk <mt...@apache.org> wrote:

> On 04/03/2013 11:48 AM, sebb wrote:
>
>> On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> 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 handcraft from
>>> release manager.
>>>
>>>
>>>  The two should be identical except for the SVN files (and perhaps FOAF
>> etc
>> that only belong in SVN).
>>
>>
> Says who? Take a look at APR, Httpd, Tomcat (those are the one I know)
>

It's true of all Commons components, and JMeter and HttpComponents.


>
>  Third parties need to be able to build from the tag if they wish.
>>
>>
> You said earlier:
>
> "building from the tag should be equivalent to building from the source
> archive"
>
> This is clearly not the case with our products.
>

It is true for the projects I am familiar with.


> I'm sure infrastructure team would very pleased with the idea that our
> main distribution media is SVN rather then maintaining all those mirroring
> around the world ;)
>

That's irrelevant; it does not mean that 3rd parties have to build from the
SVN tag.
Merely that it should be possible to do so.

Indeed that's what the CI systems (Buildr, Continuum, Jenkins) do.
Well, they don't use a tag, but they still build from SVN.
Which is another reason why having the SVN details is useful - it's
possible to track the source of a snapshot build.



>
>
>
> Regards
> --
> ^TM
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 04/03/2013 11:48 AM, sebb wrote:
> On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> 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 handcraft from
>> release manager.
>>
>>
> The two should be identical except for the SVN files (and perhaps FOAF etc
> that only belong in SVN).
>

Says who? Take a look at APR, Httpd, Tomcat (those are the one I know)

> Third parties need to be able to build from the tag if they wish.
>

You said earlier:
"building from the tag should be equivalent to building from the source archive"

This is clearly not the case with our products.
I'm sure infrastructure team would very pleased with the idea that our
main distribution media is SVN rather then maintaining all those mirroring around the world ;)



Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by sebb <se...@gmail.com>.
On 3 April 2013 06:56, Mladen Turk <mt...@apache.org> wrote:

> On 04/03/2013 02:21 AM, sebb wrote:
>
>> On 2 April 2013 16:25, Mladen Turk <mt...@apache.org> 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 with continuous integration. Our release version is build number in
>>>>> this case.
>>>>>
>>>>>
>>>> We configured the build to take it from the current svn number to
>>>> reflect
>>>> the unique state of the repository. An entry like
>>>>
>>>> =========== %< =============
>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>>> =========== %< =============
>>>>
>>>> will give the immediate impression, that something did go wrong with the
>>>> build. I'd rather drop the entry completely.
>>>>
>>>>
>>>>  I mean ASF is all about releasing sources. That's our primary product.
>>>
>>>
>> 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 handcraft from
> release manager.
>
>
It should still be possible to start from a workspace checkout of the tag,
rather than an unpack of the source archive.
The two should be identical except for the SVN files (and perhaps FOAF etc
that only belong in SVN).

Third parties need to be able to build from the tag if they wish.


>
>>> Perhaps we can just disable build-number plugin and have it enabled
>>> for some continuous build profile. Or at least have some 'non-error' like
>>> message in case the product is not build from SVN checkout.
>>>
>>>
>> What error message?
>> The build is not halted if the code is built from source.
>>
>>
> Yes but it produces a trash (or error) like content in manifest
> unless build from svn checkout.
>
>
>
> Regards
> --
> ^TM
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 04/03/2013 02:21 AM, sebb wrote:
> On 2 April 2013 16:25, Mladen Turk <mt...@apache.org> 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 with continuous integration. Our release version is build number in
>>>> this case.
>>>>
>>>
>>> We configured the build to take it from the current svn number to reflect
>>> the unique state of the repository. An entry like
>>>
>>> =========== %< =============
>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>> =========== %< =============
>>>
>>> will give the immediate impression, that something did go wrong with the
>>> build. I'd rather drop the entry completely.
>>>
>>>
>> I mean ASF is all about releasing sources. That's our primary product.
>>
>
> 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 handcraft from
release manager.

>>
>> Perhaps we can just disable build-number plugin and have it enabled
>> for some continuous build profile. Or at least have some 'non-error' like
>> message in case the product is not build from SVN checkout.
>>
>
> What error message?
> The build is not halted if the code is built from source.
>

Yes but it produces a trash (or error) like content in manifest
unless build from svn checkout.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by sebb <se...@gmail.com>.
On 2 April 2013 16:25, Mladen Turk <mt...@apache.org> 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 with continuous integration. Our release version is build number in
>>> this case.
>>>
>>
>> We configured the build to take it from the current svn number to reflect
>> the unique state of the repository. An entry like
>>
>> =========== %< =============
>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>> =========== %< =============
>>
>> will give the immediate impression, that something did go wrong with the
>> build. I'd rather drop the entry completely.
>>
>>
> I mean ASF is all about releasing sources. That's our primary product.
>

Indeed, but the SVN tag is supposed to be the same as the source archive.
If it's not, then I would hope this would be flagged up in the RC vote, and
likely cause a respin.

So building from the tag should be equivalent to building from the source
archive.

Everything else is just for users convenience. So the user must be
> able to build from our source distribution.
>
> Perhaps we can just disable build-number plugin and have it enabled
> for some continuous build profile. Or at least have some 'non-error' like
> message in case the product is not build from SVN checkout.
>

What error message?
The build is not halted if the code is built from source.


>
> Regards
> --
> ^TM
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
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 with continuous integration. Our release version is build number in
>> this case.
>
> We configured the build to take it from the current svn number to reflect
> the unique state of the repository. An entry like
>
> =========== %< =============
> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
> =========== %< =============
>
> will give the immediate impression, that something did go wrong with the
> build. I'd rather drop the entry completely.
>

I mean ASF is all about releasing sources. That's our primary product.
Everything else is just for users convenience. So the user must be
able to build from our source distribution.

Perhaps we can just disable build-number plugin and have it enabled
for some continuous build profile. Or at least have some 'non-error' like
message in case the product is not build from SVN checkout.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Mladen,

Mladen Turk wrote:

> On 04/02/2013 03:30 PM, Jörg Schaible wrote:
>> Hi Mladen,
>>
>> Mladen Turk wrote:
>>
>>> On 04/02/2013 09:49 AM, Jörg Schaible wrote:
>>>> Mladen Turk wrote:
>>>>
>>>>> On 03/30/2013 11:47 PM, sebb wrote:
>>>>>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>> Not sure what would be the reason to have that (SVN) info in the
>>>>>>> manifest at the first place.
>>>>>>>
>>>>>>
>>>>>> It shows that the build was done from the relevant tag.
>>>>>>
>>>>>
>>>>> mvn -DbuildNumber=1234 -DscmBranch=54678  ...
>>>>>
>>>>> It doesn't show a thing. I can put there whatever I like anyhow.
>>>>
>>>> The build-helper plugin sets the properties automatically gathering the
>>>> info from a checkout. It is not meant to be set manually.
>>>>
>>>
>>> Anyhow, IMO this metadata is useless.
>>> For example my company (and vast majority of other vendors) use source
>>> .tar.gz and produces .jar (and signs it for security purposes)
>>> This is obviously not done using SVN so we always have a UNKNOWN SCM tag
>>> inside manifest. Of course this is usually handled by invoking
>>> mvn -Prelease -Dimplementation.build="`date -R`" ...
>>>
>>> As you can see, makes no sense to have something if its easily
>>> overridden, particularly if someone thinks this is some kind of proof
>>> the binaries were build from some particular branch or tag.
>>
>> Which is a valid assumption using Maven and the build-number plugin,
>> since in Maven it is all about convention.
>>
> 
> I'm not trying to break the build convention.
> All I'm saying is that we should build from foo-src.tar.gz rather then
> from SVN. This is at least the proof of concept if our users will be able
> to build the same stuff. Otherwise make no sense to release sources if for
> building one needs to do svn export from ASF site.

This is what I normally test for different compilers before voting. Actually 
it is good, that we ensure that it builds from the distributes sources 
tarball, but as long as we deliver such automated data in the manifest, we 
should really build from a tagged checkout (that's what the Maven release 
plugin actually does).

> And BTW, build number can use multiple sources and its primary usage
> is with continuous integration. Our release version is build number in
> this case.

We configured the build to take it from the current svn number to reflect 
the unique state of the repository. An entry like

=========== %< =============
Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
=========== %< =============

will give the immediate impression, that something did go wrong with the 
build. I'd rather drop the entry completely.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 04/02/2013 03:30 PM, Jörg Schaible wrote:
> Hi Mladen,
>
> Mladen Turk wrote:
>
>> On 04/02/2013 09:49 AM, Jörg Schaible wrote:
>>> Mladen Turk wrote:
>>>
>>>> On 03/30/2013 11:47 PM, sebb wrote:
>>>>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>>>>
>>>>>
>>>>>> Not sure what would be the reason to have that (SVN) info in the
>>>>>> manifest at the first place.
>>>>>>
>>>>>
>>>>> It shows that the build was done from the relevant tag.
>>>>>
>>>>
>>>> mvn -DbuildNumber=1234 -DscmBranch=54678  ...
>>>>
>>>> It doesn't show a thing. I can put there whatever I like anyhow.
>>>
>>> The build-helper plugin sets the properties automatically gathering the
>>> info from a checkout. It is not meant to be set manually.
>>>
>>
>> Anyhow, IMO this metadata is useless.
>> For example my company (and vast majority of other vendors) use source
>> .tar.gz and produces .jar (and signs it for security purposes)
>> This is obviously not done using SVN so we always have a UNKNOWN SCM tag
>> inside manifest. Of course this is usually handled by invoking
>> mvn -Prelease -Dimplementation.build="`date -R`" ...
>>
>> As you can see, makes no sense to have something if its easily overridden,
>> particularly if someone thinks this is some kind of proof the binaries
>> were build from some particular branch or tag.
>
> Which is a valid assumption using Maven and the build-number plugin, since
> in Maven it is all about convention.
>

I'm not trying to break the build convention.
All I'm saying is that we should build from foo-src.tar.gz rather then from SVN.
This is at least the proof of concept if our users will be able to build
the same stuff. Otherwise make no sense to release sources if for building
one needs to do svn export from ASF site.

And BTW, build number can use multiple sources and its primary usage
is with continuous integration. Our release version is build number in this case.



Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Mladen,

Mladen Turk wrote:

> On 04/02/2013 09:49 AM, Jörg Schaible wrote:
>> Mladen Turk wrote:
>>
>>> On 03/30/2013 11:47 PM, sebb wrote:
>>>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>>>
>>>>
>>>>> Not sure what would be the reason to have that (SVN) info in the
>>>>> manifest at the first place.
>>>>>
>>>>
>>>> It shows that the build was done from the relevant tag.
>>>>
>>>
>>> mvn -DbuildNumber=1234 -DscmBranch=54678  ...
>>>
>>> It doesn't show a thing. I can put there whatever I like anyhow.
>>
>> The build-helper plugin sets the properties automatically gathering the
>> info from a checkout. It is not meant to be set manually.
>>
> 
> Anyhow, IMO this metadata is useless.
> For example my company (and vast majority of other vendors) use source
> .tar.gz and produces .jar (and signs it for security purposes)
> This is obviously not done using SVN so we always have a UNKNOWN SCM tag
> inside manifest. Of course this is usually handled by invoking
> mvn -Prelease -Dimplementation.build="`date -R`" ...
> 
> As you can see, makes no sense to have something if its easily overridden,
> particularly if someone thinks this is some kind of proof the binaries
> were build from some particular branch or tag.

Which is a valid assumption using Maven and the build-number plugin, since 
in Maven it is all about convention.

If we simply talk about creating that jar, I can alternatively use simply 
javac.exe, a text editor of my choice for the manifest and jar.exe to 
produce it. So the possibility to "overrride" the build process is IMHO not 
a valid argument.

As RM you're absolutely free to cut a release without the build number, but 
don't expect me any longer to give a positive vote. Just my 2¢.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 04/02/2013 09:49 AM, Jörg Schaible wrote:
> Mladen Turk wrote:
>
>> On 03/30/2013 11:47 PM, sebb wrote:
>>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>>
>>>
>>>> Not sure what would be the reason to have that (SVN) info in the
>>>> manifest at the first place.
>>>>
>>>
>>> It shows that the build was done from the relevant tag.
>>>
>>
>> mvn -DbuildNumber=1234 -DscmBranch=54678  ...
>>
>> It doesn't show a thing. I can put there whatever I like anyhow.
>
> The build-helper plugin sets the properties automatically gathering the info
> from a checkout. It is not meant to be set manually.
>

Anyhow, IMO this metadata is useless.
For example my company (and vast majority of other vendors) use source .tar.gz
and produces .jar (and signs it for security purposes)
This is obviously not done using SVN so we always have a UNKNOWN SCM tag inside
manifest. Of course this is usually handled by invoking
mvn -Prelease -Dimplementation.build="`date -R`" ...

As you can see, makes no sense to have something if its easily overridden,
particularly if someone thinks this is some kind of proof the binaries were
build from some particular branch or tag.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <Jo...@scalaris.com>.
Mladen Turk wrote:

> On 03/30/2013 11:47 PM, sebb wrote:
>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>
>>
>>> Not sure what would be the reason to have that (SVN) info in the
>>> manifest at the first place.
>>>
>>
>> It shows that the build was done from the relevant tag.
>>
> 
> mvn -DbuildNumber=1234 -DscmBranch=54678  ...
> 
> It doesn't show a thing. I can put there whatever I like anyhow.

The build-helper plugin sets the properties automatically gathering the info 
from a checkout. It is not meant to be set manually.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 03/30/2013 11:47 PM, sebb wrote:
> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>
>
>> Not sure what would be the reason to have that (SVN) info in the manifest
>> at the first place.
>>
>
> It shows that the build was done from the relevant tag.
>

mvn -DbuildNumber=1234 -DscmBranch=54678  ...

It doesn't show a thing. I can put there whatever I like anyhow.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Mladen,

Mladen Turk wrote:

> On 03/30/2013 11:59 PM, Gary Gregory wrote:
>> On Mar 30, 2013, at 18:48, sebb <se...@gmail.com> wrote:
>>
>>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>>
>>>> On 03/30/2013 09:06 PM, Jörg Schaible wrote:
>>>>
>>>> Jörg Schaible wrote:
>>>>>
>>>>>>
>>>>>> the manifest of the commons-daemon-1.0.15.jar contains a strange
>>>>>> entry:
>>>>>>
>>>>>> =========== %< =============
>>>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28
>>>>>> 13:53:43+0100 =========== %< =============
>>>>>>
>>>>>> This contains normally the subversion number. Did you built the
>>>>>> release from a checkout? It looks more like an export.
>>>> Sure I did. As always (seems the same trash is in previous versions)
>>>> I always build from export as the user would from .tar.gz
>>>
>>> It works OK if you build from a checkout (can be read-only).
>>>
>>>
>>>> Not sure what would be the reason to have that (SVN) info in the
>>>> manifest at the first place.
>>>
>>> It shows that the build was done from the relevant tag.
>>
>> I thought the Commons process was clear that building from the tag was
>> the only way to go because it is the tag we vote on.
>>
> 
> This procedure must be fixed. There are vendors out there that
> produce .jar files without using SVN, but rather our distribution
> artefacts. Does it mean that our distribution artefacts are invalid !?

No, but what we release into the Maven repository is unique. Even if some 
rebuilds the jars, the MD5/SHA1-hashes will be always different, simply 
because the manifest also includes build time, name of the current user, OS, 
...

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 03/30/2013 11:59 PM, Gary Gregory wrote:
> On Mar 30, 2013, at 18:48, sebb <se...@gmail.com> wrote:
>
>> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>>
>>> On 03/30/2013 09:06 PM, Jörg Schaible wrote:
>>>
>>> Jörg Schaible wrote:
>>>>
>>>>>
>>>>> the manifest of the commons-daemon-1.0.15.jar contains a strange entry:
>>>>>
>>>>> =========== %< =============
>>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>>>> =========== %< =============
>>>>>
>>>>> This contains normally the subversion number. Did you built the release
>>>>> from a checkout? It looks more like an export.
>>> Sure I did. As always (seems the same trash is in previous versions)
>>> I always build from export as the user would from .tar.gz
>>
>> It works OK if you build from a checkout (can be read-only).
>>
>>
>>> Not sure what would be the reason to have that (SVN) info in the manifest
>>> at the first place.
>>
>> It shows that the build was done from the relevant tag.
>
> I thought the Commons process was clear that building from the tag was
> the only way to go because it is the tag we vote on.
>

This procedure must be fixed. There are vendors out there that
produce .jar files without using SVN, but rather our distribution artefacts.
Does it mean that our distribution artefacts are invalid !?


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Gary Gregory <ga...@gmail.com>.
On Mar 30, 2013, at 18:48, sebb <se...@gmail.com> wrote:

> On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:
>
>> On 03/30/2013 09:06 PM, Jörg Schaible wrote:
>>
>> Jörg Schaible wrote:
>>>
>>>>
>>>> the manifest of the commons-daemon-1.0.15.jar contains a strange entry:
>>>>
>>>> =========== %< =============
>>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>>> =========== %< =============
>>>>
>>>> This contains normally the subversion number. Did you built the release
>>>> from a checkout? It looks more like an export.
>> Sure I did. As always (seems the same trash is in previous versions)
>> I always build from export as the user would from .tar.gz
>
> It works OK if you build from a checkout (can be read-only).
>
>
>> Not sure what would be the reason to have that (SVN) info in the manifest
>> at the first place.
>
> It shows that the build was done from the relevant tag.

I thought the Commons process was clear that building from the tag was
the only way to go because it is the tag we vote on.

Gary
>
>
>> And I cannot build the native part if an IBM JDK is the current JDK,
>>> because
>>> it does not contain a jni_md.h file.
>> Never tried with that. Don't have it, so you are free to
>> to create JIRA and propose a patch. Or you can just compile with
>> standard JDK and run on IBM's one.
>>
>>
>> Regards
>> --
>> ^TM
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by sebb <se...@gmail.com>.
On 30 March 2013 20:50, Mladen Turk <mt...@apache.org> wrote:

> On 03/30/2013 09:06 PM, Jörg Schaible wrote:
>
>  Jörg Schaible wrote:
>>
>>>
>>> the manifest of the commons-daemon-1.0.15.jar contains a strange entry:
>>>
>>> =========== %< =============
>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>>> =========== %< =============
>>>
>>> This contains normally the subversion number. Did you built the release
>>> from a checkout? It looks more like an export.
>>>
>>
>>
> Sure I did. As always (seems the same trash is in previous versions)
> I always build from export as the user would from .tar.gz
>

It works OK if you build from a checkout (can be read-only).


> Not sure what would be the reason to have that (SVN) info in the manifest
> at the first place.
>

It shows that the build was done from the relevant tag.


>  And I cannot build the native part if an IBM JDK is the current JDK,
>> because
>> it does not contain a jni_md.h file.
>>
>>
> Never tried with that. Don't have it, so you are free to
> to create JIRA and propose a patch. Or you can just compile with
> standard JDK and run on IBM's one.
>
>
> Regards
> --
> ^TM
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 03/30/2013 09:06 PM, Jörg Schaible wrote:
> Jörg Schaible wrote:
>>
>> the manifest of the commons-daemon-1.0.15.jar contains a strange entry:
>>
>> =========== %< =============
>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
>> =========== %< =============
>>
>> This contains normally the subversion number. Did you built the release
>> from a checkout? It looks more like an export.
>

Sure I did. As always (seems the same trash is in previous versions)
I always build from export as the user would from .tar.gz
Not sure what would be the reason to have that (SVN) info in the manifest at the first place.


> And I cannot build the native part if an IBM JDK is the current JDK, because
> it does not contain a jni_md.h file.
>

Never tried with that. Don't have it, so you are free to
to create JIRA and propose a patch. Or you can just compile with
standard JDK and run on IBM's one.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 03/30/2013 09:06 PM, Jörg Schaible wrote:
> Jörg Schaible wrote:
>
>
> And I cannot build the native part if an IBM JDK is the current JDK, because
> it does not contain a jni_md.h file.
>

./configure --with-java=/opt/ibm-java-x86_64-70
or
export JAVA_HOME=/opt/ibm-java-x86_64-70
./configure

and then
make

Works perfectly.

Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <jo...@gmx.de>.
Jörg Schaible wrote:

> Hi,
> 
> Mladen Turk wrote:
> 
>> 
>> Apache Commons Daemon 1.0.15 based on RC1 is ready.
>> This is bug fix release fixing both bugs and regressions
>> found in previous release(s).
>> 
>> Binaries and sources for testing are at [1], dist layout is at [2],
>> generated site can be found at [3]. Tag is [4] which will be renamed to
>> COMMONS_DAEMON_1_0_15 if voted.
>> 
>> Please vote (vote will remain open for at least 72 hours).
>> 
>> Apache Commons Daemon 1.0.15 is
>>    [ ] +1 Release
>>    [ ] +0 OK, but...
>>    [ ] -0 OK, but really should fix...
>>    [ ] -1 I oppose this release because...
>> 
>> 
>> [1]
>> [https://repository.apache.org/content/repositories/orgapachecommons-027/
>> [2] http://people.apache.org/~mturk/daemon-1.0.15/ 3]
>> [http://people.apache.org/~mturk/daemon-1.0.15-site/ 4]
>> 
> 
[https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15_RC1/
>> 
>> 
>> Regards
> 
> 
> the manifest of the commons-daemon-1.0.15.jar contains a strange entry:
> 
> =========== %< =============
> Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
> =========== %< =============
> 
> This contains normally the subversion number. Did you built the release
> from a checkout? It looks more like an export.

And I cannot build the native part if an IBM JDK is the current JDK, because 
it does not contain a jni_md.h file.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Jörg Schaible <jo...@gmx.de>.
Hi,

Mladen Turk wrote:

> 
> Apache Commons Daemon 1.0.15 based on RC1 is ready.
> This is bug fix release fixing both bugs and regressions
> found in previous release(s).
> 
> Binaries and sources for testing are at [1], dist layout is at [2],
> generated site can be found at [3]. Tag is [4] which will be renamed to
> COMMONS_DAEMON_1_0_15 if voted.
> 
> Please vote (vote will remain open for at least 72 hours).
> 
> Apache Commons Daemon 1.0.15 is
>    [ ] +1 Release
>    [ ] +0 OK, but...
>    [ ] -0 OK, but really should fix...
>    [ ] -1 I oppose this release because...
> 
> 
> [1]
> [https://repository.apache.org/content/repositories/orgapachecommons-027/
> [2] http://people.apache.org/~mturk/daemon-1.0.15/ 3]
> [http://people.apache.org/~mturk/daemon-1.0.15-site/ 4]
> 
[https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15_RC1/
> 
> 
> Regards


the manifest of the commons-daemon-1.0.15.jar contains a strange entry:

=========== %< =============
Implementation-Build: UNKNOWN_BRANCH@r??????; 2013-03-28 13:53:43+0100
=========== %< =============

This contains normally the subversion number. Did you built the release from 
a checkout? It looks more like an export.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Phil Steitz <ph...@gmail.com>.
+1 for the release.

I don't see the manifest issue as a blocker.

It would be good to get rid of the full distros pushed to maven
repos, though.  As that is technically not part of the release, I
don't see that as a blocker either.

Phil

On 3/28/13 6:12 AM, Mladen Turk wrote:
>
> Apache Commons Daemon 1.0.15 based on RC1 is ready.
> This is bug fix release fixing both bugs and regressions
> found in previous release(s).
>
> Binaries and sources for testing are at [1], dist layout is at [2],
> generated site can be found at [3]. Tag is [4] which will be
> renamed to
> COMMONS_DAEMON_1_0_15 if voted.
>
> Please vote (vote will remain open for at least 72 hours).
>
> Apache Commons Daemon 1.0.15 is
>   [ ] +1 Release
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>
> [1]
> https://repository.apache.org/content/repositories/orgapachecommons-027/
>
> [2] http://people.apache.org/~mturk/daemon-1.0.15/
> [3] http://people.apache.org/~mturk/daemon-1.0.15-site/
> [4]
> https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15_RC1/
>
>
> Regards


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Gary Gregory <ga...@gmail.com>.
+1.

Sites looks ok, Maven build ok, C++ build ok on Windows with these warnings:

        cl -c -nologo -DWIN32 -D_WIN32 -D_WINDOWS -D_WINNT
-D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -D_WIN32_IE=0x0600 -W3 -D_CONSOLE
-EHsc -D_UNICODE -DUNICODE -D
_X86_=1 -O2 -Ob2 -Oy- -Zi -DNDEBUG -D_MT -MD -I.\..\..\include
-I.\..\..\src -I "C:\Program Files\Java\jdk1.6.0_43\include" -I "C:\Program
Files\Java\jdk1.6.0_4
3\include\win32" -FoWINXP_X86_EXE_RELEASE\
-FdWINXP_X86_EXE_RELEASE\prunsrv-src .\..\..\apps\prunsrv\prunsrv.c
prunsrv.c
.\..\..\apps\prunsrv\prunsrv.c(318) : warning C4996: '_wfopen': This
function or variable may be unsafe. Consider using _wfopen_s instead. To
disable deprecatio
n, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\stdio.h(601) : see declaration of '_wfopen'
.\..\..\apps\prunsrv\prunsrv.c(342) : warning C4996: '_wfopen': This
function or variable may be unsafe. Consider using _wfopen_s instead. To
disable deprecatio
n, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\stdio.h(601) : see declaration of '_wfopen'
.\..\..\apps\prunsrv\prunsrv.c(1271) : warning C4996: '_snprintf': This
function or variable may be unsafe. Consider using _snprintf_s instead. To
disable depre
cation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\stdio.h(363) : see declaration of '_snprintf'
.\..\..\apps\prunsrv\prunsrv.c(1273) : warning C4996: '_snprintf': This
function or variable may be unsafe. Consider using _snprintf_s instead. To
disable depre
cation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
        c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\stdio.h(363) : see declaration of '_snprintf'
        rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation.  All rights reserved.

c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(54)
: warning RC4011: identifier truncated to '_CRT_SECURE_CPP_OVERLOAD_STANDA'
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\string.h(76)
: warning RC4011: identifier truncated to '_CRT_SECURE_CPP_OVERLOAD_SECURE'

My set up:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
08:51:28-0500)
Maven home: C:\Java\apache-maven-3.0.5\bin\..
Java version: 1.6.0_43, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_43\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for
80x86
Microsoft (R) Incremental Linker Version 10.00.40219.01

Gary


On Thu, Mar 28, 2013 at 9:12 AM, Mladen Turk <mt...@apache.org> wrote:

>
> Apache Commons Daemon 1.0.15 based on RC1 is ready.
> This is bug fix release fixing both bugs and regressions
> found in previous release(s).
>
> Binaries and sources for testing are at [1], dist layout is at [2],
> generated site can be found at [3]. Tag is [4] which will be renamed to
> COMMONS_DAEMON_1_0_15 if voted.
>
> Please vote (vote will remain open for at least 72 hours).
>
> Apache Commons Daemon 1.0.15 is
>   [ ] +1 Release
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>
> [1] https://repository.apache.org/**content/repositories/**
> orgapachecommons-027/<https://repository.apache.org/content/repositories/orgapachecommons-027/>
> [2] http://people.apache.org/~**mturk/daemon-1.0.15/<http://people.apache.org/~mturk/daemon-1.0.15/>
> [3] http://people.apache.org/~**mturk/daemon-1.0.15-site/<http://people.apache.org/~mturk/daemon-1.0.15-site/>
> [4] https://svn.apache.org/repos/**asf/commons/proper/daemon/**
> tags/COMMONS_DAEMON_1_0_15_**RC1/<https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15_RC1/>
>
>
> Regards
> --
> ^TM
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
On 03/28/2013 02:12 PM, Mladen Turk wrote:
>
> Apache Commons Daemon 1.0.15 is
>    [X] +1 Release
>    [ ] +0 OK, but...
>    [ ] -0 OK, but really should fix...
>    [ ] -1 I oppose this release because...
>

My vote FTR.


Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Ognjen Blagojevic <og...@gmail.com>.
On 28.3.2013 14:12, Mladen Turk wrote:
>
> Apache Commons Daemon 1.0.15 based on RC1 is ready.
> This is bug fix release fixing both bugs and regressions
> found in previous release(s).
>
> Binaries and sources for testing are at [1], dist layout is at [2],
> generated site can be found at [3]. Tag is [4] which will be renamed to
> COMMONS_DAEMON_1_0_15 if voted.
>
> Please vote (vote will remain open for at least 72 hours).
>
> Apache Commons Daemon 1.0.15 is
>    [ ] +1 Release
>    [ ] +0 OK, but...
>    [ ] -0 OK, but really should fix...
>    [ ] -1 I oppose this release because...
>


[X] +1 Release

commons-daemon-native works fine with Tomcat 7.0.39 on 64-bit Linux.

-Ognjen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Emmanuel Bourg <eb...@apache.org>.
Why do we publish the native-src.zip/.tar.gz artifacts in the Maven
repository? That seems to be just a subset of the src.zip/.tar.gz artifacts.

Emmanuel Bourg


Le 28/03/2013 14:12, Mladen Turk a écrit :
> 
> Apache Commons Daemon 1.0.15 based on RC1 is ready.
> This is bug fix release fixing both bugs and regressions
> found in previous release(s).
> 
> Binaries and sources for testing are at [1], dist layout is at [2],
> generated site can be found at [3]. Tag is [4] which will be renamed to
> COMMONS_DAEMON_1_0_15 if voted.
> 
> Please vote (vote will remain open for at least 72 hours).
> 
> Apache Commons Daemon 1.0.15 is
>   [ ] +1 Release
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> 
> [1]
> https://repository.apache.org/content/repositories/orgapachecommons-027/
> [2] http://people.apache.org/~mturk/daemon-1.0.15/
> [3] http://people.apache.org/~mturk/daemon-1.0.15-site/
> [4]
> https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15_RC1/
> 
> 
> 
> Regards



[RESULT] Was: [VOTE] Release Apache Commons Daemon 1.0.15

Posted by Mladen Turk <mt...@apache.org>.
With 3 binding votes (Gary, Phil, Mladen) and one non-binding
vote (Ognjen) I declare this vote as passed.


On 03/28/2013 02:12 PM, Mladen Turk wrote:
>
> Please vote (vote will remain open for at least 72 hours).
>

Regards
-- 
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org