Re: [VOTE] Migrate existing Git repos to GitBox

[Gilles]

On Sun, 22 Apr 2018 14:11:46 -0500, Matt Sicker wrote:

An example project already using gitbox is whimsy:
https://github.com/apache/whimsy


And "Commons Geometry":
  https://gitbox.apache.org/repos/asf?p=commons-geometry.git

Commits were pushed to that "remote".

Gilles


On 22 April 2018 at 14:06, ajs6f  wrote:

I have asked INFRA about this (for another project) and they 
confirmed
that GitBox runs the mirroring Github => Apache, so that PRs can be 
merged
at Github. I did not ask about whether commits can also be pushed 
directly

to Apache.

ajs6f

> On Apr 22, 2018, at 3:03 PM, Matt Sicker  wrote:
>
> On 22 April 2018 at 13:34, Ralph Goers 


wrote:
>
>> For example, with GitBox can we now merge pull requests directly 
at
>> GitHub? That would be a nice benefit.  Can we still commit to the 
ASF

git
>> repo or only at GitHub?
>>
>
> From my understanding, you can merge PRs directly via the UI (or 
the

"hub"
> command line tool). As for where you push code, it seems to be 
driven

from
> either repository (apache or github), though that might be 
configurable

to
> avoid history conflicts.
>
>
> --
> Matt Sicker 



-
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: [geometry] Points and Vectors Proposal

[Gilles]

Hi.

On Mon, 23 Apr 2018 05:36:09 +, Matt Juntunen wrote:

Hi all,

I'd like to propose an update to the Euclidean Point/Vector classes
in the geometry project. We currently have a single CartesianXD class
per dimension (eg, Cartesian2D) that implements both the Point and
Vector interfaces. This is similar to the previous commons-math
version where we had VectorXD classes that were also both Points and
Vectors. The change to the current version was through discussion on
MATH-1284 (https://issues.apache.org/jira/browse/MATH-1284). My
proposal is to flip the current inheritance hierarchy so that the
CartesianXD classes become the base classes for separate PointXD and
VectorXD classes.


The hierarchy would be wrong from a conceptual POV: A vector can be
described by Cartesian coordinates, but it should be possible to
introduce new coordinate systems (polar in 2D, spherical in 3D) and
algorithms that use vectors would/should still work (transparently
doing the appropriate conversions if necessary).


PointXD classes only implement the Point interface
and VectorXD classes only implement Vector. The Cartesian base 
classes

contain the actual x, y, z coordinate values along with a few other
common methods (such as getSpace()). For performance and convenience,
we can create static methods in the VectorXD classes that accept the
Cartesian base class instances, so that users can perform common
vector operations using either type. For example, if you have a giant
list of Points, these static methods would allow you to compute dot
products without needing to convert the Point instances to Vectors
first.


I understand (and agree with) the performance goal, but let's
be careful to not define an API that does not correspond to
the underlying concepts.

What will happen when we introduce
  Spherical3D(r, theta, phi)
alongside
  Cartesian3D(x, y, z)
?


I've partially implemented this in a branch so you can get a better
idea of what I'm picturing:
https://github.com/darkma773r/commons-geometry/tree/point-vector.  
The

commons-geometry-core and commons-geometry-euclidean sub-modules
contain the changes.

[https://avatars1.githubusercontent.com/u/3809623?s=400&v=4]


darkma773r/commons-geometry
commons-geometry - Apache Commons Geometry
github.com



The main benefit I see from this approach is code clarity. The intent
of the code seems much clearer to me when the names of the types
exactly match what they represent mathematically. For example, one of
the constructors for the Plane class currently looks like this:

public Plane(final Cartesian3D p, final Cartesian3D normal, final
double tolerance)

With my proposed changes, it would look like this:

public Plane(final Point3D p, final Vector3D normal, final double 
tolerance)


The code is easier to read and the compiler will also help prevent
algorithm errors.


That API is better indeed.

If "Cartesian3D" _implements_ "Point3D" and "Vector3D", it
would still work (i.e. refactor so that "Point3D" becomes
an interface and does not assume that the coordinates are
Cartesian).

Best regards,
Gilles



Thoughts?

Regards,
Matt Juntunen



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

Re: [DISCUSS] new component for timing?

[Otto Fowler]

Bump


On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com) wrote:

There has been no comment, do we need an explicit vote?


On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com) wrote:

So do we need a vote?  What is next to move this forward?


On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) wrote:

OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) wrote:

On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 
wrote:

> How about commons-timing, having StopWatch, StackWatch and other classes
> that
> we can find?
>

I think we start small with only what we need and have today, namely these
two classes.

Gary


>
>
>
> On March 20, 2018 at 18:40:05, Romain Manni-Bucau (rmannibu...@gmail.com)
> wrote:
>
> I would be happy to revive sirona @asf but dont think [monitoring] as just
> a few classes would bring enough value compare to a lambda not worthing
any
> lib/dep in apps - just my opinion indeed.
>
> For circuit breaker: geronimo safeguard can be interested in hosting that
> utility part and drop failsafe dependency. Maybe something to discuss in
> another thread.
>
> Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :
>
> > Sirona is gone, it is a closed incubator project. Romain has forked it
to
> > his own repo.
> >
> >
> >
> > On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > > If monitoring was started a new, and not re-viving the old
> > > monitoring?
> >
> > Can the feature be contributed to "Sirona"? Otto, are you
> > interested in this?
> > Does it make sense to have "Commons Monitoring" revived based
> > on part/all of "Sirona"?
> > Romain, are you interested in this?
> > What would be the scope/description of "Commons Monitoring"?
> >
> > Noting Romain's experience that the original "Commons" project
> > evolved into "Sirona", it would be strange to start from scratch
> > without a plan to not follow the same route again...
> >
> > Gilles
> >
> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > > brunodepau...@yahoo.com.br.invalid) wrote:
> > >
> > > I think StopWatch and CircuitBreakers could be moved together to the
> > > same
> > > component. However, a circuit breaker can be time-related, or not
> > > (e.g. a
> > > circuit breaker for memory size). So probably commons-timing could be
> > > a
> > > good place for StopWatch, but maybe not for circuit-breaker. But I
> > > think
> > > both could be under commons-monitoring perhaps?
> > >
> > > From: Otto Fowler 
> > > To: Romain Manni-Bucau ; Commons Developers
> > > List <
> > > dev@commons.apache.org>
> > > Sent: Wednesday, 21 March 2018 10:30 AM
> > > Subject: Re: [DISCUSS] new component for timing?
> > >
> > > I would love to get this on track. I apologize if I have made it
> > > more
> > > confusing than it needs to be,
> > > I’m trying to be open to all the suggestions.
> > >
> > > If we assume that stack watch is worth ‘having’, then the question is
> > > where
> > > to put it.
> > > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > > as
> > > opposed to
> > > a set of or collection of like classes.
> > >
> > > Setting the community support / project aspect of sirota aside, it
> > > seems
> > > strange to put
> > > a separate class into a more complete and uniform system. Unless
> > > there is
> > > some generically
> > > useful set of timing utility classes that could be taken out of
> > > sirota to
> > > go into commons-,
> > > along with things identified ( StopWatch?) out of commons lang and
> > > possibly
> > > other commons projects.
> > >
> > > commons-timing seems reasonable. Thoughts?
> > >
> > >
> > >
> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > > (rmannibu...@gmail.com)
> > > wrote:
> > >
> > > Yes but consequence was a lack of community increase which is a
> > > killer for
> > > an incubator project on the long run.
> > >
> > > Le 17 mars 2018 15:19, "Gilles"  a
> > > écrit :
> > >
> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> > >>
> > >>> Le 17 mars 2018 11:49, "Gilles"  a
> > >>> écrit :
> > >>>
> > >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> > >>>
> > >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
> > 
> >  If we can come to consensus on the way forward, I’ll be happy to
> >  do the
> > 
> > > work ( although I’ll need help of course ).
> > > I guess I’m the straw that broke the camel’s back then? ;)
> > >
> > >
> > >
> > >
> > > On March 15, 2018 at 08:09:45, Gilles
> > > (gil...@harfang.homelinux.org)
> > > wrote:
> > >
> > > Hi.
> > >
> > > On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> > > > I think bringing back commons-monitoring/sirota would only be
> > > > possible if

Re: [DISCUSS] new component for timing?

[Gilles]

On Mon, 23 Apr 2018 04:54:21 -0700, Otto Fowler wrote:

Bump


More than a vote, you need someone to take on the tasks to
create the new component.

I feel that no argument were made against bringing ex-Sirona
back to "Commons" (or contributing your code to Romain's
Sirona fork), and I'm afraid that nothing else will be
added to that component (or: where is the plan?).

Best,
Gilles

On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


There has been no comment, do we need an explicit vote?


On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


So do we need a vote?  What is next to move this forward?


On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwa...@gmail.com) 
wrote:


OK, sounds fine to me.  Hopefully we’ll get some buy in and can move
forward.
I’m not sure what is next though ;)



On March 28, 2018 at 13:17:22, Gary Gregory (garydgreg...@gmail.com) 
wrote:


On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler 


wrote:

How about commons-timing, having StopWatch, StackWatch and other 
classes

that
we can find?



I think we start small with only what we need and have today, namely 
these

two classes.

Gary






On March 20, 2018 at 18:40:05, Romain Manni-Bucau 
(rmannibu...@gmail.com)

wrote:

I would be happy to revive sirona @asf but dont think [monitoring] 
as just
a few classes would bring enough value compare to a lambda not 
worthing

any

lib/dep in apps - just my opinion indeed.

For circuit breaker: geronimo safeguard can be interested in hosting 
that
utility part and drop failsafe dependency. Maybe something to 
discuss in

another thread.

Le 20 mars 2018 23:27, "Otto Fowler"  a 
écrit :


> Sirona is gone, it is a closed incubator project. Romain has 
forked it

to

> his own repo.
>
>
>
> On March 20, 2018 at 18:24:06, Gilles 
(gil...@harfang.homelinux.org)

> wrote:
>
> On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > If monitoring was started a new, and not re-viving the old
> > monitoring?
>
> Can the feature be contributed to "Sirona"? Otto, are you
> interested in this?
> Does it make sense to have "Commons Monitoring" revived based
> on part/all of "Sirona"?
> Romain, are you interested in this?
> What would be the scope/description of "Commons Monitoring"?
>
> Noting Romain's experience that the original "Commons" project
> evolved into "Sirona", it would be strange to start from scratch
> without a plan to not follow the same route again...
>
> Gilles
>
> > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > brunodepau...@yahoo.com.br.invalid) wrote:
> >
> > I think StopWatch and CircuitBreakers could be moved together to 
the

> > same
> > component. However, a circuit breaker can be time-related, or 
not

> > (e.g. a
> > circuit breaker for memory size). So probably commons-timing 
could be

> > a
> > good place for StopWatch, but maybe not for circuit-breaker. But 
I

> > think
> > both could be under commons-monitoring perhaps?
> >
> > From: Otto Fowler 
> > To: Romain Manni-Bucau ; Commons 
Developers

> > List <
> > dev@commons.apache.org>
> > Sent: Wednesday, 21 March 2018 10:30 AM
> > Subject: Re: [DISCUSS] new component for timing?
> >
> > I would love to get this on track. I apologize if I have made it
> > more
> > confusing than it needs to be,
> > I’m trying to be open to all the suggestions.
> >
> > If we assume that stack watch is worth ‘having’, then the 
question is

> > where
> > to put it.
> > commons-monitoring / sirota seems to me to be a ‘complete’ 
solution

> > as
> > opposed to
> > a set of or collection of like classes.
> >
> > Setting the community support / project aspect of sirota aside, 
it

> > seems
> > strange to put
> > a separate class into a more complete and uniform system. Unless
> > there is
> > some generically
> > useful set of timing utility classes that could be taken out of
> > sirota to
> > go into commons-,
> > along with things identified ( StopWatch?) out of commons lang 
and

> > possibly
> > other commons projects.
> >
> > commons-timing seems reasonable. Thoughts?
> >
> >
> >
> > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > (rmannibu...@gmail.com)
> > wrote:
> >
> > Yes but consequence was a lack of community increase which is a
> > killer for
> > an incubator project on the long run.
> >
> > Le 17 mars 2018 15:19, "Gilles"  a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >>
> >>> Le 17 mars 2018 11:49, "Gilles"  
a

> >>> écrit :
> >>>
> >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler 
:

> 
>  If we can come to consensus on the way forward, I’ll be happy 
to

>  do the
> 
> > work ( although I’ll need help of course ).
> > I guess I’m the straw that broke the camel’s back then? ;)
> >
> >
> >
> >
> > On March 15, 2018 at 08:09:45, Gilles
> > (gil...@harfang.homelinux.org)
> > wrote:
> >>>

Re: [compress][io] Avoid InputStream#skip?

[Stefan Bodewig]

On 2018-04-22, Gary Gregory wrote:

> We should at the very least document all of this carefully.

commons-io's IOUtils already quite clearly states it is using read and
not using skip at all.

> My gut reaction is that an API called skip should call skip internally.
> Doing anything else clever as you point out has performance implications
> and might violate the principle of least surprise.

Unfortunately I don't see any clean way to use skip at all.

> We could consider creating a Skipper interface that can be implemented by
> with Skip and a SkipRead implementations. Then all of the code that used to
> call skip would be parameterized. But this might be too framework-y for
> [io], or [compress]

Just grep for IOUtils.skip through the compress code base, it is used
all over the place. :-)

Stefan

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

[compress] High Level API for Archives

[Stefan Bodewig]

Hi all

I've started to work on COMPRESS-118 and added Archiver and Expander
classes - without any tests for now. As I'm trying to cover a bunch of
possible use cases there are lots of inputs or outputs that can
represent archives. When expanding archives you may want to use
auto-detect the format or specify it explicitly. You may want to filter
the files to add/entries to expand. All this leads to an explosion of
overloads that I'm not comfortable with.

One idea that I came up with is using a fluent interface like

Expander.forFile(someFile).filtering(someFilter).expandTo(someDirectory);

or similar. But before I delve deeper into it, I'd like to collect
feedback.

And then I'd like to collect additional features that might be
needed. What I can easily imaging is

* When expanding, don't overwrite existing files when expanding an
  archive (or only if the archive entries are newer.

* Add an API for updating archives - of course this boils down to
  writing a completely new archive with entries taken from two sources.

* we may want to provide a utility class that makes dealing with the
  subclasses of ArchiveEntry easier. Many of them provide a userid, but
  there is no common interface. I'm thinking about something like
  
https://github.com/apache/ant-antlibs-compress/blob/master/src/main/org/apache/ant/compress/util/EntryHelper.java

Any feedback is very much appreciated.

Stefan

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

Re: [compress][io] Avoid InputStream#skip?

[sebb]

On 23 April 2018 at 19:45, Stefan Bodewig  wrote:
> On 2018-04-22, Gary Gregory wrote:
>
>> We should at the very least document all of this carefully.
>
> commons-io's IOUtils already quite clearly states it is using read and
> not using skip at all.
>
>> My gut reaction is that an API called skip should call skip internally.
>> Doing anything else clever as you point out has performance implications
>> and might violate the principle of least surprise.
>
> Unfortunately I don't see any clean way to use skip at all.

If skip only fails when trying to read a new buffer, it might be
possible to get the file position before calling skip.
This assumes that the failure does not occur after reading any further.

>> We could consider creating a Skipper interface that can be implemented by
>> with Skip and a SkipRead implementations. Then all of the code that used to
>> call skip would be parameterized. But this might be too framework-y for
>> [io], or [compress]
>
> Just grep for IOUtils.skip through the compress code base, it is used
> all over the place. :-)
>
> Stefan
>
> -
> 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: [compress] High Level API for Archives

[Torsten Curdt]

TBH I am not such super big fan of adding and maintaining a high level
API at this stage.
You will never find the right abstraction that everyone is happy with.
If you would - well, then that should be the real API afterall.

Honestly - I would just add example code for now. Maybe that can turn
into a helper class in the long run.
But for now we would not introduce something we may no longer break.

Maybe we need to look at the various users of the API and take that as
the basis for the next step.

My 2 cents.
Torsten

On Mon, Apr 23, 2018 at 8:57 PM, Stefan Bodewig  wrote:
> Hi all
>
> I've started to work on COMPRESS-118 and added Archiver and Expander
> classes - without any tests for now. As I'm trying to cover a bunch of
> possible use cases there are lots of inputs or outputs that can
> represent archives. When expanding archives you may want to use
> auto-detect the format or specify it explicitly. You may want to filter
> the files to add/entries to expand. All this leads to an explosion of
> overloads that I'm not comfortable with.
>
> One idea that I came up with is using a fluent interface like
>
> Expander.forFile(someFile).filtering(someFilter).expandTo(someDirectory);
>
> or similar. But before I delve deeper into it, I'd like to collect
> feedback.
>
> And then I'd like to collect additional features that might be
> needed. What I can easily imaging is
>
> * When expanding, don't overwrite existing files when expanding an
>   archive (or only if the archive entries are newer.
>
> * Add an API for updating archives - of course this boils down to
>   writing a completely new archive with entries taken from two sources.
>
> * we may want to provide a utility class that makes dealing with the
>   subclasses of ArchiveEntry easier. Many of them provide a userid, but
>   there is no common interface. I'm thinking about something like
>   
> https://github.com/apache/ant-antlibs-compress/blob/master/src/main/org/apache/ant/compress/util/EntryHelper.java
>
> Any feedback is very much appreciated.
>
> Stefan
>
> -
> 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

[compress] Need Help With PAX Exam Tests

[Stefan Bodewig]

Hi all

I'm trying to resolve COMPRESS-443 which talks about having a regression
test that fails if we break the OSGi bundle again (has already happened
three times duing the life of Compress so far). But unfortunately I'm
getting stuck with my limited Maven and even more limited PAX Exam Fu.

You can see what I've tried in the COMPRESS-443 branch:
https://github.com/apache/commons-compress/tree/COMPRESS-443

The OsgiITest I've added loads the SNAPSHOT version I've installed into
my local repo last and doen't care about the current classes and POM,
which is quite understandable as the bundle hasn't even been built when
I try to run the test.

Do I have to create a separate maven project just for the tests? If so,
I'll probably just drop the very idea as turning compress into a reactor
build just for a single test case feels wrong.

I really hope I am missing something obvious. This has been true often
enough that I'm optimisitic :-)

Stefan

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

Re: [compress] High Level API for Archives

[Matt Sicker]

I went through a few iterations of my own over the weekend and wasn't
satisfied with the direction in any of them. This approach looks
interesting, though I need to take a closer look.

On 23 April 2018 at 14:48, Torsten Curdt  wrote:

> TBH I am not such super big fan of adding and maintaining a high level
> API at this stage.
> You will never find the right abstraction that everyone is happy with.
> If you would - well, then that should be the real API afterall.
>
> Honestly - I would just add example code for now. Maybe that can turn
> into a helper class in the long run.
> But for now we would not introduce something we may no longer break.
>
> Maybe we need to look at the various users of the API and take that as
> the basis for the next step.
>
> My 2 cents.
> Torsten
>
> On Mon, Apr 23, 2018 at 8:57 PM, Stefan Bodewig 
> wrote:
> > Hi all
> >
> > I've started to work on COMPRESS-118 and added Archiver and Expander
> > classes - without any tests for now. As I'm trying to cover a bunch of
> > possible use cases there are lots of inputs or outputs that can
> > represent archives. When expanding archives you may want to use
> > auto-detect the format or specify it explicitly. You may want to filter
> > the files to add/entries to expand. All this leads to an explosion of
> > overloads that I'm not comfortable with.
> >
> > One idea that I came up with is using a fluent interface like
> >
> > Expander.forFile(someFile).filtering(someFilter).
> expandTo(someDirectory);
> >
> > or similar. But before I delve deeper into it, I'd like to collect
> > feedback.
> >
> > And then I'd like to collect additional features that might be
> > needed. What I can easily imaging is
> >
> > * When expanding, don't overwrite existing files when expanding an
> >   archive (or only if the archive entries are newer.
> >
> > * Add an API for updating archives - of course this boils down to
> >   writing a completely new archive with entries taken from two sources.
> >
> > * we may want to provide a utility class that makes dealing with the
> >   subclasses of ArchiveEntry easier. Many of them provide a userid, but
> >   there is no common interface. I'm thinking about something like
> >   https://github.com/apache/ant-antlibs-compress/blob/master/
> src/main/org/apache/ant/compress/util/EntryHelper.java
> >
> > Any feedback is very much appreciated.
> >
> > Stefan
> >
> > -
> > 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
>
>


-- 
Matt Sicker 

Re: [compress] Need Help With PAX Exam Tests

[Gary Gregory]

You should take a look at the Log4j 2 module log4j-osgi. We do some "bare
bones let's make sure we can load modules" tests using both Eclipse Equinox
and Apache Felix.

Gary

On Mon, Apr 23, 2018 at 2:21 PM, Stefan Bodewig  wrote:

> Hi all
>
> I'm trying to resolve COMPRESS-443 which talks about having a regression
> test that fails if we break the OSGi bundle again (has already happened
> three times duing the life of Compress so far). But unfortunately I'm
> getting stuck with my limited Maven and even more limited PAX Exam Fu.
>
> You can see what I've tried in the COMPRESS-443 branch:
> https://github.com/apache/commons-compress/tree/COMPRESS-443
>
> The OsgiITest I've added loads the SNAPSHOT version I've installed into
> my local repo last and doen't care about the current classes and POM,
> which is quite understandable as the bundle hasn't even been built when
> I try to run the test.
>
> Do I have to create a separate maven project just for the tests? If so,
> I'll probably just drop the very idea as turning compress into a reactor
> build just for a single test case feels wrong.
>
> I really hope I am missing something obvious. This has been true often
> enough that I'm optimisitic :-)
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [geometry] Points and Vectors Proposal

[Matt Juntunen]

Hi Gilles,

The hierarchy would be wrong from a conceptual POV: A vector can be
described by Cartesian coordinates, but it should be possible to
introduce new coordinate systems (polar in 2D, spherical in 3D) ...
This approach doesn't limit the coordinate system at all. We can still make 
implementations of Point and Vector based on other 
coordinate systems. I think it'll actually be easier in this structure, since 
the details of the system are explicitly defined in a single base class. For 
example, to create polar vectors and points, we would create a 
PolarCoordinate2D base class and PolarPoint2D and PolarVector2D subclasses.
...algorithms that use vectors would/should still work (transparently
doing the appropriate conversions if necessary).
This is a general issue with the current code, separate from the changes I'm 
proposing here. I'm not introducing a new issue.

I understand (and agree with) the performance goal, but let's
be careful to not define an API that does not correspond to
the underlying concepts.
Agreed. One vote in favor of having these utility methods is that I used some 
of them while transitioning the other geometry classes for my proof-of-concept. 
For example, o.a.c.geometry.euclidean.threed.Plane uses the 
Vector3D.dotProduct(Cartesian3D, Cartesian3D) method to compute the origin 
offset directly from the origin point and plane normal.

What will happen when we introduce
   Spherical3D(r, theta, phi)
alongside
   Cartesian3D(x, y, z)
?
They should be able to get along just fine. They would each have subclasses 
that perform point and vector operations using their respective coordinate 
systems. The only issue would be trying to mix them, which as I mentioned 
above, is an existing issue with the current code base. However, I think having 
the coordinate systems encapsulated in base classes is a good first step in 
solving this.

If "Cartesian3D" _implements_ "Point3D" and "Vector3D", it
would still work (i.e. refactor so that "Point3D" becomes
an interface and does not assume that the coordinates are
Cartesian).
I'm not quite sure what you're picturing for the Point3D interface here. Even 
so, if Cartesian3D implemented both interfaces, the compiler wouldn't be any 
help in catching simple programming errors.

Thanks,
Matt

From: Gilles 
Sent: Monday, April 23, 2018 4:32 AM
To: dev@commons.apache.org
Subject: Re: [geometry] Points and Vectors Proposal

Hi.

On Mon, 23 Apr 2018 05:36:09 +, Matt Juntunen wrote:
> Hi all,
>
> I'd like to propose an update to the Euclidean Point/Vector classes
> in the geometry project. We currently have a single CartesianXD class
> per dimension (eg, Cartesian2D) that implements both the Point and
> Vector interfaces. This is similar to the previous commons-math
> version where we had VectorXD classes that were also both Points and
> Vectors. The change to the current version was through discussion on
> MATH-1284 (https://issues.apache.org/jira/browse/MATH-1284). My
> proposal is to flip the current inheritance hierarchy so that the
> CartesianXD classes become the base classes for separate PointXD and
> VectorXD classes.

The hierarchy would be wrong from a conceptual POV: A vector can be
described by Cartesian coordinates, but it should be possible to
introduce new coordinate systems (polar in 2D, spherical in 3D) and
algorithms that use vectors would/should still work (transparently
doing the appropriate conversions if necessary).

> PointXD classes only implement the Point interface
> and VectorXD classes only implement Vector. The Cartesian base
> classes
> contain the actual x, y, z coordinate values along with a few other
> common methods (such as getSpace()). For performance and convenience,
> we can create static methods in the VectorXD classes that accept the
> Cartesian base class instances, so that users can perform common
> vector operations using either type. For example, if you have a giant
> list of Points, these static methods would allow you to compute dot
> products without needing to convert the Point instances to Vectors
> first.

I understand (and agree with) the performance goal, but let's
be careful to not define an API that does not correspond to
the underlying concepts.

What will happen when we introduce
   Spherical3D(r, theta, phi)
alongside
   Cartesian3D(x, y, z)
?

> I've partially implemented this in a branch so you can get a better
> idea of what I'm picturing:
> https://github.com/darkma773r/commons-geometry/tree/point-vector.
> The
> commons-geometry-core and commons-geometry-euclidean sub-modules
> contain the changes.
>
> [https://avatars1.githubusercontent.com/u/3809623?s=400&v=4]
>
>
> darkma773r/commons-geometry
> commons-geometry - Apache Commons Geometry
> github.com
>
>
>
> The main benefit I see from this approach is code clarity. The inte

Re: [compress] Need Help With PAX Exam Tests

[Stefan Bodewig]

On 2018-04-24, Gary Gregory wrote:

> You should take a look at the Log4j 2 module log4j-osgi. We do some "bare
> bones let's make sure we can load modules" tests using both Eclipse Equinox
> and Apache Felix.

Will do, thanks.

Stefan

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

Re: [compress] High Level API for Archives

[Stefan Bodewig]

On 2018-04-23, Torsten Curdt wrote:

> TBH I am not such super big fan of adding and maintaining a high level
> API at this stage.  You will never find the right abstraction that
> everyone is happy with.

TIt's not my intention to make everybody happy, there will still be use
cases that won't be covered by the high level API where you stil need to
go to the lower level. The parallel creation of zip archives is
something that is far out of scope for the high level IMHO.

> Maybe we need to look at the various users of the API and take that as
> the basis for the next step.

Yes, this is soemthing I intend to do.

Thanks

Stefan

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