Github user ameyjadiye commented on the issue:
https://github.com/apache/commons-text/pull/44
Hi @britter, there is no issue even in checkstyle with my changes, above
Travis build failed because there was some trailing space issue in master and
which you have already fixed. merging t
Hi,
> Am 07.06.2017 um 15:09 schrieb Jörg Schaible :
>
> Stefan Bodewig wrote:
>
>> On 2017-06-07, Benedikt Ritter wrote:
>>
>>> here [1] is my proposal on how to add the Automatic-Module-Name entry
>>> to MANIFEST. This just duplicates the maven-jar-plugin configuration
>>> from parent pom. I
Github user britter commented on the issue:
https://github.com/apache/commons-text/pull/44
@chtompki did you run chirr manually? Because it was checkstyle which
caused the Travis build to fail (trailing white spaces). I think this change
should not break BC. @ameyjadiye can you please
> On Jun 7, 2017, at 8:31 PM, Gary Gregory wrote:
>
>> On Wed, Jun 7, 2017 at 5:30 PM, Gary Gregory wrote:
>>
>>
>>
>>> On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins wrote:
>>>
>>>
>>>
On Jun 7, 2017, at 8:20 PM, Gary Gregory
>>> wrote:
The ASC does not seem to have a pu
On Wed, Jun 7, 2017 at 5:30 PM, Gary Gregory wrote:
>
>
> On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins wrote:
>
>>
>>
>> > On Jun 7, 2017, at 8:20 PM, Gary Gregory
>> wrote:
>> >
>> > The ASC does not seem to have a public key.:
>> >
>> > gpg --verify commons-fileupload-1.3.3-source-release.zip
On Wed, Jun 7, 2017 at 5:27 PM, Rob Tompkins wrote:
>
>
> > On Jun 7, 2017, at 8:20 PM, Gary Gregory wrote:
> >
> > The ASC does not seem to have a public key.:
> >
> > gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> > gpg: assuming signed data in 'commons-fileupload-1.3.3-
> sour
> On Jun 7, 2017, at 8:20 PM, Gary Gregory wrote:
>
> The ASC does not seem to have a public key.:
>
> gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
> gpg: assuming signed data in 'commons-fileupload-1.3.3-source-release.zip'
> gpg: Signature made 12/04/16 05:15:02 Pacific Stand
The ASC does not seem to have a public key.:
gpg --verify commons-fileupload-1.3.3-source-release.zip.asc
gpg: assuming signed data in 'commons-fileupload-1.3.3-source-release.zip'
gpg: Signature made 12/04/16 05:15:02 Pacific Standard Time using DSA key
ID 7188601C
*gpg: Can't check signature: No
Hello everyone,
I am new to the ASF community and decided to grab something easy to
attempt. I decided to take a shot at:
https://issues.apache.org/jira/browse/NUMBERS-40.
The rationale of implementing this design would be this:
GammaException is currently a subclass of IllegalArgumentException b
Hello.
On Wed, 7 Jun 2017 23:52:59 +0530, Amey Jadiye wrote:
Hi,
I was trying to run all checks on commons-number and found findbug is
failing in Precision.java[544] FE_FLOATING_POINT_EQUALITY
{code}
case BigDecimal.ROUND_HALF_EVEN : {
double fraction = unscaled - Math.floor(unscal
On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero wrote:
> As Bertrand mentioned earlier, the bundle:baseline goal is built in to the
> maven-bundle-plugin already in use!
>
> The pull-request adds that goal to the verify phase of the maven build (and
> changes the travis config to run 'mvn verify'
Hi,
I was trying to run all checks on commons-number and found findbug is
failing in Precision.java[544] FE_FLOATING_POINT_EQUALITY
{code}
case BigDecimal.ROUND_HALF_EVEN : {
double fraction = unscaled - Math.floor(unscaled);
if (fraction > 0.5) {
unscaled
As Bertrand mentioned earlier, the bundle:baseline goal is built in to the
maven-bundle-plugin already in use!
The pull-request adds that goal to the verify phase of the maven build (and
changes the travis config to run 'mvn verify' instead of 'mvn test' ). The
baseline goal is set to fail the b
Github user ameyjadiye commented on the issue:
https://github.com/apache/commons-text/pull/44
Hi @chtompki , since commons-text is relatively new there are very [low
usage](https://mvnrepository.com/artifact/org.apache.commons/commons-text),
```clirr:check``` is also passed whoever is
Hello.
On Wed, 07 Jun 2017 12:53:42 +, Amey Jadiye wrote:
Hi Gilles,
Thanks for inputs, I will generate some stats with jmh let's see if
we are
getting benefits with my proposal.
Mean time I have submitted test cases[1] for NUMBERS-38, please
review.
Tabs is a "no-no". ;-)
I find it
On 2017-06-07, Jörg Schaible wrote:
> Stefan Bodewig wrote:
>> On 2017-06-07, Benedikt Ritter wrote:
>>> here [1] is my proposal on how to add the Automatic-Module-Name entry
>>> to MANIFEST. This just duplicates the maven-jar-plugin configuration
>>> from parent pom. I don’t want to wait much l
Github user chtompki commented on the issue:
https://github.com/apache/commons-text/pull/44
The change is generally all right with me, but we can't release this until
a 2.X release though because of signature changes.
---
If your project is set up for it, you can reply to this email
Stefan Bodewig wrote:
> On 2017-06-07, Benedikt Ritter wrote:
>
>> here [1] is my proposal on how to add the Automatic-Module-Name entry
>> to MANIFEST. This just duplicates the maven-jar-plugin configuration
>> from parent pom. I don’t want to wait much longer to release
>> 3.6. After we have im
Hi Gilles,
Thanks for inputs, I will generate some stats with jmh let's see if we are
getting benefits with my proposal.
Mean time I have submitted test cases[1] for NUMBERS-38, please review.
[1] https://github.com/apache/commons-numbers/pull/5
Regards,
Amey
On Wed, Jun 7, 2017, 4:44 AM Gille
> On Jun 7, 2017, at 3:19 AM, Bruno P. Kinoshita
> wrote:
>
> [ X ] +1 Release it.
>
> All tests pass, artifacts generated successfully, and site correctly
> generated too with `mvn clean test install -e -X` on the following
> environments.
>
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c094
On 2017-06-07, Benedikt Ritter wrote:
> here [1] is my proposal on how to add the Automatic-Module-Name entry
> to MANIFEST. This just duplicates the maven-jar-plugin configuration
> from parent pom. I don’t want to wait much longer to release
> 3.6. After we have implemented a more general soluti
> On Jun 7, 2017, at 4:25 AM, Benedikt Ritter wrote:
>
> Hi,
>
> here [1] is my proposal on how to add the Automatic-Module-Name entry to
> MANIFEST. This just duplicates the maven-jar-plugin configuration from parent
> pom. I don’t want to wait much longer to release 3.6. After we have
> im
This looks fine in terms of what it does. Obviously not ideal to have
the copying, but that is the right choice to make right now.
Stephen
On 7 June 2017 at 09:25, Benedikt Ritter wrote:
> Hi,
>
> here [1] is my proposal on how to add the Automatic-Module-Name entry to
> MANIFEST. This just dup
On Wed, 7 Jun 2017 10:54:54 +0100, sebb wrote:
On 7 June 2017 at 09:02, Bertrand Delacretaz
wrote:
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg
wrote:
Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
... Implementing semantic versioning at the java package level as
opposed
to bundle le
On 7 June 2017 at 09:02, Bertrand Delacretaz wrote:
> On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg wrote:
>> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>>... Implementing semantic versioning at the java package level as opposed
>>> to bundle level.
>>
>> That's the theory, I'm actuall
Hi,
here [1] is my proposal on how to add the Automatic-Module-Name entry to
MANIFEST. This just duplicates the maven-jar-plugin configuration from parent
pom. I don’t want to wait much longer to release 3.6. After we have implemented
a more general solution in parent pom, we can revert this fi
Hi,
> Am 23.05.2017 um 12:13 schrieb Emmanuel Bourg :
>
> Le 23/05/2017 à 00:52, Stephen Colebourne a écrit :
>
>> One final option is to declare an optional dependency on java.desktop,
>> such that the AbstractCircuitBreaker will fail to load unless the
>> end-user manually chooses to add java.
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg wrote:
> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>... Implementing semantic versioning at the java package level as opposed
>> to bundle level.
>
> That's the theory, I'm actually curious to see what real issue it solves
> with commons-co
Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
> With the right tools as mentioned in my previous message it's quite easy.
Easier but not easy.
> Implementing semantic versioning at the java package level as opposed
> to bundle level.
That's the theory, I'm actually curious to see what re
> Anyway, FILEUPLOAD-279 is not there, but this shouldn't be a blocker.
Just to be clear, it is not in
http://home.apache.org/~chtompki/commons-fileupload-1.3.3-RC5/changes-report.html,
but it's correctly displayed in my local generated site. So no issues I think.
Bruno
_
On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg wrote:
> ...Do I understand well that we would have to micro manage versions at the
> package level different from the version at the component level, and
> sometimes significantly different versions (like foo 1.2.3 and
> org.apache.commons.foo.bar 2.
[ X ] +1 Release it.
All tests pass, artifacts generated successfully, and site correctly generated
too with `mvn clean test install -e -X` on the following environments.
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T05:41:47+13:00)
Maven home: /opt/maven
Java version
Le 7/06/2017 à 02:10, Jörg Schaible a écrit :
> Your opinions?
Do I understand well that we would have to micro manage versions at the
package level different from the version at the component level, and
sometimes significantly different versions (like foo 1.2.3 and
org.apache.commons.foo.bar 2.3
33 matches
Mail list logo
