Github user mridulm commented on the pull request:

    https://github.com/apache/spark/pull/569#issuecomment-42132244
  
    If we are depending on something and bundling it, we might as well use it
    instead of duplicating code and having to maintain the changes : assuming
    it is intutive to use.
    Since apache commons is used by whole bunch of projects, bugs would be
    better reported and fixed there than hacked up code within spark.
    
    The long term maintenance cost adds up for these 'small' changes.
    Things like os.name.tolowercase startswith windows or file.separator ==\\
    are hacks we should avoid and let others handle if being maintained.
    
    Regards
    Mridul
    On May 4, 2014 12:55 PM, "Sean Owen" <[email protected]> wrote:
    
    > Yes, but those are transitive dependencies. core happens to bring in both
    > lang and lang3, and this was using the old lang dependency even. It would
    > be correct-er to either depend directly on it, or not use it. To me it
    > seems better to inline what amounts to one-liner access of a standard
    > system property.
    >
    > I think it's also true that Guava is the go-to utility package and would
    > be better to use Guava where possible rather than encourage use of lang 
too.
    >
    > The use of lang3 in ReplSuite should also either be 'inlined', or else
    > supplemented with a direct test-scope dependency. It's just a test, so not
    > as big of an issue. I think the one use can even be replaced with a simple
    > escape, which I presume is there to handle backslash on Windows.
    >
    > —
    > Reply to this email directly or view it on 
GitHub<https://github.com/apache/spark/pull/569#issuecomment-42126473>
    > .
    >


---
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 [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to