Re: Applicability of PolyhedronsSet for high polygon counts

[Wes Gilster]

I really appreciate the quick response. Even though I believe this API 
has the functionality I need, I'm not really sure I can easily tune the 
performance. I need to check out a few other APIs to determine if they 
will be a better fit, and if I can't find anything that fits, I'll 
probably see what I can do with this geom package. Thanks again for 
being so upfront about the state of the project.


Thanks,

Wes G.

On 11/5/2016 11:03 AM, Gilles wrote:

Hello.

On Fri, 4 Nov 2016 23:57:48 -0500, Wes Gilster wrote:

I've been using the commons math geometry libraries for some simple
2d intersection functions, but I'm now interested in expanding it's
use to include some manipulation of 3d models with polygon counts that
will easily reach 200,000 tris. More specifically I would like to
build physical support structures in 3d models. Given that commons
math geo libraries used BSP trees, I had assumed the performance would
be quite adequate. However I'm having second thoughts as to whether
this is the right API for this modeling. I'm building models from STL
files with this constructor:

org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.PolyhedronsSet(List, 


List, double)

It seems there are some quite in-efficient loops in here, and with
models with high polygon counts this function really performs poorly:

org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.buildBoundary(List, 


List, double)

It also seems as though this API is going to be quite intolerant of
imperfect geometry.

Below is an example that loads an STL from disk and inserts into this
the PolyhedronsSet:

https://github.com/WesGilster/Photonic3D/blob/master/host/src/main/java/org/area515/resinprinter/supports/ImpossiblePerformance.java 



I'm hoping someone with a bit of experience in this API could confirm
this assessment.


I have no good news; there is probably no one listening here who
has more experience than you on using this part of the Commons
Math library.

Many of the more advanced codes (in size and/or complexity) have
been orphaned by a fork last May.

A lot of discussion has arisen about the future of CM (have a look
at the ML archive if you are interested).
Some parts have found new maintainers.
We should certainly welcome people who have expertise with using the
"geometry" package, to improve and maintain it, and eventually
release it as a standalone component.


Best regards,
Gilles



Thanks,
Wes G.



-
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: [ALL] Git repository for a sandbox component?

[Matt Sicker]

GitHub mirrors both the svn and git repos for ASF projects, so you get the
advantages either way. Merging pull requests from GitHub is easier via git,
but they do provide .patch files as well which work just as well in svn.

On 5 November 2016 at 13:54, Eric Barnhill  wrote:

> Speaking for myself either is fine. I find svn commands easier to deal with
> than git, but github is easy to use as a site.
>
> Eric
>
> On Sat, Nov 5, 2016 at 4:43 PM, Gilles 
> wrote:
>
> > On Sat, 5 Nov 2016 09:53:01 -0500, Matt Sicker wrote:
> >
> >> Is this a vote of some sort to convert from svn?
> >>
> >
> > Not really (at least if your question is whether I ask to
> > convert the whole sandbox, or all sandbox components).
> >
> > I thought that a sandbox component had to use the same repository
> > as all other sandbox components:
> >   $ svn list http://svn.apache.org/repos/asf/commons/sandbox
> >
> > Hence I suggested to Eric to create the new "filter" one.
> >
> > But then I saw that the "Text" component is not listed by the above,
> > command but uses git.
> >
> > So if this is OK, I'd rather ask for a new git repository for "filter"
> > too (that is currently empty).
> >
> > Regards,
> > Gilles
> >
> >
> > So far we've all been
> >> pretty on board with migrating Commons projects to git.
> >>
> >> On 4 November 2016 at 16:27, Gilles 
> wrote:
> >>
> >> Hello.
> >>>
> >>> I noticed that the "Text" component uses "git".
> >>> It would be simpler to also use git for the "filter" component.
> >>>
> >>> Regards,
> >>> Gilles
> >>>
> >>>
> >>>
> >>> -
> >>> 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: commons-io git repository write access

[Gary Gregory]

Nothing if you are an Apache committer already, you have karma
automatically.

Gary

On Nov 5, 2016 2:43 PM, "Pascal Schumacher" 
wrote:

> Hello everybody,
>
> if nobody objects I would like to help maintaining commons-io.
>
> What would I have to do in order to get write access to the git repository?
>
> -Pascal
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Gary Gregory]

There is no need to maintain BC since 2.0 is not out. Changing package
names and Maven coordinates must also happen hand in hand. Changing one
means changing the other.

Gary

On Nov 5, 2016 1:37 PM, "Thomas Vandahl"  wrote:

> Hi Oliver,
>
> On 05.11.16 21:18, Oliver Heger wrote:
> > It seems that there are many breaking changes between this release and
> > beta1; for instance, the clirr report for the core component lists
> > numerous errors. Is it not against Commons policy to publish
> > incompatible artifacts with the same maven and package coordinates to
> > Maven central?
>
> I thought that is why we call it "beta"? It basically boils down again
> to the question what should be considered a public API (which btw hasn't
> changed since beta-1).
> I have no problem with changing the coordinates but I'm pretty sure that
> the next iteration to 2.0 final will introduce more incompatibilities
> and we may run out of coordinates...
>
> As I see it, we are still in the transition from 1.3
> (org.apache.jcs:jcs) to 2.0 (org.apache.commons.jcs:commons-jcs-core)
> but I'm ready to change whatever is necessary to get this out of the door.
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Git repository for a sandbox component?

[Gilles]

On Sat, 5 Nov 2016 19:54:02 +0100, Eric Barnhill wrote:
Speaking for myself either is fine. I find svn commands easier to 
deal with

than git, but github is easy to use as a site.


I find the above a little contradictory but since you are
going to manage this, it's up to you. ;-)

Gilles



Eric

On Sat, Nov 5, 2016 at 4:43 PM, Gilles  
wrote:



On Sat, 5 Nov 2016 09:53:01 -0500, Matt Sicker wrote:


Is this a vote of some sort to convert from svn?



Not really (at least if your question is whether I ask to
convert the whole sandbox, or all sandbox components).

I thought that a sandbox component had to use the same repository
as all other sandbox components:
  $ svn list http://svn.apache.org/repos/asf/commons/sandbox

Hence I suggested to Eric to create the new "filter" one.

But then I saw that the "Text" component is not listed by the above,
command but uses git.

So if this is OK, I'd rather ask for a new git repository for 
"filter"

too (that is currently empty).

Regards,
Gilles


So far we've all been

pretty on board with migrating Commons projects to git.

On 4 November 2016 at 16:27, Gilles  
wrote:


Hello.


I noticed that the "Text" component uses "git".
It would be simpler to also use git for the "filter" component.

Regards,
Gilles



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

[GitHub] commons-io pull request #26: README.md: update maven coordinates to version ...

[PascalSchumacher]

GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-io/pull/26

README.md: update maven coordinates to version 2.5



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-io readme_update

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/26.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #26


commit 287c6c2c40faedde7515d4392522076bf17dd981
Author: Pascal Schumacher 
Date:   2016-11-05T21:49:23Z

README.md: update maven coordinates to version 2.5




---
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

commons-io git repository write access

[Pascal Schumacher]

Hello everybody,

if nobody objects I would like to help maintaining commons-io.

What would I have to do in order to get write access to the git repository?

-Pascal


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

[GitHub] commons-io pull request #25: IO-514: Remove org.apache.commons.io.Java7Suppo...

[PascalSchumacher]

GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-io/pull/25

IO-514: Remove org.apache.commons.io.Java7Support



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-io 
remove_java7support_class

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/25.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #25


commit b26901c008d7f00c24e1060899cf81e0b07c0883
Author: Pascal Schumacher 
Date:   2016-11-05T21:29:56Z

IO-514: Remove org.apache.commons.io.Java7Support




---
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: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Thomas Vandahl]

Hi Oliver,

On 05.11.16 21:18, Oliver Heger wrote:
> It seems that there are many breaking changes between this release and
> beta1; for instance, the clirr report for the core component lists
> numerous errors. Is it not against Commons policy to publish
> incompatible artifacts with the same maven and package coordinates to
> Maven central?

I thought that is why we call it "beta"? It basically boils down again
to the question what should be considered a public API (which btw hasn't
changed since beta-1).
I have no problem with changing the coordinates but I'm pretty sure that
the next iteration to 2.0 final will introduce more incompatibilities
and we may run out of coordinates...

As I see it, we are still in the transition from 1.3
(org.apache.jcs:jcs) to 2.0 (org.apache.commons.jcs:commons-jcs-core)
but I'm ready to change whatever is necessary to get this out of the door.

Bye, Thomas.


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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Oliver Heger]

It seems that there are many breaking changes between this release and
beta1; for instance, the clirr report for the core component lists
numerous errors. Is it not against Commons policy to publish
incompatible artifacts with the same maven and package coordinates to
Maven central?

Oliver

Am 05.11.2016 um 20:50 schrieb Gary Gregory:
> Good to know, TY. Hopefully someone will take the time to review over the
> weekend.
> 
> Gary
> 
> On Sat, Nov 5, 2016 at 12:37 PM, Thomas Vandahl  wrote:
> 
>> On 05.11.16 20:24, Gary Gregory wrote:
>>> Time to tally?
>>
>> I would like to. However, AFAIK, we are one PMC vote short.
>>
>> Bye, Thomas.
>>
>>
>>
>> -
>> 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: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Gary Gregory]

Good to know, TY. Hopefully someone will take the time to review over the
weekend.

Gary

On Sat, Nov 5, 2016 at 12:37 PM, Thomas Vandahl  wrote:

> On 05.11.16 20:24, Gary Gregory wrote:
> > Time to tally?
>
> I would like to. However, AFAIK, we are one PMC vote short.
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Thomas Vandahl]

On 05.11.16 20:24, Gary Gregory wrote:
> Time to tally?

I would like to. However, AFAIK, we are one PMC vote short.

Bye, Thomas.



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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Gary Gregory]

Time to tally?

Gary

On Sat, Nov 5, 2016 at 4:38 AM, Thomas Vandahl  wrote:

> On 01.11.16 09:24, Thomas Vandahl wrote:
> >   [X] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
>
> My vote.
>
> Bye, Thomas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ALL] Git repository for a sandbox component?

[Eric Barnhill]

Speaking for myself either is fine. I find svn commands easier to deal with
than git, but github is easy to use as a site.

Eric

On Sat, Nov 5, 2016 at 4:43 PM, Gilles  wrote:

> On Sat, 5 Nov 2016 09:53:01 -0500, Matt Sicker wrote:
>
>> Is this a vote of some sort to convert from svn?
>>
>
> Not really (at least if your question is whether I ask to
> convert the whole sandbox, or all sandbox components).
>
> I thought that a sandbox component had to use the same repository
> as all other sandbox components:
>   $ svn list http://svn.apache.org/repos/asf/commons/sandbox
>
> Hence I suggested to Eric to create the new "filter" one.
>
> But then I saw that the "Text" component is not listed by the above,
> command but uses git.
>
> So if this is OK, I'd rather ask for a new git repository for "filter"
> too (that is currently empty).
>
> Regards,
> Gilles
>
>
> So far we've all been
>> pretty on board with migrating Commons projects to git.
>>
>> On 4 November 2016 at 16:27, Gilles  wrote:
>>
>> Hello.
>>>
>>> I noticed that the "Text" component uses "git".
>>> It would be simpler to also use git for the "filter" component.
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>
>>> -
>>> 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: commons-filter sandbox is operational

[Bernd Porr]

Hi Eric,

the error came from not having a site subtree. I've added one. That 
needs to change so that it fits into the numbering scheme of the 
library. I guess it will be a sub-topic in the filter.xml?


Either way "mvn site" works now to get it going.

/Bernd

On 02/11/16 09:09, Eric Barnhill wrote:

Hi Bernd,

looks like I need org/sonatype/aether/graph/DependencyFilter .

Any ideas where to find that?

Complete stack trace  below Bernd's reply.

Eric


On Tue, Nov 1, 2016 at 5:50 PM, Bernd Porr  wrote:


Thanks, Eric for setting up a sandbox project. What is required for "mvn
site"?

/Bernd


On 01/11/16 16:17, Eric Barnhill wrote:


I have set up a sandbox project for commons-filter in the commons sandbox
subversion repository.

I used models in the sandbox for LICENSE.txt, NOTICE.txt and the pom.xml,
and set up a folder tree for src . mvn install runs successfully, mvn site
does not.

The pom model I used (cli2) had jira-related tags. I do not appear to have
the authority to create a JIRA project. Should I create a JIRA for this
project? If so, am I missing this option because I have not yet linked my
Apache JIRA with my apache.org ID? And if so, can anyone tell me a way to
link them?

Thanks,
Eric



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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






[WARNING] Error injecting:
org.apache.maven.reporting.exec.DefaultMavenReportExecutor
java.lang.NoClassDefFoundError: org/sonatype/aether/graph/DependencyFilter
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getDeclaredConstructors(Class.java:2020)
at
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:658)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:882)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:805)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:282)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:214)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:1006)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at
org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at
org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at

Re: Applicability of PolyhedronsSet for high polygon counts

[Gilles]

Hello.

On Fri, 4 Nov 2016 23:57:48 -0500, Wes Gilster wrote:

I've been using the commons math geometry libraries for some simple
2d intersection functions, but I'm now interested in expanding it's
use to include some manipulation of 3d models with polygon counts 
that

will easily reach 200,000 tris. More specifically I would like to
build physical support structures in 3d models. Given that commons
math geo libraries used BSP trees, I had assumed the performance 
would

be quite adequate. However I'm having second thoughts as to whether
this is the right API for this modeling. I'm building models from STL
files with this constructor:

org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.PolyhedronsSet(List,
List, double)

It seems there are some quite in-efficient loops in here, and with
models with high polygon counts this function really performs poorly:

org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.buildBoundary(List,
List, double)

It also seems as though this API is going to be quite intolerant of
imperfect geometry.

Below is an example that loads an STL from disk and inserts into this
the PolyhedronsSet:

https://github.com/WesGilster/Photonic3D/blob/master/host/src/main/java/org/area515/resinprinter/supports/ImpossiblePerformance.java

I'm hoping someone with a bit of experience in this API could confirm
this assessment.


I have no good news; there is probably no one listening here who
has more experience than you on using this part of the Commons
Math library.

Many of the more advanced codes (in size and/or complexity) have
been orphaned by a fork last May.

A lot of discussion has arisen about the future of CM (have a look
at the ML archive if you are interested).
Some parts have found new maintainers.
We should certainly welcome people who have expertise with using the
"geometry" package, to improve and maintain it, and eventually
release it as a standalone component.


Best regards,
Gilles



Thanks,
Wes G.



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

Re: [ALL] Git repository for a sandbox component?

[Gilles]

On Sat, 5 Nov 2016 09:53:01 -0500, Matt Sicker wrote:

Is this a vote of some sort to convert from svn?


Not really (at least if your question is whether I ask to
convert the whole sandbox, or all sandbox components).

I thought that a sandbox component had to use the same repository
as all other sandbox components:
  $ svn list http://svn.apache.org/repos/asf/commons/sandbox

Hence I suggested to Eric to create the new "filter" one.

But then I saw that the "Text" component is not listed by the above,
command but uses git.

So if this is OK, I'd rather ask for a new git repository for "filter"
too (that is currently empty).

Regards,
Gilles



So far we've all been
pretty on board with migrating Commons projects to git.

On 4 November 2016 at 16:27, Gilles  
wrote:



Hello.

I noticed that the "Text" component uses "git".
It would be simpler to also use git for the "filter" component.

Regards,
Gilles



-
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: [ALL] Git repository for a sandbox component? (Was: commons-filter sandbox is operational)

[Matt Sicker]

Is this a vote of some sort to convert from svn? So far we've all been
pretty on board with migrating Commons projects to git.

On 4 November 2016 at 16:27, Gilles  wrote:

> Hello.
>
> I noticed that the "Text" component uses "git".
> It would be simpler to also use git for the "filter" component.
>
> Regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC2

[Thomas Vandahl]

On 01.11.16 09:24, Thomas Vandahl wrote:
>   [X] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...

My vote.

Bye, Thomas


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