brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrew.kenn...@cloudsoftcorp.com>
Subject Re: Moving PortRange to utils?
Date Wed, 20 Aug 2014 19:23:05 GMT
+1

The changes sound reasonable, including the project move. The Guava method
naming conventions and patterns are familiar to most Java developers, so it
makes sense to copy them where we can. I really think the impact on
downstream projects will be minimal, to be honest. There can't be many
implementations at the moment, apart from Brooklyn itself, anyway.

Andrew.
-- 
-- andrew kennedy ? cloudsoft & software engineer : @grkvlt ;
On 5 Aug 2014 21:21, "Aled Sage" <aled.sage@gmail.com> wrote:

> Hi all,
>
> A couple of suggestions for PortRanges [1].
>
> First, I'd also like to add the static methods PortRanges.of(int) and
> PortRanges.of(String). Currently the methods are
> PortRanges.fromInteger(int) and PortRanges.fromString(String).
>
> The overloaded of() method feels simpler to use, and also more consistent
> with guava (whose naming conventions we follow in other places).
>
> ---
> I'm considering moving PortRange (and PortRanges) to brooklyn's
> utils/common project (in package brooklyn.util.net), next to Networking.
>
>
> Currently the interface is in the api project
> (brooklyn.location.PortRange), and PortRanges is in core
> (brooklyn.location.basic.PortRanges).
>
> The reasons for moving it are:
>
>  * PortRange and PortRanges being next to each other will make the code
>    easier to navigate / more discoverable for a newbee.
>  * They feel like utility classes/methods, rather than the "api" of
>    Brooklyn.
>  * It will allow Networking etc to have utilities that work with PortRange.
>
> For backwards compatibility, we'd leave the old PortRange and PortRanges
> (extending the new ones). The methods in the old brooklyn.location.basic.PortRanges
> would return an old-style brooklyn.location.PortRange.
>
> The tricky bit is brooklyn.location.PortSupplier with its method
> obtainPort(brooklyn.location.PortRange). Changing that signature to use
> the new interface will break all existing implementations. I think we can
> live with that.
>
>
> Thoughts?
>
> Aled
>
> [1] https://github.com/apache/incubator-brooklyn/blob/
> master/core/src/main/java/brooklyn/location/basic/PortRanges.java
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message