Re: Proposal for creating a CompositeException in ExceptionUtils

[Thomas]

I understand the use case.

But starting with JDK 7, java.lang.Throwable has

   Throwable#addSuppressed(Throwable)

   Throwable[] getSuppressed()

which would lend themselves pretty obviously to the purpose, at least if
the mechanism hasn't been disabled using the special ctor

protected Throwable(String message, Throwable cause,
    boolean enableSuppression,
    boolean writableStackTrace)

And the suppressed are printed!

So, probably, we are loading ourselves with future redundancy, aren't we?  

On 17.07.2020 20:10, Adwait Kumar Singh wrote:
> Sample use cases:
> 1. Perform multiple operations, some failed due to different reasons.
> Return a CompositeException for the failed ones.
> 2. Do a validation on some input. I want to collect all different failures,
> I can throw a CompositeException.
> 3. In some cases the exception had occurred earlier, and we want to throw
> all such exceptions. For example failures caused by Java Agent, some java
> agents store such failures. During actual execution I want to throw all
> such exceptions.
>
> Basically any such scenarios where there are multiple causes for failure
> and I want to throw all of them.
>
> On Fri, Jul 17, 2020 at 10:06 PM sebb  wrote:
>
>> What is the use case for this?
>>
>> On Fri, 17 Jul 2020 at 16:29, Adwait Kumar Singh
>>  wrote:
>>> Yes Gary, something similar. However it would differ from IOExceptionList
>>> which creates an aggregated message of all exceptions but loses the
>>> stacktrace via getCause or printStackTrace.
>>>
>>> To be precise, this is exactly what I am taking about
>>>
>> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException
>> .
>>> <
>> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
>>>
>>> Created a JIRA issue 
>> for
>>> the same.
>>>
>>> <
>> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
>>>
>>> On Fri, Jul 17, 2020 at 8:44 PM Gary Gregory 
>> wrote:
 Would it be like Common IO's IOExceptionList or Commons DBCP
 SQLExceptionList ?

 Gary

 On Fri, Jul 17, 2020 at 11:01 AM Adwait Kumar Singh <
 theadvaitkumarsi...@gmail.com> wrote:

> To be more specific, I meant a util function in ExceptionUtils. Like
 this,
> ExceptionUtils.createCompositeException(String overallErrorMessage,
> Throwable... throwables)
>
> This would return a CompositeException which would contain all the
> Throwables and whose getCause() and printStackTrace() methods have
>> been
> overridden to given out a verbose cause and stacktrace which would
>> be an
> aggregation of the throwables supplied.
>
> Pardon me if this is not the correct platform or right mechanism to
 propose
> such changes. Please let me know the correct way to proceed.
>
> Thanks,
> Adwait.
>
> On Fri, Jul 17, 2020 at 5:18 PM Adwait Kumar Singh <
> theadvaitkumarsi...@gmail.com> wrote:
>
>> Hi Commons devs,
>>
>> Use case : Ability to a single exceptions with multiple causes.
>> This
>> required in validation or initialization scenarios for example
>> when I
> want
>> to Validation/Initialization failures for multiple reasons and each
> reason
>> having a unique cause.
>> RxJava provides something similar
>> <
>> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/exceptions/CompositeException.java
>> .
>>
>> Wanted to know if this makes sense, would raise a PR if it does.
>>
>> Thanks,
>> Adwait.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

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

Re: [lang] Introduce @NonNull, and @Nullable

[Thomas]

Hi,

I'd like to point out, that there actually *is* a licensing issue
regarding @NonNull and its siblings in javax.annotations : Not with the
library, but with the prefix 'javax.'. As you might have noted, Oracle
recently closed a deal with the Eclipse Foundation, allowing the Eclipse
Foundation to step into the development of the JEE-API, under one
essential premise: They have to drop the prefix 'javax.' and Eclipse is
going to switch to the prefix 'jakarta.' instead.

Even if 'javax.annotation' & JSR-305 might not be considered part of
deal this makes one thing pretty obvious: Oracle is not going to allow
anybody else to add extend something into any of the 'javax.' packages.
And  since JSR-305 has been without development since 2012, officially
declared 'dormant', it is rather unlikely, this will be taken up again now.

So unless apache-commons is comfortable riding a dead horse, we
shouldn't pull this into any commons module.

This leaves us with 2 options:

- Wait for somebody else to step in. Maybe the good folks at Eclipse
Foundation are interested in taking that up too? They would be certainly
free to duplicate the JSR-305 annotations into the jakarta Namespace.

- Or rolling our own.

I would be in favor of the second option, as this would be easier to
control for commons. Maybe it is finally time to start modules
'annotation' and/or 'annotation-processing' within the commons-sandbox?

Thomas




On 01.02.2021 11:58, Jochen Wiedmann wrote:
> Hi,
>
> as a followup to a discussion, that we had in August 2020, I'd like to
> propose, that we introduce the @NonNull, and @Nullable annotations
> into commons-lang.
>
> Since that discussion, I began to gradually introduce those
> annotations into my own code. From that, I have learned three things:
>
>  1.) Although those annotations have RetentionPolicy.RUNTIME, they are 
> still
>   invisible at runtime. In particular, they do not impose any
> runtime requirements.
>   We *can* use those annotations, but still remain a standalone 
> library.
>  2.) There is no problem with mixed code: You can have some
> classes, that use
>   those annotations, while others don't. Or, to rephrase that:
> Even, if the ultimate
>   target should be, to use those annotations everywhere, they
> can be introduced
>   gradually on a per-class base. We can have the target as a
> long time goal, but
>   start small.
>  3.) Although the annotations aren't present in the compiled code,
> they still provide
>   valuable information, if the source code is present in the
> users IDE, because
>   the user can quickly jump into the respective file. (IDE
> support could be enhanced,
>   for example Eclipse doesn't provide them as quick hints, but
> that's something we
>   can work on.
>   Besides, static code analysis clearly *does* help (at least
> in the current case) to
>   avoid errors. In my opinion, we are the ones, who are
> setting the standards in good
>   code style, and this would clearly be an enhancement in that area).
>
> So, assuming that my proposal should be accepted: How do we proceed? I
> see two alternatives:
>
> a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> "provided" to our dependencies. The scope will guarantee, that users
> aren't affected at all.
> b) We create our own annotations, say
> org.apache.commons.lang3.annotations.NonNull, etc. When using
> Spotbugs, or the respective IDE's, we need to adjust the namespace,
> but that should be doable.
>
> Personally, I'm in favour of using the javax.annotation namespace, thus a).
>
> From my experiences, I conclude that we should also do the following:
>
> - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> a @NonNull result,
>   because in practice, they are going to be used frequently. (In
> cases, where the compiler
>   doesn't understand, that a value is, in fact, not nullable.)
> - Convince the maintainers of the maven-compiler-plugin, that use of
> those annotations
>   is something, that should be documented in the plugin configuration.
> If that is given,
>   then IDE's might configure themselves automatically without the need
> for IDE specific
>   files.
>
>
> Jochen
>
>
> 1.)
>

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

Re: [all] Binaries for example modules

[Thomas]

Maybe a bit late in the game, but still:

In face of the fact, that we are already looking at a multi module project:

Having all the examples within a dedicated module added into the 
hierarchy would allow us, to have it all, and still without burdening 
the RM:


- keeping the examples current by compiling and executing/testing them 
during releases


- maintaining arbitrary links from other modules sites/javadoc into the 
site generated by the examples


- we may still avoid to distribute some of their artifacts, especially 
the binaries, by simply excluding them from install/deploy/release 
steps, which could done by properly configuring the 
install/deploy/release plugins within the examples pom. It shouldn't 
even be necessary, to have a profile for that.


Just my 2 cents.

The only thing, that might be of interest is the question, whether as 
part of the process, the examples module should produce and release kind 
of a source artifact, containing the *complete* source (with pom, 
src/main/** etc), or  if we point the users simply to the version 
control URL, where they might check it out.


Regards,

Thomas


On 09.08.2021 13:22, Matt Juntunen wrote:

Advertising
the examples at a higher level in the project site is better, so adding
them to the user guide is an appropriate place. The question then is should
the higher location point the user to the module site index, recommend
downloading the source release which contains all the examples (and not
having the module site published), or both.

I would say both.


I do not think pushing the artifacts to Maven Central is useful

+1. I think we're all agreed on this point.

-Matt J

On Sun, Aug 8, 2021 at 5:38 PM Alex Herbert  wrote:

On Fri, 6 Aug 2021 at 04:01, Gilles Sadowski  wrote:


Le ven. 6 août 2021 à 04:01, Matt Juntunen  a
écrit :

Gilles,


I do _not_ ask any work to be done in order to complicate the release
process and/or review.
My question was (cf. above and the other thread) whether singling out
the "examples" module has any benefit (apart from saving a few bytes
on Maven Central).

Yes, I believe it is beneficial. If nothing else, it keeps maven
central and the project site uncluttered and reduces the chance of
user confusion.

I do not see where the problem is supposed to be (with Maven Central).
But, either way, it's not worth fighting over it, as long as the examples
are kept in sync with the code (and this is done at the lastest as part
of the current release process).  [The counter-example is "Commons
Math", where the code examples were not kept up to date with the
main code...]
For the site, I believe that the examples should be there, as they are
show-cases (for users!) of fully-working applications.[1]


I do not think that the layout of the site for maven modules is very
friendly for browsing the source. You are required to traverse down the
hierarchy to the module site index, then click the project reports link
then either the javadoc or xref reports. It takes a lot of finding and may
not be found at all by a new user of the modular site layout. Advertising
the examples at a higher level in the project site is better, so adding
them to the user guide is an appropriate place. The question then is should
the higher location point the user to the module site index, recommend
downloading the source release which contains all the examples (and not
having the module site published), or both.

I do not think pushing the artifacts to Maven Central is useful as the
applications are either developer testing tools or integration test demos.
These are not of use to be linked by a third party as a dependency, and
given they have no binary compatibility guarantee it would be unwise to
depend on them anyway.



Gilles

[1] See e.g.
https://commons.apache.org/proper/commons-rng/commons-rng-examples/commons-rng-examples-quadrature/xref/index.html

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



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



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

Re: New component proposal: commons-plugins

[Thomas]

On 11.04.2022 00:00, Ralph Goers wrote:

See below


On Apr 8, 2022, at 9:23 AM, Peter Verhas  wrote:

Thanks Ralph for the detailed explanation. I appreciate it and now I see
the points.

I’ve removed the parts that I don’t think need any more discussion.


- How will it be a “plugin" project and not another dependency injection
framework?

This is a great question. I think the main difference is with examples like 
Log4j
and Apache Flume, and even Apache Maven. All wire components together via
user provided configuration, not code. Dependency injection could certainly be
part of the plugin framework but that would be for implementors of plugins,
not the users using them. Users of Maven don’t know that Plexus is used under
the covers and neither should users of a commons-plugins implementation.


- What will distinguish it from module systems, like OSGi and what will
stop it from becoming another OSGi by the years as new features get added
to the library.

OSGi is complicated. Implementing plugins should not be. Just as I described
using ServiceLoader to locate plugins, plugins should also be accessible in
OSGi bundles. Users should be required to do as little as possible to adapt the
plugin system to the environment it is running in*but plugins shouldn’t know or care anything about how they are 
located and loaded.*  Plugins are also to the

application or framework that will be using them. They essentially define what
the valid plugin types are and where they can be used.


This is impossible. The bare minimum, any system or artifact has to do, 
to be recognized as a plugin, is advertising itself as one. That would 
be true, even if your service locator is crawling through every class of 
the classloader it can get hold of to determine, whether it is a 
candidate to consider.


- OSGI does this by parsing the MANIFEST and OSGI-INF

- Spring uses a combination of XML and crawling annotations and packages

Every other CDI framework does it similar to these two, most of them 
heavily reliying on XML- or property based configuration too. With one 
notable exception: the dreaded ServiceLoader mechanism, which fixes this 
during compile time in the module-info, if you use JPMS, else mapping it 
in META-INF/services with simple plain text files, that require no 
parsing other then getting the line breaks right - no reflection / 
premature loading required. (Which btw, I think is the slickest solution 
so far, as it does make service discovery very cheap for small systems, 
with few class path entries. Complication is inevitably the result of 
large classpaths, that require plugin arbitration to resolve ambiguities 
and filtering)


So no: at the very least, a plugin has to know, by what plugin system it 
is going to be loaded. And - a different hyperbole: because of this, 
apache commons has started to introduce the attributes required by OSGi 
into the MANIFESTs of many of its components, just to bridge the gap, 
and to aleviate the need to for OSGi-Users to introduce wrappers.


For me, this will be all well and fine, as long as none of the current 
or future apache commons artefacts will  become unusable unless I also 
put commons-plugin or some arcane configuration parser into the class path.

Re: New component proposal: commons-plugins

[Thomas]

Users should be required to do as little as possible to adapt the
plugin system to the environment it is running in*but plugins shouldn’t know or 
care anything about how they are located and loaded.* Plugins are also to the
application or framework that will be using them. They essentially define what
the valid plugin types are and where they can be used.

This is impossible. The bare minimum, any system or artifact has to do, to be 
recognized as a plugin, is advertising itself as one. That would be true, even 
if your service locator is crawling through every class of the classloader it 
can get hold of to determine, whether it is a candidate to consider.

- OSGI does this by parsing the MANIFEST and OSGI-INF

- Spring uses a combination of XML and crawling annotations and packages

Every other CDI framework does it similar to these two, most of them heavily 
reliying on XML- or property based configuration too. With one notable 
exception: the dreaded ServiceLoader mechanism, which fixes this during compile 
time in the module-info, if you use JPMS, else mapping it in META-INF/services 
with simple plain text files, that require no parsing other then getting the 
line breaks right - no reflection / premature loading required. (Which btw, I 
think is the slickest solution so far, as it does make service discovery very 
cheap for small systems, with few class path entries. Complication is 
inevitably the result of large classpaths, that require plugin arbitration to 
resolve ambiguities and filtering)

So no: at the very least, a plugin has to know, by what plugin system it is 
going to be loaded. And - a different hyperbole: because of this, apache 
commons has started to introduce the attributes required by OSGi into the 
MANIFESTs of many of its components, just to bridge the gap, and to aleviate 
the need to for OSGi-Users to introduce wrappers.

For me, this will be all well and fine, as long as none of the current or 
future apache commons artefacts will  become unusable unless I also put 
commons-plugin or some arcane configuration parser into the class path.

I never said a plugin shouldn’t know it is a plugin. Providing the manifest 
entries required to make a component usable in an OSGi environment doesn’t mean 
the Plugin has to know it is being used in a an OSGi environment. Likewise, 
providing a module-info.java doesn’t mean the plugin will be used as part of a 
module on a module path. Using Log4j as an example once again, its Plugins know 
that they are a Filter, Appender, Lookup, Layout, or whatever. But they have no 
knowledge of how they were loaded. They DO know that they are being used by 
Log4j for a specific purpose and what contract they have to implement for that, 
but that is exactly what plugins are for.

So I guess Log4j is doing the impossible?

... only if your Log4J plugins would be automagically recognised as 
regular plugins by other frameworks, ranging from OSGi, to Spring, CDI, 
Jakarta, Plexus, Avalon, Netbeans, JMeter, ANT, Gradle, ... without 
adding the required plugin descriptors these systems need to find it. It 
probably wouldn't. In IT and programming, to know generally means, to 
directly refer to it. In this case: to refer to the plugin 
infrastructure supported. So your plugin is plugin, not just because it 
has the string 'plugin', somewhere in the documentation; it's not just 
any plugin, but a Log4J plugin, and knows it. No magic there.


BTW.: I can see, that there may be some need to add some convenience to 
the bare ServiceLoader mechanism, in order to standardise/support some 
version/feature/provider negotiation in certain corner cases. I would 
even see usecases for that in commons components like vfs, encoding, 
compress etc, that are meant to offer a facade to plugable 
implementations of a certain family.


But I don't think, there is a need to support an other full fledged 
module or plugin framework with features like dependency injection, 
component lifecycle management, interceptor chains, not to speak of 
interpolating configuration values from sources outside of Java. Even 
less do I feel the need to have an abstraction layer that enables us to 
swap out say, CDI for Spring or OSGi. Don't tempt me to cite XKCD 927 on 
you!


Cheers, Thomas


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

Re: Is there a need for a commons-physics project?

[Thomas]

Maybe start small, with a universally usable prerequisite:

something like commons-unit as an implementation of javax.measure.

See:

https://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/class-use/Unit.html

| javax.measure 
unit-api 1.0  
Even if not used for physics projects, it might still be very usefull 
for dev-ops / JMX / SNMP measurements, and certain business 
applications. Downside: there are already implementations out there. 
Else, I find it extremely difficult, to select the topics addressed in 
something simply called 'physics'. You might end up trying to 
reimplement Mathematica with Java. |


On 17.07.2023 03:55, Dimitrios Efthymiou wrote:

RE: Re: [IO] Suggestion for AbstractFileComparator

[Thomas]

Sorry to barge in, several things here:

I love the JDK. At the very least, you could say, that 
'IllegalStateException' is the appropriate name in this case, as it 
purveys the fact, that the results might fail to fulfill the contract. 
UncheckedIoException doesn't do that. Pretty subtle! ;-)  I would 
expect, that the IOException would be nested as cause.


In the greater scheme of things, the 'unexpected' has its ways to mess 
up things. RuntimeExceptions are Java's way of accepting, that the 
unexpected actually exists. That is, why I would actually advocate, to 
move away from the 'UncheckedIoException' in this case, and instead use 
the IllegalStateException - and of course, nest the cause.


The missingFilesFirst/Last()  methods are a good idea, only, that I 
wouldn't start with 'missingFiles', but rather something like 
'inaccessibleFiles' - because, appart from not being there, various 
other reasons could lead to an exception - missing permissions, or 
IO-errors to name two.


Catching this, you now have the problem, that you are depriving the user 
of choice, because he actually might _want_ the Comparator to fail, if 
the read fails.


So you might have have several mutually exclusive "access failure 
policies" here:


inaccessibleFilesFirst/Last()

   failIfInaccessible() -- using a fixed exception, I would suggest 
IllegalStateException, as argued above.


But you could also do

failIfInaccessible(Function exceptionFactory)

which would allow the user to inject his own favorite wrapper exception.

But we are still not in the clear, because the class and its use in a 
sort has the potential to mess up things even without throwing any 
exception. As unlikely as it sounds, if some process in the background 
is constantly touching the sorted files, the sort could produce an 
ordering, that never existed on the disk - I'm not quite certain, what 
will happen, when during sorting a file time stamp will get read a 
second time with a changed value. Incomplete sorting? Maybe an infinite 
loop?


You could prevent this, by caching the result of the lastModified 
timestamp for the duration of the sort - but then the documentation has 
to make absolutely clear, that the comparator is no longer light-weight 
constant, and should be discarded after the sort.


This could also used as an opportunity to safeguard against the 
situation: by throwing another exception, if such a change was detected.


Having choice, you still have the possibility to reuse code, without 
giving up control, and inadvertently hiding problems.


Just my thoughts.

Thomas

On 2023/12/03 12:29:40 Elliotte Rusty Harold wrote:
> On Sat, Dec 2, 2023 at 12:01 AM Miguel Muñoz  wrote:
> >
> > @Elliotte Rusty Harold,
> > I'd like to make two unrelated points.
> > 1. I wasn't suggesting the missingFilesFirst() or 
missingFilesLast() methods as a solution to the issues raised in IO-813 
LastModifiedFileComparator should not throw exceptions, period. I just 
thought these methods would be useful for cases where the users needs to 
sort file collections where some files might not be valid anymore. This 
could easily arise in cases that are unrelated to the issue in IO-813.

>
> Yes, I agree. I suspect this can also happen in a case where a file
> never existed. Java Path and File objects do not guarantee the
> existence of the file pointed to. It's just a name that might or might
> not correspond to a file. I do suspect that missingFilesFirst() or
> missingFilesLast() are overkill. We should pick one behavior and make
> it always work that way.
>
> > 2. As for your point about external conditions changing the code, I 
would like to point out that working with a file system is hardly the 
only place where developers will encounter this problem.

>
> Absolutely. Every case where this can happen is another place where a
> checked exception is needed. I/O is the most common example, but there
> are others.
>
> That said, threads are *not* such a case because they are completely
> internal to the program. Concurrency failures within a program are
> bugs that can and should be fixed by the devs who maintain that
> program. Having fixed such a bug, the exception should not be able to
> occur. Bug free concurrent programming is hard. Personally I'm bad at
> it. But it is possible. I/O error free programming in programs that
> access the file system is not possible.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

--
Cheers, Thomas


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

Re: [numbers][GSoC] Slack for GSoC mentees

[Mark Thomas]

On 01/05/2019 21:38, Eric Barnhill wrote:
> Actually some objections have been raised to using Slack because it is not
> open source. So the options will be either zulipchat if a group of people
> want to use it, or Riot if it is just me.

Better stop using GitHub as well then.

There is no ASF policy that requires the tools we use to be open source.

There is an ASF slack instance - you could request (create?) a
commons-gsoc channel there.

Mark


> 
> Thanks, Eric
> 
> On Wed, May 1, 2019 at 1:20 PM Eric Barnhill  wrote:
> 
>> I am going to set up a Slack to communicate with my GSoC mentees.
>>
>> I know official policy is to communicate on this list, but especially with
>> small setup questions the mentees might have, or gaps in their knowledge,
>> that will create unnecessary spam for everyone. Larger-scale decisions will
>> be posted here so they are on the record.
>>
>> I didn't know what scope to make this Slack. So I called it
>> apachecommonsnumbers.slack.com . If more people in commons are interested
>> in this idea, I could change its name to apachecommons.slack.com, and we
>> could all set up our own channels on it. It's free if that concerns anyone.
>>
>> Give me a +1 if you want to use it and I will invite you. Otherwise it
>> will be lonely, just me and my mentees. :)
>>
> 


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

Re: [VFS] Deleting the git branch 'trunk'

[Mark Thomas]

On 01/05/2019 21:48, Gary Gregory wrote:
> On Wed, May 1, 2019 at 3:54 PM Gary Gregory  wrote:
> 
>> I created https://issues.apache.org/jira/browse/INFRA-18316
>>
> 
> And the work is done. Note that open PRs on trunk have been closed
> automatically, so they would need to be re-opened.

Note that as far as I can tell, the trunk branches have not been removed
from gitbox (because trunk branches are automatically protected).

I recommend leaving them on gitbox in case someone realises in a week or
two that there is some work on trunk that isn't anywhere else.

I suspect we can quietly forget about the trunks on gitbox but if they
do become an issue, I can remove them from there as well.

Mark


> 
> Gary
> 
> 
>>
>> Gary
>>
>> On Wed, May 1, 2019 at 3:55 AM Benedikt Ritter  wrote:
>>
>>> Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
>>> garydgreg...@gmail.com>:
>>>
 Should we take a broader stroke and remove ALL trunk branches from all
 Commons git repos?

>>>
>>> I think we should remove all trunk branches from git repos.
>>>
>>>

 Gary

 On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler 
 wrote:

> Probably need INFRA
>
>
> On April 29, 2019 at 11:23:38, Gary Gregory (garydgreg...@gmail.com)
> wrote:
>
> On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory >>>
> wrote:
>
>> Well, crud, neither these works:
>>
>> C:\git\commons-vfs>git push origin --delete trunk
>> remote: Rewinding refs/heads/trunk is forbidden.
>> remote:
>> To https://gitbox.apache.org/repos/asf/commons-vfs
>> ! [remote rejected] trunk (pre-receive hook declined)
>> error: failed to push some refs to '
>> https://gitbox.apache.org/repos/asf/commons-vfs'
>>
>> C:\git\commons-vfs> git push origin :trunk
>> remote: Rewinding refs/heads/trunk is forbidden.
>> remote:
>> To https://gitbox.apache.org/repos/asf/commons-vfs
>> ! [remote rejected] trunk (pre-receive hook declined)
>> error: failed to push some refs to '
>> https://gitbox.apache.org/repos/asf/commons-vfs'
>>
>> Thoughts?
>>
>
> BTW, I had deleted the branch locally OK with 'git branch -d trunk'
>
> Gary
>
>
>>
>> Gary
>>
>> On Mon, Apr 29, 2019 at 11:11 AM Rob Tompkins 
> wrote:
>>
>>> +1
>>>
 On Apr 29, 2019, at 10:58 AM, Otto Fowler <
>>> ottobackwa...@gmail.com>
>>> wrote:

 +1


 On April 29, 2019 at 08:01:43, Gary Gregory (
>>> garydgreg...@gmail.com
 )
>>> wrote:

 I am going to delete the branch 'trunk'.

 It's too confusing.

 Gary
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>

>>>
>>
> 


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

Re: [numbers][GSoC] Slack for GSoC mentees

[Mark Thomas]

On 01/05/2019 21:54, Eric Barnhill wrote:
> On Wed, May 1, 2019 at 1:49 PM Mark Thomas  wrote:
> 
>> On 01/05/2019 21:38, Eric Barnhill wrote:
>>> Actually some objections have been raised to using Slack because it is
>> not
>>> open source. So the options will be either zulipchat if a group of people
>>> want to use it, or Riot if it is just me.
>>
>> Better stop using GitHub as well then.
>>
>> There is no ASF policy that requires the tools we use to be open source.
>>
>>
> Thanks for clarifying.
> 
> 
>> There is an ASF slack instance - you could request (create?) a
>> commons-gsoc channel there.
>>
> 
> Knock me over with a feather. This not appear to be mentioned at
> community.apache.org .  Is it asf.slack.com?

the-asf.slack.com
There is already a commons channel. I think you can create commons-gsoc
if you need it. If not, I look to be able to create channels. Just ping me.

Mark

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

Re: [numbers][GSoC] Slack for GSoC mentees

[Mark Thomas]

On 01/05/2019 22:09, Eric Barnhill wrote:
> Thanks Mark,
> 
> It looks like an apache.org domain email is required to register, and I
> don't think my mentees are going to have one of those, so I may still open
> a Zulip on the side. I am happy to have joined the commons slack there
> though!

You should be able to invite folks without @apache.org addresses

Mark


> 
> Eric
> 
> On Wed, May 1, 2019 at 1:58 PM Mark Thomas  wrote:
> 
>> On 01/05/2019 21:54, Eric Barnhill wrote:
>>> On Wed, May 1, 2019 at 1:49 PM Mark Thomas  wrote:
>>>
>>>> On 01/05/2019 21:38, Eric Barnhill wrote:
>>>>> Actually some objections have been raised to using Slack because it is
>>>> not
>>>>> open source. So the options will be either zulipchat if a group of
>> people
>>>>> want to use it, or Riot if it is just me.
>>>>
>>>> Better stop using GitHub as well then.
>>>>
>>>> There is no ASF policy that requires the tools we use to be open source.
>>>>
>>>>
>>> Thanks for clarifying.
>>>
>>>
>>>> There is an ASF slack instance - you could request (create?) a
>>>> commons-gsoc channel there.
>>>>
>>>
>>> Knock me over with a feather. This not appear to be mentioned at
>>> community.apache.org .  Is it asf.slack.com?
>>
>> the-asf.slack.com
>> There is already a commons channel. I think you can create commons-gsoc
>> if you need it. If not, I look to be able to create channels. Just ping me.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


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

Re: [daemon] release 1.1.1?

[Mark Thomas]

On 03/05/2019 13:59, Gary Gregory wrote:
> Hi Mark and All:
> 
> I've seen a lot of commits lately in Daemon from Mark T.
> 
> Are you planning a release?

I am starting to think in that direction. There are still a handful of
Jira issues I want to look at first.

Given past experience with the Commons release process, I'd avoid it if
I could but that isn't an option in this case.

Mark

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

Re: [daemon] release 1.1.1?

[Mark Thomas]

On 03/05/2019 14:20, Rob Tompkins wrote:
>> On May 3, 2019, at 9:18 AM, Mark Thomas  wrote:
>>
>>> On 03/05/2019 13:59, Gary Gregory wrote:
>>> Hi Mark and All:
>>>
>>> I've seen a lot of commits lately in Daemon from Mark T.
>>>
>>> Are you planning a release?
>>
>> I am starting to think in that direction. There are still a handful of
>> Jira issues I want to look at first.
>>
>> Given past experience with the Commons release process, I'd avoid it if
>> I could but that isn't an option in this case.
> 
> Let me know if you want me to do the release dirty work. I’d be happy to.

Thanks. I suspect I'll need to do at least the creation of the Windows
binaries a) because of the build environment and b) because they need to
be signed.

If you are able to answer questions as I go that will hopefully ease
most of the pain.

It looks like I updated the "HOWTO-RELEASE" when I did the last Daemon
release. That should mean the only difficulties are process changes
since ~Nov 2017.

Mark

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

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[Thomas Vandahl]

On 24.05.19 12:33, Gary Gregory wrote:
> -1
> 
> We are now on gitbox https://gitbox.apache.org/repos/asf/commons-jcs.git
> 

When did that happen? I don't remember an announcement or a vote.

Bye, Thomas


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

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[Thomas Vandahl]

On 26.05.19 15:54, sebb wrote:
> Jan 2019
> 
> https://lists.apache.org/thread.html/053bb8f18e90800d918956f69364167b23c0cdca175568300b1108f6@%3Cdev.commons.apache.org%3E

Ok, I missed that one completely.
What do I have to do?

Bye, Thomas


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

Re: svn commit: r1859859 [1/5] - in /commons/proper/jcs/trunk/commons-jcs-core/src: main/java/org/apache/commons/jcs/ main/java/org/apache/commons/jcs/access/ main/java/org/apache/commons/jcs/admin/ m

[Thomas Vandahl]

On 27.05.19 10:21, sebb wrote:
> Either re-apply each of the commits in turn to Git.
Done.

Bye, Thomas

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

Re: [daemon] release plans

[Mark Thomas]

On 12/06/2019 14:09, Gary Gregory wrote:
> Hi All:
> 
> I am pleased to see renewed activity in Commons Daemon.
> 
> Are there any release thoughts?

https://commons.markmail.org/thread/qklsh7jg3qwo2uf3

Mark

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

Re: [daemon] release plans

[Mark Thomas]

On 12/06/2019 14:23, Mark Thomas wrote:
> On 12/06/2019 14:09, Gary Gregory wrote:
>> Hi All:
>>
>> I am pleased to see renewed activity in Commons Daemon.
>>
>> Are there any release thoughts?
> 
> https://commons.markmail.org/thread/qklsh7jg3qwo2uf3

I've addressed the issues I plan to before the next release.

I'm going to start the release process shortly. I may get to the point
where I tag later today but more likely early next week.

If anyone else has an DAEMON itch they want to scratch now would be a
really good time to do so.

Mark

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

Re: [daemon] release plans

[Mark Thomas]

On 14/06/2019 20:31, Gary Gregory wrote:
> This one: https://github.com/apache/commons-daemon/pull/11

Review for what? Looks pretty uncontroversial to me.

Mark


> 
> Gary
> 
> On Fri, Jun 14, 2019, 15:24 Gary Gregory  wrote:
> 
>> I created a PR a couple of days ago that needs a review.
>>
>> Gary
>>
>> On Fri, Jun 14, 2019, 12:34 Mark Thomas  wrote:
>>
>>> On 12/06/2019 14:23, Mark Thomas wrote:
>>>> On 12/06/2019 14:09, Gary Gregory wrote:
>>>>> Hi All:
>>>>>
>>>>> I am pleased to see renewed activity in Commons Daemon.
>>>>>
>>>>> Are there any release thoughts?
>>>>
>>>> https://commons.markmail.org/thread/qklsh7jg3qwo2uf3
>>>
>>> I've addressed the issues I plan to before the next release.
>>>
>>> I'm going to start the release process shortly. I may get to the point
>>> where I tag later today but more likely early next week.
>>>
>>> If anyone else has an DAEMON itch they want to scratch now would be a
>>> really good time to do so.
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
> 


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

Re: [daemon] release plans

[Mark Thomas]

On 14/06/2019 20:39, Gary Gregory wrote:
> On Fri, Jun 14, 2019 at 3:36 PM Mark Thomas  wrote:
> 
>> On 14/06/2019 20:31, Gary Gregory wrote:
>>> This one: https://github.com/apache/commons-daemon/pull/11
>>
>> Review for what? Looks pretty uncontroversial to me.
>>
> 
> I've not taken the time to setup my new laptop to build the C part of this
> project. So instead of asking for a review, I should have asked "Did I
> break the compile or cause runtime error?"

Ah. Right. Let me fire up my VM and check...

Mark

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

Re: [daemon] release plans

[Mark Thomas]

On 14/06/2019 20:43, Mark Thomas wrote:
> On 14/06/2019 20:39, Gary Gregory wrote:
>> On Fri, Jun 14, 2019 at 3:36 PM Mark Thomas  wrote:
>>
>>> On 14/06/2019 20:31, Gary Gregory wrote:
>>>> This one: https://github.com/apache/commons-daemon/pull/11
>>>
>>> Review for what? Looks pretty uncontroversial to me.
>>>
>>
>> I've not taken the time to setup my new laptop to build the C part of this
>> project. So instead of asking for a review, I should have asked "Did I
>> break the compile or cause runtime error?"
> 
> Ah. Right. Let me fire up my VM and check...

All good.

What I did notice while testing is that you didn't reformat all of the
messages.

Mark

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

[VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

It has been ~18 months since the last Commons Daemon release. After the
recent flurry of activity, I think we are ready for a release.

Notable changes include:
- Improved JRE/JDK detection to support increased range of both JVM
  versions and vendors.
- Procrun. Change the default service from LocalSystem to
  'NT Authority\LocalService'

The full set of changes is in the changelog

1.1.1 can be obtained from (r34537):
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
4319f482e1ff6ea7655e1377120750fd6ecc3810

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1441/

The Windows binaries have been signed by the Symantec code signing service.



[ ] Approved - go ahead and release Commons Daemon 1.1.1
[ ] Broken   - do not release because...

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

Re: [VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

On 17/06/2019 15:58, Gary Gregory wrote:
> The version in the release notes at the top still says "1.1" instead of
> "1.1.1".

My understanding was they referred to 1.1.x (i.e. all of the 1.1
releases) so the version number was appropriate.

> It seems to me that 1.2 would be more appropriate since we upgraded both
> the Java and OS requirements.

No we didn't. See the changelog. The Java and OS requirements are the
same for 1.1.1 as they are for 1.1.0.

Mark


> 
> Gary
> 
> On Mon, Jun 17, 2019, 08:13 Mark Thomas  wrote:
> 
>> It has been ~18 months since the last Commons Daemon release. After the
>> recent flurry of activity, I think we are ready for a release.
>>
>> Notable changes include:
>> - Improved JRE/JDK detection to support increased range of both JVM
>>   versions and vendors.
>> - Procrun. Change the default service from LocalSystem to
>>   'NT Authority\LocalService'
>>
>> The full set of changes is in the changelog
>>
>> 1.1.1 can be obtained from (r34537):
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>
>> The git tag is:
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>> <https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810>
>>
>> The Maven Staging repo is:
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>
>> The Windows binaries have been signed by the Symantec code signing service.
>>
>>
>>
>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>> [ ] Broken   - do not release because...
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


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

Re: [VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

On 18/06/2019 14:20, Gary Gregory wrote:
> Also, while we even discussed PR
> https://github.com/apache/commons-daemon/pull/11, it was not merged fir
> this RC. I'd like to see an RC2 with it included.

Looking at this now.

Thinking about version numbers as a result of one of your other posts
there probably is a case for 1.2.0.

Since the 1.1.0 release Windows XP, Vista and Server 2003 have all
fallen out of support. Some of the Procrun changes assume Windows 7 /
Server 2008 SP2 (i.e. only currently supported versions of Windows) as a
minimum.

I think you could make a case for 1.1.1 on the grounds the older OSes
are unsupported but using 1.2.0 makes it cleaner.

The changes from the 1.1.1 tag to 1.2.0 are essentially cosmetic so far
so I'd urge folks to continue to test 1.1.1 and provide feedback.

Mark


> 
> Gary
> 
> On Mon, Jun 17, 2019 at 8:13 AM Mark Thomas  wrote:
> 
>> It has been ~18 months since the last Commons Daemon release. After the
>> recent flurry of activity, I think we are ready for a release.
>>
>> Notable changes include:
>> - Improved JRE/JDK detection to support increased range of both JVM
>>   versions and vendors.
>> - Procrun. Change the default service from LocalSystem to
>>   'NT Authority\LocalService'
>>
>> The full set of changes is in the changelog
>>
>> 1.1.1 can be obtained from (r34537):
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>
>> The git tag is:
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>> <https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810>
>>
>> The Maven Staging repo is:
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>
>> The Windows binaries have been signed by the Symantec code signing service.
>>
>>
>>
>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>> [ ] Broken   - do not release because...
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


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

Re: [VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

On 18/06/2019 17:15, Gary Gregory wrote:
> On Tue, Jun 18, 2019 at 11:43 AM Mark Thomas  wrote:
> 
>> On 18/06/2019 14:20, Gary Gregory wrote:
>>> Also, while we even discussed PR
>>> https://github.com/apache/commons-daemon/pull/11, it was not merged fir
>>> this RC. I'd like to see an RC2 with it included.
>>
>> Looking at this now.
>>
>> Thinking about version numbers as a result of one of your other posts
>> there probably is a case for 1.2.0.
>>
>> Since the 1.1.0 release Windows XP, Vista and Server 2003 have all
>> fallen out of support. Some of the Procrun changes assume Windows 7 /
>> Server 2008 SP2 (i.e. only currently supported versions of Windows) as a
>> minimum.
>>
>> I think you could make a case for 1.1.1 on the grounds the older OSes
>> are unsupported but using 1.2.0 makes it cleaner.
>>
>> The changes from the 1.1.1 tag to 1.2.0 are essentially cosmetic so far
>> so I'd urge folks to continue to test 1.1.1 and provide feedback.
>>
> 
> See my previous emails then.

Apart from switching 1.2.0 (addressed above) and your PR to modify log
messages (mentioned above and already committed) I don't see any other
feedback for 1.1.1 from you.

What am I missing?

Mark


> 
> Gary
> 
> 
>>
>> Mark
>>
>>
>>>
>>> Gary
>>>
>>> On Mon, Jun 17, 2019 at 8:13 AM Mark Thomas  wrote:
>>>
>>>> It has been ~18 months since the last Commons Daemon release. After the
>>>> recent flurry of activity, I think we are ready for a release.
>>>>
>>>> Notable changes include:
>>>> - Improved JRE/JDK detection to support increased range of both JVM
>>>>   versions and vendors.
>>>> - Procrun. Change the default service from LocalSystem to
>>>>   'NT Authority\LocalService'
>>>>
>>>> The full set of changes is in the changelog
>>>>
>>>> 1.1.1 can be obtained from (r34537):
>>>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>>>
>>>> The git tag is:
>>>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>>>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>>>> <
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810
>>>
>>>>
>>>> The Maven Staging repo is:
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>>>
>>>> The Windows binaries have been signed by the Symantec code signing
>> service.
>>>>
>>>>
>>>>
>>>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>>>> [ ] Broken   - do not release because...
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


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

Re: [VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

On 19/06/2019 02:04, Rob Tompkins wrote:
> Build works on java8 with “mvn clean test install site.” On java7 and java11 
> “mvn clean test” works.

Great. Thanks for looking.

> One curiousity, “mvn apache-rat:check” fails with 4 license violations, 
> namely:
> 
>   src/native/unix/native/.indent.pro
>   src/native/unix/configure
>   src/native/unix/support/config.guess
>   src/native/unix/support/config.sub
> 
> I think aside from these I would likely be a +1.

Excellent. Things look to be in pretty good shape.

> The “.indent.pro” looks to be excludable,

It looks similar to checkstyle. It might be possible to add a header as
a comment. I'll take a look. I'll also see what happens if we run indent
against the current code.

> the others, being GPL licensed,

Not exactly.

configure is licensed as:


# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.



config.guess and config.sub are GPL v3 or later with an exception namely:


# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that
# program.  This Exception is an additional permission under section 7
# of the GNU General Public License, version 3 ("GPLv3").


That exception applies in this case so those files are distributed under
the terms of the ALv2.

> we may need to add to the NOTICE.txt

No. Only required notices go in NOTICE and there is no such requirement
for any of these three files.

> and then add the Apache 2.0 license header to them? IIRC, we should be able 
> to do something like that

No. You can't re-license code if you don't own the copyright.

If code is licensed under something other than ALv2 that license needs
to be added to LICENSE. In this case the files are ALv2 licensed so I
don't think adding anything to LICENSE is necessary either.

Legally, I think 1.1.1 is fine.

ASF policy wise, we should try and put a header in .indent.pro but if
the file format doesn't support comments then it would be acceptable to
leave them out.

As an additional check, I looked at how httpd handles the same 3 files
and it includes them in the source as is and does not mention them in
either LICENSE or NOTICE so that reinforces my belief that Commons
Daemon is handling these 3 files correctly.

What we should do is ensure that those 3 files are excluded from RAT.
I'll add that to my TODO list but I won't complain if someone beats me
to it.

Mark


> 
> Cheers,
> -Rob
> 
> 
>> On Jun 17, 2019, at 8:13 AM, Mark Thomas  wrote:
>>
>> It has been ~18 months since the last Commons Daemon release. After the
>> recent flurry of activity, I think we are ready for a release.
>>
>> Notable changes include:
>> - Improved JRE/JDK detection to support increased range of both JVM
>>  versions and vendors.
>> - Procrun. Change the default service from LocalSystem to
>>  'NT Authority\LocalService'
>>
>> The full set of changes is in the changelog
>>
>> 1.1.1 can be obtained from (r34537):
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>
>> The git tag is:
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>>
>> The Maven Staging repo is:
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>
>> The Windows binaries have been signed by the Symantec code signing service.
>>
>>
>>
>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>> [ ] Broken   - do not release because...
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

On 19/06/2019 10:44, Jonathan Gallimore wrote:
> This works well in my tests, many thanks for the release.

Thanks for the confirmation.

Mark

> 
> (non-binding) +1.
> 
> Jon
> 
> On Mon, Jun 17, 2019 at 1:13 PM Mark Thomas  wrote:
> 
>> It has been ~18 months since the last Commons Daemon release. After the
>> recent flurry of activity, I think we are ready for a release.
>>
>> Notable changes include:
>> - Improved JRE/JDK detection to support increased range of both JVM
>>   versions and vendors.
>> - Procrun. Change the default service from LocalSystem to
>>   'NT Authority\LocalService'
>>
>> The full set of changes is in the changelog
>>
>> 1.1.1 can be obtained from (r34537):
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>
>> The git tag is:
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>> <https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810>
>>
>> The Maven Staging repo is:
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>
>> The Windows binaries have been signed by the Symantec code signing service.
>>
>>
>>
>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>> [ ] Broken   - do not release because...
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


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

Re: [commons-daemon] 02/02: Update RAT config to exclude generated files and autoconf related files

[Mark Thomas]

On 19/06/2019 12:24, Rob Tompkins wrote:
> Given that the files were auto-generated, do we require another RC? I
> think that the precedent is yes, but the question I think is a
> reasonable one.

ASF policy doesn't require another RC in these circumstances.

Whether we choose to is a slightly different questions. The more
frequently a product is released, the more relaxed I am about just
fixing minor issues in the next release.

Nearly all of the changes since 1.1.1 have been cosmetic. The exception
is the PR I missed to improve mips detection. The other factor is the
change in Windows OS support.

Given the relative low frequency of releases, the mips PR and the
Windows version support, a 1.2.0 RC (and it can be an RC now I have got
my head around how to get the code signing to handle multiple RCs
without complaining about duplicate version numbers) looks like the
right way to go.

That said, given that the changes since the 1.1.1 tag are nearly all
cosmetic, I think it makes sense to keep testing 1.1.1 to ensure we ID
all the issues to avoid multiple 1.2.0 RCs.

Any issues that emerge during the 1.2.0 release vote that were also
present, but not found, in 1.1.1 are going to have to have significant
end-user impact to motivate me to roll as second 1.2.0 RC.

Mark


> 
> -Rob
> 
> 
> On 6/19/2019 6:46 AM, ma...@apache.org wrote:
> 
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> markt pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/commons-daemon.git
>>
>> commit a089ee036affef903029b481de9e9137294b0217
>> Author: Mark Thomas 
>> AuthorDate: Wed Jun 19 11:46:19 2019 +0100
>>
>>  Update RAT config to exclude generated files and autoconf related
>> files
>> ---
>>   pom.xml | 49 ++---
>>   1 file changed, 34 insertions(+), 15 deletions(-)
>>
>> diff --git a/pom.xml b/pom.xml
>> index 5110711..c8c4c40 100644
>> --- a/pom.xml
>> +++ b/pom.xml
>> @@ -116,20 +116,39 @@
>>     
>>       
>> -    
>> -  
>> -    maven-assembly-plugin
>> -    
>> -  
>> -    src/assembly/native-src.xml
>> -    src/assembly/bin.xml
>> -    src/assembly/src.xml
>> -    src/assembly/win.xml
>> -  
>> -  gnu
>> -    
>> -  
>> -    
>> +    
>> +  
>> +    
>> +  org.apache.rat
>> +  apache-rat-plugin
>> +  
>> +    
>> +  
>> +  src/native/unix/configure
>> +  
>> +  src/native/unix/support/config.guess
>> +  src/native/unix/support/config.sub
>> +  
>> +  
>> +  src/native/unix/config.nice
>> +  src/native/unix/config.status
>> +  src/native/unix/config.log
>> +    
>> +  
>> +    
>> +    
>> +  maven-assembly-plugin
>> +  
>> +    
>> +  src/assembly/native-src.xml
>> +  src/assembly/bin.xml
>> +  src/assembly/src.xml
>> +  src/assembly/win.xml
>> +    
>> +    gnu
>> +  
>> +    
>> +  
>> +    
>>     
>> -
>>   
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

[CANCEL][VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

Given the discussions around 1.1.1 vs 1.2.0 I'm cancelling this release
vote.

I'll start preparing for a 1.2.0 RC now (I think things are pretty much
there but a final check won't hurt) with a view to tagging sometime
between late tomorrow and early next week.

If anyone has any objections to this plan then please speak up in the
next 24 hours.

Mark


On 17/06/2019 13:13, Mark Thomas wrote:
> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity, I think we are ready for a release.
> 
> Notable changes include:
> - Improved JRE/JDK detection to support increased range of both JVM
>   versions and vendors.
> - Procrun. Change the default service from LocalSystem to
>   'NT Authority\LocalService'
> 
> The full set of changes is in the changelog
> 
> 1.1.1 can be obtained from (r34537):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
> 
> The git tag is:
> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
> 4319f482e1ff6ea7655e1377120750fd6ecc3810
> 
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1441/
> 
> The Windows binaries have been signed by the Symantec code signing service.
> 
> 
> 
> [ ] Approved - go ahead and release Commons Daemon 1.1.1
> [ ] Broken   - do not release because...
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VOTE] Release Apache Commons Daemon 1.1.1

[Mark Thomas]

On 20/06/2019 13:34, Gary Gregory wrote:
> I do not understand the lack of reply to my requests to follow our release
> process:
> 
> - Hashes to files on dist/dev

Not necessary.
The revision number for the dist repo is sufficient for traceability.

> - Link to site

Not part of the release.

> - Link to KEYS file

Not part of the release.
That said, it is trivial to include the link. I'll try and remember to
do that for 1.2.0.

> - Link to apache.org instead of github.com for the tag

Not necessary. The hash is sufficient.
That said, it is trivial to reference gitbox.a.o rather than GitHub.
I'll try and remember to do that for 1.2.0.

For a longer response, see the Daemon 1.1.0 vote thread.

Mark


> 
> Gary
> 
> On Wed, Jun 19, 2019 at 6:30 AM Mark Thomas  wrote:
> 
>> On 19/06/2019 10:44, Jonathan Gallimore wrote:
>>> This works well in my tests, many thanks for the release.
>>
>> Thanks for the confirmation.
>>
>> Mark
>>
>>>
>>> (non-binding) +1.
>>>
>>> Jon
>>>
>>> On Mon, Jun 17, 2019 at 1:13 PM Mark Thomas  wrote:
>>>
>>>> It has been ~18 months since the last Commons Daemon release. After the
>>>> recent flurry of activity, I think we are ready for a release.
>>>>
>>>> Notable changes include:
>>>> - Improved JRE/JDK detection to support increased range of both JVM
>>>>   versions and vendors.
>>>> - Procrun. Change the default service from LocalSystem to
>>>>   'NT Authority\LocalService'
>>>>
>>>> The full set of changes is in the changelog
>>>>
>>>> 1.1.1 can be obtained from (r34537):
>>>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>>>>
>>>> The git tag is:
>>>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
>>>> 4319f482e1ff6ea7655e1377120750fd6ecc3810
>>>> <
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810
>>>
>>>>
>>>> The Maven Staging repo is:
>>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1441/
>>>>
>>>> The Windows binaries have been signed by the Symantec code signing
>> service.
>>>>
>>>>
>>>>
>>>> [ ] Approved - go ahead and release Commons Daemon 1.1.1
>>>> [ ] Broken   - do not release because...
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


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

[VOTE] Release Apache Commons Daemon 1.2.0 RC2

[Mark Thomas]

It has been ~18 months since the last Commons Daemon release. After the
recent flurry of activity and a couple of failed RCs, it is time for
another release vote.

Notable changes since 1.1.0 include:
- Improved JRE/JDK detection to support increased range of both JVM
  versions and vendors.
- Procrun. Minimum target platform for Windows binaries is now Windows 7
- Procrun. Change the default service from LocalSystem to
  'NT Authority\LocalService'

The full set of changes is in the changelog

1.2.0 RC2 can be obtained from (r34680):
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
Tag: COMMONS_DAEMON_1_2_0_RC2
URL:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
Hash:  d88fd9100c1110fa51b7c7a08e3e7efd0e58227b

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1443/

The Windows binaries have been signed by the Symantec code signing service.

Files signed with my preferred key:
http://people.apache.org/~markt/
KEYS file is standard Apache Commons keys file:
http://www.apache.org/dist/commons/KEYS


[ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0
[ ] Broken   - do not release because...

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

Re: [VOTE] Release Apache Commons Daemon 1.2.0 RC2

[Mark Thomas]

On 28/06/2019 15:49, Gary Gregory wrote:
> +1
> 
> TODO later: Update RNs since the POM uses version "1.2.0" and the release
> notes use "1.2".

That is by design. The release notes are intended for the entire 1.2.x
release stream. This is how Daemon has done it in the past.

Do we want to switch to point release specific notes, change the version
in the release notes to 1.2.x or something else?

> TODO later: src\native\windows\README should have a file extension since on
> Windows text files without extensions are not customary.

I'll get that done now and I'll check for any other extension-less files
too.

> TODO later: Fix Javadocs for Java 11 with 'mvn -V clean install site'
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on
> project commons-daemon: Error generating maven-javadoc-plugin:3.1.0:javadoc
> report:
> [ERROR] Exit code: 1 -
> C:\temp\rc\commons-daemon\src\main\java\org\apache\commons\daemon\DaemonPermission.java:38:
> error: attribute not supported in HTML5: width
> [ERROR]  * 

Fixed (locally - I'll commit shortly). I was surprised that was the only
issue.

> Java 8 OK with:
> - 'mvn apache-rat:check',
> - 'mvn clirr:check'.
> - 'mvn -V clean install site',
> 
> Java 11 OK with 'mvn -V clean install'
> 
> I was able to run 'nmake CPU=X86' (NMake Version 14.21.27702.2) on Windows
> 10.0.16299.1087 for both Windows apps. There is no 'SetEnv' script in my VS
> install so 'nmake CPU=X64' failed. Our README needs a bit of updating.

More than a bit :)

> Did you use the antique versions mentioned in the README? If not, please
> update the file for future reference.

I'll update the release build instructions. It should be possible to
build with recent Visual Studio versions too. If someone familiar with
that tool can add instructions for Visual Studio that would be helpful.

> Java versions mentioned above:
> 
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T15:00:29-04:00)
> Maven home: C:\Java\apache-maven-3.6.1\bin\..
> Java version: 11.0.3, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-11.0.3
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T15:00:29-04:00)
> Maven home: C:\Java\apache-maven-3.6.1\bin\..
> Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_212\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Gary

Many thanks.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.0 RC2

[Mark Thomas]

On 28/06/2019 15:20, Mark Thomas wrote:



> [X] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0
> [ ] Broken   - do not release because...

Tested with Tomcat 9.0.x build process and the resulting Windows installer.

There were (expected) file permission issues due to the change in the
default user. Otherwise all good. The service ran without issues.

Mark

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

Re: [VOTE][RESULT] Release Apache Commons Daemon 1.2.0 RC2

[Mark Thomas]

The following votes were cast:

Binding:
+1: ggregory, markt, chtompki, stain

Non-binding:
+1: Jonathan Gallimore

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 28/06/2019 15:20, Mark Thomas wrote:
> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity and a couple of failed RCs, it is time for
> another release vote.
> 
> Notable changes since 1.1.0 include:
> - Improved JRE/JDK detection to support increased range of both JVM
>   versions and vendors.
> - Procrun. Minimum target platform for Windows binaries is now Windows 7
> - Procrun. Change the default service from LocalSystem to
>   'NT Authority\LocalService'
> 
> The full set of changes is in the changelog
> 
> 1.2.0 RC2 can be obtained from (r34680):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
> 
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_0_RC2
> URL:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
> Hash:  d88fd9100c1110fa51b7c7a08e3e7efd0e58227b
> 
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1443/
> 
> The Windows binaries have been signed by the Symantec code signing service.
> 
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
> 
> 
> [ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0
> [ ] Broken   - do not release because...
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

[ANNOUNCEMENT] Commons Daemon 1.2.0 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.2.0.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.2.0 is a feature and bugfix release.

A full list of changes can be found at
  https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark, on behalf of the Apache Commons community

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

Re: [commons-dbcp] branch master updated: [DBCP-547] Add a ConnectionFactory class name setting for BasicDataSource.createConnectionFactory() #33.

[Mark Thomas]

On 08/07/2019 16:14, ggreg...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 8a579d3  [DBCP-547] Add a ConnectionFactory class name setting for 
> BasicDataSource.createConnectionFactory() #33.
> 8a579d3 is described below
> 
> commit 8a579d304595853012ccf8c2bc93022c383a35bb
> Author: Gary Gregory 
> AuthorDate: Mon Jul 8 11:13:58 2019 -0400
> 
> [DBCP-547] Add a ConnectionFactory class name setting for
> BasicDataSource.createConnectionFactory() #33.
> 
> - Update version from 2.6.1-SNAPSHOT to 2.7.0 since this commits adds
> new public APIs in BasicDataSource.
> - Provide an alternative implementation from the PR
> https://github.com/apache/commons-dbcp/pull/33 WRT to String value
> handling. The handling of empty string for the new APIs is made
> consistent with other String APIs instead of what is done in PR 33.
> - Formatted new class TesterConnectionFactory differently from the PR
> and sorted its methods.

This appears to have used an indent of 4 spaces for continuation lines
rather than 8, making the code harder to read.

Mark


> - Closes #33.
> ---
>  pom.xml|   4 +-
>  src/changes/changes.xml|   7 +-
>  .../org/apache/commons/dbcp2/BasicDataSource.java  | 110 
> -
>  .../commons/dbcp2/BasicDataSourceFactory.java  |  11 ++-
>  .../apache/commons/dbcp2/TestBasicDataSource.java  |  45 -
>  .../commons/dbcp2/TesterConnectionFactory.java |  84 
>  6 files changed, 229 insertions(+), 32 deletions(-)
> 
> diff --git a/pom.xml b/pom.xml
> index 399774a..3d9b8f8 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -26,7 +26,7 @@
>
>4.0.0
>commons-dbcp2
> -  2.6.1-SNAPSHOT
> +  2.7.0-SNAPSHOT
>Apache Commons DBCP
>  
>2001
> @@ -293,7 +293,7 @@
>  RC1
>  org.apache.commons.dbcp2
>  
> -2.6.1
> +2.7.0
>  for JDBC 4.2 on Java 8
>  
>  2.4.0
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 6815b40..53e40a6 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -60,7 +60,7 @@ The  type attribute can be add,update,fix,remove.
>   -->
>  
>
> -
> +
>
>  ManagedDataSource#close() should declare used exceptions.
>
> @@ -71,7 +71,7 @@ The  type attribute can be add,update,fix,remove.
>  Update tests from H2 1.4.198 to 1.4.199.
>
>
> -Close ObjectOutputStream before calling toByteArray on underlying 
> ByteArrayOutputStream #28.
> +Close ObjectOutputStream before calling toByteArray() on underlying 
> ByteArrayOutputStream #28.
>
>
>  Upgrade to JUnit Jupiter #19.
> @@ -85,6 +85,9 @@ The  type attribute can be add,update,fix,remove.
>
>  Avoid NPE when calling DriverAdapterCPDS.toString().
>
> +   due-to="leechoongyon, Gary Gregory">
> +Add a ConnectionFactory class name setting for 
> BasicDataSource.createConnectionFactory() #33.
> +  
>  
>  
>
> diff --git a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java 
> b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> index 7c46359..3a3d065 100644
> --- a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> +++ b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> @@ -109,7 +109,7 @@ public class BasicDataSource implements DataSource, 
> BasicDataSourceMXBean, MBean
>  }
>  
>  protected static void validateConnectionFactory(final 
> PoolableConnectionFactory connectionFactory)
> -throws Exception {
> +throws Exception {
>  PoolableConnection conn = null;
>  PooledObject p = null;
>  try {
> @@ -315,6 +315,11 @@ public class BasicDataSource implements DataSource, 
> BasicDataSourceMXBean, MBean
>  private volatile int validationQueryTimeoutSeconds = -1;
>  
>  /**
> + * The fully qualified Java class name of a {@link ConnectionFactory} 
> implementation.
> + */
> +private String connectionFactoryClassName;
> +
> +/**
>   * These SQL statements run once after a Connection is created.
>   * 
>   * This property can be used for example to run ALTER SESSION SET 
> NLS_SORT=XCYECH in an Oracle Database only once
> @@ -364,7 +369,7 @@ public class BasicDataSource implements DataSource, 
> BasicDataSourceMXBean, MBean
>   * The PrintWriter to which log messages should be directed.
>   */
>  private volatile PrintWriter logWriter = new PrintWriter(
> -new OutputStreamWriter(System.out, StandardCharsets.UTF_8));
> +new OutputStreamWriter(System.out, StandardCharsets

Re: [commons-dbcp] branch master updated: [DBCP-547] Add a ConnectionFactory class name setting for BasicDataSource.createConnectionFactory() #33.

[Mark Thomas]

On 08/07/2019 21:42, Gary Gregory wrote:
> On Mon, Jul 8, 2019 at 11:23 AM Mark Thomas  wrote:
> 
>> On 08/07/2019 16:14, ggreg...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> ggregory pushed a commit to branch master
>>> in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>  new 8a579d3  [DBCP-547] Add a ConnectionFactory class name setting
>> for BasicDataSource.createConnectionFactory() #33.
>>> 8a579d3 is described below
>>>
>>> commit 8a579d304595853012ccf8c2bc93022c383a35bb
>>> Author: Gary Gregory 
>>> AuthorDate: Mon Jul 8 11:13:58 2019 -0400
>>>
>>> [DBCP-547] Add a ConnectionFactory class name setting for
>>> BasicDataSource.createConnectionFactory() #33.
>>>
>>> - Update version from 2.6.1-SNAPSHOT to 2.7.0 since this commits adds
>>> new public APIs in BasicDataSource.
>>> - Provide an alternative implementation from the PR
>>> https://github.com/apache/commons-dbcp/pull/33 WRT to String value
>>> handling. The handling of empty string for the new APIs is made
>>> consistent with other String APIs instead of what is done in PR 33.
>>> - Formatted new class TesterConnectionFactory differently from the PR
>>> and sorted its methods.
>>
>> This appears to have used an indent of 4 spaces for continuation lines
>> rather than 8, making the code harder to read.
>>
> 
> I'm pretty sure most of the code base does not use super-wide 8 spaces for
> indentation (for example between an if-statement and its body.

I am not talking about standard indentation of code blocks, for which |I
agree 4 spaces is thr standard. I am talking about indentation *for
continuation lines*. Take the following example:

>>> diff --git a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
>> b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
>>> index 7c46359..3a3d065 100644
>>> --- a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
>>> +++ b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
>>> @@ -109,7 +109,7 @@ public class BasicDataSource implements DataSource,
>> BasicDataSourceMXBean, MBean
>>>  }
>>>
>>>  protected static void validateConnectionFactory(final
>> PoolableConnectionFactory connectionFactory)
>>> -throws Exception {
>>> +throws Exception {
>>>  PoolableConnection conn = null;
>>>  PooledObject p = null;
>>>  try {

I've edited the code to avoid line wrapping in email but the original was:

protected static void validateConnectionFactory(final PCF factory)
throws Exception {
PoolableConnection conn = null;
PooledObject p = null;
try {

Note how the "throws Exception {" line is indented 8 spaces rather than
4 because it is a continuation of the line above.

After the reformatting this became:

protected static void validateConnectionFactory(final PCF factory)
throws Exception {
PoolableConnection conn = null;
PooledObject p = null;
try {

The continuation line is now only indented 4 spaces. This aligns it with
the contained code block making it visually harder to separate the two.

I quickly skimmed through the DBCP code base. I didn't find that many
continuation lines but those that I did all used an 8 space indent.

mark

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

Re: [commons-dbcp] branch master updated: [DBCP-547] Add a ConnectionFactory class name setting for BasicDataSource.createConnectionFactory() #33.

[Mark Thomas]

On 10/07/2019 15:49, Gary Gregory wrote:

> Without arguing about the merits of one kind of formatting vs. another...
> If you can configure the Eclipse formatter to do that, I'd consider it,
> otherwise, I'm not into what I'd call "artisanal formatting" ;-)


The Eclipse setting you want is:

Formatter > Line Wrapping > Default indentation for wrapped lines

and set it to 2 (which should be the default).


That seems to do the trick when I run it locally. I'd commit the result
but the default settings change nearly every line in the file.

Looking more closely, that appears to be a line ending issue. I thought
the accepted practice was to use unix line endings in the repo and
native line endings locally. It looks like there are some Windows line
endings in the repo.

It would be worth saving your Eclipse formatter settings in the source
tree somewhere so everybody can work from the same set.

Mark

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

Re: [commons-dbcp] branch master updated: [DBCP-547] Add a ConnectionFactory class name setting for BasicDataSource.createConnectionFactory() #33.

[Mark Thomas]

On 10/07/2019 22:47, Gary Gregory wrote:
> On Wed, Jul 10, 2019 at 11:52 AM Mark Thomas  wrote:
> 
>> On 10/07/2019 15:49, Gary Gregory wrote:
>>
>>> Without arguing about the merits of one kind of formatting vs. another...
>>> If you can configure the Eclipse formatter to do that, I'd consider it,
>>> otherwise, I'm not into what I'd call "artisanal formatting" ;-)
>>
>>
>> The Eclipse setting you want is:
>>
>> Formatter > Line Wrapping > Default indentation for wrapped lines
>>
>> and set it to 2 (which should be the default).
>>
>>
>> That seems to do the trick when I run it locally. I'd commit the result
>> but the default settings change nearly every line in the file.
>>
>> Looking more closely, that appears to be a line ending issue. I thought
>> the accepted practice was to use unix line endings in the repo and
>> native line endings locally. It looks like there are some Windows line
>> endings in the repo.
>>
>> It would be worth saving your Eclipse formatter settings in the source
>> tree somewhere so everybody can work from the same set.
>>
> 
> I set the setting you mentioned to 2 and saved my config
> here: src/conf/eclipse/formatter.xml
> I did not reformat anything.

Thanks. I applied that to BasicDataSource.

I haven't applied that formatting to all files although it probably
makes sense to do so.

I've looked through the formatting and my personal preference would be
to change one more thing (actually a handful of settings for different
operators):
- wrap before operator -> wrap after operator

but that is a low priority for me. If the consensus is against that I'm
fine with that. I'd rather spend time convincing people it is helpful
for the project to use a consistent formatting throughout than endlessly
debate the merits of each individual option.

I also fixed the line endings of the 10 or so files that were using \r\n
line endings rather than the recommended \n.

Mark

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

Re: [commons-daemon] branch master updated: Correct regression in DAEMON-401

[Mark Thomas]

On 03/09/2019 22:34, Gary Gregory wrote:
> Mark,
> 
> Do you feel like creating an RC to push this through to a release? It feels
> pretty important (crash) eventhough this is for 32-bit only.

I want to fix some other issues first.

Mark


> 
> Gary
> 
> On Tue, Sep 3, 2019, 17:31  wrote:
> 
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> markt pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/commons-daemon.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 4228b53  Correct regression in DAEMON-401
>> 4228b53 is described below
>>
>> commit 4228b53ec99ae4e7f1d96242fbc8d4a27316fd57
>> Author: Mark Thomas 
>> AuthorDate: Tue Sep 3 22:30:37 2019 +0100
>>
>> Correct regression in DAEMON-401
>>
>> An incorrect calling convention (__stdcall rather than __cdecl) caused
>> memory corruption when running as a 32-bit process.
>> ---
>>  src/changes/changes.xml | 4 
>>  src/native/windows/include/apxwin.h | 2 +-
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
>> index 17e040e..6ce7717 100644
>> --- a/src/changes/changes.xml
>> +++ b/src/changes/changes.xml
>> @@ -42,6 +42,10 @@
>>
>>  jsvc. Correct debug log message that reports change in umask.
>>
>> +  
>> +Procrun. Correct a regression in the previous fix for this issue
>> that
>> +caused 32-bit services to crash on start-up.
>> +  
>>  
>>  
>>
>> diff --git a/src/native/windows/include/apxwin.h
>> b/src/native/windows/include/apxwin.h
>> index cbd4ac9..1d70063 100644
>> --- a/src/native/windows/include/apxwin.h
>> +++ b/src/native/windows/include/apxwin.h
>> @@ -118,7 +118,7 @@ LPSTR   MzWideToAscii(LPCWSTR ws, LPSTR s);
>>  LPSTR   WideToANSI(LPCWSTR ws);
>>  LPSTR   MzWideToANSI(LPCWSTR ws);
>>
>> -typedef int (__stdcall *WPUTENV) (const wchar_t *env);
>> +typedef int (*WPUTENV) (const wchar_t *env);
>>
>>  typedef struct APXMULTISZ APXMULTISZ;
>>  typedef APXMULTISZ*   LPAPXMULTISZ;
>>
>>
> 


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

[VOTE] Release Apache Commons Daemon 1.2.1 RC1

[Mark Thomas]

A couple of regressions have been identified in the 1.2.0 release so I'd
like to get 1.2.1 released to address them. So, time for another release
vote.

Notable changes since 1.2.0 include:
- Correct a regression (DAEMON-401) that caused 32-bit Windows services
  to crash on start-up
- Correct a regression (DAEMON-407) the caused the Windows GUI to mix up
  the WARN and INFO log levels.
- Expand (and document) the search algorithm for the Java runtime
  library to better support newer versions of Java that do not install a
  separate JRE when installing a JDK.

The full set of changes is in the changelog

1.2.1 RC1 can be obtained from (r35583)
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
Tag: COMMONS_DAEMON_1_2_1_RC1
URL:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=3fc90a64726639c32a46ec25a5f8ac1b84525082
Hash:  3fc90a64726639c32a46ec25a5f8ac1b84525082

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1463/

The Windows binaries have been signed by the Symantec code signing service.

Files signed with my preferred key:
http://people.apache.org/~markt/
KEYS file is standard Apache Commons keys file:
http://www.apache.org/dist/commons/KEYS


[ ] Approved - go ahead and release Commons Daemon 1.2.1 RC1 as 1.2.1
[ ] Broken   - do not release because...

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

Re: [VOTE] Release Apache Commons Daemon 1.2.1 RC1

[Mark Thomas]

On 05/09/2019 21:39, Mark Thomas wrote:



> [X] Approved - go ahead and release Commons Daemon 1.2.1 RC1 as 1.2.1
> [ ] Broken   - do not release because...

Tested with a release build of Tomcat 9.0.x - all good.

I did notice that the about box for prunmgr uses the old Commons logo.
I'll get that fixed for the next release.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.1 RC1

[Mark Thomas]

On 06/09/2019 13:05, Gilles Sadowski wrote:
> Hi.
> 
> Le ven. 6 sept. 2019 à 12:17, Mark Thomas  a écrit :
>>
>> On 05/09/2019 21:39, Mark Thomas wrote:
>>
>> 
>>
>>> [X] Approved - go ahead and release Commons Daemon 1.2.1 RC1 as 1.2.1
>>> [ ] Broken   - do not release because...
>>
>> Tested with a release build of Tomcat 9.0.x - all good.
>>
>> I did notice that the about box for prunmgr uses the old Commons logo.
> 
> Is there a new one?
> AFAIK, the matter has never been settled.[1]

Ah. I found yet another one here:

https://www.apache.org/logos/?#commons

The one I found doesn't comply with the style guide (the feather is
rotated).

I'll check the options currently in COMMONSSITE-86 against the style
guide. Then I guess we need a VOTE to select one.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.1 RC1

[Mark Thomas]

On 06/09/2019 14:07, Gilles Sadowski wrote:
> Hi.
> 
> Le ven. 6 sept. 2019 à 14:49, Mark Thomas  a écrit :
>>
>> On 06/09/2019 13:05, Gilles Sadowski wrote:
>>> Hi.
>>>
>>> Le ven. 6 sept. 2019 à 12:17, Mark Thomas  a écrit :
>>>>
>>>> On 05/09/2019 21:39, Mark Thomas wrote:
>>>>
>>>> 
>>>>
>>>>> [X] Approved - go ahead and release Commons Daemon 1.2.1 RC1 as 1.2.1
>>>>> [ ] Broken   - do not release because...
>>>>
>>>> Tested with a release build of Tomcat 9.0.x - all good.
>>>>
>>>> I did notice that the about box for prunmgr uses the old Commons logo.
>>>
>>> Is there a new one?
>>> AFAIK, the matter has never been settled.[1]
>>
>> Ah. I found yet another one here:
>>
>> https://www.apache.org/logos/?#commons
>>
> 
> It's the one I provided, when we were asked.
> 
>>
>> The one I found doesn't comply with the style guide (the feather is
>> rotated).
> 
> It depends on how the wind was blowing before it settled
> on the common(s) ground... :-)
> 
> Where are the guidelines?

https://apache.org/foundation/press/kit/ApacheFoundation_StyleGuide.pdf


>> I'll check the options currently in COMMONSSITE-86 against the style
>> guide. Then I guess we need a VOTE to select one.
> 
> IIRC, there must be one pending (from a long long time ago).

Pointers welcome if anyone has them. If not, I'll go doing through the
archives.

Mark

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

Updating the logo

[Mark Thomas]

Hi all,

I've looked but can't find a previous vote on this.

The current logo is:
https://apache.org/foundation/press/kit/ApacheFoundation_StyleGuide.pdf

The options for the new logo are:

https://issues.apache.org/jira/browse/COMMONSSITE-86

Of those, commons_logo.small.png is not consistent with the style guide
(the feather is rotated).

I can't see a difference (apart from size) between commons-logo_new.svg
and commons-logo_new4.svg. Am I missing something?

My intention is, therefore, to put commons-logo_new[1-4].svg onto a wiki
page so they can be viewed side-by-side and then to start a VOTE. I'll
probably do that next week some time to give time for any discussion
required before the vote starts.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.1 RC1

[Mark Thomas]

On September 7, 2019 1:31:28 PM UTC, Rob Tompkins  wrote:
>Validated all signatures nexus and dist. Rat good, build on both java8
>and java11 good (maven 3.6.1). Nit - Building with maven 3.1.1 with
>java 7 fails (plugin related). @Mark - do you have an opinion on the
>following failure? If you’re cool with it, then I’ll upvote the
>release.

That looks to be ok. If I am reading it correctly a plugin needs Java 8.

As long as the commons daemon JAR is built for Java 6 (it should be but this 
just makes me want to double check that) all should be fine.

Mark

>
>[INFO] --- maven-bundle-plugin:4.1.0:manifest (bundle-manifest) @
>commons-daemon ---
>[WARNING] Error injecting: org.apache.felix.bundleplugin.ManifestPlugin
>java.lang.UnsupportedClassVersionError: aQute/bnd/osgi/Analyzer :
>Unsupported major.minor version 52.0
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>   at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at
>org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:389)
>   at
>org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
>   at
>org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
>   at
>org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
>   at
>org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
>   at java.lang.Class.getDeclaredConstructors0(Native Method)
>
>
>
>-Rob
>
>> On Sep 5, 2019, at 4:39 PM, Mark Thomas  wrote:
>> 
>> A couple of regressions have been identified in the 1.2.0 release so
>I'd
>> like to get 1.2.1 released to address them. So, time for another
>release
>> vote.
>> 
>> Notable changes since 1.2.0 include:
>> - Correct a regression (DAEMON-401) that caused 32-bit Windows
>services
>>  to crash on start-up
>> - Correct a regression (DAEMON-407) the caused the Windows GUI to mix
>up
>>  the WARN and INFO log levels.
>> - Expand (and document) the search algorithm for the Java runtime
>>  library to better support newer versions of Java that do not install
>a
>>  separate JRE when installing a JDK.
>> 
>> The full set of changes is in the changelog
>> 
>> 1.2.1 RC1 can be obtained from (r35583)
>> https://dist.apache.org/repos/dist/dev/commons/daemon/
>> 
>> The git tag is:
>> Tag: COMMONS_DAEMON_1_2_1_RC1
>> URL:
>>
>https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=3fc90a64726639c32a46ec25a5f8ac1b84525082
>> Hash:  3fc90a64726639c32a46ec25a5f8ac1b84525082
>> 
>> The Maven Staging repo is:
>>
>https://repository.apache.org/content/repositories/orgapachecommons-1463/
>> 
>> The Windows binaries have been signed by the Symantec code signing
>service.
>> 
>> Files signed with my preferred key:
>> http://people.apache.org/~markt/
>> KEYS file is standard Apache Commons keys file:
>> http://www.apache.org/dist/commons/KEYS
>> 
>> 
>> [ ] Approved - go ahead and release Commons Daemon 1.2.1 RC1 as 1.2.1
>> [ ] Broken   - do not release because...
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: Updating the logo

[Mark Thomas]

On September 7, 2019 1:25:41 AM UTC, Gilles Sadowski  
wrote:
>2019-09-06 16:53 UTC+02:00, Mark Thomas :
>> Hi all,
>>
>> I've looked but can't find a previous vote on this.
>>
>> The current logo is:
>>
>https://apache.org/foundation/press/kit/ApacheFoundation_StyleGuide.pdf
>>
>> The options for the new logo are:
>>
>> https://issues.apache.org/jira/browse/COMMONSSITE-86
>>
>> Of those, commons_logo.small.png is not consistent with the style
>guide
>> (the feather is rotated).
>>
>> I can't see a difference (apart from size) between
>commons-logo_new.svg
>> and commons-logo_new4.svg. Am I missing something?
>>
>> My intention is, therefore, to put commons-logo_new[1-4].svg onto a
>wiki
>> page so they can be viewed side-by-side and then to start a VOTE.
>
>All proposals currently on that JIRA page are ruled out (see the URL).

On what basis? 1-4 looked OK to me.

Mark

>
>Gilles
>
>> I'll
>> probably do that next week some time to give time for any discussion
>> required before the vote starts.
>>
>> Mark
>>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [VOTE][RESULT] Release Apache Commons Daemon 1.2.1 RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, kinow, chtompki, ggregory

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark



On 05/09/2019 21:39, Mark Thomas wrote:
> A couple of regressions have been identified in the 1.2.0 release so I'd
> like to get 1.2.1 released to address them. So, time for another release
> vote.
> 
> Notable changes since 1.2.0 include:
> - Correct a regression (DAEMON-401) that caused 32-bit Windows services
>   to crash on start-up
> - Correct a regression (DAEMON-407) the caused the Windows GUI to mix up
>   the WARN and INFO log levels.
> - Expand (and document) the search algorithm for the Java runtime
>   library to better support newer versions of Java that do not install a
>   separate JRE when installing a JDK.
> 
> The full set of changes is in the changelog
> 
> 1.2.1 RC1 can be obtained from (r35583)
> https://dist.apache.org/repos/dist/dev/commons/daemon/
> 
> The git tag is:
> Tag: COMMONS_DAEMON_1_2_1_RC1
> URL:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=3fc90a64726639c32a46ec25a5f8ac1b84525082
> Hash:  3fc90a64726639c32a46ec25a5f8ac1b84525082
> 
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1463/
> 
> The Windows binaries have been signed by the Symantec code signing service.
> 
> Files signed with my preferred key:
> http://people.apache.org/~markt/
> KEYS file is standard Apache Commons keys file:
> http://www.apache.org/dist/commons/KEYS
> 
> 
> [ ] Approved - go ahead and release Commons Daemon 1.2.1 RC1 as 1.2.1
> [ ] Broken   - do not release because...
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

[ANNOUNCEMENT] Commons Daemon 1.2.1 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.2.1.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.2.1 is a bugfix release.

A full list of changes can be found at
  https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark, on behalf of the Apache Commons community

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

Re: [CONFIGURATION] Formatting braces

[Thomas Vandahl]

On 11.09.19 15:53, Gary Gregory wrote:
> public static final ConfigurationConsumer
> DEFAULT_INCLUDE_LISTENER = e -> { throw e; };
> 
> public static final ConfigurationConsumer
> NOOP_INCLUDE_LISTENER = e -> { /* noop */ };

+1 for these.

> I propose a reformatting to use the "{ on the same line" which means that
> blocks go from:
> 
> if (test)
> {
>// this
> }
> else
> {
>   // that
> }
> 
> to:
> 
> if (test) {
>// this
> } else {
>   // that
> }

-1 here. At least not for all components.

Bye, Thomas


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

Re: [commons-daemon] branch master updated: Fix https://issues.apache.org/jira/browse/DAEMON-408 Procrun start fail

[Mark Thomas]

On 25/09/2019 12:34, ma...@apache.org wrote:



> Fix https://issues.apache.org/jira/browse/DAEMON-408 Procrun start fail
> 
> Correct a regression in the fix for DAEMON-401 that prevented the
> service from starting unless support for the universal C runtime had
> been installed.

This is sufficiently problematic that I intend to start a Commons 1.2.2
release shortly. I expect to tag later today once I have run through all
the pre-tag checks and updates.

Mark

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

[VOTE] Release Apache Commons Daemon 1.2.2 RC1

[Mark Thomas]

A further regression has been identified in the 1.2.0/1.2.1 releases so
I'd like to get 1.2.2 released to address it. So, time for another
release vote.

Notable changes since 1.2.1 include:
- Correct a regression (DAEMON-408) that caused Windows services to
  crash on start-up when the universal C runtime was not available

The full set of changes is in the changelog

1.2.2 RC1 can be obtained from (r36024)
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
Tag: COMMONS_DAEMON_1_2_2_RC1
URL:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=cb6754d51a008418ed93e29cde141f046766fee3
Hash:  cb6754d51a008418ed93e29cde141f046766fee3

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1471/

The Windows binaries have been signed by the DigiCert (formerly
Symantec) code signing service.

Files signed with my preferred key:
http://people.apache.org/~markt/
KEYS file is standard Apache Commons keys file:
http://www.apache.org/dist/commons/KEYS


[ ] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2
[ ] Broken   - do not release because...

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

[Mark Thomas]

On 25/09/2019 15:57, Mark Thomas wrote:



> [X] Approved - go ahead and release Commons Daemon 1.2.2 RC1 as 1.2.2

Tested a Tomcat 9.0.26 install that failed to start with 1.2.1 and it
starts cleanly with 1.2.2

Also double-checked that the configure script was in place.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

[Mark Thomas]

On 28/09/2019 17:06, Gary Gregory wrote:
> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory 
> wrote:
> 
>> I can confirm that if I delete all of:
>>
>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>
>> I can build without errors but with warnings:
>>
>> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
>> function or variable may be unsafe. Consider using _wfopen_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>> declaration of '_wfopen'
>> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
>> function or variable may be unsafe. Consider using _wfopen_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>> declaration of '_wfopen'
>> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
>> function or variable may be unsafe. Consider using _snprintf_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
>> '_snprintf'
>> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
>> function or variable may be unsafe. Consider using _snprintf_s instead. To
>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>> details.
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
>> '_snprintf'
>> rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
>> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc
>>
> 
> FWIW, using:
> 
> Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86
> Copyright (C) Microsoft Corporation.  All rights reserved.

Since I am going to re-tag for an RC2 (see below) I'll see what I can do
to clean up those warnings.

>> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory 
>> wrote:
>>> On Sat, Sep 28, 2019 at 10:03 AM sebb  wrote:
 On Sat, 28 Sep 2019 at 13:39, Gary Gregory 
 wrote:



> It seems we should NOT deliver the following folders in the src zip
 which
> now contain objs and exes:
>
> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>
> WDYT?

 Looks like the build created the files in the wrong directories?

They should not be present in the source zip. I normally build the
binaries from the same tag but in a completely different checkout to
avoid this sort of thing. I'll see if I can figure out what I did wrong
but regardless of whether I can or not, I'll cancel this release, update
the estimated release date, re-tag and start an RC2 vote.

I'll also take a brief look at whether I can exclude those directories
explicitly from the source build to avoid this issue in future although
my Maven foo may not be up to that.


 The src zip also contains:
 src/native/unix/configure
 AIUI this is a generated file; I would expect it to be in the binary
 artifact, if anywhere

No. The configure script is generated but it *is* meant to be in the
source distribution. Without it, building from source is more difficult.
I forgot this for the 1.2.0 release and there were complaints as a result.

 Also there are some Git files missing from the src zip.
 Not sure if that is intentional?

 CONTRIBUTING.md
 HOWTO-RELEASE.txt
 README.md

>>>
>>> I certainly would expect CONTRIBUTING.md and README.md to be in the src
>>> zip, not quite a blocker for me. I am more concerned that we are including
>>> all of these OBJ and EXE files.

The .md files are generated but I agree they should be in the source
distribution. I'll see about getting them added.

The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think
it should be there too.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

[Mark Thomas]

On 29/09/2019 23:15, Gary Gregory wrote:
> On Sun, Sep 29, 2019 at 6:04 PM sebb  wrote:
> 
>> On Sun, 29 Sep 2019 at 22:36, Matt Sicker  wrote:
>>>
>>> I’m sort of going off of what GNU projects do (they use autotools for
>> any C
>>> projects), but the common ‘./configure && make && sudo make install’
>>> snippet is almost timeless.
>>
>> Not sure what that has to do with the question at hand, i.e
>>
>> Is the file is allowed to be in the source artifact if it is not in
>> the source repository?
>>
> 
> For me, no, I expect the source zip/tar to be a subset of what is in the
> repo for the purposes of building usable artifacts, not a super-set.

That goes against the standard practice which is not to put the
configure script under version control.

I assume that this is because the file is generated.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

[Mark Thomas]

On 28/09/2019 17:42, Mark Thomas wrote:
> On 28/09/2019 17:06, Gary Gregory wrote:
>> On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory 
>> wrote:



>>> I can build without errors but with warnings:
>>>
>>> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This
>>> function or variable may be unsafe. Consider using _wfopen_s instead. To
>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>>> details.
>>> C:\Program Files (x86)\Windows
>>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>>> declaration of '_wfopen'
>>> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This
>>> function or variable may be unsafe. Consider using _wfopen_s instead. To
>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>>> details.
>>> C:\Program Files (x86)\Windows
>>> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see
>>> declaration of '_wfopen'
>>> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This
>>> function or variable may be unsafe. Consider using _snprintf_s instead. To
>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>>> details.
>>> C:\Program Files (x86)\Windows
>>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
>>> '_snprintf'
>>> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This
>>> function or variable may be unsafe. Consider using _snprintf_s instead. To
>>> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for
>>> details.
>>> C:\Program Files (x86)\Windows
>>> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of
>>> '_snprintf'
>>> rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo
>>> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc

These have been fixed in 1d0243e

I also tried turning up warnings from -W3 (the compiler default) to -W4
and I fixed a reasonable proportion (but not all) of the additional
warnings that generated.



>>>>>> It seems we should NOT deliver the following folders in the src zip
>>>>> which
>>>>>> now contain objs and exes:
>>>>>>
>>>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE
>>>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE
>>>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE
>>>>>>
>>>>>> WDYT?
>>>>>
>>>>> Looks like the build created the files in the wrong directories?

I've modified the assembly descriptors to always exclude these files.

>>>>> The src zip also contains:
>>>>> src/native/unix/configure
>>>>> AIUI this is a generated file; I would expect it to be in the binary
>>>>> artifact, if anywhere
> 
> No. The configure script is generated but it *is* meant to be in the
> source distribution. Without it, building from source is more difficult.
> I forgot this for the 1.2.0 release and there were complaints as a result.

I disagree with adding this to source control since it goes against the
standard convention and will not be what developers will expect.

>>>>> Also there are some Git files missing from the src zip.
>>>>> Not sure if that is intentional?
>>>>>
>>>>> CONTRIBUTING.md
>>>>> HOWTO-RELEASE.txt
>>>>> README.md

All fixed.

I want to do some test builds locally and then I should be ready to tag RC2.

Mark

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

Re: [VOTE][CANCELLED] Release Apache Commons Daemon 1.2.2 RC1

[Mark Thomas]

I am cancelling this vote due to the presence of Windows build artefacts
in RC1.

RC2 should follow shortly.

Mark


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

[VOTE] Release Apache Commons Daemon 1.2.2 RC2

[Mark Thomas]

A further regression has been identified in the 1.2.0/1.2.1 releases so
I'd like to get 1.2.2 released to address it. So, time for another
release vote.

Notable changes since 1.2.1 include:
- Correct a regression (DAEMON-408) that caused Windows services to
  crash on start-up when the universal C runtime was not available
- Improve the source assembly definitions to prevent build artefacts
  from being included in the source distributions
- Fix various compiler warnings with newer compilers / stricter compiler
  warning settings

The full set of changes is in the changelog

1.2.2 RC2 can be obtained from (r36129)
https://dist.apache.org/repos/dist/dev/commons/daemon/

The git tag is:
Tag: COMMONS_DAEMON_1_2_2_RC2
URL:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=a92401b3bf4f6ec7661f7a4efe20d04421a06a4a
Hash:  a92401b3bf4f6ec7661f7a4efe20d04421a06a4a

The Maven Staging repo is:
https://repository.apache.org/content/repositories/orgapachecommons-1473/

The Windows binaries have been signed by the DigiCert (formerly
Symantec) code signing service.

Files signed with my preferred key:
http://people.apache.org/~markt/
KEYS file is standard Apache Commons keys file:
http://www.apache.org/dist/commons/KEYS


[ ] Approved - go ahead and release Commons Daemon 1.2.2 RC2 as 1.2.2
[ ] Broken   - do not release because...

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC2

[Mark Thomas]

On 30/09/2019 21:09, Gary Gregory wrote:
> Hi Mark,
> 
> I know you said you fixed a bunch of warnings but I still warning get these
> using CPU=X64; I had only tested CPU=X86 previously (sorry):

No problem. I think you hit upon I configuration I've never tested.

> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstring.h(139): warning C4391:
> 'size_t wcslen(const wchar_t *)': incorrect return type for intrinsic
> function, expected 'unsigned int'
> 
> I can't imagine this would be a blocker but I wanted to get your feedback.

TL;DR - I don't think this is an issue.

If I build with my standard release environment (the one designed not to
create dependencies on anything that doesn't ship in a clean Windows 7 /
Server 2008 install) I don't get any warnings.

If I build with the Visual Studio 2017 command line tools the x86 build
is clean whereas I do get one warning with the x64 build. It is a
slightly different one to you:

.\..\..\apps\prunsrv\prunsrv.c(1389): warning C4312: 'type cast':
conversion from 'DWORD' to 'LPVOID' of greater size.

If I cross-compile for x64 from the VS 2017 x86 toolchain (which I have
never done previously for Daemon) then I get a whole bunch of warnings
similar to yours.

I'm not concerned about the cross-compilation warnings since I don't
need to cross compile. I can use an x64 toolchain for the x64 build and
and an x86 toolchain for the x86 build. My initial impression is that
the warnings are not a significant concern but I haven't dug into them.
If cross-compilation becomes an itch someone wants to scratch then
confirming exactly what is going on with these warnings is probably one
of the first things they'd need to look at.

I'm not concerned about the warning I see with the VS 2017 x64 build but
I'd still like to see that warning go away if possible. I'll take a
quick look at that now but I don't see it as an issue that should
prevent the release.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC2

[Mark Thomas]

On 30/09/2019 17:04, Mark Thomas wrote:



> [X] Approved - go ahead and release Commons Daemon 1.2.2 RC2 as 1.2.2
> [ ] Broken   - do not release because...

I've checked the contents of the src distros against the 1.2.1 release.
That identified no missing files in 1.2.2 but a few files that should
not have been in 1.2.1 (the build process now excludes these).

I have confirmed that the regression reported on Windows installs
without the universal C runtime has been resolved.

I've built the Windows binaries from source.

I've tested the provided binaries with the Tomcat build and install
process. All good.

Mark

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

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC2

[Mark Thomas]

The following votes were cast:

Binding:
+1: ggregory, markt, chtompki

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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

Re: [pool] POOL-376 and release?

[Mark Thomas]

On 05/10/2019 18:59, Gary Gregory wrote:
> On Sat, Oct 5, 2019 at 1:19 PM Phil Steitz  wrote:
> 
>>
>> On 10/5/19 5:47 AM, Gary Gregory wrote:
>>> On Sat, Oct 5, 2019 at 8:17 AM sebb  wrote:
>>>
 On Sat, 5 Oct 2019 at 02:32, Gary Gregory 
>> wrote:
> Hi Phil and all:
>
> It looks like you merged from the "old" git repo
> https://git-wip-us.apache.org/repos/asf/commons-pool
>
> I am not sure why we have two named repos but I am basing my work on
 GitBox
> https://gitbox.apache.org/repos/asf/commons-pool.git
>
> I think these are in fact the same (?)

They are now (after a server failure a little while ago). They point to
the same box. gitbox.a.o is the new name, git-wip-us.a.o is the old name.

Even if they weren't the same box, if the hash of the tag matches then
that should provide sufficient reassurance that the tags are identical.

Mark

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

[ANNOUNCEMENT] Commons Daemon 1.2.2 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.2.2.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.2.2 is a bugfix release.

A full list of changes can be found at
  https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

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

Re: [commons-daemon] branch master updated: [DAEMON-414] prunsrv uses its log is before it is initialized.

[Mark Thomas]

On 22/11/2019 18:11, Gary Gregory wrote:
> On Fri, Nov 22, 2019 at 12:29 PM Mark Thomas  wrote:
> 
>> On 21/11/2019 19:29, ggreg...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> ggregory pushed a commit to branch master
>>> in repository https://gitbox.apache.org/repos/asf/commons-daemon.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>  new 8a46539  [DAEMON-414] prunsrv uses its log is before it is
>> initialized.
>>> 8a46539 is described below
>>>
>>> commit 8a46539bd0a7fe42fab667a249a1c59906faf9ab
>>> Author: Gary Gregory 
>>> AuthorDate: Thu Nov 21 14:29:25 2019 -0500
>>
>>
>> Sorry, this needs to be reverted.
>>
>> You've moved the logging initialisation above the code that reads the
>> logging configuration. This breaks the logging.
>>
>> A better fix would probably be to change the two lines that write to the
>> log file before it is ready to write to stderr instead.
>>
> 
> Reverted. Thank you for reviewing.

Thanks, and sorry I missed that first time around.

> Two items:
> 
> 1) There is a LOT of logging I feel we are missing. I want to turn on DEBUG
> logging and see EVERYTHING that happens at init time to be able to help
> users figure out why a service cannot be registered or, seemingly
> registered OK but getting a weird error on service start. The classic
> example, is using 64-bit prunsrv with 32-bit Java. Or, having JAVA_HOME
> pointing to the "wrong" place where "wrong" can be wrong in all sorts of
> ways.

Having spent several hours last night debugging why the Java start mode
wasn't working to find it was a typo in the location of JAVA_HOME in the
registry I completely agree with you.

> 2) When I do turn on DEBUG logging, I only see ERROR on stderr on startup.
> 
> So I'd like help in getting help for our users :-)

I'm happy to help out where I can. My normal approach is to add debug
logging when I'm trying to fix something and I can't figure out what
went wrong. I'm expecting to be adding a log of debug logging to the
start-up process after last night and the next bug on my TODO list is
start-up related as well. It won't be completely comprehensive but it
should be better than what we have.

Mark

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

[uom][math][numbers] Request for feedback on Units of Measurement library

[Thomas Neidhart]

Hi all,

recently I had more time to work on open source and I always wanted to
work on a fully typed Units of Measurements library.

My initial results can be found here:

https://github.com/netomi/uom

Its already fully functional, I am working on more unit tests,
documentation and as many units / quantities as possible.

It uses the BigFraction / Fraction class of commons-math /
commons-numbers internally (I copied the source for now as I had to make
some small modifications).

The main page of the project explain some basic uses of the library.

In general it allows to do things like that:

Length l1 = Length.of(1, Units.SI.METRE);
Length l2 = Length.of(4, Units.Imperial.YARD);

Length l3 = l1.add(l2);

System.out.println(l3.to(Units.Imperial.INCH));

It supports using quantities in double or decimal precision using the
BigDecimal class if this is needed.

I would be very grateful if somebody with an interest in this topic
could take a look and provide feedback.

Thanks & Regards,
Thomas

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

Re: Quick questions about this mailing list

[Mark Thomas]

On 13/06/2020 05:06, Miguel Munoz wrote:
> When I send an email to this list, my email address shows up in the archive 
> as ending with .INVALID. Is there anything I can do about this? (I submitted 
> an ICLA, so that shouldn't be the problem.)

https://blogs.apache.org/infra/entry/dmarc_filtering_on_lists_that

Mark

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

Re: [all] release validation

[Mark Thomas]

On 13/07/2020 06:43, Stefan Bodewig wrote:
> On 2020-07-12, Rob Tompkins wrote:
> 
>> given the consistency of the signatures from the plugins…do we need to
>> check them for releases anymore?
> 
> Yes, please. Not everybody uses the plugins and even if everybody did a
> misconfiguration could be pulling in the wrong key or a key not
> available from the expected download location.

+1, for several reasons

It also catches corrupted uploads.

It is simpler to fix during a release vote than after a release where
we'd have to at least consider the possibility of malicious activity and
respond accordingly until we could prove it wasn't.

Mark

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

Re: [all] Thoughts on build system maven -> gradle??

[Thomas Vandahl]

On 17.07.20 10:13, Claude Warren wrote:
> -1 from me.  I have a philosophical objection.

Same here: -1

> Much like HTTP's mod_rewrite[1] gradle's greatest strength is that it
> allows the developer to do so much in so many ways.  But its greatest
> weakness is that it allows the developer to do so much in so many ways.
> 
> My experience with Ant and Gradle is that in a fairly short period of time
> the build scripts become so complex that it takes a development team just
> to maintain them.
> 
> The greatest strength of Maven is that it requires developers to seriously
> work to do things outside of the "Maven way".  But its greatest weakness is
> that developers have to seriously work  to do things outside of the "Maven
> way".
> 
> My experience with Maven is that if the developer wants to do something
> outside of the "Maven way" it is difficult, but it also forces the
> developer to think about what they are doing.

Very well put. The "Maven way" is a concept that makes it easy for new
people to understand how a project is structured. If you know how a
Maven project works in principle, you can understand all others. This is
one of the greatest strengths of Maven IMO.

> With respect to this project, it is my opinion that we do not want to
> create a build system that is so complex that it becomes difficult for the
> uninitiated developer to contribute to the project.

Couldn't agree more.

Bye, Thomas

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

Re: [pool][dbcp] Move AbandonedObjectPool in v 2's?

[Mark Thomas]

On 22/07/2012 22:41, Phil Steitz wrote:
> One more quick question as I begin hacking:
> 
> Currently, abandoned object recuperation is triggered by
> borrowObject in AOP.   I am thinking about moving this to the
> evictor.  Or I guess it could be in both places?

The third option is a separate thread. That feels like overkill.

The evictor is the natural place for this although not everyone wants to
use an evictor. How feasible is use the evictor but do it on
borrowObject() if an evictor is not configured?

Mark

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

Re: [pool] Question / potential improvement on KeyedObjectPool

[Mark Thomas]

On 24/07/2012 08:42, Liviu Tudor wrote:
> Phil & others who have been in touch with [pool],
> 
> A follow up to this: I'm trying to log this in JIRA and submit a patch but
> I've come across the following problem:
> 
> 1/ The mechanism I am referring to had pool-1.6.0 in mind, however, I
> can't find in SVN the branch for 1.6? There are release branches going up
> to 1.5 but no 1.6? Can you point me in the right direction so I can create
> the patch in the right branch?

Pool 2.x: http://svn.apache.org/repos/asf/commons/proper/pool/trunk/
Pool 1.6:
http://svn.apache.org/repos/asf/commons/proper/pool/branches/POOL_1_X/
Pool 1.5:
http://svn.apache.org/repos/asf/commons/proper/pool/branches/1_5_RELEASE/

In theory pool 1.5.x + conversion to generics = pool 1.6.x

Pool 2.x is a complete re-write of the pooling mechanism.

> 2/ Since we've moved now to pool2, I would like to apply something similar
> for [pool2], however, looking at the code, I see we now have a
> 
> List getKeys();
> 
> Due to the Mbean interface we're implementing. This looks similar to my
> idea of returning a Set for the keys -- since the order of the keys of
> the cache is not important I thought. Looking at the code it turns out
> indeed the order is not important, so List is not justified and Set could
> have done it just fine. So am I ok to change the Mbean and the class to
> actually use a Set rather than a List?

No. Order is important for eviction. Internally it has to be a List.
Externally, the keys could be returned as a Set or a List. I don't have
any strong feelings. Regardless, we should more clearly (there is a
comment already) document the requirement for ordering of keys for
eviction somewhere in the code since it doesn't appear to be clear enough.

Mark


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

Re: svn commit: r1365732 [5/5] - in /commons/proper/collections/trunk: ./ src/main/java/org/apache/commons/collections/ src/main/java/org/apache/commons/collections/trie/ src/test/java/org/apache/comm

[Thomas Neidhart]

On 07/26/2012 01:44 PM, sebb wrote:
> On 25 July 2012 21:42,   wrote:
>> Propchange: 
>> commons/proper/collections/trunk/src/test/resources/org/apache/commons/collections/trie/hamlet.txt
>> --
>> svn:eol-style = native
>>
>> Propchange: 
>> commons/proper/collections/trunk/src/test/resources/org/apache/commons/collections/trie/hamlet.txt
>> --
>> svn:executable = *
> 
> Should not use executable for any files.

removed.

Thomas

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

[collections] hudson/jira integration

[Thomas Neidhart]

Hi,

is there a way to disable the hudson integration with jira?

Is is just annoying and confusing if build failure comments pop up in
completely unrelated issues.

Thanks,

Thomas

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

Re: [collections] hudson/jira integration

[Thomas Neidhart]

On 07/26/2012 11:41 PM, sebb wrote:
> On 26 July 2012 21:27, Thomas Neidhart  wrote:
>> Hi,
>>
>> is there a way to disable the hudson integration with jira?
> 
> Try asking on the bui...@apache.org list.

Thanks, but no feedback yet.

Thomas

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

Re: [collections] hudson/jira integration

[Thomas Neidhart]

On 07/27/2012 08:33 PM, sebb wrote:
> On 27 July 2012 19:17, Thomas Neidhart  wrote:
>> On 07/26/2012 11:41 PM, sebb wrote:
>>> On 26 July 2012 21:27, Thomas Neidhart  wrote:
>>>> Hi,
>>>>
>>>> is there a way to disable the hudson integration with jira?
>>>
>>> Try asking on the bui...@apache.org list.
>>
>> Thanks, but no feedback yet.
> 
> Huh?
> 
> I saw some a while back:
> 
> "Have a look at the post build actions of your build configuration and
> just remove the JIRA update action."

ah stupid me, I posted to a ML, just checked it.

Does anybody have the proper rights to do the changes in the build
configuration of commons-collections?

Thanks,

Thomas

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

Re: [collections] hudson/jira integration

[Thomas Neidhart]

On 07/27/2012 09:17 PM, sebb wrote:
> On 27 July 2012 20:02, Thomas Neidhart  wrote:
>> On 07/27/2012 08:33 PM, sebb wrote:
>>> On 27 July 2012 19:17, Thomas Neidhart  wrote:
>>>> On 07/26/2012 11:41 PM, sebb wrote:
>>>>> On 26 July 2012 21:27, Thomas Neidhart  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> is there a way to disable the hudson integration with jira?
>>>>>
>>>>> Try asking on the bui...@apache.org list.
>>>>
>>>> Thanks, but no feedback yet.
>>>
>>> Huh?
>>>
>>> I saw some a while back:
>>>
>>> "Have a look at the post build actions of your build configuration and
>>> just remove the JIRA update action."
>>
>> ah stupid me, I posted to a ML, just checked it.
>>
>> Does anybody have the proper rights to do the changes in the build
>> configuration of commons-collections?
> 
> Done

Thanks!

Thomas

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

Re: [pool] Question / potential improvement on KeyedObjectPool

[Mark Thomas]

On 30/07/2012 09:36, Liviu Tudor wrote:
> Thanks very much for pointing me in the right direction, Mark!
> As with all development tasks, this, however, opened up new questions --
> not entirely sure if these are best discussed on this list or whether
> occasionally I should open up a JIRA ticket for this so more than
> welcoming suggestions here.

Jira is not the place for discussions. That is best done on the dev
list. Once we have an agreed direction then we can open a Jira to track
the work.

> * on the [pool2] -- I haven't investigated the eviction mechanism in
> detail there, but I understand the need for a List and that's fine. My
> original idea was to provide a Set with all the keys for the
> KeyedObjectPool interface, as there is no need for ordering of the keys
> here (same as in Map.keySet) however, I can just as well have a List and
> provide a getKeys() in the KeyedObjectPool interface -- it will be used
> the same ultimately for my idea, which in fact needs just a collection
> (Set was preferred due to the fact that Map provides access to the keys
> via a Set and the fact that keys are unique obviously). So, in the light
> of that, which would be better to have in KeyedObjectPool interface (if
> any):
>   1/ Set keySet(); //returns a Set with all the keys in the pool
>   2/ List getKeys(); //this is already implemented part of the Mbean
> implementation in GenericKeyedObjectPool
>   3/ Collection getKeys();//this allows us to customise it in
> subclasses, so we can have List in GenericKeyedObjectPool but perhaps
> other implementation can return Set if needed

Since the keys are a Set, that seems like the most appropriate option.
I'd be happy changing the existing method to use Set. We should think
about switching the internal list as well, e.g. to a LinkedHashSet
(would need to check behaviour was unchanged).

> * Looking at [pool-1.6] -- there are a few problems with the code on that
> branch, not sure if this was abandoned or not?

Absolutely not.

> The layout of the project
> is a bit non-maven, but that is fine. Checkstyle throws a bunch of errors

Checkstyle 'errors' are not bugs. Cleaner code is nice but not essential.

> due to misconfiguration in pom.xml (which I have easily fixed). Also there
> are a bunch of FindBungs which I have fixed too.

Based on previous experience they may or may not be valid.

> There are a few unit
> tests failing which I am looking at while also trying to slot in my actual
> commit (as per below) :)

That sounds like your setup isn't quite right. The unit tests should
always pass and did on my machine the last time I touched the 1.x code.
There are also regular CI builds that check this.

> So, what are the best practices here -- separate these into a bunch of
> JIRA issues/patches :
>   1/ checkstyle fixes
>   2/ findbugs fixes
>   3/ unit test fixes
>   4/ my component
> Or just put everything into one patch?

One issue per Jira please.

Mark


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

Re: [pool] Question / potential improvement on KeyedObjectPool

[Mark Thomas]

On 30/07/2012 21:07, Liviu Tudor wrote:
> * Findbugs: indeed, some of the findbugs warnings are not entirely correct
> -- and we should probably look at using the Findbugs annotations to
> manually annotate the ones which we know to actually be false alarms?
> There were also a couple related to performance suggestions which were
> valid -- so as per your suggestion I'm going to submit a patch for those.
> Regarding the false alerts in FindBugs -- there are 2 ways to proceed with
> "removing" these alerts:
>   ** one is as I suggested above to enable the findbugs annotations in the
> pom and manually annotate those 2 methods to remove the findbugs checks
>   ** second one is to manually remove the findbugs checks via a
> findbugs-exclude.xml from the suite of findbugs tests run.
> Not sure which one do we prefer in Commons? (or more to the point in this
> case?)

Personally, I prefer findbugs-exclude.xml since that doesn't pollute the
build for folks who have no interest in FindBugs.

> * The unit test thing though puzzles me as I keep constantly get this :
> 
> Results :
> 
> Failed tests:   
> testConstructors(org.apache.commons.pool.impl.TestGenericKeyedObjectPool):
> expected:<4> but was:<2>
>   
> testConstructors(org.apache.commons.pool.impl.TestGenericKeyedObjectPoolFac
> tory): expected:<4> but was:<2>
>   
> testConstructors(org.apache.commons.pool.impl.TestGenericObjectPoolFactory)
> : expected:<4> but was:<2>
> 
> 
> When running the TestGenericKeyedObjectPool! I'm running them on a Mac --
> but checked them on a win machine with the same result. Looking closer, it
> seems to be down to the fact that the maxIdle is set to be lower than
> midIdle -- and there is logic in the GenericKeyedObjectPool to return
> maxIdle in such cases. I'm not sure therefore if the default values in the
> unit test are wrong or the logic in the GenericKeyedObjectPool is wrong?
> I'm happy to change the assert's in the unit test and submit a patch --
> but I would like this validated by someone who has been involved
> previously in this piece of code?
> Also, I would be curious to know whether the tests are indeed passing ?

They fail for me to. Odd. I would have expected a CI nag about that.

'svn log' and 'svn blame' can be very useful when determining why code
is the way it is. In this case they point to POOL-212 and it is indeed
the unit tests that are wrong.

> * Last but not the least, I see the pom references junit-4.10 but the unit
> tests are still based on the old junit-3.8 looking at it. Worth to change
> these to annotations a la junit-4?

Not for Pool 1.5. The target Java version is < 1.5. Not sure it is worth
it for 1.6 (and it easier to keep the 1.5.x and 1.6.x in sync if it is
just generics that is the difference). For Pool 2.x I don't have a
strong preference.

Mark


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

Re: [POOL] 4 broken tests Pool 1.6.x branch

[Mark Thomas]

On 30/07/2012 22:04, Gary Gregory wrote:
> Hi All:
> 
> I wonder if this change:
> 
> POOL-212. If minIdle > maxIdle use maxIdle in place of minIdle (rev 1325476
> by markt)
> 
> broke the 4 tests below.
> 
> Could the change be bogus or the tests need to be adjusted.

As per my previous message, the tests need to be updated.

Mark

> 
> My set up:
> 
> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: C:\Java\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_31\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> 
> test (2)
> org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders
> testContextClassLoader(org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders)
> junit.framework.AssertionFailedError: Wrong number of idle objects in pool1
> expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at
> org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders.testContextClassLoader(TestGenericObjectPoolClassLoaders.java:46)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> 
> org.apache.commons.pool.impl.TestGenericObjectPoolFactory
> testConstructors(org.apache.commons.pool.impl.TestGenericObjectPoolFactory)
> junit.framework.AssertionFailedError: expected:<4> but was:<2>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:199)
> at junit.framework.Assert.assertEquals(Assert.java:205)
> at
> org.apache.commons.pool.impl.TestGenericObjectPoolFactory.testConstructors(TestGenericObjectPoolFactory.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> 
> org.apache.commons.pool.impl.TestGenericKeyedObjectPoolFactory
> testConstructors(org.apache.commons.pool.impl.TestGenericKeyedObjectPoolFactory)
> junit.framework.AssertionFailedError: expected:<4> but was:<2>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework

Re: [pool] Question / potential improvement on KeyedObjectPool

[Mark Thomas]

On 30/07/2012 22:33, Gary Gregory wrote:
> On Mon, Jul 30, 2012 at 5:21 PM, Liviu Tudor  wrote:
> 
>> Mark/Gary/Seb,
>>
>> Just to clarify this: I haven't touched at all the 1.5 branch -- all of
>> these refer strictly to the 1.6 branch (which uses JDK 1.5 according to
>> the pom and also uses Junit 4.10).
>>
>> So in the light of these, should I:
>>
>> 1/ also apply these patches to the 1.5 branch?
>>
> 
> Up to you.
> 
> 
>> 2/ downgrade junit to 3.8.2 on the 1.6 branch?
>>
> 
> I do not think so, this branch is for Java >= 1.5. Why? Does JUnit 4.10 not
> run on Java 5?

1.6.x is meant to be 1.5.x plus generics. The more they diverge, the
harder they will be to keep in sync.

Mark


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

Re: Trie data structure

[Thomas Neidhart]

Hi Tommaso,

you may want to take a look at commons-collections, which now has a Trie
implementation (see https://issues.apache.org/jira/browse/COLLECTIONS-225).

The code can be found here
http://svn.apache.org/viewvc/commons/proper/collections/trunk/

Any feedback, help is welcome!

Thomas

On Wed, Aug 1, 2012 at 8:48 AM, Tommaso Teofili
wrote:

> Hi all,
>
> recently I've been working on implementing the Trie [1] data structure for
> fast retrieval given a prefix thus, since I've now a first prototype
> implementation, I was wondering if Apache Commons would be interested in
> that as a possible contribution.
> Thanks in advance and have a nice day,
>
> Tommaso
>
>
> [1] : http://en.wikipedia.org/wiki/Trie
>

Re: svn commit: r1369292 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/TestCollectionUtils.java

[Thomas Neidhart]

On 08/04/2012 11:26 AM, sebb wrote:
> On 4 August 2012 10:06,   wrote:
>> Author: tn
>> Date: Sat Aug  4 09:06:21 2012
>> New Revision: 1369292
>>
>> URL: http://svn.apache.org/viewvc?rev=1369292&view=rev
>> Log:
>> Add javadoc comment to prevent removal of a generics fix.
>>
>> Modified:
>> 
>> commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/TestCollectionUtils.java
>>
>> Modified: 
>> commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/TestCollectionUtils.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/TestCollectionUtils.java?rev=1369292&r1=1369291&r2=1369292&view=diff
>> ==
>> --- 
>> commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/TestCollectionUtils.java
>>  (original)
>> +++ 
>> commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/TestCollectionUtils.java
>>  Sat Aug  4 09:06:21 2012
>> @@ -520,10 +520,11 @@ public class TestCollectionUtils extends
>>  Collection> col = new ArrayList> extends Number>>();
>>  col.add(collectionA);
>>  col.add(collectionB);
>> -Closure> resultClosure = 
>> CollectionUtils.,Closure> Number>>>forAllDo(col, testClosure);
>> +Closure> resultClosure = 
>> CollectionUtils.forAllDo(col, testClosure);
>>  assertSame(testClosure, resultClosure);
>>  assertTrue(collectionA.isEmpty() && collectionB.isEmpty());
>> -resultClosure = CollectionUtils.forAllDo(col, null);
>> +// fix for various java 1.6 versions: keep the specialization
>> +resultClosure = CollectionUtils.> Number>,Closure>>forAllDo(col, null);
>>  assertNull(resultClosure);
>>  assertTrue(collectionA.isEmpty() && collectionB.isEmpty());
>>  resultClosure = CollectionUtils.forAllDo((Collection) null, 
>> testClosure);
>> @@ -542,6 +543,7 @@ public class TestCollectionUtils extends
>>  Closure> resultClosure = 
>> CollectionUtils.forAllDo(col.iterator(), testClosure);
>>  assertSame(testClosure, resultClosure);
>>  assertTrue(collectionA.isEmpty() && collectionB.isEmpty());
>> +// fix for various java 1.6 versions: keep the specialization
> 
> Sorry, but what does that mean?

hmm, would be "force type erasure" better?

Certain java versions can not compile the following construct:

resultClosure = CollectionUtils.forAllDo(col, null);

when the return type is derived from a null argument parameter.

Thomas

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

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Group (shared) Maven 2 Build Definition (Java 1.5)

[Thomas Neidhart]

On 08/04/2012 02:13 PM, Gilles Sadowski wrote:
> On Fri, Aug 03, 2012 at 08:47:56PM +, Continuum@vmbuild wrote:
>> Online report : 
>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=24474&projectId=97
>>
>> Build statistics:
>>   State: Failed
>>   Previous State: Failed
>>   Started at: Fri 3 Aug 2012 20:41:53 +
>>   Finished at: Fri 3 Aug 2012 20:47:54 +
>>   Total time: 6m 1s
>>   Build Trigger: Schedule
>>   Build Number: 908
>>   Exit code: 1
>>   Building machine hostname: vmbuild
>>   Operating system : Linux(unknown)
>>   Java Home version : 
>>   java version "1.6.0_30"
>>   Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
>>   Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
>> 
>>   Builder version :
>>   Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
>>   Java version: 1.6.0_30
>>   Java home: /usr/lib/jvm/jdk1.6.0_30/jre
>>   Default locale: en_US, platform encoding: ANSI_X3.4-1968
>>   OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
>> "unix"
>> 
>> 
>> SCM Changes:
>> 
>> Changed: erans @ Fri 3 Aug 2012 19:59:36 +
>> Comment: Typo.
>> Files changed:
>>   
>> /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/analysis/FunctionUtils.java
>>  ( 1369188 )
>>
>> 
>> Dependencies Changes:
>> 
>> No dependencies changed
>>
>>
>> 
>> Build Definition:
>> 
>> POM filename: pom.xml
>> Goals: clean deploy   
>> Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
>> Build Fresh: false
>> Always Build: false
>> Default Build Definition: true
>> Schedule: COMMONS_SCHEDULE
>> Profile Name: Maven 2.2.1
>> Description: Group (shared) Maven 2 Build Definition (Java 1.5)
>>
>> 
>> Test Summary:
>> 
>> Tests: 3989
>> Failures: 0
>> Errors: 2
>> Success Rate: 99
>> Total time: 290.1982
>>
> 
> On the web page referred to above, the console output indicates:
> ---
> Please refer to
> /home/continuum/continuum-base/data/working-directory/97/target/surefire-reports
> /for the individual test results.
> ---
> 
> How can I connect to the build machine in order to see the full error
> message (i.e. line number in the source file)?

On the page there is a link to the surefire reports (it's a bit
difficult to find).

There you see each test executed with a more detailed report for
failures. The stacktrace for the failing test:

org.apache.commons.math3.exception.NumberIsTooLargeException: lower
bound (65) must be strictly less than upper bound (65)
at
org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:73)
at
org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:53)
at
org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.generatePartition(AggregateSummaryStatisticsTest.java:275)
at
org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.testAggregationConsistency(AggregateSummaryStatisticsTest.java:89)


I think it should be fixed now, as you changed the test already?

Thomas

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

Re: [Math] Towards release 3.1

[Thomas Neidhart]

On 08/03/2012 10:22 PM, Gilles Sadowski wrote:
> Hello.
> 
> More than 60 issues have been resolved since the release of Commons Math
> 3.0.

The number of resolved issues in JIRA is misleading as it includes also
issues resolved as Won't Fix or Duplicate. Also not all issues have been
closed after the release of 3.0, some have been kept in status resolved
intentionally as they were marked as "Later" or "Incomplete".

> I think that it is time to lay out a road map for the next release (3.1),
> with a target date of early September (at which point, 3.0 will be 6 months
> old).

+1

> The following are the more serious issues:
>   MATH-836 Fraction(double, int) constructor strange behaviour:
 should be solved

>   MATH-828 Unbounded solutions in Simplex Solver:
 should be solved, will create another issue as follow up

>   MATH-819 Infeasible solution in Simplex Solver:
 either won't fix or not a problem, user was providing very large
 (unnecessary) bounds in the problem which lead to obvious
 numerical problems.

>   MATH-789 Correlated random vector generator fails:
 I did initial analysis, but need more information about the
 implemented algorithm to fix it

 * MATH-777 More CrossoverPolicy's are needed: partly done, need to add
 two more policies from the patch

> "Wish" or "improvement" issues that miss a patch should not be blocking the
> 3.1 release.
> Some of them are still marked with 3.1 as the target version. Please give
> your opinion about whether they could be easily implemented in the next few
> weeks, or should be postponed to release 3.2 or 4.0.

MATH-748 Clustering algos
MATH-749 Complex Hull
MATH-750 Voronoi
MATH-751 Computational geometry algos (wrapper issue for the 3 others)
MATH-752 Triangulation

I put them with target release 3.1, but they are obviously not blocking,
but I am willing to do work on them in the coming weeks.

> Please review all issues (especially those assigned to you, or reported by
> you, or where you took an active part in the discussion) and provide
> feedback on their "currentness".

see above.

Thomas

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

Re: Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/

[Thomas Neidhart]

On 08/06/2012 10:00 PM, Jörg Schaible wrote:
> 
> === %< ==
> 
> Betreff: svn commit: r1369931 - in 
> /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
>  
> keyvalue/ list/
> Absender: tn-1odqgaof3lkdnm+yrof...@public.gmane.org
> Datum: Mon, 06 Aug 2012 19:21:30 +
> Newsgruppe: gmane.comp.jakarta.commons.scm
> 
> Author: tn
> Date: Mon Aug  6 19:21:29 2012
> New Revision: 1369931
> 
> URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
> Log:
> Checkstyle fixes.
> 
> [snip]
> 
> @@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
>  }
>  
>  //---
> +
> +/** {@inheritDoc} */
>  public K getKey() {
>  return entry.getKey();
>  }
>  
> +/** {@inheritDoc} */
>  public V getValue() {
>  return entry.getValue();
>  }
>  
> +/** {@inheritDoc} */
>  public V setValue(V object) {
>  return entry.setValue(object);
>  }
> === %< ==
> 
> Geeez, what's that for an annoying change? Since Java 5 this is already the 
> default for Javadoc when overwriting/implementing methods, so adding a Javdoc 
> comment with a single @inheritDoc is completely superfluous and adds simply 
> clutter!
> 
> Can we stop Checkstyle complaining about it and revert these lines again?

If you have a better solution, I am really willing to include it.

My suggestion to go for java 6 source compatibility to be able to use
@Override tags was so far objected.

Thomas

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

Re: Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/

[Thomas Neidhart]

On Tue, Aug 7, 2012 at 10:24 AM, Jörg Schaible
wrote:

> Hi Thomas,
>
> Thomas Neidhart wrote:
>
> > On 08/06/2012 10:00 PM, Jörg Schaible wrote:
> >>
> >> === %< ==
> >>
> >> Betreff: svn commit: r1369931 - in
> >>
>
> /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
> >> keyvalue/ list/
> >> Absender: t...@apache.org
> >> Datum: Mon, 06 Aug 2012 19:21:30 +
> >> Newsgruppe: gmane.comp.jakarta.commons.scm
> >>
> >> Author: tn
> >> Date: Mon Aug  6 19:21:29 2012
> >> New Revision: 1369931
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
> >> Log:
> >> Checkstyle fixes.
> >>
> >> [snip]
> >>
> >> @@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
> >>  }
> >>
> >>
> //---
> >> +
> >> +/** {@inheritDoc} */
> >>  public K getKey() {
> >>  return entry.getKey();
> >>  }
> >>
> >> +/** {@inheritDoc} */
> >>  public V getValue() {
> >>  return entry.getValue();
> >>  }
> >>
> >> +/** {@inheritDoc} */
> >>  public V setValue(V object) {
> >>  return entry.setValue(object);
> >>  }
> >> === %< ==
> >>
> >> Geeez, what's that for an annoying change? Since Java 5 this is already
> >> the default for Javadoc when overwriting/implementing methods, so adding
> >> a Javdoc comment with a single @inheritDoc is completely superfluous and
> >> adds simply clutter!
> >>
> >> Can we stop Checkstyle complaining about it and revert these lines
> again?
> >
> > If you have a better solution, I am really willing to include it.
> >
> > My suggestion to go for java 6 source compatibility to be able to use
> > @Override tags was so far objected.
>
> @Override and the Javadoc inheritance is not related, automatic Javadoc
> inheritance works for Java 5 independently. It seems just this bogus
> Checkstyle rule, but I have nothing done with Checkstyle rules ever.
>

Yes, I am perfectly aware of this. My goal was to bring the number of
checkstyle warnings to a manageable amount, so see the real issues more
easily (now there are still more than 800 warnings).

Afaik, there is no easy way to exclude certain methods from the check, it
only works on scope level, but as these methods all have public scope, we
are somehow stuck.

Thomas

Re: svn commit: r1369332 - in /commons/proper/jcs/trunk/src/test/org/apache/jcs: ./ auxiliary/disk/block/ auxiliary/disk/file/ auxiliary/disk/indexed/ auxiliary/disk/jdbc/ auxiliary/disk/jdbc/mysql/ a

[Thomas Vandahl]

On 06.08.12 00:12, sebb wrote:
> On 4 August 2012 15:23,   wrote:
>> Author: tv
>> Date: Sat Aug  4 14:23:36 2012
>> New Revision: 1369332
>>
>> URL: http://svn.apache.org/viewvc?rev=1369332&view=rev
>> Log:
>> - Fixed lots of warnings and FindBugs issues
>> - Introduced carefully crafted @SuppressWarnings annotations
> 
> Please add a comment to each suppression to say why it is safe to ignore.

Will do. May take some time, though.

Bye, Thomas.


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

Re: [math] problems with tests due to matrix formatting

[Thomas Neidhart]

On 08/14/2012 05:25 PM, luc wrote:
> Hi,
> 
> Since a few weeks, I have lots of tests failures due to matrix formats.
> 
> I'm not sure exactly when this started, but I think this may be related
> to MATH-831 and the fix introduced as of r1364775 in late July. This
> changed the behaviour of toString in AbstractRealMatrix. The difference
> is that despite the default number of digits is set to one, matrix
> entries that happen to be integer are displayed as "1" or "0" and not as
> "1.0" or "0.0" as expected by the Junit tests.
> 
> The tests that fail for me are:
> 
> MultivariateSummaryStatisticsTest: testToString,
> SparseRealMatrixTest: testToString
> SynchronizedMultivariateSummaryStatisticsTest: testToString
> Array2DRowRealMatrixTest: testToString
> BlockRealMatrixTest: testToString
> 
> They fail both when I use eclipse and when I use maven from the command
> line.  Eclipse is configured to use Sun Java 1.5.0_22 JVM. Maven is
> configured with OpenJDK 1.6.0_24. I use a Linux computer running Debian,
> configured with the French locale (but the tests do reset the locale
> themselves).
> 
> Here is the output from Maven:
> 
> Results :
> 
> Failed tests:  
> testForgottenSeparator(org.apache.commons.math3.linear.RealMatrixFormatTest):
> expected:<7> but was:<5>
>  
> testForgottenSuffix(org.apache.commons.math3.linear.RealMatrixFormatTest):
> expected:<9> but was:<5>
>   testToString(org.apache.commons.math3.linear.BlockRealMatrixTest):
> expected:
> but was:
>  
> testToString(org.apache.commons.math3.linear.Array2DRowRealMatrixTest):
> expected:<...ay2DRowRealMatrix{{1[.0,2.0,3.0},{2.0,5.0,3.0},{1.0,0.0,8.]0}}>
> but was:<...ay2DRowRealMatrix{{1[,0,2,0,3,0},{2,0,5,0,3,0},{1,0,0,0,8,]0}}>
>   testToString(org.apache.commons.math3.linear.SparseRealMatrixTest):
> expected: but
> was:
>  
> testToString(org.apache.commons.math3.stat.descriptive.MultivariateSummaryStatisticsTest):
> expected:<...ay2DRowRealMatrix{{1[.0,-1.0},{-1.0,1.]0}}(..)
>  
> testToString(org.apache.commons.math3.stat.descriptive.SynchronizedMultivariateSummaryStatisticsTest):
> expected:<...ay2DRowRealMatrix{{1[.0,-1.0},{-1.0,1.]0}}(..)
> 
> Tests run: 4067, Failures: 7, Errors: 0, Skipped: 40
> 
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] There are test failures.
> 
> 
> Do someone else experience the same problems?

Hi Luc,

the problem is that

 * not all tests override the locale with US
 * in some locales (like yours) the decimal point is a ',' instead of a
   '.'

The RealMatrixFormat tests have to be improved to include always the
currently configured decimal separator for the expected result (as in
the RealVectorFormatTest class).

For the RealMatrix.toString, I kept the ',' as element separator for
backwards compatibility, but this will fail for certain locales, so I
guess it would be better to also set the used locale to US instead of
the local configured one to prevent such situations.

The same may also happen if some tests depend on the output of
RealVectorFormat (e.g. in ArrayRealVector), so maybe we should do the
same there?

Thomas

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

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math -

[Thomas Neidhart]

t; org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:592)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

as already agreed with Gilles, I will remove the random data tests for
EigenvalueDecomposition.

Thomas

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

Re: [Codec] Next Commons-Codec release?

[Thomas Neidhart]

On 08/16/2012 01:37 PM, Gary Gregory wrote:
> (edited message subject to add "[Codec]" prefix)
> 
> Yes, there is a certain amount of rain dancing, keeping of fingers crossed,
> and cussing involved when cutting releasing, and it's fallen off my radar
> to due other priorities.
> 
> Is the ML content by the state of the new Crypt classes in
> org.apache.commons.codec.digest?

I did some javadoc cleanup of the package.

(btw. I find non-closing  tags on a separate line the most readable
solution as outlined in the javadoc tutorial
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html

what do other people think about it?)

What is a bit odd is that the methods throw Exception although it's not
needed at all (e.g. UnixCrypt) or could be constrained to
NoSuchAlgorithmException (e.g. in Md5Crypt).

Javadoc does not yet mention the exceptions too (but I can fix that).

Thomas

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

Re: [Codec] Next Commons-Codec release?

[Thomas Neidhart]

On 08/17/2012 09:15 PM, Gary Gregory wrote:
> On Fri, Aug 17, 2012 at 2:49 PM, Thomas Neidhart
> wrote:
> 
>> On 08/16/2012 01:37 PM, Gary Gregory wrote:
>>> (edited message subject to add "[Codec]" prefix)
>>>
>>> Yes, there is a certain amount of rain dancing, keeping of fingers
>> crossed,
>>> and cussing involved when cutting releasing, and it's fallen off my radar
>>> to due other priorities.
>>>
>>> Is the ML content by the state of the new Crypt classes in
>>> org.apache.commons.codec.digest?
>>
>> I did some javadoc cleanup of the package.
>>
> 
> Thank you TN!
> 
> 
>>
>> (btw. I find non-closing  tags on a separate line the most readable
>> solution as outlined in the javadoc tutorial
>>
>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
>>
>> what do other people think about it?)
>>
> 
> It is nice and clear. I personally do not use the style but am willing to
> change ;) Since we all know that Javadoc is [X?]HTML-lite, using "broken"
> XHTML feels odd (unbalanced tags). I might be speaking from fuzzy memory
> but I vaguely recall odd things happening in combination with opening,
> closing and nesting some tags. I guess we could use  and deal with
> special cases when they come up.
> 
> 
>> What is a bit odd is that the methods throw Exception although it's not
>> needed at all (e.g. UnixCrypt)
> 
> 
> I see that with org.apache.commons.codec.digest.UnixCrypt.crypt(String)...
> nasty! Good catch!
> 
> 
>> or could be constrained to
>> NoSuchAlgorithmException (e.g. in Md5Crypt).
>>
> 
> Yes, more nastiness.
> 
> The exceptions might have been there with the though of making all of these
> classes implement a common interface. I do not seen the need for that ATM.
> We can always add it later if needed.
> 
> 
>>
>> Javadoc does not yet mention the exceptions too (but I can fix that).
>>
> 
> 
> Yes, please fix it all up as much as you can.

ok done.

Regarding the TODO in the B64 class:

I do not think that the existing Base64 implementation can be reused, as
the cipher text encoded by crypt is only "in a form of" Base64.

Actually the encoding alphabet is slightly different ('.' instead of
'+') and also the encoding itself is not the same.

Thomas

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

Re: [Codec] Next Commons-Codec release?

[Thomas Neidhart]

On 08/20/2012 10:46 PM, Gary Gregory wrote:
> TN (or anyone):
> 
> I get a lot of Checstyle errors "Missing a header - not enough lines in
> file."
> 
> Do you get those too?

Yes, indeed, I get the same errors, but I had the header check disabled
locally (I guess for the very same reason).

Thomas

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

Re: [Codec] Next Commons-Codec release?

[Thomas Neidhart]

On 08/21/2012 03:33 PM, Gary Gregory wrote:
> On Mon, Aug 20, 2012 at 5:36 PM, Thomas Neidhart
> wrote:
> 
>> On 08/20/2012 10:46 PM, Gary Gregory wrote:
>>> TN (or anyone):
>>>
>>> I get a lot of Checstyle errors "Missing a header - not enough lines in
>>> file."
>>>
>>> Do you get those too?
>>
>> Yes, indeed, I get the same errors, but I had the header check disabled
>> locally (I guess for the very same reason).
>>
> 
> Arg, we need to fix that then.

fixed. There were trailing spaces in the template header.

Thomas

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

Re: [Codec] Next Commons-Codec release?

[Thomas Neidhart]

On 08/22/2012 02:49 AM, Gary Gregory wrote:
> On Tue, Aug 21, 2012 at 4:50 PM, Thomas Neidhart
> wrote:
> 
>> On 08/21/2012 03:33 PM, Gary Gregory wrote:
>>> On Mon, Aug 20, 2012 at 5:36 PM, Thomas Neidhart
>>> wrote:
>>>
>>>> On 08/20/2012 10:46 PM, Gary Gregory wrote:
>>>>> TN (or anyone):
>>>>>
>>>>> I get a lot of Checstyle errors "Missing a header - not enough lines in
>>>>> file."
>>>>>
>>>>> Do you get those too?
>>>>
>>>> Yes, indeed, I get the same errors, but I had the header check disabled
>>>> locally (I guess for the very same reason).
>>>>
>>>
>>> Arg, we need to fix that then.
>>
>> fixed. There were trailing spaces in the template header.
>>
> 
> Arg again, I am seeing the same header problems even after an svn update...

in eclipse?

I had to restart eclipse otherwise the changes were not taken into account.

Thomas

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

Re: [math] Formatting

[Thomas Neidhart]

On Thu, Aug 23, 2012 at 1:16 PM, Sébastien Brisard <
sebastien.bris...@m4x.org> wrote:

> Hi,
>
> >
> > Probably easiest to use the Wiki for this, at least initially.
> >
> I'm not very fond of the Wiki: maybe I could just start a JIRA ticket,
> that would allow recording our discussions.
>
> > If there are compulsory rules - e.g. no tabs - a reason should be
> > given, for example:
> > Tab settings vary. This causes alignment issues, so tabs are banned.
> >
> > Generally it's easier to understand and follow rules if their purpose
> > is made explicit.
> >
> OK, so for all rules, we will try to provide a reason.
>

It would be nice to have something in common for all commons (sic!)
components ;-)

It is somehow odd that one has to switch coding style when working on
different components

Thomas

Re: [Codec] Next Commons-Codec release?

[Thomas Neidhart]

On 08/22/2012 01:23 PM, Gary Gregory wrote:

> I did the SVN update from E and the build from a Win7 command line.

Does it still not work for you? I do not get warning anymore (apart from
the generics related in StringEncoderComparator), both via the
checkstyle eclipse plugin and by doing mvn site.

btw. I did some more cleanup on the Beider-Morse code by removing debug
prints and improving the javadoc.

There are still some System.err.println in case the resource files are
corrupted, but I think we should throw an IllegalStateException in such
cases (as it is done already at some occasions). Atm I put FIXME
comments and commented the System.err lines out.

Thomas

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

Re: [math] About MATH-849 and the NSWC library

[Thomas Neidhart]

On 08/22/2012 06:43 AM, Sébastien Brisard wrote:
> Dear all,
> please review the code I've attached to MATH-849. The improvement in
> accuracy is great. I also implemented, besides logGamma(x), a new function
> -- namely Gamma(x).
> I would like to know if you feel the references to the NSWC library is fair.

Hi Sebastien,

I have looked briefly at the code so far, but apart from a very minor
thing (static final double HALF_LOG_2_PI is not used anymore), it looks
pretty good imho.

Great work!

Thomas

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

Re: [pool][dbcp] POOL-229 (move AbandonedObjectPool to pool)

[Mark Thomas]

On 22/08/2012 13:51, Phil Steitz wrote:
> Any feedback on the patch?  Should I go ahead and apply the [pool]
> patch?

Sorry for the very late review. Some comments/questions on the pool2
part (I haven't looked at DBCP):

- Why not add abandoned support to GKOP as well as GOP?
- I wasn't convinced at first about separating standard and abandoned
  config. It is growing on me but I'd be interested in hearing your
  reasons for this.
- What is the reasoning behind the tests:
  - getNumIdle() < 2
  - getNumActive() > getMaxTotal() - 3
  in borrowObject()? It would be good to document these reasons in a
  comment.
- I think an explicit state of PooledObjectState.ABANDONED would be
  clearer / easier to work with (see below).
- There are various timing issues/questions in removeAbandoned()
  - what is the lock on allObjects meant to achieve?
  - an object may be returned and re-borrowed after being added to
"remove" and before it is invalidated
- abandonedConfig should be in the config section not the JMX section


My instinct is that a checkAbandoned() method on PooledObject that
changes the state to PooledObjectState.ABANDONED and returns true if it
does this is likely to be an easier starting point for a thread-safe
solution rather than separating the timing check and the state change.

Mark

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

Re: [pool][dbcp] POOL-229 (move AbandonedObjectPool to pool)

[Mark Thomas]

On 24/08/2012 16:22, Phil Steitz wrote:
> On 8/24/12 7:42 AM, Mark Thomas wrote:
>> On 22/08/2012 13:51, Phil Steitz wrote:
>>> Any feedback on the patch?  Should I go ahead and apply the [pool]
>>> patch?
>> Sorry for the very late review. Some comments/questions on the pool2
>> part (I haven't looked at DBCP):
>>
>> - Why not add abandoned support to GKOP as well as GOP?
> 
> Could definitely be done, but GKOP is tricky because of the dual
> parameter set (per key / global) and starvation prevention stuff
> already there.  I don't see the need to add it right away, but am OK
> with the idea and might eventually get to it.

Fair enough.

>> - I wasn't convinced at first about separating standard and abandoned
>>   config. It is growing on me but I'd be interested in hearing your
>>   reasons for this.
> 
> I was in exactly the same place.  I actually coded an initial
> version combining it all, looked at it and thought it was simpler to
> keep them separate.  I do not have strong feelings either way.  I
> chose to keep them separate because a) it was a smaller change and
> b) I liked the encapsulation of abandoned object cleanup parameters
> (and not having to look at them if not using this).

Fair enough. Works for me since I was thinking pretty much the same.

>> - What is the reasoning behind the tests:
>>   - getNumIdle() < 2
>>   - getNumActive() > getMaxTotal() - 3
>>   in borrowObject()? It would be good to document these reasons in a
>>   comment.
> Hmm.  Archaeology ;)
> Seriously, I suspect the original reasoning behind this test remains
> valid for activation within borrowObject - you don't want to take
> the hit of doing an abandoned cleanup if you are flush with
> instances.  Note that there is a flag that controls whether
> borrowObject does cleanup at all (actually was in the original).

The patch is missing the AbandonedConfig file which I suspect would have
some Javadoc that would help here.

>> - I think an explicit state of PooledObjectState.ABANDONED would be
>>   clearer / easier to work with (see below).
> 
> You are probably right.
>> - There are various timing issues/questions in removeAbandoned()
>>   - what is the lock on allObjects meant to achieve?
> It was intended to ensure that remove was formed using a consistent
> snapshot.  Given the way ConcurrentHashMap works, this is not
> correct.  So there is no value in the lock.
>>   - an object may be returned and re-borrowed after being added to
>> "remove" and before it is invalidated
> Right.  That is why this check is there
>  if (pooledObject.getState() != PooledObjectState.ALLOCATED) {
> continue;
> }

You can't differentiate between still allocated (and abandoned) and
return and re-allocated.

>> - abandonedConfig should be in the config section not the JMX section
> 
> Good catch.  Will add that.
>>
>>
>> My instinct is that a checkAbandoned() method on PooledObject that
>> changes the state to PooledObjectState.ABANDONED and returns true if it
>> does this is likely to be an easier starting point for a thread-safe
>> solution rather than separating the timing check and the state change.
> 
> Can you explain more what you mean here?

The current patch does not perform the following actions in an atomic
manner:
- check to see if object is abandoned
- mark the object as abandoned / invalidate it

Currently these steps are separate. All sorts of things could happen
between the two steps. With the aim of avoiding the sort of timing bugs
that gave me a headache with POOLv1, I would much prefer to see a method
(probably on PooledObject) that checked the last used time and changed
the state atomically.

Mark

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

Re: [codec] Vacuous bit mask operation on integer value in UnixCrypt

[Thomas Neidhart]

On 08/27/2012 03:36 PM, Gary Gregory wrote:
> Hi All:
> 
> FindBugs says the following a couple of times for UnixCrypt:
> "Vacuous bit mask operation on integer value (INT_VACUOUS_BIT_OPERATION)
> 
> This is an integer bit operation (and, or, or exclusive or) that doesn't do
> any useful work (e.g., v & 0x)."
> This makes me wonder if the whole class is correct in the first place and
> if/how/why these ops got in there.
> 
> Was this translated (incorrectly) from JetSpeed's implementation? Where the
> types (int vs longs?) in JetSpeed different? Where did JetSpeed get this
> implementation?

I do not know the source of the JetSpeed implementation, but there are
several (slightly different) variants of this floating around in other
projects:

http://grepcode.com/file/repository.jboss.org/maven2/postgresql/postgresql/8.4-701.jdbc3/org/postgresql/util/UnixCrypt.java

http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.11/org/mortbay/jetty/security/UnixCrypt.java

The jetty version looks the most clean one, and as it is also Apache
license, maybe we should take this one and cleanup the code a bit?

Thomas

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

Re: [codec] Vacuous bit mask operation on integer value in UnixCrypt

[Thomas Neidhart]

On 08/28/2012 03:33 AM, Christian Hammers wrote:
> Am Tue, 28 Aug 2012 00:09:41 +0200
> schrieb Christian Hammers :
> 
>> Hello
>>
>> Am Mon, 27 Aug 2012 16:39:23 -0400
>> schrieb Gary Gregory :
>>
>>> On Mon, Aug 27, 2012 at 2:53 PM, Thomas Neidhart
>>> wrote:
>>>
>>>> On 08/27/2012 03:36 PM, Gary Gregory wrote:
>>>>> Hi All:
>>>>>
>>>>> FindBugs says the following a couple of times for UnixCrypt:
>>>>> "Vacuous bit mask operation on integer value
>>>>> (INT_VACUOUS_BIT_OPERATION)
>>>>>
>>>>> This is an integer bit operation (and, or, or exclusive or) that
>>>>> doesn't
>>>> do
>>>>> any useful work (e.g., v & 0x)."
>>>>> This makes me wonder if the whole class is correct in the first
>>>>> place and if/how/why these ops got in there.
>>>>>
>>>>> Was this translated (incorrectly) from JetSpeed's
>>>>> implementation? Where
>>>> the
>>>>> types (int vs longs?) in JetSpeed different? Where did JetSpeed
>>>>> get this implementation?
>>>>
>>>> I do not know the source of the JetSpeed implementation, but there
>>>> are several (slightly different) variants of this floating around
>>>> in other projects:
>>>>
>>>>
>>>> http://grepcode.com/file/repository.jboss.org/maven2/postgresql/postgresql/8.4-701.jdbc3/org/postgresql/util/UnixCrypt.java
>>>>
>>>>
>>>> http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.11/org/mortbay/jetty/security/UnixCrypt.jav
>>>>
>>>> The jetty version looks the most clean one, and as it is also
>>>> Apache license, maybe we should take this one and cleanup the
>>>> code a bit?
>>>>
>>>
>>> The first thing to try would be to drop in the Jetty impl (I looked
>>> at the one in the 8.1 version) and see our unit tests run unchanged
>>> (aside from the different APIs). I cannot do this today though. Feel
>>> try to try ;)
>>>
>>> Gary
>>
>> The original Jetspeed source also had this "v & 0x":
>>   
>> http://www.javadocexamples.com/java_source/org/apache/jetspeed/services/security/ldap/UnixCrypt.java.html
>>   http://archive.apache.org/dist/jakarta/jetspeed/jetspeed-current-src.zip 
>>
>> But I will have a look now how the Jetty source looks in comparison...
> 
> The Aki Yoshida version from Jetty does not pass the UTF-8 unit tests:
> It gives the same result for ASCII inputs and also for a single 0x80
> but two consecutive bytes > 0x80 like 0xC3 0xA4 for "ä" gives a
> different result than "perl -e 'print crypt("ä", "xx");'.
> As it looks totally different than all the other UnixCrypt
> implementations I have no clue how to fix it.
> 
> Regarding the other ones, most of them have a common ancestors in
> John Dumas Java port which is the one with the "v & 0x".
> http://www.dynamic.net.au/christos/crypt/ gives a nice
> genealogy overview :)
> 
> The first one mentioned there, from Davit Scott, also works but is
> not only significantly slower than all the other ones but also
> does not have a clear license statement so I doubt that we could
> use it.
> 
> Our current version, which is similar to the PostgreSQL JDBC one
> mentioned above, passes all tests without the "0x" though.
> As it "int" is defined as a 4 bytes in the JLS 4.2.1 and not platform
> dependend like in C, we could just remove it and make FindBugs happy.
> 
> Apropos, "Math.abs(r.nextInt()) % numSaltChars" could be replaced by
> "r.nextInt(numSaltChars)" and FindBugs would be completely
> clean for this file.

Interesting is also that in the postgresql variant, the bitwise and
operation is using a slightly different argument:

 c &= 0x0fff;

So they must have made this observation too because the rest of the code
looks very much the same.

Thomas

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