[GitHub] commons-fileupload pull request #8: FILEUPLOAD-283: add tests for the portle...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-fileupload/pull/8


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [FUNCTOR] Why do we have an API module?

[Benedikt Ritter]

Hi Matt,

what is your opinion in this topic (targeting Java 8)

Benedikt

Matt Benson  schrieb am Sa. 24. Juni 2017 um 19:18:

> If we want to repurpose functor for Java 8 then I imagine we'd just
> use their interfaces, for the most part. So the API module would
> indeed probably go away.
>
> Matt
>
> On Sat, Jun 24, 2017 at 12:08 PM, Benedikt Ritter 
> wrote:
> > Hi,
> >
> >> Am 16.06.2017 um 13:03 schrieb Matt Benson :
> >>
> >> Yes, the point of the API module was to define the functional interfaces
> >> separately from the utility code around them; particularly pre-Java 8,
> >> these could be used apart from the utility code from the core.
> >
> > Since we discussed to just release functor for Java 8, do we still need
> this separation?
> >
> > Cheers,
> > Benedikt
> >
> >>
> >> Matt
> >>
> >> On Jun 16, 2017 4:27 AM, "Bruno P. Kinoshita"
> >>  wrote:
> >>
> >> No objection here too. I've been gathering some links about other
> libraries
> >> and extensions to Java 8, to have a look at functor in the future and
> see
> >> if it would be interesting to have something there, unless it made more
> >> sense to put it on lang.
> >>
> >>
> >> The reason for the API module, if memory serves me well, was to provide
> a
> >> pre Java 8 implementation. This way we would have
> >>
> >> - api
> >> - an implementation for Java 7
> >> - an implementation Java 8 that used Lambdas
> >>
> >> Though right now, with Java 9 around the corner, a single module,
> trying to
> >> provide useful code that doesn't fit in lang would be better IMHO.
> >>
> >> Hope that helps.
> >>
> >> Thanks
> >> Bruno
> >> 
> >> From: Benedikt Ritter 
> >> To: Commons Developers List 
> >> Sent: Friday, 16 June 2017 9:04 PM
> >> Subject: [FUNCTOR] Why do we have an API module?
> >>
> >>
> >>
> >> Hi,
> >>
> >>
> >> I’m about to start work on functor. Looking at the project, I wonder
> why we
> >> have a separation bewteen an API module and implementations. This feels
> >> like overkill to me for a project like functor. Further more I don’t see
> >> other parties extending the stuff in the API module. If nobody objects,
> I’d
> >> like to remove the multi-module build and move everything into a single
> >> code base.
> >>
> >>
> >> Regards,
> >>
> >> Benedikt
> >>
> >> -
> >>
> >> 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [FUNCTOR] Why do we have an API module?

[Benedikt Ritter]

Hi,

> Am 16.06.2017 um 13:03 schrieb Matt Benson :
> 
> Yes, the point of the API module was to define the functional interfaces
> separately from the utility code around them; particularly pre-Java 8,
> these could be used apart from the utility code from the core.

Since we discussed to just release functor for Java 8, do we still need this 
separation?

Cheers,
Benedikt

> 
> Matt
> 
> On Jun 16, 2017 4:27 AM, "Bruno P. Kinoshita"
>  wrote:
> 
> No objection here too. I've been gathering some links about other libraries
> and extensions to Java 8, to have a look at functor in the future and see
> if it would be interesting to have something there, unless it made more
> sense to put it on lang.
> 
> 
> The reason for the API module, if memory serves me well, was to provide a
> pre Java 8 implementation. This way we would have
> 
> - api
> - an implementation for Java 7
> - an implementation Java 8 that used Lambdas
> 
> Though right now, with Java 9 around the corner, a single module, trying to
> provide useful code that doesn't fit in lang would be better IMHO.
> 
> Hope that helps.
> 
> Thanks
> Bruno
> 
> From: Benedikt Ritter 
> To: Commons Developers List 
> Sent: Friday, 16 June 2017 9:04 PM
> Subject: [FUNCTOR] Why do we have an API module?
> 
> 
> 
> Hi,
> 
> 
> I’m about to start work on functor. Looking at the project, I wonder why we
> have a separation bewteen an API module and implementations. This feels
> like overkill to me for a project like functor. Further more I don’t see
> other parties extending the stuff in the API module. If nobody objects, I’d
> like to remove the multi-module build and move everything into a single
> code base.
> 
> 
> Regards,
> 
> Benedikt
> 
> -
> 
> 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: [configuration] checkstyle fails build

[Oliver Heger]

Should changes related to the setup and handling of checkstyle then be
done for Commons as a whole?

Oliver

(No P.S.)

Am 23.06.2017 um 21:19 schrieb Gary Gregory:
> I
> 
> P.S.
> 
> Agree
> 
> P.P.S.
> 
> With
> 
> P.P.P.S.
> 
> you!
> 
> Gary
> 
> On Jun 23, 2017 10:28, "Simon Spero"  wrote:
> 
>> On Jun 23, 2017 11:03 AM, "Oliver Heger" 
>> wrote:
>>
>> However, letting the build fail because of checkstyle error is too
>> restrictive IMHO. My approach is to work through the errors before creating
>> a new release. This has the disadvantage that errors might accumulate; but
>> from one release to the next one there is typically not that much.
>>
>>
>> That's still my gut feeling- checkstyle build fails are infuriating - but
>> annoyingly there are issues doing things at the release stage that are
>> worse  
>>
>> The big problem is related to recent discussions about code styles and
>> commits, and the diff bloats and blame/praise shifting that happen when
>> formatting drifts during a development cycle.  Things turn out much better
>> if formatting / style checking is done before a commit, or at least fails
>> the build so that things can be fixed and disappeared if a PR is merged as
>> a SquashBase (so a change  + a revert cancels out ).
>>
>> IntelliJ has a checkstyle plugin, which, um, checks for checkstyle
>> violations. This can run as a real time inspection, or during pre-commit
>> analysis. It can also adjust code formatting options to match the
>> checkstyle profile,which helps avoid many issues in the first place.
>> Eclipse has  similar support, but I am not an Eclipse user so I don't know
>> the details.
>>
>> The validate phase checkstyle execution then becomes more of a backstop
>> (validation is usually the right phase, since that is prior to
>> compilation).  It's a lot less annoying if it doesn't have too many
>> "violations".
>>
>> Since checkstyle can be configured to allow a small number of violations,
>> and to only treat rule-breakings above a certain severity  as violations
>> (error by default, but a pre-release execution could increase fussiness to
>> include warnings).
>>
>> One thing that is tricky, but which can be worth it, is having a pseudo
>> flag-day reformatting, where you use an ide to apply the code style to the
>> entire project, then apply the changes all at once (possibly using a
>> disposable committer, though this isn't as important if the annotate view
>> you use shows a bit of commit message).
>>
>> It is a bit more effort if there a bunch of unmerged branches, but since
>> the formatting changes  are automated, they can be applied on the branch so
>> it's not *that* horrible to get a mergeable branch back.
>>
>> History checking for a few lines may require going one revision back, but
>> having all the format fixes in a single commit is a lot better than having
>> them mixed in with real changes.
>>
>> Simon
>>  P. S.
>>
>> I prefer the builtin /google_checks.xml styleguide to the older sun_checks,
>> partly because it's more up to date, and partly because Google provides
>> native  ide configuration files for Eclipse and intellij so there's no need
>> to import the checkstyle file.
>> The Checkstyle plugin  tracks the Google style guide pretty closely, so as
>> long as the plugin is up to date, there won't be much divergence. The most
>> significant changes happen when there are new constructs to consider (e.g.
>> lambda).
>>
>> P.P.S.
>> I do think the google rules are wrong about horizontal alignment (at least
>> for continuation lines). It makes a huge difference when you have to use
>> obnoxious amounts of chained methods (can't say fluent without saying flu).
>>
>>
>> P.P.S.
>> I do like their tip on the appropriate use of finalize:
>>
>> *Tip:* Don't do it. If you absolutely must, first read and understand
>> *Effective
>> Java* Item 7,  "Avoid
>> Finalizers," very carefully, and *then* don't do it.
>>
>> I say finalizers are OK as long as they  warn, and don't actually  do
>> anything ("you didn't commit a batch insert of 10M items. Were you sure?
>> Yes / Tough").
>>
> 


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

Re: Some ideas for improving Travis build performance improvements:

[Stefan Bodewig]

Hi Simon et al

I'm not sure what we are using Travis CI for in the first place. Maybe
we can minimize build time by reducing the build to the utter minimum
required to achieve that - whatever that is?

Honestly I don't see anything we couldn't do with our Jenkins
installation as well. Maybe having Coveralls for pull requests, but
that's it (and Coveralls itself seems to produce random ups and downs
occasionally).

Stefan

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

[GitHub] commons-text pull request #54: TEXT-93: RandomStringGenerator accepts a list...

[ameyjadiye]

Github user ameyjadiye commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/54#discussion_r123877950
  
--- Diff: src/main/java/org/apache/commons/text/RandomStringGenerator.java 
---
@@ -76,23 +78,29 @@
 private final TextRandomProvider random;
 
 /**
+ * The source of provided charachters.
+ */
+private final List characterList;
+
+/**
  * Constructs the generator.
- *
- * @param minimumCodePoint
+ *  @param minimumCodePoint
  *smallest allowed code point (inclusive)
  * @param maximumCodePoint
  *largest allowed code point (inclusive)
  * @param inclusivePredicates
- *filters for code points
- * @param random
- *source of randomness
+ *filters for code points
--- End diff --

yeah, seems like IntelliJ did this unknowingly, fixed it!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text issue #54: TEXT-93: RandomStringGenerator accepts a list of val...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/54
  

[![Coverage 
Status](https://:/builds/12116448/badge)](https://:/builds/12116448)

Coverage decreased (-0.02%) to 97.305% when pulling 
**9db77088ecc557c2f209dd36972746d6de8dfc4a on ameyjadiye:TEXT-93** into 
**569dbc09402a6f28334936567a597e3d0db9185c on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-fileupload issue #8: FILEUPLOAD-283: add tests for the portlet packa...

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-fileupload/pull/8
  
No objections so far, will merge it tomorrow after reviewing the code once 
more :+1: 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] commons-text pull request #54: TEXT-93: RandomStringGenerator accepts a list...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/54#discussion_r123874569
  
--- Diff: src/main/java/org/apache/commons/text/RandomStringGenerator.java 
---
@@ -76,23 +78,29 @@
 private final TextRandomProvider random;
 
 /**
+ * The source of provided charachters.
+ */
+private final List characterList;
+
+/**
  * Constructs the generator.
- *
- * @param minimumCodePoint
+ *  @param minimumCodePoint
  *smallest allowed code point (inclusive)
  * @param maximumCodePoint
  *largest allowed code point (inclusive)
  * @param inclusivePredicates
- *filters for code points
- * @param random
- *source of randomness
+ *filters for code points
--- End diff --

Indentation got a bit messed up here, and the param entry for 
minimumCodePoint too


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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