Re: [TEXT] Site pointing to wrong javadoc location

[Rob Tompkins]

> On Jan 11, 2017, at 2:23 AM, Jan Matèrne (jhm)  wrote:
> 
> On the main page [1] the link to the javadoc is wrong. It is [2] instead of
> [3]:
> 
> "The package descriptions in the JavaDoc give an overview ..."
> 
> So you'll get a 404.
> 
> 

Thanks for that catch. I thought I had caught all of those. I'll try to get 
that sorted out today. 

-Rob

> 
> 
> 
> Jan
> 
> 
> 
> [1] http://commons.apache.org/proper/commons-text/
> 
> [2]
> http://commons.apache.org/proper/commons-text/javadocs/api-release/index.htm
> l
> 
> [3] http://commons.apache.org/proper/commons-text/apidocs/index.html
> 

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

[GitHub] commons-rdf pull request #28: COMMONSRDF-52 set distinct Bundle-SymbolicName...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-rdf/pull/28


---
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-rdf issue #28: COMMONSRDF-52 set distinct Bundle-SymbolicName values

[stain]

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/28
  
Thanks! Merged. I also added you as a `` to be shown on 
https://commons.apache.org/proper/commons-rdf/team-list.html - hope that's OK.

Any other OSGi issues? How do you do the equivalent of `ServiceLoader` of 
`RDF` instances? Do we need to make OSGi service annotations/XML?


---
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] Rename "Complex" to "Numbers" (Was: [complex] Make multi-module and rename component?)

[Eric Barnhill]

+1

On Tue, Jan 10, 2017 at 12:56 AM, Brent Worden 
wrote:

> Are the originally mentioned transforms in or out of scope of
> commons-numbers?
>
> Brent
>
> On Mon, Jan 9, 2017 at 12:02 PM, Gilles 
> wrote:
>
> > See discussion thread, copied below.
> >
> > [ ] Yes
> > [ ] Yes but I prefer this name: ...
> > [ ] No, because ...
> >
> > I'll assume that this is a lazy consensus vote, to be closed in 72 hours
> > from now (i.e. on January 12, at 18:00:00 UTC).
> >
> > Thanks,
> > Gilles
> >
> >
> > On Mon, 9 Jan 2017 15:57:51 +, sebb wrote:
> >
> >> On 9 January 2017 at 11:46, Gilles 
> wrote:
> >>
> >>> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
> >>>
> 
>  It is overall a fine plan by me. A precision class makes more sense
> than
>  duplicating equals methods.
> 
>  From a practical standpoint I think it would be better to see
> Quaternion
>  in
>  its own subpackage than with Complex. Simply because I don't use them
>  and
>  packages are better maintained by those who use them.
> 
>  It is hard to see how the transforms fit in. If anything they belong
>  with
>  the new sigproc libraries.
> 
> >>>
> >>>
> >>> Fine.
> >>>
> >>> Is there any objection on the name "Commons Numbers"?
> >>>
> >>
> >> Since the namespace belongs to the whole of Commons, this question
> >> should be posed to all of Commons, i.e. using the [ALL] prefix.
> >>
> >> Are there better matches for the intended scope? [Or do we want that
> >>> the scope grows to also contain the "o.a.c.math4.prime" package" and
> >>> possibly more of number-theoretic functionality (as was proposed some
> >>> time ago to be added to Commons Math)?]
> >>>
> >>> Shall I wait a couple of days before filing the request with INFRA?
> >>> [I.e. to change the "git" repository, JIRA project and github mirror.]
> >>>
> >>>
> >>> Gilles
> >>>
> >>>
> >>>
>  Eric
>  On 8 Jan 2017 10:17, "Gilles"  wrote:
> 
>  Hi.
> >
> > How about renaming the component to "Commons Numbers" (or another
> name
> > if preferred) that would contain the following modules:
> >  * commons-numbers-core (with classes such as "Precision").
> >  * commons-numbers-complex
> >  * commons-numbers-quaternion
> >  * commons-numbers-fraction
> >  * commons-numbers-continued-fraction
> >  * commons-numbers-fft (Fast Fourier Transform)
> >  * commons-numbers-fct (Fast Cosine Transform)
> >  * ...
> > ?
> >
> > Gilles
> >
> >
> >
> >>>
> >>>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [VOTE] Rename "Complex" to "Numbers" (Was: [complex] Make multi-module and rename component?)

[Rob Tompkins]

+1 

> On Jan 11, 2017, at 8:39 AM, Eric Barnhill  wrote:
> 
> +1
> 
> On Tue, Jan 10, 2017 at 12:56 AM, Brent Worden 
> wrote:
> 
>> Are the originally mentioned transforms in or out of scope of
>> commons-numbers?
>> 
>> Brent
>> 
>> On Mon, Jan 9, 2017 at 12:02 PM, Gilles 
>> wrote:
>> 
>>> See discussion thread, copied below.
>>> 
>>> [ ] Yes
>>> [ ] Yes but I prefer this name: ...
>>> [ ] No, because ...
>>> 
>>> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
>>> from now (i.e. on January 12, at 18:00:00 UTC).
>>> 
>>> Thanks,
>>> Gilles
>>> 
>>> 
>>> On Mon, 9 Jan 2017 15:57:51 +, sebb wrote:
>>> 
 On 9 January 2017 at 11:46, Gilles 
>> wrote:
 
> On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
> 
>> 
>> It is overall a fine plan by me. A precision class makes more sense
>> than
>> duplicating equals methods.
>> 
>> From a practical standpoint I think it would be better to see
>> Quaternion
>> in
>> its own subpackage than with Complex. Simply because I don't use them
>> and
>> packages are better maintained by those who use them.
>> 
>> It is hard to see how the transforms fit in. If anything they belong
>> with
>> the new sigproc libraries.
>> 
> 
> 
> Fine.
> 
> Is there any objection on the name "Commons Numbers"?
> 
 
 Since the namespace belongs to the whole of Commons, this question
 should be posed to all of Commons, i.e. using the [ALL] prefix.
 
 Are there better matches for the intended scope? [Or do we want that
> the scope grows to also contain the "o.a.c.math4.prime" package" and
> possibly more of number-theoretic functionality (as was proposed some
> time ago to be added to Commons Math)?]
> 
> Shall I wait a couple of days before filing the request with INFRA?
> [I.e. to change the "git" repository, JIRA project and github mirror.]
> 
> 
> Gilles
> 
> 
> 
>> Eric
>> On 8 Jan 2017 10:17, "Gilles"  wrote:
>> 
>> Hi.
>>> 
>>> How about renaming the component to "Commons Numbers" (or another
>> name
>>> if preferred) that would contain the following modules:
>>> * commons-numbers-core (with classes such as "Precision").
>>> * commons-numbers-complex
>>> * commons-numbers-quaternion
>>> * commons-numbers-fraction
>>> * commons-numbers-continued-fraction
>>> * commons-numbers-fft (Fast Fourier Transform)
>>> * commons-numbers-fct (Fast Cosine Transform)
>>> * ...
>>> ?
>>> 
>>> 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

[GitHub] commons-rdf issue #28: COMMONSRDF-52 set distinct Bundle-SymbolicName values

[acoburn]

Github user acoburn commented on the issue:

https://github.com/apache/commons-rdf/pull/28
  
@stain for a `ServiceLoader` equivalent in OSGi, it would make sense to add 
a `Require-Capability` and `Provide-Capability` to each implementation's 
`MANIFEST.MF` -- it will simply be some minor maven changes, and I can add that 
in a forthcoming pull request.


---
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-rdf pull request #29: [COMMONSRDF-53] Add ServiceLoader support in O...

[acoburn]

GitHub user acoburn opened a pull request:

https://github.com/apache/commons-rdf/pull/29

[COMMONSRDF-53] Add ServiceLoader support in OSGi

Resolves: COMMONSRDF-53

This adds bundle metadata for the commons-rdf modules to make it easier to 
work with the Java `ServiceLoader` in an OSGi context. This consolidates the 
OSGi configuration, removing the `commons.osgi.symbolicName` definition and 
putting all OSGi-related configuration directly in the `maven-bundle-plugin` 
(now that the plugin must be explicitly configured in maven).

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

$ git pull https://github.com/acoburn/commons-rdf osgi_serviceloader

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

https://github.com/apache/commons-rdf/pull/29.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 #29


commit 27dbd9eda02550df85734c6198a0308cf5ca55e0
Author: Aaron Coburn 
Date:   2017-01-11T15:11:38Z

Add ServiceLoader support in OSGi




---
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] Rename "Complex" to "Numbers" (Was: [complex] Make multi-module and rename component?)

[Jörg Schaible]

+1

Gilles wrote:

> See discussion thread, copied below.
> 
> [ ] Yes
> [ ] Yes but I prefer this name: ...
> [ ] No, because ...
> 
> I'll assume that this is a lazy consensus vote, to be closed in 72
> hours
> from now (i.e. on January 12, at 18:00:00 UTC).
> 
> Thanks,
> Gilles



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

Re: [VOTE] Rename "Complex" to "Numbers" (Was: [complex] Make multi-module and rename component?)

[Emmanuel Bourg]

+1, but without the transforms.

Emmanuel Bourg


Le 9/01/2017 à 19:02, Gilles a écrit :
> See discussion thread, copied below.
> 
> [ ] Yes
> [ ] Yes but I prefer this name: ...
> [ ] No, because ...
> 
> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
> from now (i.e. on January 12, at 18:00:00 UTC).
> 
> Thanks,
> Gilles
> 
> 
> On Mon, 9 Jan 2017 15:57:51 +, sebb wrote:
> 
> 
> -
> 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] Rename "Complex" to "Numbers" (Was: [complex] Make multi-module and rename component?)

[Rob Tompkins]

> On Jan 11, 2017, at 7:23 PM, Emmanuel Bourg  wrote:
> 
> +1, but without the transforms.
> 

Yes. The transforms do seem a tad out of place. 

> Emmanuel Bourg
> 
> 
>> Le 9/01/2017 à 19:02, Gilles a écrit :
>> See discussion thread, copied below.
>> 
>> [ ] Yes
>> [ ] Yes but I prefer this name: ...
>> [ ] No, because ...
>> 
>> I'll assume that this is a lazy consensus vote, to be closed in 72 hours
>> from now (i.e. on January 12, at 18:00:00 UTC).
>> 
>> Thanks,
>> Gilles
>> 
>> 
>> On Mon, 9 Jan 2017 15:57:51 +, sebb wrote:
>> 
>> 
>> -
>> 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: Build failed in Jenkins: Commons-Compress-Windows #119

[Bhowmik, Bindul]

Looks like it is fixed now with build #275 [1].

- Bindul

[1] https://builds.apache.org/job/Commons-Compress-Windows/275/

On Thu, Jan 5, 2017 at 8:15 AM, sebb  wrote:
> And I've switched off the build emails
>
> On 5 January 2017 at 11:40, sebb  wrote:
>> I've moved it back to "Waiting for Infra"
>>
>> On 5 January 2017 at 10:13, Bhowmik, Bindul  wrote:
>>> On Wed, Jan 4, 2017 at 8:46 PM, Gary Gregory  wrote:
 Does anyone know how to fix this?
>>>
>>> Does not seem like a project issue, there is also a maven wagon
>>> failure [1], and an open ticket [INFRA-13224], but not sure it is in
>>> the right 'Status' for Infra to be looking at it.
>>>
>>>
>>> [1] https://builds.apache.org/job/maven-wagon-windows/298/console
>>>

 Gary

 -- Forwarded message --
 From: Apache Jenkins Server 
 Date: Wed, Jan 4, 2017 at 7:21 PM
 Subject: Build failed in Jenkins: Commons-Compress-Windows #119
 To: dev@commons.apache.org


 See 

 --
 Started by an SCM change
 [EnvInject] - Loading node environment variables.
 Building remotely on windows-2012-2 (Windows) in workspace <
 https://builds.apache.org/job/Commons-Compress-Windows/ws/>
 Cloning the remote Git repository
 Cloning repository https://git-wip-us.apache.org/
 repos/asf/commons-compress.git
  > git init  #
 timeout=10
 ERROR: Error cloning remote repo 'origin'
 hudson.plugins.git.GitException: Could not init 
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.
 execute(CliGitAPIImpl.java:652)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.
 execute(CliGitAPIImpl.java:463)
 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$
 CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$
 CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
 at hudson.remoting.UserRequest.perform(UserRequest.java:120)
 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
 at hudson.remoting.Request$2.run(Request.java:326)
 at hudson.remoting.InterceptingExecutorService$1.call(
 InterceptingExecutorService.java:68)
 at java.util.concurrent.FutureTask.run(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
 Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
 Source)
 at hudson.remoting.Engine$1$1.run(Engine.java:62)
 at java.lang.Thread.run(Unknown Source)
 at ..remote call to windows-2012-2(Native Method)
 at hudson.remoting.Channel.attachCallSiteStackTrace(
 Channel.java:1416)
 at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
 at hudson.remoting.Channel.call(Channel.java:781)
 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$
 CommandInvocationHandler.execute(RemoteGitImpl.java:145)
 at sun.reflect.GeneratedMethodAccessor761.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(
 DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$
 CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
 at com.sun.proxy.$Proxy175.execute(Unknown Source)
 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1046)
 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086)
 at hudson.scm.SCM.checkout(SCM.java:485)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
 at hudson.model.AbstractBuild$AbstractBuildExecution.
 defaultCheckout(AbstractBuild.java:604)
 at jenkins.scm.SCMCheckoutStrategy.checkout(
 SCMCheckoutStrategy.java:86)
 at hudson.model.AbstractBuild$AbstractBuildExecution.run(
 AbstractBuild.java:529)
 at hudson.model.Run.execute(Run.java:1741)
 at hudson.maven.MavenModuleSetBuild.run(
 MavenModuleSetBuild.java:531)
 at hudson.model.ResourceController.execute(
 ResourceController.java:98)
 at hudson.model.Executor.run(Executor.java:410)
 Caused by: hudson.plugins.git.GitException: Error performing command: git
 init 
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.
 launchCommandIn(CliGitAPIImpl.java:1730)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.
 launchCommandIn(CliGitAPIImpl.java:1699)
 at org.jenkinsci.plugins.git

[GitHub] commons-rdf pull request #29: [COMMONSRDF-53] Add ServiceLoader support in O...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-rdf/pull/29


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