[Numbers] Make "Complex" a "final" class? (Was: [...] API of "Complex")

[Gilles]

On Thu, 1 Feb 2018 08:30:00 -0700, Gary Gregory wrote:

Hi All:

I like the "of" prefix but I think it might be odd to force the 
convention

for ALL factories. It might be an English language thing for me.

For example, (picking a made up example) this reads really well to 
me:

Pair.of(foo, bar) because that what you'd use in spoken English.

OTOH, this does not read well to me: Fraction.of(num, denum); this 
would be

better: Fraction.from(num, denum)

All of this to say that we should make sure that the factory method 
"reads

well" for that class. I know it might feel subjective.

I like the idea of a private ctor but it does not have to be unique 
in my

mind. Sure, it's nice if there is one.

I also like the idea of the ctor being private because we can open it 
up

later to protected if we want to allow for subclassing.

I would also consider making classes final, especially if the ctor is
private.


Any caveat on doing that?  Is this a final (!) decision or can one
change one's mind in a later release?
What are the benefits?

Thanks,
Gilles



Gary


On Thu, Feb 1, 2018 at 7:07 AM, Gilles  
wrote:



On Thu, 01 Feb 2018 13:59:13 +0100, Gilles wrote:


Hi.

IMHO, there are too many accessor and factory methods.
We should strive for a lean and consistent API.

For the factory methods, I suggest the "of" convention:
 public static Complex ofCartesian(double re, double im)
 public static Complex ofPolar(double abs, double arg)
And, as syntactic sugar:
 public static Complex ofCis(double arg)



Those are useful too:
   public ofReal(double re)
   public ofImaginary(double im)



For the accessors:
 public double re() { return real }
 public double im() { return imaginary }

I'd have
  public double arg()
  public double abs()
in order to compute the polar coordinates.

I'm -0 to have others as syntactic sugar since they are
misleading (a.o. when "implying" the read of a field when
a computation is performed).

WDYT?



In addition to the above, I propose
* to have a single, "private", constructor:
private Complex(double re, double im)
* to remove the "protected" method "createComplex" (
  unless there is a case for inheritance).

Regards,
Gilles



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

Re: [Numbers] Make "Complex" a "final" class?

[Gilles]

On Fri, 2 Feb 2018 13:20:21 +, Stephen Colebourne wrote:

Some of the classes you are talking about are what I call VALJOs.
Follow these guidelines and your class will be well placed for the
future.
http://blog.joda.org/2014/03/valjos-value-java-objects.html


Thanks.
In that post, you mention "final" in this sentence:
---CUT---
The class must be immutable, which implies the final keyword
and thread-safety.
---CUT---
Do you mean that the *class* must be declared "final"?
A class can be immutable without being "final", can't it?
Or is the requirement necessary for future optimization of
value objects?

Regards,
Gilles


Stephen

On 2 February 2018 at 12:45, Gilles  
wrote:

On Thu, 1 Feb 2018 08:30:00 -0700, Gary Gregory wrote:


Hi All:

I like the "of" prefix but I think it might be odd to force the 
convention

for ALL factories. It might be an English language thing for me.

For example, (picking a made up example) this reads really well to 
me:

Pair.of(foo, bar) because that what you'd use in spoken English.

OTOH, this does not read well to me: Fraction.of(num, denum); this 
would

be
better: Fraction.from(num, denum)

All of this to say that we should make sure that the factory method 
"reads

well" for that class. I know it might feel subjective.

I like the idea of a private ctor but it does not have to be unique 
in my

mind. Sure, it's nice if there is one.

I also like the idea of the ctor being private because we can open 
it up

later to protected if we want to allow for subclassing.

I would also consider making classes final, especially if the ctor 
is

private.



Any caveat on doing that?  Is this a final (!) decision or can one
change one's mind in a later release?
What are the benefits?

Thanks,
Gilles



Gary


On Thu, Feb 1, 2018 at 7:07 AM, Gilles 


wrote:


On Thu, 01 Feb 2018 13:59:13 +0100, Gilles wrote:


Hi.

IMHO, there are too many accessor and factory methods.
We should strive for a lean and consistent API.

For the factory methods, I suggest the "of" convention:
 public static Complex ofCartesian(double re, double im)
 public static Complex ofPolar(double abs, double arg)
And, as syntactic sugar:
 public static Complex ofCis(double arg)



Those are useful too:
   public ofReal(double re)
   public ofImaginary(double im)



For the accessors:
 public double re() { return real }
 public double im() { return imaginary }

I'd have
  public double arg()
  public double abs()
in order to compute the polar coordinates.

I'm -0 to have others as syntactic sugar since they are
misleading (a.o. when "implying" the read of a field when
a computation is performed).

WDYT?



In addition to the above, I propose
* to have a single, "private", constructor:
private Complex(double re, double im)
* to remove the "protected" method "createComplex" (
  unless there is a case for inheritance).

Regards,
Gilles



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

Re: [Numbers] Make "Complex" a "final" class? (Was: [...] API of "Complex")

[Stephen Colebourne]

Some of the classes you are talking about are what I call VALJOs.
Follow these guidelines and your class will be well placed for the
future.
http://blog.joda.org/2014/03/valjos-value-java-objects.html
Stephen

On 2 February 2018 at 12:45, Gilles  wrote:
> On Thu, 1 Feb 2018 08:30:00 -0700, Gary Gregory wrote:
>>
>> Hi All:
>>
>> I like the "of" prefix but I think it might be odd to force the convention
>> for ALL factories. It might be an English language thing for me.
>>
>> For example, (picking a made up example) this reads really well to me:
>> Pair.of(foo, bar) because that what you'd use in spoken English.
>>
>> OTOH, this does not read well to me: Fraction.of(num, denum); this would
>> be
>> better: Fraction.from(num, denum)
>>
>> All of this to say that we should make sure that the factory method "reads
>> well" for that class. I know it might feel subjective.
>>
>> I like the idea of a private ctor but it does not have to be unique in my
>> mind. Sure, it's nice if there is one.
>>
>> I also like the idea of the ctor being private because we can open it up
>> later to protected if we want to allow for subclassing.
>>
>> I would also consider making classes final, especially if the ctor is
>> private.
>
>
> Any caveat on doing that?  Is this a final (!) decision or can one
> change one's mind in a later release?
> What are the benefits?
>
> Thanks,
> Gilles
>
>>
>> Gary
>>
>>
>> On Thu, Feb 1, 2018 at 7:07 AM, Gilles 
>> wrote:
>>
>>> On Thu, 01 Feb 2018 13:59:13 +0100, Gilles wrote:
>>>
 Hi.

 IMHO, there are too many accessor and factory methods.
 We should strive for a lean and consistent API.

 For the factory methods, I suggest the "of" convention:
  public static Complex ofCartesian(double re, double im)
  public static Complex ofPolar(double abs, double arg)
 And, as syntactic sugar:
  public static Complex ofCis(double arg)

>>>
>>> Those are useful too:
>>>public ofReal(double re)
>>>public ofImaginary(double im)
>>>
>>>
 For the accessors:
  public double re() { return real }
  public double im() { return imaginary }

 I'd have
   public double arg()
   public double abs()
 in order to compute the polar coordinates.

 I'm -0 to have others as syntactic sugar since they are
 misleading (a.o. when "implying" the read of a field when
 a computation is performed).

 WDYT?

>>>
>>> In addition to the above, I propose
>>> * to have a single, "private", constructor:
>>> private Complex(double re, double im)
>>> * to remove the "protected" method "createComplex" (
>>>   unless there is a case for inheritance).
>>>
>>> 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: [How to contribute] How to contribute to the community

[Yan, Xianming]

hi stefan

thanks for your reply.

i have a lot of free time.

i will check the informatin you gave me first and decie what next.

Thanks
Xianming

? 2018?2?24:41?Stefan Bodewig 
> ???

Hello

On 2018-02-02, Yan, Xianming wrote:

I just joined the mail group

welcome.

and want to do some contribution for the project, but don't know
how. If anyone know would you please tell me.

First of all you should find out what it is that looks like fun to
you. Which of the several Commons components are you interested in, what
is it that you want to spend your time on?

Once you have identified a component that you think is interesting go
looking at their bug tracker, maybe there are issues that sound
interesting or you see something where you immediately think "I can do
that!". Then mention in the issue you'd like to tackle it and give it a
try. If you realize you get stuck or you need to ask somebody why things
are the way they are, this list is the place to go.

On the commons website there are some more elaborate hints

http://commons.apache.org/volunteering.html
http://commons.apache.org/patches.html

the latter being more technical. And if you are new to the Apache
community you may want to quickly glance over
http://community.apache.org/newcomers/ and the "For Contributors" part
of the community website.

But don't get lost in too many details first. Remember this is supposed
to be fun and that you can always ask for advice on this list if
anything is unclear.

Cheers

   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: [VOTE] Create new component commons-signing

[Romain Manni-Bucau]

+1

Le 2 févr. 2018 18:54, "Mark Thomas"  a écrit :

Hello all,

I propose that we create a new component [commons-signing].

The scope of the component is code signing utilities including, but not
limited to, Ant and Maven plugins for the Symantec code signing service
that a number of ASF projects use.

We'll work most things out as we go along but the rough plan at this stage
is:

* git repo
* start with the Symantec Ant task in Tomcat
* add the Maven plugin from Sling
* refactor out the duplicate code
* first release

I'm leaning towards using GitHub issues rather than Jira.

Please review the proposal and vote. This vote will close no sooner that 72
hours from now.

  [ ] +1 Create the component
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this component because…

Cheers,

Mark

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

[VOTE] Create new component commons-signing

[Mark Thomas]

Hello all,

I propose that we create a new component [commons-signing].

The scope of the component is code signing utilities including, but not 
limited to, Ant and Maven plugins for the Symantec code signing service 
that a number of ASF projects use.


We'll work most things out as we go along but the rough plan at this 
stage is:


* git repo
* start with the Symantec Ant task in Tomcat
* add the Maven plugin from Sling
* refactor out the duplicate code
* first release

I'm leaning towards using GitHub issues rather than Jira.

Please review the proposal and vote. This vote will close no sooner that 
72 hours from now.


  [ ] +1 Create the component
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this component because…

Cheers,

Mark

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

Re: [VOTE] Create new component commons-signing

[Stefan Bodewig]

On 2018-02-02, Mark Thomas wrote:

> I propose that we create a new component [commons-signing].

> The scope of the component is code signing utilities including, but
> not limited to, Ant and Maven plugins for the Symantec code signing
> service that a number of ASF projects use.

+1

Stefan

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

[VOTE] Release Commons Compress 1.16 based on RC1

[Stefan Bodewig]

As indicated I think it is time to get Compress 1.16 out.

Compress 1.16 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 
24646)

The tag is here:

https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=tag;h=ead7ce22ad9aae1d099bb920a5bd6968a62177ad

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1303/org/apache/commons/commons-compress/1.16/

These are the Maven artifacts and their sha256 hashes

24aecd2a5223cf38fa438c789eb150bf87808dde225c9f199025af3a3bf5f2a8  
commons-compress-1.16.jar
a7e719e734e28c2b05ad97cde17491d76ed2f82bfdaa3445d2ab0a5108494fc5  
commons-compress-1.16-javadoc.jar
2f6f535dbad8d3929204608d0c6bf81bd0f94782aa2df89129e3ca10d7f54943  
commons-compress-1.16.pom
1472aca5ea66fe67c4dcde1a90667a3b0908b0f4ae56b55ef02f0b31f0709c82  
commons-compress-1.16-sources.jar
6381b09dfff184da2454b5590b94807604e5d7ee72af6eea6573d3b8af518a78  
commons-compress-1.16-tests.jar
d963a9cc8e314de0aabc3d7adccf4bc8449223b50b97722a9c17c7bb34117677  
commons-compress-1.16-test-sources.jar

I have tested this with JDK 8 ... using Maven 3

Details of changes since 1.15 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt

https://stefan.samaflost.de/staging/commons-compress-1.16/changes-report.html

Site:
https://stefan.samaflost.de/staging/commons-compress-1.16/

As usual when I cut a release this is not the site I'm going to
publish. I'll publish a fresh site from master once the release date
is known.

The download link and the link to the 1.16 javadocs are not expected
to work.

japicmp Report (compared to 1.15):
https://stefan.samaflost.de/staging/commons-compress-1.16/japicmp.html

Note that japicmp reports a source incompatible change to
LZ77Compressor.Block that I consider OK as the class is only used
internally and nobody is supposed to create subclasses outside of
Commons Compress.

RAT Report:
https://stefan.samaflost.de/staging/commons-compress-1.16/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 19:00 UTC 05-March 2018

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!

Stefan

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

Re: [VOTE] Create new component commons-signing

[sebb]

On 2 February 2018 at 17:54, Mark Thomas  wrote:
> Hello all,
>
> I propose that we create a new component [commons-signing].
>
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec code signing service that
> a number of ASF projects use.
>
> We'll work most things out as we go along but the rough plan at this stage
> is:
>
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
>
> I'm leaning towards using GitHub issues rather than Jira.

I think this may be too basic.
AFAIK it's currently not possible to document version numbers etc.
It may be possible to add labels (Bug, Enhancement etc) but it does
not look like it's possible to add a priority
Also there are only two states: open and closed. It might be possible
to use labels for some other states.
There does not seem to be any history for changes to labels.

In my experience GH issues work fine if there are not very many open ones.
Otherwise it can get very unwieldy.

> Please review the proposal and vote. This vote will close no sooner that 72
> hours from now.
>
>   [X] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
>
> Cheers,
>
> Mark
>
> -
> 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] Create new component commons-signing

[Emmanuel Bourg]

+1

Emmanuel Bourg

Le 02/02/2018 à 18:54, Mark Thomas a écrit :
> Hello all,
> 
> I propose that we create a new component [commons-signing].
> 
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec code signing service
> that a number of ASF projects use.
> 
> We'll work most things out as we go along but the rough plan at this
> stage is:
> 
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
> 
> I'm leaning towards using GitHub issues rather than Jira.
> 
> Please review the proposal and vote. This vote will close no sooner that
> 72 hours from now.
> 
>   [ ] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
> 
> Cheers,
> 
> Mark
> 
> -
> 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] Create new component commons-signing

[Gary Gregory]

+1 but use JIRA not GH.

Gary

On Feb 2, 2018 10:54, "Mark Thomas"  wrote:

> Hello all,
>
> I propose that we create a new component [commons-signing].
>
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec code signing service
> that a number of ASF projects use.
>
> We'll work most things out as we go along but the rough plan at this stage
> is:
>
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
>
> I'm leaning towards using GitHub issues rather than Jira.
>
> Please review the proposal and vote. This vote will close no sooner that
> 72 hours from now.
>
>   [ ] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
>
> Cheers,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Create new component commons-signing

[Rob Tompkins]

+1, the project convention is jira but I’m indifferent. Could be interesting to 
use github issues. 

> On Feb 2, 2018, at 12:54 PM, Mark Thomas  wrote:
> 
> Hello all,
> 
> I propose that we create a new component [commons-signing].
> 
> The scope of the component is code signing utilities including, but not 
> limited to, Ant and Maven plugins for the Symantec code signing service that 
> a number of ASF projects use.
> 
> We'll work most things out as we go along but the rough plan at this stage is:
> 
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
> 
> I'm leaning towards using GitHub issues rather than Jira.
> 
> Please review the proposal and vote. This vote will close no sooner that 72 
> hours from now.
> 
>  [ ] +1 Create the component
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this component because…
> 
> Cheers,
> 
> Mark
> 
> -
> 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] Create new component commons-signing

[Oliver Heger]

+1

Oliver

Am 02.02.2018 um 18:54 schrieb Mark Thomas:
> Hello all,
> 
> I propose that we create a new component [commons-signing].
> 
> The scope of the component is code signing utilities including, but not
> limited to, Ant and Maven plugins for the Symantec code signing service
> that a number of ASF projects use.
> 
> We'll work most things out as we go along but the rough plan at this
> stage is:
> 
> * git repo
> * start with the Symantec Ant task in Tomcat
> * add the Maven plugin from Sling
> * refactor out the duplicate code
> * first release
> 
> I'm leaning towards using GitHub issues rather than Jira.
> 
> Please review the proposal and vote. This vote will close no sooner that
> 72 hours from now.
> 
>   [ ] +1 Create the component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this component because…
> 
> Cheers,
> 
> Mark
> 
> -
> 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

[io] New filevisitor package

[Gary Gregory]

Hi All:

I propose a new package for [IO]: org.apache.commons.io.filevisitor.

This package will implementations of FileVisitor just like our filefilter
package contains implementations of java.io.FileFilter.

These implementation can then be used with the more efficient Java 7
Files.walk() methods.

Thoughts?

Gary

Re: [VOTE] Release Commons Compress 1.16 based on RC1

[Gary Gregory]

+1

>From src zip file: ASC, MD5, SHA1, SHA512 OK.

RAT check OK.

CLIRR check fails as noted:

[ERROR] 7013:
org.apache.commons.compress.compressors.lz77support.LZ77Compressor$Block:
Abstract method 'public
org.apache.commons.compress.compressors.lz77support.LZ77Compressor$Block$BlockType
getType()' has been added

" LZ77Compressor.Block that I consider OK as the class is only used
internally and nobody is supposed to create subclasses outside of
Commons Compress."

Can you Javadoc this for future releases then?

Did you consider using Rob's new Commons release plugin?

Tested 'mvn clean site' with:

Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T01:58:13-06:00)
Maven home: C:\Java\apache-maven-3.5.2\bin\..
Java version: 1.8.0_162, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_162\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Fails:

[INFO] Generating "japicmp" report   ---
japicmp-maven-plugin:0.11.0:cmp-report
[debug] No packaging support defined, no filtering
[debug] Searching for versions in versionRange: (,1.16)
[debug] Parameter  not configured, i.e. no version
filtered.
[warn] No new version specified and file
'C:\temp\rc\commons-compress-1.16-src\target\classes' of artifact could not
be opened as jar archive:
C:\temp\rc\commons-compress-1.16-src\target\classes (Access is denied)

java.io.FileNotFoundException:
C:\temp\rc\commons-compress-1.16-src\target\classes (Access is denied)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:225)
at java.util.zip.ZipFile.(ZipFile.java:155)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:130)
at
japicmp.maven.JApiCmpMojo.populateArchivesListsFromParameters(JApiCmpMojo.java:341)
at japicmp.maven.JApiCmpMojo.getOptions(JApiCmpMojo.java:704)
at
japicmp.maven.JApiCmpMojo.executeWithParameters(JApiCmpMojo.java:136)
at japicmp.maven.JApiCmpReport.executeReport(JApiCmpReport.java:71)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:255)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:230)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
at
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:184)
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:133)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 01:45 min
[INFO] Finished at: 2018-02-02T15:23:59-07:00
[INFO] Final Memory: 76M/881M
[INFO]

[ERROR] Failed to execute goal

Re: [VOTE] Create new component commons-signing

[Bernd Eckenfels]

+1

Greetings
Bernd

Von: Mark Thomas
Gesendet: Freitag, 2. Februar 2018 18:54
An: Commons Developers List
Betreff: [VOTE] Create new component commons-signing

Hello all,

I propose that we create a new component [commons-signing].

The scope of the component is code signing utilities including, but not 
limited to, Ant and Maven plugins for the Symantec code signing service 
that a number of ASF projects use.

We'll work most things out as we go along but the rough plan at this 
stage is:

* git repo
* start with the Symantec Ant task in Tomcat
* add the Maven plugin from Sling
* refactor out the duplicate code
* first release

I'm leaning towards using GitHub issues rather than Jira.

Please review the proposal and vote. This vote will close no sooner that 
72 hours from now.

   [ ] +1 Create the component
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this component because…

Cheers,

Mark

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

Re: [How to contribute] How to contribute to the community

[Stefan Bodewig]

Hello

On 2018-02-02, Yan, Xianming wrote:

> I just joined the mail group

welcome.

> and want to do some contribution for the project, but don't know
> how. If anyone know would you please tell me.

First of all you should find out what it is that looks like fun to
you. Which of the several Commons components are you interested in, what
is it that you want to spend your time on?

Once you have identified a component that you think is interesting go
looking at their bug tracker, maybe there are issues that sound
interesting or you see something where you immediately think "I can do
that!". Then mention in the issue you'd like to tackle it and give it a
try. If you realize you get stuck or you need to ask somebody why things
are the way they are, this list is the place to go.

On the commons website there are some more elaborate hints

http://commons.apache.org/volunteering.html
http://commons.apache.org/patches.html

the latter being more technical. And if you are new to the Apache
community you may want to quickly glance over
http://community.apache.org/newcomers/ and the "For Contributors" part
of the community website.

But don't get lost in too many details first. Remember this is supposed
to be fun and that you can always ask for advice on this list if
anything is unclear.

Cheers

Stefan

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