Re: [all] What versions of java do we support?

[Ralph Goers]

Why are you singling out Corretto? What about AdoptOpenJDK or RedHat’s OpenJDK 
support? The ASF is supposed to be vendor neutral.

Ralph

> On Mar 21, 2019, at 11:05 AM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> I would think that with the Amazon Corretto play at long term support for 
> java 8 and 11 we would want to build using the latest version of the Corretto 
> 8-JDK, and we would want to ensure that we work for Java 11. Regarding later 
> versions of Java I’m a tad agnostic currently as we are less certain with 
> their stability.
> 
> What are folks’ thoughts?
> 
> -Rob
> -
> 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: [VFS] Publishing a snapshot

[Ralph Goers]

I did a fresh checkout and got the same error. Although I am using Maven 3.0.3 
and you are using 3.0.4 I think it is unlikely to be the cause. More likely is 
that I am on a Mac and you are on Windows.

Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.6.0_33, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"

Ralph

On Jul 23, 2012, at 5:04 AM, Gary Gregory wrote:

> Maven work for me with:
> 
>> m3 clean test
> 
> Can you check that you have the latest from SVN?
> 
>> m3 -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: C:\Java\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_31\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> 
> Thank you,
> Gary
> 
> On Mon, Jul 23, 2012 at 3:22 AM, Ralph Goers 
> wrote:
> 
>> I was going to try to see if I could do it but I am getting a unit test
>> failure.
>> 
>> 
>> ---
>> Test set: org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase
>> 
>> ---
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.145 sec
>> <<< FAILURE!
>> junit.framework.TestSuite@3dd06d02(org.apache.commons.vfs2.test.ProviderTestSuite)
>> Time elapsed: 3.144 sec  <<< ERROR!
>> org.apache.commons.vfs2.FileSystemException: Unknown message with code
>> "org.apache.commons.vfs2.FileNotFoundException Could not read from
>> "file:///Users/rgoers/projects/apache/commons/vfs/trunk/core/target/test-classes/test-data/write-tests/file1.txt"
>> because it is a not a file.".
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:289)
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.importTree(RamFileSystem.java:231)
>>at
>> org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase.getBaseTestFolder(RamProviderTestCase.java:90)
>>at
>> org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:166)
>>at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
>>at junit.framework.TestResult.runProtected(TestResult.java:128)
>>at junit.extensions.TestSetup.run(TestSetup.java:27)
>>at
>> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>at java.lang.reflect.Method.invoke(Method.java:597)
>>at
>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>>at
>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>>at
>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
>> 
>> 
>> 
>> 
>> On Jul 22, 2012, at 10:53 PM, Gary Gregory wrote:
>> 
>>> Ugh, I hate these Maven problems.
>>> 
>>> With the command below, Maven hangs on:
>>> 
>>> [INFO] --- maven-gpg-plugin:1.4:sign (default) @ commons-vfs2-project ---
>>> 
>>> My set up works for other Commons component when I use

Re: [VFS] Publishing a snapshot

[Ralph Goers]

Unfortunately, I don't have much time during work hours. I might have time 
tonight.

Ralph

On Jul 23, 2012, at 9:04 AM, Gary Gregory wrote:

> On Mon, Jul 23, 2012 at 10:48 AM, Ralph Goers 
> wrote:
> 
>> I did a fresh checkout and got the same error. Although I am using Maven
>> 3.0.3 and you are using 3.0.4 I think it is unlikely to be the cause. More
>> likely is that I am on a Mac and you are on Windows.
>> 
>> Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
>> Maven home: /usr/share/maven
>> Java version: 1.6.0_33, vendor: Apple Inc.
>> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"
>> 
> 
> Arg, do you have time to debug that one?
> 
> Anyone else w/ a Mac handy?
> 
> I am guessing Linux is OK or Continuum would have complained here:
> http://vmbuild.apache.org/continuum/buildResults.action?projectId=129&projectGroupId=16
> 
> Gary
> 
> 
>> 
>> Ralph
>> 
>> On Jul 23, 2012, at 5:04 AM, Gary Gregory wrote:
>> 
>>> Maven work for me with:
>>> 
>>>> m3 clean test
>>> 
>>> Can you check that you have the latest from SVN?
>>> 
>>>> m3 -version
>>> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
>>> Maven home: C:\Java\apache-maven-3.0.4\bin\..
>>> Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
>>> Java home: C:\Program Files\Java\jdk1.6.0_31\jre
>>> Default locale: en_US, platform encoding: Cp1252
>>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>> 
>>> Thank you,
>>> Gary
>>> 
>>> On Mon, Jul 23, 2012 at 3:22 AM, Ralph Goers >> wrote:
>>> 
>>>> I was going to try to see if I could do it but I am getting a unit test
>>>> failure.
>>>> 
>>>> 
>>>> 
>> ---
>>>> Test set: org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase
>>>> 
>>>> 
>> ---
>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.145
>> sec
>>>> <<< FAILURE!
>>>> junit.framework.TestSuite@3dd06d02
>> (org.apache.commons.vfs2.test.ProviderTestSuite)
>>>> Time elapsed: 3.144 sec  <<< ERROR!
>>>> org.apache.commons.vfs2.FileSystemException: Unknown message with code
>>>> "org.apache.commons.vfs2.FileNotFoundException Could not read from
>>>> 
>> "file:///Users/rgoers/projects/apache/commons/vfs/trunk/core/target/test-classes/test-data/write-tests/file1.txt"
>>>> because it is a not a file.".
>>>>   at
>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:289)
>>>>   at
>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>>>   at
>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>>>   at
>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.importTree(RamFileSystem.java:231)
>>>>   at
>>>> 
>> org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase.getBaseTestFolder(RamProviderTestCase.java:90)
>>>>   at
>>>> 
>> org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:166)
>>>>   at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
>>>>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>>>>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>>>>   at
>>>> 
>> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
>>>>   at
>>>> 
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
>>>>   at
>>>> 
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
>>>>   at
>>>> 
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
>>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>&g

Re: [configuration] Checkstyle warning about double-checked locking in DynamicCombinedConfiguration

[Ralph Goers]

I used that specifically to avoid creating multiple combined configurations 
since it can be fairly expensive to create them.  I looked into the guarantees 
that ConcurrentMap provides before I implemented that and included the comment 
since I knew it would catch someone's eye.  

Ralph

On Jul 29, 2012, at 12:40 PM, Oliver Heger wrote:

> There is a checkstyle warning about double-checked locking in method 
> DynamicCombinedConfiguration.getCurrentConfig(). Indeed, the double-check 
> locking idiom is used, however, there is a comment saying that this safe due 
> to the usage of a ConcurrentMap.
> 
> This may be true, but I wonder whether it would be better to use the map's 
> putIfAbsent() method and avoid synchronization. The worst thing that can 
> happen is that on parallel access multiple CombinedConfiguration instances 
> are created which can be passed immediately to the garbage collector.
> 
> Thoughts?
> 
> Oliver
> 
> -
> 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: [configuration] Checkstyle warning about double-checked locking in DynamicCombinedConfiguration

[Ralph Goers]

On Jul 30, 2012, at 2:10 PM, sebb wrote:

> On 30 July 2012 20:34, Oliver Heger  wrote:
>> Am 29.07.2012 22:41, schrieb Ralph Goers:
>> 
>>> I used that specifically to avoid creating multiple combined
>>> configurations since it can be fairly expensive to create them.  I looked
>>> into the guarantees that ConcurrentMap provides before I implemented that
>>> and included the comment since I knew it would catch someone's eye.
>>> 
>>> Ralph
>> 
>> 
>> Thanks for clarifying. I added a suppression in the Checkstyle configuration
>> so that this warning will not pop up again.
> 
> An alternative solution might be to drop the synchronised block and
> use the atomic putIfAbsent() method.
> 
> That would reduce the synch. overhead.
> The downside is that the code might occasionally create and configure
> an instance of CombinedConfiguration that is then not used (if another
> thread happens to do the same).

Did you read Oliver's message which is directly below what you wrote?

Ralph

> 
>> Oliver
>> 
>> 
>>> 
>>> On Jul 29, 2012, at 12:40 PM, Oliver Heger wrote:
>>> 
>>>> There is a checkstyle warning about double-checked locking in method
>>>> DynamicCombinedConfiguration.getCurrentConfig(). Indeed, the double-check
>>>> locking idiom is used, however, there is a comment saying that this safe 
>>>> due
>>>> to the usage of a ConcurrentMap.
>>>> 
>>>> This may be true, but I wonder whether it would be better to use the
>>>> map's putIfAbsent() method and avoid synchronization. The worst thing that
>>>> can happen is that on parallel access multiple CombinedConfiguration
>>>> instances are created which can be passed immediately to the garbage
>>>> collector.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Oliver
>>>> 
>>>> -
>>>> 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
>> 
> 
> -
> 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: [configuration] Checkstyle warning about double-checked locking in DynamicCombinedConfiguration

[Ralph Goers]

On Jul 30, 2012, at 2:17 PM, sebb wrote:

> On 30 July 2012 22:13, Ralph Goers  wrote:
>> 
>> On Jul 30, 2012, at 2:10 PM, sebb wrote:
>> 
>>> On 30 July 2012 20:34, Oliver Heger  wrote:
>>>> Am 29.07.2012 22:41, schrieb Ralph Goers:
>>>> 
>>>>> I used that specifically to avoid creating multiple combined
>>>>> configurations since it can be fairly expensive to create them.  I looked
>>>>> into the guarantees that ConcurrentMap provides before I implemented that
>>>>> and included the comment since I knew it would catch someone's eye.
>>>>> 
>>>>> Ralph
>>>> 
>>>> 
>>>> Thanks for clarifying. I added a suppression in the Checkstyle 
>>>> configuration
>>>> so that this warning will not pop up again.
>>> 
>>> An alternative solution might be to drop the synchronised block and
>>> use the atomic putIfAbsent() method.
>>> 
>>> That would reduce the synch. overhead.
>>> The downside is that the code might occasionally create and configure
>>> an instance of CombinedConfiguration that is then not used (if another
>>> thread happens to do the same).
>> 
>> Did you read Oliver's message which is directly below what you wrote?
> 
> Yes, but that only talks about suppressing the warning, not reducing
> the amount of time spent in the synchronised block.

We must be reading something different. In the second paragraph below Oliver 
also suggested using putIfAbsent and removing the synchronization.  My response 
at the top of this is exactly why I chose not to do that.

Ralph

> 
>> Ralph
>> 
>>> 
>>>> Oliver
>>>> 
>>>> 
>>>>> 
>>>>> On Jul 29, 2012, at 12:40 PM, Oliver Heger wrote:
>>>>> 
>>>>>> There is a checkstyle warning about double-checked locking in method
>>>>>> DynamicCombinedConfiguration.getCurrentConfig(). Indeed, the double-check
>>>>>> locking idiom is used, however, there is a comment saying that this safe 
>>>>>> due
>>>>>> to the usage of a ConcurrentMap.
>>>>>> 
>>>>>> This may be true, but I wonder whether it would be better to use the
>>>>>> map's putIfAbsent() method and avoid synchronization. The worst thing 
>>>>>> that
>>>>>> can happen is that on parallel access multiple CombinedConfiguration
>>>>>> instances are created which can be passed immediately to the garbage
>>>>>> collector.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> Oliver
>>>>>> 
>>>>>> -
>>>>>> 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
>>>> 
>>> 
>>> -
>>> 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
> 


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

Commons web site

[Ralph Goers]

Infra has mandated that all projects move to the Apache CMS (or svnpubsub) by 
the end of the year. We also must change from distributing releases from 
people.apache.org to https://dist.apache.org/repos/dist/commons.  Changing the 
second item is fairly trivial but migrating the web site is a pretty large 
effort. 

The Logging project is also an umbrella project, albeit much smaller, and 
recently made the migration.  I recommend that commons use the same (or 
similar) mechanism that Logging is using - the main site uses the CMS directly 
and sub projects can either use the CMS or be manually committed. See 
(http://wiki.apache.org/logging/ManagingTheWebSite).

To summarize, 
1. The main Commons site would be managed at 
https://svn.apache.org/repos/asf/commons/site/trunk. 
2. Each subproject would reside at 
https://svn.apache.org/repos/infra/websites/production/commons/content/projectname.
3. If the subproject does not use the CMS it would be specified in extpaths.txt 
and would follow guidelines similar to the wiki link above.
4. If the project uses the CMS it would not be specified in extpaths.txt and 
would commit its files into the svn area in item 1.

FWIW,  I've also built the Flume website using this model. They use maven to 
build the main site (the CMS will run "mvn site" when any content is changed). 
Logging is using a tool called Twig. 

I'm not necessarily volunteering to build the site as I don't have a lot of 
time at the moment, but I am willing to help since I've done it for two 
projects now.

Comments?

Ralph

Re: [VOTE] Release Commons Configuration 1.9 based on RC 1

[Ralph Goers]

I don't think that is serious enough to warrant another candidate. I plan to 
review RC1 later today.

Ralph

On Aug 19, 2012, at 6:38 AM, Gary Gregory wrote:

> If you change the POM and you want that to be part of the release then
> you need another RC. In this case, you want a cleaner Clirr report for
> that release which means that report must be able to be generated from
> the release tag and sources. At least that's how it seems to me.
> 
> Gary
> 
> On Aug 18, 2012, at 11:13, Oliver Heger  wrote:
> 
>> Am 17.08.2012 23:58, schrieb sebb:
>>> On 17 August 2012 21:02, Oliver Heger  wrote:
 Hi Gary,
 
 Am 17.08.2012 21:19, schrieb Gary Gregory:
 
> Hi All,
> 
> Are the Clirr warning about constant value changes from 1.8 be an issue
> for
> existing clients?
> Or, are the values only used by [configuration] itself?
 
 
 the constants are only used internally. They belong to the parser for plist
 configuration files (which is generated by JavaCC) and define its state
 transition graph. They have changed because the parser now supports 
 comments
 in configuration files.
>>> 
>>> If there is a need to add new constants in the future, can JavaCC be
>>> persuaded to add them at the end?
>>> This would avoid needless warnings in the Clirr report.
>>> 
>>> Also, it would help if the release notes explained why the Clirr
>>> warnings are harmless to forestall any questions by users.
>> 
>> The affected class is not even part of the code base, it is generated during 
>> the build process. If you have a look at the source code [1], you will 
>> probably agree that it is hardly of any use for client applications. 
>> Therefore, I think writing a warning in the release notes will add more 
>> confusion than it helps.
>> 
>> Wouldn't it be better then to exclude the class from the Clirr report? Will 
>> have to check whether this is possible. This could be done before publishing 
>> the site for the next SNAPSHOT version and would not require a new RC, right?
>> 
>> Oliver
>> 
>> [1] 
>> http://people.apache.org/~oheger/configuration-1.9rc1/xref/org/apache/commons/configuration/plist/PropertyListParserConstants.html
>> 
>>> 
 Thanks for the review.
 Oliver
 
 
> 
> Thank you,
> Gary
> 
> On Thu, Aug 16, 2012 at 4:09 PM, Oliver Heger
> wrote:
> 
>> This is a vote to release Apache Commons Configuration 1.9 based on the
>> first release candidate.
>> 
>> Tag:
>> http://svn.apache.org/repos/**asf/commons/proper/**configuration/tags/**
>> 
>> CONFIGURATION_1_9RC1/
>> 
>> Site:
>> 
>> http://people.apache.org/~**oheger/configuration-1.9rc1/
>> 
>> Binaries:
>> https://repository.apache.org/**content/repositories/**
>> 
>> orgapachecommons-016/
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>> 
>> Vote will remain open for at least 72 hours.
>> 
>> Oliver
>> 
>> --**--**-
>> To unsubscribe, e-mail:
>> dev-unsubscribe@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
>>> 
>> 
>> 
>> -
>> 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: [VOTE] Release Commons Configuration 1.9 based on RC 1

[Ralph Goers]

Yes - and I didn't get a chance to do it last night.  Please give me another 24 
hrs.

Ralph

On Aug 20, 2012, at 4:43 AM, Gary Gregory wrote:

> Oops I meant Ralph not Sebb!
> 
> Gary
> 
> On Aug 20, 2012, at 7:38, Oliver Heger  wrote:
> 
>> Am 19.08.2012 20:00, schrieb Ralph Goers:
>>> I don't think that is serious enough to warrant another candidate. I plan 
>>> to review RC1 later today.
>>> 
>>> Ralph
>>> 
>>> On Aug 19, 2012, at 6:38 AM, Gary Gregory wrote:
>>> 
>>>> If you change the POM and you want that to be part of the release then
>>>> you need another RC. In this case, you want a cleaner Clirr report for
>>>> that release which means that report must be able to be generated from
>>>> the release tag and sources. At least that's how it seems to me.
>>>> 
>>>> Gary
>> 
>> A configuration of the clirr plug-in was added to the pom which excludes 
>> parser classes generated by JavaCC from the clirr report, so the report is 
>> now clear.
>> 
>> After the release the site for the new snapshot will be deployed, so there 
>> won't be any clirr warnings.
>> 
>> BTW, 72 hours are passed now, and there are only 2 +1 votes. It would be 
>> nice if somebody did another review!
>> 
>> Oliver
>> 
>>>> 
>>>> On Aug 18, 2012, at 11:13, Oliver Heger  
>>>> wrote:
>>>> 
>>>>> Am 17.08.2012 23:58, schrieb sebb:
>>>>>> On 17 August 2012 21:02, Oliver Heger  
>>>>>> wrote:
>>>>>>> Hi Gary,
>>>>>>> 
>>>>>>> Am 17.08.2012 21:19, schrieb Gary Gregory:
>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Are the Clirr warning about constant value changes from 1.8 be an issue
>>>>>>>> for
>>>>>>>> existing clients?
>>>>>>>> Or, are the values only used by [configuration] itself?
>>>>>>> 
>>>>>>> 
>>>>>>> the constants are only used internally. They belong to the parser for 
>>>>>>> plist
>>>>>>> configuration files (which is generated by JavaCC) and define its state
>>>>>>> transition graph. They have changed because the parser now supports 
>>>>>>> comments
>>>>>>> in configuration files.
>>>>>> 
>>>>>> If there is a need to add new constants in the future, can JavaCC be
>>>>>> persuaded to add them at the end?
>>>>>> This would avoid needless warnings in the Clirr report.
>>>>>> 
>>>>>> Also, it would help if the release notes explained why the Clirr
>>>>>> warnings are harmless to forestall any questions by users.
>>>>> 
>>>>> The affected class is not even part of the code base, it is generated 
>>>>> during the build process. If you have a look at the source code [1], you 
>>>>> will probably agree that it is hardly of any use for client applications. 
>>>>> Therefore, I think writing a warning in the release notes will add more 
>>>>> confusion than it helps.
>>>>> 
>>>>> Wouldn't it be better then to exclude the class from the Clirr report? 
>>>>> Will have to check whether this is possible. This could be done before 
>>>>> publishing the site for the next SNAPSHOT version and would not require a 
>>>>> new RC, right?
>>>>> 
>>>>> Oliver
>>>>> 
>>>>> [1] 
>>>>> http://people.apache.org/~oheger/configuration-1.9rc1/xref/org/apache/commons/configuration/plist/PropertyListParserConstants.html
>>>>> 
>>>>>> 
>>>>>>> Thanks for the review.
>>>>>>> Oliver
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> On Thu, Aug 16, 2012 at 4:09 PM, Oliver Heger
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> This is a vote to release Apache Commons Configuration 1.9 based on 
>>>>>>>>> the
>>>>>>>>> first release candidate.
>>>>

Re: [all] displaying some class and sequence diagrams for our components

[Ralph Goers]

I use http://www.websequencediagrams.com/  for most of my sequence diagrams. It 
won't do other UML diagrams but the sequence diagrams are incredibly easy to 
do.  It is also possible to just embed links to their service with your diagram 
text in the web site.

Ralph



On Aug 20, 2012, at 5:27 AM, Luc Maisonobe wrote:

> Hello,
> 
> As our components are mainly low level libraries, they target
> developers. I wonder if we could add some basic UML diagrams for some
> elements.
> 
> I know such diagrams are a pain to maintain, so I have looked at
> something really simple, with the goal to only display a few core elements.
> 
> I have found plantuml  to be
> almost a perfect fir for this goal. It can be used from the command
> line, it can be used with eclipse, it can be used with Maven (see
> ).
> 
> Here are some diagrams I have made for [math]:
> . There are
> also other diagrams I have made for Orekit, which aslo show some
> sequence diagrams:
> .
> 
> I would like to add such diagrams to our documentation, for example by
> adding a "design" directory under "src/site" for holding the .puml text
> files that depict the diagrams, and generating the png images under
> target/site/images. This can be done by adding the following plugin
> definition to the pom, in the build section:
> 
>  
>com.github.jeluard
>maven-plantuml-plugin
>7876
>
>  
>${basedir}
>
>  
>src/site/design/*.puml
>  
>
>  
>  
>${basedir}/target/site/images/design
>  
>
>
>  
>pre-site
>
>  generate
>
>  
>
>
>  
>net.sourceforge.plantuml
>plantuml
>7930
>  
>
>  
> 
> I don't know however if this runs everywhere, as I guess plantuml itself
> has a hidden dependency to graphviz.
> 
> I have two questions. Could someone check if the maven integration runs
> by itself on a pristine computer with nothing special installed (i.e.
> without having graphviz pre-installed) ? What do you think about adding
> such feature, either with an automatic generation of images or with the
> images pre-generated by our own build tools and included (together with
> their source script) in the distribution archive?
> 
> best regards,
> Luc
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [VOTE] Release Commons Configuration 1.9 based on RC 1

[Ralph Goers]

With Phil's +1 you should now have the 3 +1s.  I still haven't been able to 
look at it so go ahead.

Ralph

On Aug 20, 2012, at 11:33 AM, Phil Steitz wrote:

> On 8/16/12 1:09 PM, Oliver Heger wrote:
>> This is a vote to release Apache Commons Configuration 1.9 based
>> on the first release candidate.
>> 
>> Tag:
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_1_9RC1/
>> 
>> 
>> Site:
>> http://people.apache.org/~oheger/configuration-1.9rc1/
>> 
>> Binaries:
>> https://repository.apache.org/content/repositories/orgapachecommons-016/
>> 
>> 
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>> 
>> Vote will remain open for at least 72 hours.
>> 
>> Oliver
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> Checked build on
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_33
> OS name: "mac os x" version: "10.7.4" arch: "x86_64" Family: "mac"
> 
> Checked sigs on tars, tar / jar content, release notes.
> 
> All look fine to me.
> 
> +1 to release
> 
> Phil
> 
> -
> 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: [vfs] dependencies update to new versions & etc.

[Ralph Goers]

I will second what others have said.  There really is no way to effectively 
review an 800k patch.  If it is that big largely because it is including a 
jackrabbit jar directly into the project I would probably not be in favor of 
that.  I am not a fan of directly including project A's jars directly in 
project B. 

Please open JIRA issues and attach the patches to them.  

Ralph

On Aug 23, 2012, at 6:17 AM, Syao Work wrote:

> Hello,
> 
> we have some patches for VFS trunk version. We used trunk version as
> parent. The mailing list doesn't take 800K patch file. Where can we send
> the patch?
> 
> The fixes we made:
>   1. updated dependencies on VFS project,
>   2. Moved to JCR-2.0 and Jackrabbit 2.5.1
>   3. some minor changes to remove some warnings.
>   4. jackrabbit-standalone-2.5.1.jar file was added to
> ./core/src/test/resources/ directory (to satisfy tests). []
>   5. More TODOs were added.
> that's all for now.
> 
> P.S. To make WebDav tests you need to run jackrabbit-standalone.jar. Then
> copy the test data to remote webdav directory as pointed in your webpage.
> P.S.S I could commit the changes to svn but I don't have user for that.
> 
> Best regards.
> Jonny


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

Re: [site] yet another proposal on how to restyle the commons site

[Ralph Goers]

Actually, I am not sure that the full listing of the components on the main 
page even needs to be there.  If you click on "components" in the left nav you 
get pretty much the same thing. So I would prefer to see a much shorter 
section on Commons Proper, perhaps with the same link in that text.

Is this work in preparation for moving to the CMS?

Ralph


On Aug 31, 2012, at 3:28 AM, sebb wrote:

> On 31 August 2012 10:09, Simone Tripodi  wrote:
>> Hi again,
>> 
>> Thanks to Christian Grobmeier, we also added the responsive bootstrap css.
>> 
>> I re-uploaded the site, can you please have a look at it?
>> TIA,
>> -Simo
> 
> Looks much better now; seems to contain all the required elements, and
> they are easier to find than on the horizontal menu.
> Compared with the present design, it does look cleaner.
> 
> However the pages are considerably longer; it's a pity that the lhs
> menu does not fit on the first page.
> 
> I'm not sure it makes sense to add the Google and Facebook links, but
> if they are present, they should both have hover text; only Google
> does at present.
> Also, the ApacheCon advert is more important to the ASF, and should
> appear before them.
> Can they appear horizontally aligned?
> 
> The text font on the Commons logo now looks out of place (and the TM
> is missing - wrong file used?), so at some point it would be sensible
> to redo it.
> 
> -
> 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: [site] yet another proposal on how to restyle the commons site

[Ralph Goers]

On Aug 31, 2012, at 10:47 AM, Simone Tripodi wrote:

> Hi Ralph!
> 
>> Actually, I am not sure that the full listing of the components on the main 
>> page even needs to be there.  If you click on "components" in the left nav 
>> you get pretty much the same thing.  So I would prefer to see a much shorter 
>> section on Commons Proper, perhaps with the same link in that text.
>> 
> 
> That is indeed the reason why I originally put the carousel in the
> first attempt[1] rather than the complete list, but I reverted for the
> purpose to achieve the general agreement to apply the skin

With as many projects as we have the carousel isn't very usable as it takes too 
long to cycle. With the sidebar I don't think you really need that.

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

Re: [configuration] Plan for 2.0

[Ralph Goers]

If you are going to break compatibility the package names need to be changed.

I really dislike CombinedConfiguration.  Having the combined nodes point into 
other configuration nodes makes reloading fragile which is why it now copies 
nodes.  This means that a DynamicCombinedConfiguration that has a common 
default node will have as many copies of the default node as there are 
instances of the CombinedConfiguration.  This uses a large amount of memory.  I 
really wish DefaultConfigurationBuilder worked on an AggregateConfiguration, 
but that isn't designed to support XML.

The bottom line is that we should think about the classes and interfaces that 
are there and create a more rational hierarchy. For example, 
DefaultConfigurationBuilder should be able to create any kind of combination, 
which means it should work with an Interface, not a concrete class.

I still believe HierarchicalConfiguration should be a base Interface, not a 
Class.

The nonsense with attribute splitting and delimiter parsing needs to go away.

Ralph

On Sep 7, 2012, at 12:46 PM, Oliver Heger wrote:

> Hi all,
> 
> the pom was updated to make 2.0-SNAPSHOT the current development version. 
> This means we are free to implement major changes without having to enforce 
> binary backwards compatibility.
> 
> The question is: What are the goals for version 2.0? I would recommend to 
> define a clear focus so that the next release will not take too long. 
> Obviously there are already people waiting for a [configuration] version 
> compatible with [lang3].
> 
> Some points I have in mind are the following ones:
> - Switch to [lang3]. This is the main reason for going to version 2.0 because 
> this cannot be done in a binary compatible way.
> - Improve thread safety and concurrent implementations in general.
> - Rework reloading. This is related to the previous point because I think the 
> tight coupling of the current reloading implementation is one of the root 
> causes making the implementation of thread-safe configurations so hard.
> - Have a look at older Jira tickets which have been postponed because they 
> would break binary compatibility.
> 
> Any other points, wishes, or opinions? We should discuss the points 
> separately when it comes to their implementation.
> 
> Oliver
> 
> -
> 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: [configuration] Should we remove list splitting for attributes in XMLConfiguration?

[Ralph Goers]

No objection.

I believe this was done because of the way lists are done in property files - a 
comma separated list of values on a single property.  In XML you would just 
have multiple instances of the element, each with its own value.  This is one 
of the reasons why having the "flat" configuration as the base for hierarchical 
configurations is bad.

Ralph


On Sep 8, 2012, at 8:11 AM, Oliver Heger wrote:

> Currently XMLConfiguration allows setting multiple values for an attribute 
> node. (This is possible through the Configuration interface, but of course 
> not supported by XML.) When saving the configuration it tries to encode the 
> list as a comma-separated string. On reloading, such strings are split again.
> 
> The implementation of this feature is pretty complex because points like 
> escaping delimiter characters have to be taken into account. I doubt that it 
> works in a reliable way in all possible constellations. OTOH, I don't think 
> that this functionality provides much value to users.
> 
> So, in short, I propose to remove this feature. I would change the 
> implementation to check for attributes with multiple values when the 
> configuration is to be saved. If such attributes are detected, an exception 
> can be thrown.
> 
> Any objections?
> Oliver
> 
> -
> 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] xdoc vs. apt

[Ralph Goers]

I did the whole Flume web site in Sphinx -  http://flume.apache.org.   It works 
great for documentation but isn't really designed to build a web site - 
although you can.  

The Maven plugin has a few gotchas at the moment: 
1 - it has a bug that causes it to use a lot of memory on multi-module builds 
2. It can't effectively render PDFs (you can manually do this with rst2pdf). 

Ralph

On Sep 17, 2012, at 10:39 PM, Sébastien Brisard wrote:

> Hi,
> thanks for these answers.
> I agree that apt does not seem much better than xdoc, but it at least
> offers table formatting and so on.
> So can anyone recommend a good format? Otherwise, I'm quite happy with xhtml.
> 
> An option I'm going to look at at work is sphinx [1]. It has become
> widely spread in the python community and is based on the restructured
> text format.
> More importantly (for Commons-Math), it supports formulas, either with
> dvipng (requires a local installation of LaTeX), or Mathjax (which is
> pretty good, and could also be used in xhtml).
> I can report on my experiments with this format.
> 
> Best regards,
> Sébastien
> 
> [1] http://sphinx.pocoo.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: [configuration] Refactoring FileConfiguration

[Ralph Goers]

I second Joerg's statement.

Ralph

On Sep 29, 2012, at 4:02 AM, Jörg Schaible wrote:

> Oliver Heger wrote:
> 
>> One of the pain points in the 1.x versions of [configuration] is IMHO
>> the implementation of FileConfiguration using inheritance over
>> AbstractFileConfiguration and AbstractHierarchicalFileConfiguration.
>> 
>> I started an attempt to work around this: The part of
>> AbstractFileConfiguration which deals with handling of a location (file
>> name, File, URL, ...) and reading/writing data from/to it was extracted
>> into a new FileHandler class. An instance of this class is associated
>> with an object implementing the new FileBased interface. It is this
>> interface which now has to be implemented by file-based configuration
>> classes. It only defines the methods read(Reader) and write(Writer).
> 
> +1
> 
> Anything that improves the current situation is welcome :)
> 
> - Jörg
> 
> 
> -
> 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: svn commit: r1403346 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java

[Ralph Goers]

Gary,

What are you using to validate checkstyle?  checkstyle.xml says the max line 
length is 120 yet your log message says it is 150.

Ralph

On Oct 29, 2012, at 8:06 AM, ggreg...@apache.org wrote:

> Author: ggregory
> Date: Mon Oct 29 15:06:48 2012
> New Revision: 1403346
> 
> URL: http://svn.apache.org/viewvc?rev=1403346&view=rev
> Log:
> Checkstyle: Method length is 166 lines (max allowed is 150). Refactor large 
> method. Refactor anon constant.
> 
> Modified:
>
> commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java
> 
> Modified: 
> commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java?rev=1403346&r1=1403345&r2=1403346&view=diff
> ==
> --- 
> commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java
>  (original)
> +++ 
> commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java
>  Mon Oct 29 15:06:48 2012
> @@ -34,12 +34,9 @@ import org.apache.commons.vfs2.util.User
>  */
> public final class FtpsClientFactory
> {
> +private static final char[] ANON_CHAR_ARRAY = "anonymous".toCharArray();
> private static final int SHORT_MONTH_NAME_LEN = 40;
> 
> -private FtpsClientFactory()
> -{
> -}
> -
> /**
>  * Creates a new connection to the server.
>  * @param hostname The host name.
> @@ -57,81 +54,23 @@ public final class FtpsClientFactory
> // Determine the username and password to use
> if (username == null)
> {
> -username = "anonymous".toCharArray();
> +username = ANON_CHAR_ARRAY;
> }
> 
> if (password == null)
> {
> -password = "anonymous".toCharArray();
> +password = ANON_CHAR_ARRAY;
> }
> 
> try
> {
> 
> -final FTPSClient client;
> -
> -if 
> (FtpsFileSystemConfigBuilder.getInstance().getFtpsType(fileSystemOptions)
> -.equals(FtpsFileSystemConfigBuilder.FTPS_TYPE_EXPLICIT))
> -{
> -client = new FTPSClient();
> -}
> -else if 
> (FtpsFileSystemConfigBuilder.getInstance().getFtpsType(fileSystemOptions)
> -.equals(FtpsFileSystemConfigBuilder.FTPS_TYPE_IMPLICIT))
> -{
> -client = new FTPSClient(true);
> -}
> -else
> -{
> -throw new FileSystemException("Invalid FTPS type of "
> -+ 
> FtpsFileSystemConfigBuilder.getInstance().getFtpsType(fileSystemOptions)
> -+ " specified. Must be 'implicit' or 'explicit'");
> -}
> +final FTPSClient client = createFTPSClient(fileSystemOptions);
> 
> String key = 
> FtpsFileSystemConfigBuilder.getInstance().getEntryParser(fileSystemOptions);
> if (key != null)
> {
> -FTPClientConfig config = new FTPClientConfig(key);
> -
> -String serverLanguageCode = 
> FtpsFileSystemConfigBuilder.getInstance().getServerLanguageCode(
> -fileSystemOptions);
> -if (serverLanguageCode != null)
> -{
> -config.setServerLanguageCode(serverLanguageCode);
> -}
> -String defaultDateFormat = 
> FtpsFileSystemConfigBuilder.getInstance().getDefaultDateFormat(
> -fileSystemOptions);
> -if (defaultDateFormat != null)
> -{
> -config.setDefaultDateFormatStr(defaultDateFormat);
> -}
> -String recentDateFormat = 
> FtpsFileSystemConfigBuilder.getInstance().getRecentDateFormat(
> -fileSystemOptions);
> -if (recentDateFormat != null)
> -{
> -config.setRecentDateFormatStr(recentDateFormat);
> -}
> -String serverTimeZoneId = 
> FtpsFileSystemConfigBuilder.getInstance().getServerTimeZoneId(
> -fileSystemOptions);
> -if (serverTimeZoneId != null)
> -{
> -config.setServerTimeZoneId(serverTimeZoneId);
> -}
> -String[] shortMonthNames = 
> FtpsFileSystemConfigBuilder.getInstance().getShortMonthNames(
> -fileSystemOptions);
> -if (shortMonthNames != null)
> -{
> -StringBuilder shortMonthNamesStr = new 
> StringBuilder(SHORT_MONTH_NAME_LEN);
> -for (String shortMonthName : shortMonthNames)
> -  

[VFS] Unit test failure

[Ralph Goers]

I haven't run the build in a while but I don't recall ever seeing this before.

Running org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.229 sec <<< 
FAILURE!
junit.framework.TestSuite@77c7bee2(org.apache.commons.vfs2.test.ProviderTestSuite)
  Time elapsed: 3228 sec  <<< ERROR!
org.apache.commons.vfs2.FileSystemException: Unknown message with code 
"org.apache.commons.vfs2.FileNotFoundException Could not read from 
"file:///Users/rgoers/projects/apache/commons/vfs/trunk/core/target/test-classes/test-data/write-tests/file1.txt"
 because it is a not a file.".
at 
org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:289)
at 
org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
at 
org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
at 
org.apache.commons.vfs2.provider.ram.RamFileSystem.importTree(RamFileSystem.java:231)
at 
org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase.getBaseTestFolder(RamProviderTestCase.java:90)
at 
org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:166)
at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


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

Re: [VFS] Unit test failure

[Ralph Goers]

Nope.  Mac OS/X Lion

Ralph

On Oct 29, 2012, at 9:49 AM, Gary Gregory wrote:

> Hi Ralph,
> 
> I've never seen that one! I am on Windows. Are you on Linux?
> 
> Gary
> 
> On Mon, Oct 29, 2012 at 12:34 PM, Ralph Goers 
> wrote:
> 
>> I haven't run the build in a while but I don't recall ever seeing this
>> before.
>> 
>> Running org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.229 sec
>> <<< FAILURE!
>> junit.framework.TestSuite@77c7bee2(org.apache.commons.vfs2.test.ProviderTestSuite)
>> Time elapsed: 3228 sec  <<< ERROR!
>> org.apache.commons.vfs2.FileSystemException: Unknown message with code
>> "org.apache.commons.vfs2.FileNotFoundException Could not read from
>> "file:///Users/rgoers/projects/apache/commons/vfs/trunk/core/target/test-classes/test-data/write-tests/file1.txt"
>> because it is a not a file.".
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:289)
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>at
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.importTree(RamFileSystem.java:231)
>>at
>> org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase.getBaseTestFolder(RamProviderTestCase.java:90)
>>at
>> org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:166)
>>at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
>>at junit.framework.TestResult.runProtected(TestResult.java:128)
>>at junit.extensions.TestSetup.run(TestSetup.java:27)
>>at
>> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>at java.lang.reflect.Method.invoke(Method.java:597)
>>at
>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>>at
>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>>at
>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
>> 
>> 
>> -
>> 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
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


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

Re: [VFS] Unit test failure

[Ralph Goers]

I would expect file://c:\Users\ or file://c:/Users/ on Windows.

Ralph


On Oct 29, 2012, at 11:01 AM, Gary Gregory wrote:

> file:///Users/ smells like Windows 7... Hm...
> 
> G
> 
> On Mon, Oct 29, 2012 at 1:51 PM, James Carman 
> wrote:
> 
>> Same result here on Mac OS X Mountain Lion:
>> 
>> Results :
>> 
>> Tests in error:
>>  junit.framework.TestSuite@6e6dcfde
>> (org.apache.commons.vfs2.test.ProviderTestSuite):
>> Unknown message with code
>> "org.apache.commons.vfs2.FileNotFoundException Could not read from
>> 
>> "file:///Users/jcarman/IdeaProjects/commons-vfs/core/target/test-classes/test-data/write-tests/file1.txt"
>> because it is a not a file.".
>> 
>> 
>> 
>> On Mon, Oct 29, 2012 at 1:32 PM, Ralph Goers 
>> wrote:
>>> Nope.  Mac OS/X Lion
>>> 
>>> Ralph
>>> 
>>> On Oct 29, 2012, at 9:49 AM, Gary Gregory wrote:
>>> 
>>>> Hi Ralph,
>>>> 
>>>> I've never seen that one! I am on Windows. Are you on Linux?
>>>> 
>>>> Gary
>>>> 
>>>> On Mon, Oct 29, 2012 at 12:34 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>wrote:
>>>> 
>>>>> I haven't run the build in a while but I don't recall ever seeing this
>>>>> before.
>>>>> 
>>>>> Running org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase
>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.229
>> sec
>>>>> <<< FAILURE!
>>>>> junit.framework.TestSuite@77c7bee2
>> (org.apache.commons.vfs2.test.ProviderTestSuite)
>>>>> Time elapsed: 3228 sec  <<< ERROR!
>>>>> org.apache.commons.vfs2.FileSystemException: Unknown message with code
>>>>> "org.apache.commons.vfs2.FileNotFoundException Could not read from
>>>>> 
>> "file:///Users/rgoers/projects/apache/commons/vfs/trunk/core/target/test-classes/test-data/write-tests/file1.txt"
>>>>> because it is a not a file.".
>>>>>   at
>>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:289)
>>>>>   at
>>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>>>>   at
>>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.toRamFileObject(RamFileSystem.java:254)
>>>>>   at
>>>>> 
>> org.apache.commons.vfs2.provider.ram.RamFileSystem.importTree(RamFileSystem.java:231)
>>>>>   at
>>>>> 
>> org.apache.commons.vfs2.provider.ram.test.RamProviderTestCase.getBaseTestFolder(RamProviderTestCase.java:90)
>>>>>   at
>>>>> 
>> org.apache.commons.vfs2.test.AbstractTestSuite.setUp(AbstractTestSuite.java:166)
>>>>>   at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
>>>>>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>>>>>   at junit.extensions.TestSetup.run(TestSetup.java:27)
>>>>>   at
>>>>> 
>> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
>>>>>   at
>>>>> 
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>>>>>   at
>>>>> 
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>>>>>   at
>>>>> 
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>>>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>   at
>>>>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>   at
>>>>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>>   at java.lang.reflect.Method.invoke(Method.java:597)
>>>>>   at
>>>>> 
>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>>>>>   at
>>>>> 
>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>>>>>   at
>>>>> 
>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>>>>

Re: [all] moving to svnpubsub or CMS?

[Ralph Goers]

On Nov 14, 2012, at 2:03 PM, Ted Dunning wrote:

> On Wed, Nov 14, 2012 at 1:53 PM, Olivier Lamy  wrote:
> 
>> 2012/11/14 Thomas Vandahl :
>>> On 14.11.2012 08:40, Luc Maisonobe wrote:
 
 Please, could someone who knows what to do step up?
>>> 
>>> 
>>> Just a quick note that sites created by Maven can be published with
>>> svnpubsub using the  SCM Publish Maven Plugin
>>> (http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/). I guess
>>> this may keep the effort manageable (no further experience, though).
>>> 
>>> See especially the link
>>> 
>> http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/examples/importing-maven-site.html
>>> for how to do the initial import.
>> IMHO first checkin will be simpler doing a checkin of content from p.a.o
>> 
>> If you use this maven plugin and your project doesn't have any sub
>> modules deploying a site is a simple as today: mvm site-deploy (for
>> multi modules it's a different if needed I can help a bit as I have
>> setup that for other asf projects and write some part of this plugin
>> :-) ).
>> 
>> The question is more do you want to continue maven site generation for
>> docs or move to asf cms ?
>> 
> 
> This is a false dichotomy.
> 
> Maven site generation can work with ASF CMS if desired.

That is sort of true but doesn't really apply to commons.  I created the Flume 
site using Maven and Maven generates the site from RST source files.  This 
isn't a typical Maven project site.  In essence it is a CMS project that 
happens to invoke Maven whenever content is changed.  

IMO the Logging project site is a lot closer to what Commons needs.  The top 
level site is managed by the CMS.  Each of the project sites is built by Maven 
and is directly checked into the production area and each is independently 
managed.  See http://wiki.apache.org/logging/ManagingTheWebSite

Ralph

Re: Moving to svnpubsub for dist releases

[Ralph Goers]

Actually, if you use the Release plugin the artifacts will be uploaded to the 
staging repository. At least that is what VFS does.  They can be voted on there 
and then checked into SVN.  You can easily verify they didn't change because 
the MD5s go along with them.

Ralph

On Nov 26, 2012, at 8:41 AM, sebb wrote:

> On 26 November 2012 11:24, sebb  wrote:
>> On 26 November 2012 09:53, Emmanuel Bourg  wrote:
>>> Le 26/11/2012 01:01, sebb a écrit :
>>> 
 Hope this all makes sense!
>>> 
>>> Well, maybe I misunderstood, but committing the RC sites for review into
>>> a SVN repository seems a bit convoluted to me. A good old upload on
>>> people.apache.org was perfectly fine.
>> 
>> AIUI that's what infra want.
> 
> If the dist/dev URL (plus revision) is used in the vote thread, it's
> possible to easily trace the files from the ASF mirror back to the
> actual files used in the vote.
> 
> This is not nearly so easy if the files are just uploaded to a user
> directory on minotaur - there's no proof that the the files that were
> voted on are the ones that were eventually released.
> 
> At some point the files must be uploaded to SVN; once in SVN they can
> be moved around very cheaply.
> 
>>> Emmanuel Bourg
>>> 
>>> 
> 
> -
> 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: Moving to svnpubsub for dist releases

[Ralph Goers]

Traceability by who?

PMC members can easily verify that what is committed to dist matches what they 
verified using what they downloaded and the MD5s that came with them.  They are 
the ones responsible for the vote and the artifacts so I don't see a problem 
with that.  Why you would need some sort of formal linking once the artifacts 
are published escapes me.

Ralph


On Nov 26, 2012, at 9:23 AM, sebb wrote:

> On 26 November 2012 17:01, Ralph Goers  wrote:
>> Actually, if you use the Release plugin the artifacts will be uploaded to 
>> the staging repository. At least that is what VFS does.  They can be voted 
>> on there and then checked into SVN.  You can easily verify they didn't 
>> change because the MD5s go along with them.
> 
> But do the MD5s get automatically added to the release vote?
> And how can one prove later that the MD5s in the VOTE thread are the
> same as the ones in the staging repo?
> 
> AFAICT that is no different from uploading to anywhere else, unless I
> misunderstand what the release staging repository is.
> 
> The point is that uploading to SVN and voting on the URL+revision
> automatically provides traceability.
> Whereas AFAICT the other methods don't, at least not without
> additional work by the RM and all reviewers.
> 
>> Ralph
>> 
>> On Nov 26, 2012, at 8:41 AM, sebb wrote:
>> 
>>> On 26 November 2012 11:24, sebb  wrote:
>>>> On 26 November 2012 09:53, Emmanuel Bourg  wrote:
>>>>> Le 26/11/2012 01:01, sebb a écrit :
>>>>> 
>>>>>> Hope this all makes sense!
>>>>> 
>>>>> Well, maybe I misunderstood, but committing the RC sites for review into
>>>>> a SVN repository seems a bit convoluted to me. A good old upload on
>>>>> people.apache.org was perfectly fine.
>>>> 
>>>> AIUI that's what infra want.
>>> 
>>> If the dist/dev URL (plus revision) is used in the vote thread, it's
>>> possible to easily trace the files from the ASF mirror back to the
>>> actual files used in the vote.
>>> 
>>> This is not nearly so easy if the files are just uploaded to a user
>>> directory on minotaur - there's no proof that the the files that were
>>> voted on are the ones that were eventually released.
>>> 
>>> At some point the files must be uploaded to SVN; once in SVN they can
>>> be moved around very cheaply.
>>> 
>>>>> Emmanuel Bourg
>>>>> 
>>>>> 
>>> 
>>> -
>>> 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
> 


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

Re: Moving to svnpubsub for dist releases

[Ralph Goers]

On Nov 27, 2012, at 5:12 AM, Gilles Sadowski wrote:

> On Tue, Nov 27, 2012 at 10:55:14AM +, sebb wrote:
>> On 26 November 2012 17:41, Ralph Goers  wrote:
>>> Traceability by who?
>>> 
>>> PMC members can easily verify that what is committed to dist matches what 
>>> they verified using what they downloaded and the MD5s that came with them.  
>>> They are the ones responsible for the vote and the artifacts so I don't see 
>>> a problem with that.  Why you would need some sort of formal linking once 
>>> the artifacts are published escapes me.
>> 
>> The point is that using the SVN URL+revsion in the vote thread
>> automatically identifies a unique set of artifacts, and is a single
>> item to check.
> 
> That seems a welcome simplification.
> 

If you use the release plugin it isn't simpler.  Maven is going to deploy all 
the artifacts to the staging repository, including the distribution artifacts.  
Reviewers then do "wget -e robots=off --cut-dirs=3 -r -p -np 
--no-check-certificate link", where link is the url to the staging repository.  
After that the reviewer will have all the artifacts for inspection.  With what 
Sebb is proposing you will have to still do this to verify the Maven artifacts 
but you will also have to checkout the distribution artifacts from SVN, which 
seems like a needless step to me.

Ralph

Re: We will not be able to update our websites...

[Ralph Goers]

That is what we did in logging. Changing it at the end is fairly easy.  
However, we don't have much time for testing.

Ralph

On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:

> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory  wrote:
>> Well, we have to start somewhere. This is going to be a lot of work,
>> we have many components, unless you see a short cut.
> 
> I thought we would create: commons-test.apache.org
> move all components to there and then make a switch from
> commons.apache.org to the new site
> 
> 
> 
> 
>> Gary
>> 
>> On Dec 10, 2012, at 7:13, Christian Grobmeier  wrote:
>> 
>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory  
>>> wrote:
>>>> Bah, let's pick one component and start there and skip a test site.
>>> 
>>> But then there is only one component visible under the new commons.a.o?
>>> 
>>>> Gary
>>>> 
>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier  wrote:
>>>> 
>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>> 
>>>>> Commons is surely a LOT of work.
>>>>> 
>>>>> I would like to suggest we act immediately.
>>>>> 
>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>> out and prepare the new sites.
>>>>> 
>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>> too.
>>>>> 
>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>> generated via Maven. The target of this generation is then copied to
>>>>> another svn tree from which it will be taken and published.
>>>>> 
>>>>> Obviously we will have to generate sites for each component then, which
>>>>> will be a tough job with x-mas arriving.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>> 
>>> -
>>> 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
>> 
> 
> 
> 
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
> 
> -
> 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: We will not be able to update our websites...

[Ralph Goers]

All the sub-sites are hooked off the main site.  I would have no idea how to 
migrate anything without migrating the main site first.

I suppose it is possible to point to the sub-sites in their current location 
but in logging we found it more beneficial to simply copy the content under the 
main site in the CMS.

Are all the sub-sites built with Maven?  Any that are not could move to the CMS 
as part of the main site.

Ralph


On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:

> On 12/10/12 7:55 AM, Ralph Goers wrote:
>> That is what we did in logging. Changing it at the end is fairly easy.  
>> However, we don't have much time for testing.
> 
> Do we really have to do it all at once?
> 
> IIUC (which is quite possibly false), the intent here is to get
> everyone onto svn pub-sub and kill off the rsync processes from
> p.a.o to the live site.  The stake in the ground is that the rsyncs
> are going to stop Jan 1.  Do I have that right?
> 
> Why can't we move to svn pub-sub incrementally somehow,
> understanding that until individual components move, their sites
> will be read-only?  So basically, when you decide to make changes to
> a site, you get it set up for svn pub-sub?  Note I am including the
> main site in this - i.e., it does not have to "move" until it needs
> to be changed.  It would seem to me (again, may be missing something
> critical) that we could build the newly definitive source svn repo
> incrementally, with publishing always sourced from there, but "old"
> directories on the live host remaining until they get clobbered.  In
> the worst case, if the live host *must* include only svn-published
> files, we could seed the new repo with the "old" content.  But I
> don't get why that has to be the case; because if it is, we are in
> worse shape than Christian suggests - come Jan 1 we will be dark if
> we don't get everything moved to svn pub-sub.
> 
> Sorry if above is naive.  The intent is to avoid a huge amount of
> fiddling in a short period of time when quite a few component sites
> have not changed and will not change for some time to come.
> 
> Phil
> 
> 
>> 
>> Ralph
>> 
>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>> 
>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory  
>>> wrote:
>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>> we have many components, unless you see a short cut.
>>> I thought we would create: commons-test.apache.org
>>> move all components to there and then make a switch from
>>> commons.apache.org to the new site
>>> 
>>> 
>>> 
>>> 
>>>> Gary
>>>> 
>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier  wrote:
>>>> 
>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory  
>>>>> wrote:
>>>>>> Bah, let's pick one component and start there and skip a test site.
>>>>> But then there is only one component visible under the new commons.a.o?
>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier  
>>>>>> wrote:
>>>>>> 
>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>> 
>>>>>>> Commons is surely a LOT of work.
>>>>>>> 
>>>>>>> I would like to suggest we act immediately.
>>>>>>> 
>>>>>>> In other terms: let us request a commons-test cms where we can try 
>>>>>>> things
>>>>>>> out and prepare the new sites.
>>>>>>> 
>>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>>> too.
>>>>>>> 
>>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>>> another svn tree from which it will be taken and published.
>>>>>>> 
>>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>>> will be a tough job with x-mas arriving.
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> --
>>>>>>> http://www.grobmeier.de
>>>>>

Re: We will not be able to update our websites...

[Ralph Goers]

Yes, I think you are missing something fundamental.

If you check in "the whole mess" you will never again be able to properly build 
a sub-project's site with Maven.  This is because the process of updating the 
site would require first doing a diff and then deleting items that are not 
included in the new version. Someone created a Maven plugin to try to do this 
but it is not the way I would want to go at all.

Ralph

On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:

> I don't think there's much percentage in moving to the CMS with a structure
> like that of Commons.  That said, checking in the whole mess, as Phil
> suggests, seems perfectly doable and should not preclude updating parts of
> the tree in quite a similar fashion as how updating a given component's
> site is done today, except no ssh to mino.  Am I missing something
> fundamental?
> 
> Matt
> 
> 
> On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz  wrote:
> 
>> On 12/10/12 11:40 AM, Phil Steitz wrote:
>>> On 12/10/12 10:50 AM, Ralph Goers wrote:
>>>> All the sub-sites are hooked off the main site.  I would have no idea
>> how to migrate anything without migrating the main site first.
>>> Having now looked at [1], it looks to me like we can solve the
>>> immediate problem using svn pub-sub.  The docs are not clear and
>>> they may not allow it, but in theory, we could in fact do this
>>> incrementally - start an svn repo and move the "mutable" portions
>>> there incrementally, understanding that only changes to the
>>> svn-migrated stuff will be propagated.  If infra barfs on that, then
>>> we just commit the whole mess starting at the top level commons
>>> site, following the Ant example linked on [1].  Then to make
>>> changes, we follow the process that has been in place for the main
>>> ASF site for ages - maintain a local checkout of the generated site,
>>> re-gen when you want to update and check in.
>>> 
>>> I know playing with the CMS might be fun and interesting; but a) we
>>> have no volunteers to do this and b) we do not have time to migrate
>>> all of the content.
>>> 
>>> Therefore, I suggest we just follow the Ant route; possibly moving
>>> incrementally if infra allows that.
>> 
>> Let me modify the proposal to make it simpler and more palatable to
>> infra:
>> 
>> Just do like Ant - check in the whole mess.
>> 
>> Phil
>>> 
>>> Phil
>>> 
>>> [1] http://www.apache.org/dev/project-site.html
>>>> I suppose it is possible to point to the sub-sites in their current
>> location but in logging we found it more beneficial to simply copy the
>> content under the main site in the CMS.
>>>> 
>>>> Are all the sub-sites built with Maven?  Any that are not could move to
>> the CMS as part of the main site.
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>>> 
>>>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>>>> That is what we did in logging. Changing it at the end is fairly
>> easy.  However, we don't have much time for testing.
>>>>> Do we really have to do it all at once?
>>>>> 
>>>>> IIUC (which is quite possibly false), the intent here is to get
>>>>> everyone onto svn pub-sub and kill off the rsync processes from
>>>>> p.a.o to the live site.  The stake in the ground is that the rsyncs
>>>>> are going to stop Jan 1.  Do I have that right?
>>>>> 
>>>>> Why can't we move to svn pub-sub incrementally somehow,
>>>>> understanding that until individual components move, their sites
>>>>> will be read-only?  So basically, when you decide to make changes to
>>>>> a site, you get it set up for svn pub-sub?  Note I am including the
>>>>> main site in this - i.e., it does not have to "move" until it needs
>>>>> to be changed.  It would seem to me (again, may be missing something
>>>>> critical) that we could build the newly definitive source svn repo
>>>>> incrementally, with publishing always sourced from there, but "old"
>>>>> directories on the live host remaining until they get clobbered.  In
>>>>> the worst case, if the live host *must* include only svn-published
>>>>> files, we could seed the new repo with the "old" content.  But I
>>>>> don't get why that has to be the case; b

Re: We will not be able to update our websites...

[Ralph Goers]

On Dec 10, 2012, at 4:12 PM, sebb wrote:

> On 10 December 2012 21:53, Phil Steitz  wrote:
>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>> Yes, I think you are missing something fundamental.
>>> 
>>> If you check in "the whole mess" you will never again be able to properly 
>>> build a sub-project's site with Maven.  This is because the process of 
>>> updating the site would require first doing a diff and then deleting items 
>>> that are not included in the new version. Someone created a Maven plugin to 
>>> try to do this but it is not the way I would want to go at all.
>> 
>> Sorry, I don't get it.  Why won't the following work:
>> 
>> 0) Grab all of, say p.a.o/www/commons.apache.org
>> 1) check all of that into an svn repo
>> 2) when I want to update, say, math, I generate the content locally,
>> copy it to the /math subtree and check it in.
> 
> There would need to be some extra work done to ensure that stale files
> are deleted.
> 
> For some projects, it would be possible to just delete the existing
> sub-tree and check the whole new site in.
> [This can be done as one transaction in svnmucc]
> 
> However, for sites that retain Javadoc etc. for older releases, one
> would need to re-instate that part of the tree somehow.
> 
> Given that svnpubsub immediately publishes what is checked in, it
> might be sensible to have a parallel staging directory tree where
> files can be updated piecemeal if necessary, and then use svnmucc to
> replace the live component subtree with the staging component subtree
> as part of a single transaction.
> 
> There would need to be some co-ordination between committers when
> updating commons parent, as that would affect the whole tree.
> 

Yes. This is why Logging used the extpath approach where each subproject 
commits directly to production. Each release goes to a release subdirectory 
under each subproject's directory.  Then you can just perform your maven site 
build to a local directory, copy that into the production svn location, and 
commit it.

See "Managing the subproject sites" at 
http://wiki.apache.org/logging/ManagingTheWebSite

Ralph

Re: We will not be able to update our websites...

[Ralph Goers]

At the very least, someone should file a Jira asking for a commons-test site.

Ralph

On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:

> On 12/10/12 5:10 PM, Ralph Goers wrote:
>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>> 
>>> On 10 December 2012 21:53, Phil Steitz  wrote:
>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>> Yes, I think you are missing something fundamental.
>>>>> 
>>>>> If you check in "the whole mess" you will never again be able to properly 
>>>>> build a sub-project's site with Maven.  This is because the process of 
>>>>> updating the site would require first doing a diff and then deleting 
>>>>> items that are not included in the new version. Someone created a Maven 
>>>>> plugin to try to do this but it is not the way I would want to go at all.
>>>> Sorry, I don't get it.  Why won't the following work:
>>>> 
>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>> 1) check all of that into an svn repo
>>>> 2) when I want to update, say, math, I generate the content locally,
>>>> copy it to the /math subtree and check it in.
>>> There would need to be some extra work done to ensure that stale files
>>> are deleted.
> 
> I get it now.  In practice, with maven sites, is this a big deal?  I
> don't remember seeing lots of cruft accumulating on p.a.o, which
> would happen if this were common.  If it is not that common, then
> manual svn rm's would not be that onerous.
> 
> Phil
>>> 
>>> For some projects, it would be possible to just delete the existing
>>> sub-tree and check the whole new site in.
>>> [This can be done as one transaction in svnmucc]
>>> 
>>> However, for sites that retain Javadoc etc. for older releases, one
>>> would need to re-instate that part of the tree somehow.
>>> 
>>> Given that svnpubsub immediately publishes what is checked in, it
>>> might be sensible to have a parallel staging directory tree where
>>> files can be updated piecemeal if necessary, and then use svnmucc to
>>> replace the live component subtree with the staging component subtree
>>> as part of a single transaction.
>>> 
>>> There would need to be some co-ordination between committers when
>>> updating commons parent, as that would affect the whole tree.
>>> 
>> Yes. This is why Logging used the extpath approach where each subproject 
>> commits directly to production. Each release goes to a release subdirectory 
>> under each subproject's directory.  Then you can just perform your maven 
>> site build to a local directory, copy that into the production svn location, 
>> and commit it.
>> 
>> See "Managing the subproject sites" at 
>> http://wiki.apache.org/logging/ManagingTheWebSite
>> 
>> Ralph
> 
> 
> -
> 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: We will not be able to update our websites...

[Ralph Goers]

ke a nice starting point. I.e. we should have the top-level
>>>>>> web
>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>> button would point to the corresponding legacy site (until the
>>>> components'
>>>>>> sites themselves are ready).
>>>>>> 
>>>>>> 
>>>>>> Gilles
>>>>>> 
>>>>>>> 
>>>>>>> Matt
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>> gil...@harfang.homelinux.org> wrote:
>>>>>>> 
>>>>>>>> Hi.
>>>>>>>> 
>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>> using a
>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>> exposed to
>>>>>>>>> commons.a.o until we're satisfied with it.  Do we want to use the
>>>>>> CMS a
>>>>>>>> la
>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>> Maven-generated?  The Maven guys, particularly Olivier Lamy (do
>>>> you
>>>>>>>> follow
>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>> Actually
>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>> guess
>>>>>> we
>>>>>>>> can
>>>>>>>>> just request the CMS site and go from there.  Issue created.  [2]
>>>>>>>> 
>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Gilles
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Matt
>>>>>>>>> 
>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>> 
>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>> ralph.go...@dslextreme.com
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>> commons-test
>>>>>>>>>> site.
>>>>>>>>>> 
>>>>>>>>>> Ralph
>>>>>>>>>> 
>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>> 
>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>> phil.ste...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>> able to
>>>>>>>>>> properly build a sub-project's site with Maven.  This is because
>>>>>> the
>>>>>>>>>> process of updating the site would require first doing a diff
>>>> and
>>>>>> then
>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>> created a
>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>> want
>>>>>> to
>>>>>>>> go at
>>>>>>>>>> all.
>>>>>>>>>>>>>> Sorry, I don't get it.  Why won't the following work:
>&

Re: We will not be able to update our websites...

[Ralph Goers]

And now I'm even more confused since I just saw your commits to build the CMS 
site using Maven.

Ralph

On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:

> So now I'm confused.  You are proposing to bypass the CMS altogether and only 
> publish to the live site.  Why?  Even projects like Flume that use maven for 
> the site build still do it in the CMS.
> 
> Ralph
> 
> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
> 
>> 2012/12/15 Olivier Lamy :
>>> 2012/12/15 Matt Benson :
>>>> Olivier,
>>>> Thanks for your response and offer to contribute!  We do have a few
>>>> multi-module components here.  Of "proper" components, there is only [jci]
>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>> intended to take [functor] multimodule before a release is made.  I'm
>>>> perusing your wiki link now.
>>>> 
>>> 
>>> Maybe you can update the jira entry to say you want a solution "à la" maven 
>>> ?
>>> and website content from
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>> 
>>> I will update commons-site now to get it working for cms.
>>> 
>> 
>> Done.
>> 
>>> For deploying I can try make configuration easy if you accept to use
>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>> ).
>>> 
>>> Note that will need a release of your parent pom.
>>> 
>>>> Matt
>>>> 
>>>> 
>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy  wrote:
>>>> 
>>>>> /me listening here
>>>>> 
>>>>> Note maven.apache.org has been migrated this week.
>>>>> 
>>>>> If you want to mix cms and maven site generation, we do that.
>>>>> Note: even the main site is generated with a maven build but we can
>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>> 
>>>>> The source tree need some modifications: see
>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>> 
>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>> do a bit of pom.xml stuff :-) )
>>>>> 
>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>> which is dedicated to this purpose.
>>>>> 
>>>>> As I can see you are using this module
>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>> for main site ?
>>>>> If you want I can do the necessary changes to make it working with
>>>>> both cms and mvn site.
>>>>> 
>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>> this case mvn site-deploy works)
>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>> projects here ?
>>>>> 
>>>>> --
>>>>> Olivier
>>>>> 
>>>>> 2012/12/14 Matt Benson :
>>>>>> I never questioned that the individual components would most likely
>>>>>> continue with the Maven-generated content.  I do question whether we want
>>>>>> to bother laying out the main site when we have something that works.
>>>>>> 
>>>>>> br,
>>>>>> Matt
>>>>>> 
>>>>>> 
>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>> gil...@harfang.homelinux.org> wrote:
>>>>>> 
>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>> someplace at which to point it.  I think the next step is to determine
>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>> quite
>>>>>>>> popular among ASF TLPs.  If we like to keep a Maven-generated look,
&

Re: [vfs] How can find the maven repository of commons-vfs , and how can develope the filesystem protocol for myself?

[Ralph Goers]

On Dec 17, 2012, at 6:08 PM, yeyz wrote:

> Hi, everyone.
> 
> I delivered one post about vfs without detail title, getting no
> reply. So I want to ask the same question again. Thks!
> 
> I am a new comer to apache vfs. But when I import the vfs project
> to eclipse through maven, there are five errors listed in the [problems]
> list. 
> 
> And one is :
> 
> Description  Resource Path Location   Type
> 
> Project build error: Non-resolvable parent POM for
> org.apache.commons:commons-vfs2-project:2.1-SNAPSHOT: Failure to transfer
> org.apache.commons:commons-parent:pom:27 from http://repo1.maven.org/maven2
> was cached in the local repository, resolution will not be reattempted until
> the update interval of central has elapsed or updates are forced. Original
> error: Could not transfer artifact org.apache.commons:commons-parent:pom:27
> from/to central (http://repo1.maven.org/maven2): Connect times out and
> 'parent.relativePath' points at wrong local POM pom.xml /Commons
> VFS Coreline 1 Maven pom Loading Problem

This error seems to indicate you are having connectivity issues getting to the 
Maven central repository. I'm not sure how we can help with that.



> 
> 
> 
> And when I want to use vfs in another Java project use :
> 
> 
> 
>commons-vfs
> 
>Apache Commons VFS Repository Group
> 
>https://repository.apache.org/content/groups/snapshots/
>  
> 
>default
> 
>
> 
>true
> 
>
> 
>
> 
> 
> 
>
> 
>   org.apache.commons
> 
>   commons-vfs2
> 
>   2.0
> 
>   
> 
> 
> 
>Or 
> 
>
> 
>org.apache.commons
> 
>commons-vfs2
> 
>2.1-SNAPSHOT
> 
>
> 
> 
> 
> The jar cannot be downloaded correct. 

Why? What error are you getting. Again, the 2.0 version should be downloadable 
from the Maven central repository.  The 2.1 snapshot may not have ever been 
deployed to a Nexus repository.  In that case you should just run mvn install 
from the command line to build it.  However, if Maven can't connect to the 
central repository not much is going to work.  Perhaps you have a local proxy 
for Maven Central?

Ralph


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

Re: We will not be able to update our websites...

[Ralph Goers]

I still don't understand why you are committing the subprojects to svn.  That 
is not required.  Just use stage-deploy to deploy to a local directory on your 
computer, then copy that under where you have the production web site checked 
out and check it in.  See http://wiki.apache.org/logging/ManagingTheWebSite


Ralph

On Dec 18, 2012, at 3:20 AM, Olivier Lamy wrote:

> 2012/12/18 Olivier Lamy :
>> 2012/12/18 Phil Steitz :
>>> On 12/17/12 5:55 AM, Olivier Lamy wrote:
>>>> ETA of the migration:
>>>> collections and lang done.
>>>> 
>>>> results:
>>>> * http://people.apache.org/~olamy/commons/lang/
>>>> * http://people.apache.org/~olamy/commons/collections/
>>>> 
>>>> As Gary suggested old javadocs are
>>>> http://people.apache.org/~olamy/commons/lang/javadocs
>>>> 
>>>> NOTE I didn't import all previous versions. Does it make sense ?
>>> 
>>> Makes sense to me.  Older javadocs can be retrieved from the archives.
>>> 
>>> THANKS for jumping on this, Olivier!
>>> 
>>> Other than helping getting site builds working where they may be
>>> broken, what can the rest of us do to help?
>> Help me a bit on other components :-).
>> There are a lot to do (end of proper then sandbox then dormant.
>> What I can do is to import content manually for sandbox and dormant if
>> folks want to redeploy website due to code/documentation change they
>> will need to fix the pom (at least that will work for the migration)
>> Changes are easy to apply.
>> 
>> What about releasing the parent ? (I don't know what is the procedure
>> for that here).
>> 
>> Something else is the size of sites due to a lot of reporting
>> (cobertura, findbug, pmd, etc..) and that make svn commit very long.
>> What about using sonar ? We have an instance for asf projects
>> (https://analysis.apache.org). I can at least setup this for proper
>> projects.
>> 
>> WDYT ?
> 
> I have added 4 for testing (collections, cli, lang and ognl).
> See result: 
> https://analysis.apache.org/dashboard/index/org.apache.commons:commons-proper-aggregator
> 
> I missed to explain how to configure svnpubsub for site publication.
> 
> Use last parent pom 28-SNAPSHOT
> 
> add a property to define site path:
> ognl
> (http://commons.apache.org/ognl)
> That will commit site content to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ognl/
> 
> Then test it :-)
> mvn clean site site:stage scm-publish:publish-scm
> To pass your svn authz:
> -Dusername=asf id
> -Dpassword=asf password
> 
> Once is done add the new path to
> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/content/resources/extpaths.txt
> 
> 
> 
> 
>> 
>> 
>>> 
>>> Phil
>>>> 
>>>> digester I have issues while building trunk
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
>>>> (default-testCompile) on project commons-digester3-ap: Compilation
>>>> failure: Compilation failure:
>>>> [ERROR] error: Impossible to generate class
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>>> Attempt to recreate a file for type
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>>> [ERROR] error: Impossible to generate class
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>>> Attempt to recreate a file for type
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>>> [ERROR] -> [Help 1]
>>>> [ERROR]
>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>>> the -e switch.
>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>> 
>>>> So I stop for it as no idea on WTF here
>>>> 
>>>> 2012/12/15 Olivier Lamy :
>>>>> 2012/12/15 Olivier Lamy :
>>>>>> 2012/12/15 Ralph Goers :
>>>>>>> And now I'm even more confused since I just saw your commits to build 
>>>>>>> the CMS site using Maven.
>>>>>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>>>>>> I will try to work on sub projects today (it's only a matter of
>>>>>> configuring parent pom normally)
>>>>>> And test with deploying to
>>>>

Re: We will not be able to update our websites...

[Ralph Goers]

On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:

> 2012/12/18 Ralph Goers :
>> I still don't understand why you are committing the subprojects to svn.  
>> That is not required.  Just use stage-deploy to deploy to a local directory 
>> on your computer, then copy that under where you have the production web 
>> site checked out and check it in.  See 
>> http://wiki.apache.org/logging/ManagingTheWebSite
>> 
> As I can see in section "Managing Sub-project Sites" this doc says
> "Make sure all that is added to svn and commit it."
> So subsites must be checked in (here I configure this to be done tru a
> maven plugin and not manually)
> Infra will be able to use as production web site:
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
> https://svn.apache.org/repos/infra/websites/production/commons/content/
> but this one still doesn't exist, I will ping infra on the jira entry
> for their preference).

Step 6 is referring to checking it in directly to 
https://svn.apache.org/repos/infra/websites/production/logging/content/ in the 
subdirectory that is listed in extpaths.txt, not some other subversion 
location.  If you look under log4j, for example, you will see a directory for 
each release and a directory that is a symlink to the current release (for 
Log4j 2 the 2.x directory links to log4j-2.0-beta3.

> 
> So if you want sub-project sites available AFAIK this (check in all
> content) must be done (or I misunderstand something: -)).
> 
> Makes sense ?

Not really.

Ralph

Re: We will not be able to update our websites...

[Ralph Goers]

extpaths.txt operates by saying that everything under the subdirectories named 
in it is excluded from the CMS and must be manually managed.  So what Logging 
does is have the main site be managed in the CMS.  The links in the parent 
project point to generic project directories that are symlinks.  For example, 
the parent might reference "proper/VFS/2.x " to get to the VFS web site.  Then, 
we could have content/proper be listed in extpaths.txt.  Then whenever a new 
VFS release is done it is uploaded to a directory named 
content/proper/VFS/vfs-2.n.  The 2.x link is then modified to point to the 
newly uploaded content.  Thus you never have to modify the parent (or the CMS) 
to update a subproject, nor do you need to commit it to any other location in 
subversion except for the production site which, of course, is managed by 
subversion.

Ralph


On Dec 18, 2012, at 10:56 AM, Matt Benson wrote:

> Let me see if I understand.  Are you saying, Ralph, that when we have
> generated content to expose on the website, we should commit it directly to
> the production website svn and mark it in extpaths.txt back in our tree in
> mainrepo, basically because that avoids the duplication that is created by
> storing the generated content directly in mainrepo when it would only be
> copied out anyway?  Do I finally grasp the intent of expaths.txt?
> 
> Matt
> 
> 
> On Tue, Dec 18, 2012 at 12:51 PM, Ralph Goers 
> wrote:
> 
>> 
>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>> 
>>> 2012/12/18 Ralph Goers :
>>>> I still don't understand why you are committing the subprojects to svn.
>> That is not required.  Just use stage-deploy to deploy to a local
>> directory on your computer, then copy that under where you have the
>> production web site checked out and check it in.  See
>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>> 
>>> As I can see in section "Managing Sub-project Sites" this doc says
>>> "Make sure all that is added to svn and commit it."
>>> So subsites must be checked in (here I configure this to be done tru a
>>> maven plugin and not manually)
>>> Infra will be able to use as production web site:
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>> but this one still doesn't exist, I will ping infra on the jira entry
>>> for their preference).
>> 
>> Step 6 is referring to checking it in directly to
>> https://svn.apache.org/repos/infra/websites/production/logging/content/in 
>> the subdirectory that is listed in extpaths.txt, not some other
>> subversion location.  If you look under log4j, for example, you will see a
>> directory for each release and a directory that is a symlink to the current
>> release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>> 
>>> 
>>> So if you want sub-project sites available AFAIK this (check in all
>>> content) must be done (or I misunderstand something: -)).
>>> 
>>> Makes sense ?
>> 
>> Not really.
>> 
>> Ralph
>> 
>> 
>> 


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

Re: We will not be able to update our websites...

[Ralph Goers]

On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:

> 2012/12/18 Ralph Goers :
>> 
>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>> 
>>> 2012/12/18 Ralph Goers :
>>>> I still don't understand why you are committing the subprojects to svn.  
>>>> That is not required.  Just use stage-deploy to deploy to a local 
>>>> directory on your computer, then copy that under where you have the 
>>>> production web site checked out and check it in.  See 
>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>> 
>>> As I can see in section "Managing Sub-project Sites" this doc says
>>> "Make sure all that is added to svn and commit it."
>>> So subsites must be checked in (here I configure this to be done tru a
>>> maven plugin and not manually)
>>> Infra will be able to use as production web site:
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>> but this one still doesn't exist, I will ping infra on the jira entry
>>> for their preference).
>> 
>> Step 6 is referring to checking it in directly to 
>> https://svn.apache.org/repos/infra/websites/production/logging/content/ in 
>> the subdirectory that is listed in extpaths.txt, not some other subversion 
>> location.  If you look under log4j, for example, you will see a directory 
>> for each release and a directory that is a symlink to the current release 
>> (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>> 
>>> 
>>> So if you want sub-project sites available AFAIK this (check in all
>>> content) must be done (or I misunderstand something: -)).
>>> 
>>> Makes sense ?
>> 
>> Not really.
> So maybe I misunderstood what you want to do.
> 
> What I understood:
> 1) main site is build from
> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
> (and marked as cms content so possible to modify files via the cms ui)
> technically a buildbot job run the maven build and commit the
> generated site to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
> will serve as infra for web site content staging then live) (note I
> did the change for infra requirement on sources structure)
> 2) due to #1 sub project content (take lang) must be committed to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang

This step is not necessary.  sub-project content can be committed directly to 
https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n
 or 
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n
 depending on what is in extpaths.txt

> 3) as lang is not generated by cms it must be added to extpaths file.

This is true, unless it resides under a directory that was declared in 
extpaths.txt, (for example, "proper" as in the second url above.

> 4) committing sub project content will be done using the maven
> scm-publish plugin (that's what I started to do)

I don't do this.  I do mvn site:stage-deploy 
-DstaginngSiteURL=file:///Users/rgoers/log4j  for my Log4j 2 web site. I zip it 
and publish it at p.a.o/~rgoers/log4j2 for review during a release and then I 
do a "cp -r ~/log4j/*" to where I want it to go under where I have the 
production web site checked out on my machine. After it is copied I remove the 
link from the old release and create a link to the new release and then do an 
svn commit.

> 
> Regarding your point on versionned  subsites, I don't such structure
> here (no commons.a.o/lang-2.x)

Correct. We are doing this in logging because it makes it easy to deploy a new 
release of the web site.

> 
> So let me know what is your plan ?
> I proposed to help but it looks I don't know exactly what is the plan
> so that will be a bit complicated for me.

The plan would be to follow what is published in the logging wiki link.  I'm 
not sure why you think it is complicated. It should be simpler than what you 
are doing.

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

Re: We will not be able to update our websites...

[Ralph Goers]

On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:

> 2012/12/18 Ralph Goers :
>> 
>> On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:
>> 
>>> 2012/12/18 Ralph Goers :
>>>> 
>>>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>>> 
>>>>> 2012/12/18 Ralph Goers :
>>>>>> I still don't understand why you are committing the subprojects to svn.  
>>>>>> That is not required.  Just use stage-deploy to deploy to a local 
>>>>>> directory on your computer, then copy that under where you have the 
>>>>>> production web site checked out and check it in.  See 
>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>> 
>>>>> As I can see in section "Managing Sub-project Sites" this doc says
>>>>> "Make sure all that is added to svn and commit it."
>>>>> So subsites must be checked in (here I configure this to be done tru a
>>>>> maven plugin and not manually)
>>>>> Infra will be able to use as production web site:
>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>> but this one still doesn't exist, I will ping infra on the jira entry
>>>>> for their preference).
>>>> 
>>>> Step 6 is referring to checking it in directly to 
>>>> https://svn.apache.org/repos/infra/websites/production/logging/content/ in 
>>>> the subdirectory that is listed in extpaths.txt, not some other subversion 
>>>> location.  If you look under log4j, for example, you will see a directory 
>>>> for each release and a directory that is a symlink to the current release 
>>>> (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>>> 
>>>>> 
>>>>> So if you want sub-project sites available AFAIK this (check in all
>>>>> content) must be done (or I misunderstand something: -)).
>>>>> 
>>>>> Makes sense ?
>>>> 
>>>> Not really.
>>> So maybe I misunderstood what you want to do.
>>> 
>>> What I understood:
>>> 1) main site is build from
>>> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>> (and marked as cms content so possible to modify files via the cms ui)
>>> technically a buildbot job run the maven build and commit the
>>> generated site to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
>>> will serve as infra for web site content staging then live) (note I
>>> did the change for infra requirement on sources structure)
>>> 2) due to #1 sub project content (take lang) must be committed to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
>> 
>> This step is not necessary.  sub-project content can be committed directly 
>> to 
>> https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n
>>  or 
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n
>>  depending on what is in extpaths.txt
>> 
> 
> Ok I see now (as I said in a previous mail) I believed you wanted to
> use  http://svn.apache.org/repos/asf/commons/cms-site/trunk/ rather
> than https://svn.apache.org/repos/infra/websites/production/commons/content

I'm not sure what http://svn.apache.org/repos/asf/commons/cms-site/trunk is.  
It doesn't seem to be the actual CMS site.  That seems to be at 
http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/. Personally, 
I prefer commons/cms-site/trunk as the actually location for the CMS content 
instead of proper/commons-site/trunk. But only one of the two is needed and it 
would be where the CMS content resides.

As I understand it we don't have a choice, we have to use 
https://svn.apache.org/repos/infra/websites/production/commons/content for the 
production site.

Ralph

Re: We will not be able to update our websites...

[Ralph Goers]

On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:

>> 
> Maybe could be simpler with committing your staged versionned site to
> log4j2-xxx (tru the maven plugin) for review and then modifying
> .htaccess file (too prevent huge checkout on your machine and to
> modify a symlink this probably won't work for windauze folks).
> With this, just to do: deploy the site tru scm-pub plugin then when
> vote passed only modify the .htaccess file
> (that's just an idea)

If you follow the instructions on the wiki the checkout doesn't have to be 
huge.  You will get the main part of the web site and then you can get the 
subproject parts you want individually.

I noticed that when you check out the site on Windows you get a file that 
represents the symlink. Of course, it doesn't do anything useful on windows as 
it would on a unix-based system, but I would expect you could hand modify it to 
update the link.

What does the scm-plugin do to deploy the site that makes it easier than doing 
a cp and svn commit?

Ralph


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

Re: We will not be able to update our websites...

[Ralph Goers]

On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:

> 2012/12/18 Ralph Goers :
>> 
>> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>> 
>>>> 
>>> Maybe could be simpler with committing your staged versionned site to
>>> log4j2-xxx (tru the maven plugin) for review and then modifying
>>> .htaccess file (too prevent huge checkout on your machine and to
>>> modify a symlink this probably won't work for windauze folks).
>>> With this, just to do: deploy the site tru scm-pub plugin then when
>>> vote passed only modify the .htaccess file
>>> (that's just an idea)
>> 
>> If you follow the instructions on the wiki the checkout doesn't have to be 
>> huge.  You will get the main part of the web site and then you can get the 
>> subproject parts you want individually.
>> 
>> I noticed that when you check out the site on Windows you get a file that 
>> represents the symlink. Of course, it doesn't do anything useful on windows 
>> as it would on a unix-based system, but I would expect you could hand modify 
>> it to update the link.
>> 
>> What does the scm-plugin do to deploy the site that makes it easier than 
>> doing a cp and svn commit?
> Part of the build so no manual steps (add, commit etc...)
> And do some cleanup: If content generated doesn't produce anymore
> file(s) which were in svn path they will be "svn rm".

Is this the plugin that has to checkout a copy and do a diff so that it can 
then figure out what to remove?  If so, then it is going to take longer than 
the process I outlined as each commit to the production goes to a new location 
in svn.

Ralph


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

Re: [VFS] WAS: [GUMP@vmgump]: Project commons-vfs2-test (in module apache-commons) failed

[Ralph Goers]

Can you have the test check for a supported environment and exit if it is not?

Ralph

On Jan 10, 2013, at 6:23 AM, Gary Gregory wrote:

> The new HDFS provider only works on Linux and it works for me on Ubuntu
> (via VirtualBox on Win7). How can Gump be fixed?
> 
> Gary
> 
> 
> On Thu, Jan 10, 2013 at 2:53 AM, Gump  wrote:
> 
>> To whom it may engage...
>> 
>> This is an automated request, but not an unsolicited one. For
>> more information please visit http://gump.apache.org/nagged.html,
>> and/or contact the folk at gene...@gump.apache.org.
>> 
>> Project commons-vfs2-test has an issue affecting its community integration.
>> This issue affects 1 projects.
>> The current state of this project is 'Failed', with reason 'Build Failed'.
>> For reference only, the following projects are affected by this:
>>- commons-vfs2-test :  Apache Commons
>> 
>> 
>> Full details are available at:
>> 
>> http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/index.html
>> 
>> That said, some information snippets are provided here.
>> 
>> The following annotations (debug/informational/warning/error messages)
>> were provided:
>> -WARNING- Overriding Maven settings:
>> [/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml]
>> -DEBUG- (Apache Gump generated) Apache Maven Settings in:
>> /srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
>> -INFO- Failed with reason build failed
>> -DEBUG- Maven POM in:
>> /srv/gump/public/workspace/apache-commons/vfs/pom.xml
>> -INFO- Project Reports in:
>> /srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports
>> 
>> 
>> 
>> The following work was performed:
>> 
>> http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_work/build_apache-commons_commons-vfs2-test.html
>> Work Name: build_apache-commons_commons-vfs2-test (Type: Build)
>> Work ended in a state of : Failed
>> Elapsed: 4 mins 59 secs
>> Command Line: /opt/maven3/bin/mvn --batch-mode --settings
>> /srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package
>> [Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
>> M2_HOME: /opt/maven3
>> -
>>at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>at java.lang.reflect.Method.invoke(Method.java:601)
>>at
>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>>at
>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>>at
>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>>at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
>> 
>> Running
>> org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288 sec
>> Running
>> org.apache.commons.vfs2.provider.temp.test.TemporaryProviderTestCase
>> Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.81 sec
>> Running org.apache.commons.vfs2.FileExtensionSelectorTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
>> 
>> Results :
>> 
>> Tests in error:
>>  
>> junit.framework.TestSuite@2a018b03(org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$HdfsProviderTestSuite):
>> /srv/gump/public/workspace/apache-commons/vfs/core/target/test-classes/test-data/write-tests/file1.txt
>> (Permission denied)
>> 
>> Tests run: 1697, Failures: 0, Errors: 1, Skipped: 2
>> 
>> [INFO]
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Commons VFS ... SUCCESS [9.950s]
>> [INFO] Commons VFS Core .. FAILURE
>> [4:45.160s]
>> [INFO] Commons VFS Examples .. SKIPPED
>> [INFO] Commons VFS Distribution .. SKIPPED
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 4:56.621s
>> [INFO] Finished at: Thu Jan 10 07:53:15 UTC 2013
>> [INFO] Final Memory: 28M/68M
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.12.3:test (default-test)
>> on project commons-vfs2: There are test failures.
>> [ERROR]
>> [ERROR] Please refer to
>> /srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports
>> for the individual test results.
>> [ERROR] -> [Help 1]
>> [ER

Re: [configuration] Design discussion

[Ralph Goers]

Sure - But as I've worked with CombinedConfiguration I became less enthralled 
with it.  The problem I had with the DynamicCombinedConfiguration was that 
every CombinedConfiguration has to have its own copy of all the configurations. 
Attempting to share a configuration led to all kinds of corruption when the 
file was updated and the tree was modified.  I really wanted to do the same 
thing with CompositeConfiguration but since it didn't officially support XML 
and doesn't have a builder I didn't get around to it.

Ultimately, I would prefer that there only be one ConfigurationBuilder and that 
its end result be a Configuration, not a CombinedConfiguration.  Underneath 
that there could, of course, be various flavors of builders but ideally the 
user wouldn't need to be bothered with them.

Ralph


On Jan 28, 2013, at 1:10 PM, Oliver Heger wrote:

> (From time to time I am going to post an update about the progress I have 
> made so that everybody who is interested can comment.)
> 
> Just finished reworking MultiFileConfiguration to use the new builder 
> approach. There is now a MultiFileConfigurationBuilder class offering pretty 
> much the same functionality plus that it can deal with arbitrary file-based 
> configurations.
> 
> The class now also works well together with CombinedConfigurationBuilder in 
> the same way the old integration was with DefaultConfigurationBuilder, i.e. a 
> DynamicCombinedConfiguration is used to ensure that a new 
> CombinedConfiguration is constructed every time the file pattern changes.
> 
> @Ralph: Maybe, as the original author, you find the time to have a short look 
> to verify that no features were lost?
> 
> CombinedConfigurationBuilder should now provide the same functionality as 
> DefaultConfigurationBuilder. With slight exceptions it can process the same 
> configuration definition files. So I plan to remove 
> DefaultConfigurationBuilder shortly.
> 
> Oliver
> 
> Am 05.01.2013 16:48, schrieb Oliver Heger:
>> Hi Jörg,
>> 
>> Am 04.01.2013 17:47, schrieb Jörg Schaible:
>>> Hi Oliver,
>>> 
>>> Oliver Heger wrote:
>>> 
 Hi,
 
 recently I have worked on code regarding the creation of Configuration
 objects and reloading support. I have created two Jira tickets [1, 2]
 with a description of the problems I see in the current design.
 
 The code in SVN (mainly in the new builder package) should be sufficient
 to get a good impression about the direction I would like to go. It is
 far more than a pure proof of concept.
 
 However, following this road means some significant changes in the
 design and in the way client code uses our classes. Therefore, I would
 really appreciate feedback from other committers also interested in this
 component.
 
 My main question is: Can we replace the reloading mechanisms available
 in 1.x by an approach based on builders as currently implemented in
 trunk (e.g. classes
 o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
 o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
 go forward and significantly simplify most of the file-based
 configuration implementations.
 
 Thanks
 Oliver
 
 [1] https://issues.apache.org/jira/browse/CONFIGURATION-519
 [2] https://issues.apache.org/jira/browse/CONFIGURATION-520
>>> 
>>> simply go-on with these changes. IMHO it looks good and since
>>> separation of
>>> concern leads here to significant code simplification, it's for the
>>> best of
>>> us devs and also for our users in the long term. Especially since the new
>>> approach brings also improved functionality.
>> 
>> Thanks for your feedback. Will do!
>> 
>> Oliver
>> 
>>> 
>>> Cheers,
>>> Jörg
>>> 
>>> 
>>> -
>>> 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: CMS/SvnPubSub for site live ?

[Ralph Goers]

I can't see the source for the site.  I am assuming that the "proper" 
subdirectory is in extpaths.txt?  The only thing I don't like is that when 
looking at proper it appears that each subproject has its own directory.  I 
would prefer (and recommend) that instead of being a single directory for each 
project that these be symlinks to the actual project directory.  For example, 
proper/commons-attributes could be a symlink to proper/commons-attributes-2.2.  
This makes it much easier to publish a new version of the site.

Ralph


On Jan 30, 2013, at 9:16 AM, Olivier Lamy wrote:

> Hi Folks,
> Ok to go live ?
> 
> Something missing ? (maybe sandbox parent release ?)
> 
> What else ?
> 
> Content is available for review here:
> http://people.apache.org/~olamy/commons-content/
> 
> 
> Thanks,
> --
> Olivier
> http://twitter.com/olamy | http://linkedin.com/in/olamy
> 
> -
> 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: CMS/SvnPubSub for site live ?

[Ralph Goers]

On Jan 30, 2013, at 12:16 PM, Olivier Lamy wrote:

> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
> Agree for mapping proper/commons-attributes -> proper/commons-attributes-2.2
> Why not with modifying .htaccess ?
> (http://svn.apache.org/repos/asf/commons/cms-site/trunk/content/resources/.htaccess)
> 
> RedirectMatch ^(.*)/attributes/(.*) $1/proper/commons-attributes-2.2/$2

If it works that is fine too.  I know when we were doing the logging site 
Christian had problems getting that to work properly.

> 
> symlink means:
> * probably won't work for windauze folks.

It does. On Windows svn creates a file that you can edit.

> * you will need to checkout locally all the content from
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/
> (which will be really bigger if versioned site documentation) whereas
> it's not needed as the scm pub plugin help you to not have to do that.

See the instructions on publishing the logging site. You can checkout and 
ignore most of the subdirectories you don't want.

> 
> In case of versioned documentation a new parent release will be needed
> because parent has the subpub url defined with
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}
> But each component can override that with
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/${project.artifactId}-${project.version}

I guess you are assuming the site is actually published to production via 
Maven.  I never do that so there is no need to release the parent.  I run mvn 
site:stage-deploy to a local directory and then just copy that into the correct 
svn directory (i.e. something like commons-attributes-2.2) and then do an svn 
commit.  With a symlink you don't have to update the CMS site either. With 
.htaccess I guess you would.

Ralph



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

Re: [vfs] New feature request: configurable socket timeout for HTTP and WebDAV in VFS

[Ralph Goers]

Yup.  I have no idea why I said that.  While you can certainly pass the options 
HttpClientFactory wouldn't do anything with them.

Ralph

On Feb 6, 2013, at 2:09 AM, Jean-Marc Borer wrote:

> I found this entry in JIRA:
> 
> https://issues.apache.org/jira/browse/VFS-249
> 
> Actually it is not true that it is fixed. Looking at the code Ralph
> Goers's explanation are not correct. It should be reopened.
> 
> I will create a new entry.
> 
> 
> On Wed, Feb 6, 2013 at 9:51 AM, Jean-Marc Borer  wrote:
>> OK. You seem to like the feature.
>> 
>> Can I provide the patch for integration then? To whom should I send it?
>> 
>> On Tue, Feb 5, 2013 at 10:06 PM, Mark Fortner  wrote:
>>> Perhaps not for local file systems, but I would imagine that any kind of
>>> distributed file system would have need of a socket timeout.
>>> 
>>> Cheers,
>>> 
>>> Mark
>>> 
>>> 
>>> 
>>> On Tue, Feb 5, 2013 at 1:59 PM, Gary Gregory  wrote:
>>> 
 On Tue, Feb 5, 2013 at 4:54 PM, Mark Fortner  wrote:
 
> Just out of curiousity, is there a reason that socket timeouts shouldn't
> also apply to all file systems in general?
> 
 
 How does a socket timeout make sense for a local file system, ZIP, and so
 on?
 
 Gary
 
 
> 
> Cheers,
> 
> Mark
> 
> 
> 
> On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory 
> wrote:
> 
>> Sure, make sure you base you patch on the latest from trunk.
>> 
>> Gary
>> 
>> 
>> On Tue, Feb 5, 2013 at 11:50 AM, Jean-Marc Borer 
>> wrote:
>> 
>>> Hello list members,
>>> 
>>> We need to be able to specify socket timeouts in VFS for HTTP and
>>> WebDAV in our project so that request will no hang for ever in
 certain
>>> conditions.
>>> 
>>> I have modified the sources of HttpFileSystemConfigBuilder and
>>> HttpClientFactory to be able to configure this in HttpClient.
>>> 
>>> Do you want me to propose a patch for that?
>>> 
>>> Cheers,
>>> 
>>> Jean-marc
>>> 
>>> -
>>> 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
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>> 
> 
 
 
 
 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
 Spring Batch in Action: http://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory
 
> 
> -
> 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] New repo for all proper components as submodules?

[Ralph Goers]

> On Aug 31, 2020, at 7:01 AM, Gary Gregory  wrote:
> 
> My target use case here is: I want an easy way to work on all of Commons in
> a new VM or a new machine, so I'd like to be able to check out all of
> Commons in one go from any level for example here is an imaginary git
> submodule tree:
> - Apache Commons, a git repo with submodules:
> - -  Apache Commons Proper, a git repo with submodules:
> - - - Apache Commons Lang
> - - - etc
> - -  Apache Commons Sandbox, a git repo with submodules:
> - - - etc
> 
> Right now I am checking out each and every repo one at a time. Yes, we
> could stash OS-specific scripts some place.
> 
> I was hoping to start at the Apache Commons Proper level. If I need a
> script to update each submodule to the latest HEAD, then this is less
> elegant but understandable from a git POV.
> 
> Maybe there is a git shorthand for this…
> 

I do this at work but we use BitBucket. It has the concept of projects and 
repos live under projects. So I wrote scripts that use the REST API to 
determine all the repos under and project and then use the git command to clone 
them all. Once you have them under a single directory it is easy to write a 
script to do git pull on all of them to keep them updated. IntelliJ also 
supports loading them all into a single window.

I believe Git supports labels or something. I know that the ASF knows that each 
repo belongs to a specific project so I would be surprised if you couldn’t 
accomplish something similar to what I have done using that information.

Ralph

Re: [All] New repo for all proper components as submodules?

[Ralph Goers]

> On Aug 31, 2020, at 8:24 AM, Ralph Goers  wrote:
> 
> 
> 
>> On Aug 31, 2020, at 7:01 AM, Gary Gregory  wrote:
>> 
>> My target use case here is: I want an easy way to work on all of Commons in
>> a new VM or a new machine, so I'd like to be able to check out all of
>> Commons in one go from any level for example here is an imaginary git
>> submodule tree:
>> - Apache Commons, a git repo with submodules:
>> - -  Apache Commons Proper, a git repo with submodules:
>> - - - Apache Commons Lang
>> - - - etc
>> - -  Apache Commons Sandbox, a git repo with submodules:
>> - - - etc
>> 
>> Right now I am checking out each and every repo one at a time. Yes, we
>> could stash OS-specific scripts some place.
>> 
>> I was hoping to start at the Apache Commons Proper level. If I need a
>> script to update each submodule to the latest HEAD, then this is less
>> elegant but understandable from a git POV.
>> 
>> Maybe there is a git shorthand for this…
>> 
> 
> I do this at work but we use BitBucket. It has the concept of projects and 
> repos live under projects. So I wrote scripts that use the REST API to 
> determine all the repos under and project and then use the git command to 
> clone them all. Once you have them under a single directory it is easy to 
> write a script to do git pull on all of them to keep them updated. IntelliJ 
> also supports loading them all into a single window.
> 
> I believe Git supports labels or something. I know that the ASF knows that 
> each repo belongs to a specific project so I would be surprised if you 
> couldn’t accomplish something similar to what I have done using that 
> information.

The .asf.yaml file that can be placed in every repo allows you to specify 
repository metadata. See 
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata
 
<https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-Repositorymetadata>

Ralph

Re: [All] New repo for all proper components as submodules?

[Ralph Goers]

As I said previously, I would avoid using either one.  I really don’t know why 
you would want to with Java. I can understand it with applications written in C 
where you might want to compile all the dependencies along with the main 
application. But that isn’t the case in Java. Introducing subtrees or modules 
just adds complexity you don’t need.

Ralph

> On Sep 1, 2020, at 6:06 AM, Gary Gregory  wrote:
> 
> I found the following helpful but it is from 2016,  so I wonder how much
> has changed since then:
> 
> https://martowen.com/2016/05/01/git-submodules-vs-git-subtrees/
> 
> Gary
> 
> On Mon, Aug 31, 2020, 10:34 Matt Sicker  wrote:
> 
>> The use case you're describing is fairly well handled by the git
>> subtree command. There are some git plugins that add more complex
>> workflows on top of that, but the base command is what you're looking
>> for. Git submodules, in my experience, are far more useful when
>> pointing to release commits and treating submodule updates like
>> dependency updates. If you want the equivalent of how Subversion lets
>> you link to another repo as a directory, that would be git-subtree,
>> not git-submodule.
>> 
>> On Mon, 31 Aug 2020 at 09:16, Gary Gregory  wrote:
>>> 
>>> On Mon, Aug 31, 2020 at 10:15 AM Gary Gregory 
>>> wrote:
>>> 
 On Sun, Aug 30, 2020 at 9:24 AM Gary Gregory 
 wrote:
 
> I'm talking about girl's own submodules:
> 
> https://git-scm.com/book/en/v2/Git-Tools-Submodules
> 
 
 I think the on-line book above has been updated since 2014 (as seen on
>> the
 front page https://git-scm.com/book/en/v2) so the reference page
 https://git-scm.com/docs/git-submodule should be more accurate.
 
>>> ARG: "I think the on-line book above has been updated" ->  "I think the
>>> on-line book above has *NOT *been updated"
>>> 
>>> G
>>> 
>>> 
 
 Gary
 
 
> 
> https://git-scm.com/docs/git-submodule
> 
> Gary
> 
> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
> 
>> By git submodules, are you talking about a symlink to another git
>> repository inside one of our repositories?
>> 
>> -Rob
>> 
>>> On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Any thoughts for or against creating a new git repository which
>> would
>>> contain all 'proper' Commons components as git submodules?
>>> 
>>> The idea is to be able to checkout all of Commons 'proper' in one
>> go
>> in one
>>> place.
>>> 
>>> Gary
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
>> 
>> 
>> 
>> --
>> 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: [All] New repo for all proper components as submodules?

[Ralph Goers]

Why?

> On Sep 1, 2020, at 8:39 PM, Matt Sicker  wrote:
> 
> It could be useful for grouping inter-dependent modules like pool/dbcp.
> 
> On Tue, Sep 1, 2020 at 21:46 Ralph Goers  wrote:
> 
>> As I said previously, I would avoid using either one.  I really don’t know
>> why you would want to with Java. I can understand it with applications
>> written in C where you might want to compile all the dependencies along
>> with the main application. But that isn’t the case in Java. Introducing
>> subtrees or modules just adds complexity you don’t need.
>> 
>> 
>> 
>> Ralph
>> 
>> 
>> 
>>> On Sep 1, 2020, at 6:06 AM, Gary Gregory  wrote:
>> 
>>> 
>> 
>>> I found the following helpful but it is from 2016,  so I wonder how much
>> 
>>> has changed since then:
>> 
>>> 
>> 
>>> https://martowen.com/2016/05/01/git-submodules-vs-git-subtrees/
>> 
>>> 
>> 
>>> Gary
>> 
>>> 
>> 
>>> On Mon, Aug 31, 2020, 10:34 Matt Sicker  wrote:
>> 
>>> 
>> 
>>>> The use case you're describing is fairly well handled by the git
>> 
>>>> subtree command. There are some git plugins that add more complex
>> 
>>>> workflows on top of that, but the base command is what you're looking
>> 
>>>> for. Git submodules, in my experience, are far more useful when
>> 
>>>> pointing to release commits and treating submodule updates like
>> 
>>>> dependency updates. If you want the equivalent of how Subversion lets
>> 
>>>> you link to another repo as a directory, that would be git-subtree,
>> 
>>>> not git-submodule.
>> 
>>>> 
>> 
>>>> On Mon, 31 Aug 2020 at 09:16, Gary Gregory 
>> wrote:
>> 
>>>>> 
>> 
>>>>> On Mon, Aug 31, 2020 at 10:15 AM Gary Gregory 
>> 
>>>>> wrote:
>> 
>>>>> 
>> 
>>>>>> On Sun, Aug 30, 2020 at 9:24 AM Gary Gregory 
>> 
>>>>>> wrote:
>> 
>>>>>> 
>> 
>>>>>>> I'm talking about girl's own submodules:
>> 
>>>>>>> 
>> 
>>>>>>> https://git-scm.com/book/en/v2/Git-Tools-Submodules
>> 
>>>>>>> 
>> 
>>>>>> 
>> 
>>>>>> I think the on-line book above has been updated since 2014 (as seen on
>> 
>>>> the
>> 
>>>>>> front page https://git-scm.com/book/en/v2) so the reference page
>> 
>>>>>> https://git-scm.com/docs/git-submodule should be more accurate.
>> 
>>>>>> 
>> 
>>>>> ARG: "I think the on-line book above has been updated" ->  "I think the
>> 
>>>>> on-line book above has *NOT *been updated"
>> 
>>>>> 
>> 
>>>>> G
>> 
>>>>> 
>> 
>>>>> 
>> 
>>>>>> 
>> 
>>>>>> Gary
>> 
>>>>>> 
>> 
>>>>>> 
>> 
>>>>>>> 
>> 
>>>>>>> https://git-scm.com/docs/git-submodule
>> 
>>>>>>> 
>> 
>>>>>>> Gary
>> 
>>>>>>> 
>> 
>>>>>>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins  wrote:
>> 
>>>>>>> 
>> 
>>>>>>>> By git submodules, are you talking about a symlink to another git
>> 
>>>>>>>> repository inside one of our repositories?
>> 
>>>>>>>> 
>> 
>>>>>>>> -Rob
>> 
>>>>>>>> 
>> 
>>>>>>>>> On Aug 29, 2020, at 6:52 PM, Gary Gregory 
>> 
>>>>>>>> wrote:
>> 
>>>>>>>>> 
>> 
>>>>>>>>> Hi All,
>> 
>>>>>>>>> 
>> 
>>>>>>>>> Any thoughts for or against creating a new git repository which
>> 
>>>> would
>> 
>>>>>>>>> contain all 'proper' Commons components as git submodules?
>> 
>>>>>>>>> 
>> 
>>>>>>>>> The idea is to be able to checkout all of Commons 'proper' in one
>> 
>>>> go
>> 
>>>>>>>> in one
>> 
>>>>>>>>> place.
>> 
>>>>>>>>> 
>> 
>>>>>>>>> Gary
>> 
>>>>>>>> 
>> 
>>>>>>>> 
>> 
>>>>>>>> 
>> -
>> 
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> 
>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>>>>>>>> 
>> 
>>>>>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> --
>> 
>>>> 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
>> 
>> 
>> 
>> --
> Matt Sicker 



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

Re: No more dependabot

[Ralph Goers]

I am not sure that is possible since Dependabot is actually creating PRs and 
GitHub sends those to the mailing list. What I heard was that they would like 
to have Dependabot just send reports from time to time about what dependencies 
could be changed rather than create PRs.  Matt also mentioned that if 
Dependabot is going to create PRs then it should also create the corresponding 
Jira issues and change.xml updates if and when projects require those.

Ralph

> On Sep 16, 2020, at 10:05 AM, Gary Gregory  wrote:
> 
> I think the desire-complaint is how to stop Dependabot from sending emails
> to our ML.
> 
> Gary
> 
> On Wed, Sep 16, 2020, 09:33 Matt Sicker  wrote:
> 
>> Did you know that you can configure Dependabot to ignore specific
>> dependencies and version ranges? You can also configure default
>> reviewers (see also the GitHub CODEOWNERS file which can help set up
>> default reviewers [1]). If desired, you can configure it to only make
>> PRs for security updates which would reduce them to the bare minimum.
>> If you read the (admittedly verbose) Dependabot message in the PR, it
>> has links to changelogs and whatnot for the PR it's making. Being that
>> they're PRs, I don't know of any way to hide notifications from it to
>> the dev list other than making your own filters. I think properly
>> configuring the bot would be appropriate; otherwise, it's not a useful
>> feature if it's simply ignored.
>> 
>> Now if someone discovers how to automatically create Jira tickets to
>> go with the PRs, that'd be nifty. Or changelog entries. The underlying
>> code appears to be source-available, but not open source (restrictions
>> on use) [2].
>> 
>> [1]:
>> https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
>> [2]: https://github.com/dependabot/dependabot-core
>> 
>> On Wed, 16 Sep 2020 at 07:51, Gilles Sadowski 
>> wrote:
>>> 
>>> Le mer. 16 sept. 2020 à 14:42, Jochen Wiedmann
>>>  a écrit :
 
 On Wed, Sep 16, 2020 at 2:38 PM Gilles Sadowski 
>> wrote:
 
> Isn't what
>   https://spamassassin.apache.org/
> is about?
 
 Not that I am uptodate, but at least historically it hasn't. It's
 mostly about blocking spam. Related, but not necessarily reusable for
 the suggested purpose.
>>> 
>>> I don't know the details either; I meant that, in order to block
>>> , the first step is to recognize it as such.
>>> 
>>> From the above web site:
>>> ---CUT---
>>> [...] anti-spam platform giving system administrators a filter to
>>> classify email [...]
>>> [...] scoring framework and plug-ins to integrate a wide range of
>>> advanced heuristic and statistical analysis tests on email headers and
>>> body text including text analysis [...]
>>> ---CUT---
>>> 
>>> Gilles
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> --
>> 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: Unapproved license

[Ralph Goers]

To get even more specific, That message is usually generated by the Maven RAT 
plugin. RAT is an Apache tool to verify that our projects have an appropriate 
license header. A file should have been generated in the “target” directory 
named rat.txt that lists the files without an appropriate license. You should 
inspect each one of these files and determine if it is just missing an Apache 
license, in which case you should add it, or uses some other license. If it is 
the latter then you should add it to the plugins list of excluded files and 
then, if necessary, add something to the project's NOTICE file. 

Ralph 

> On Nov 22, 2020, at 6:33 AM, Arturo Bernal  
> wrote:
> 
> 
> Hi All,
> 
> 
> Ii'm trying to do some change in commons crypto project but i always get the 
> following error-> "Too many files with unapproved license"
> Do i have to solve this issues?
> 
> 
> 
> -
> 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 a "machine learning" component

[Ralph Goers]

-1 on commons-ml as the name. My first thought is such a repo would hold stuff 
related to mailing lists. Then again maybe it contains stuff relating to markup 
languages. Maybe it is Apache’s version of the ML Programming Language [1].

However, I wouldn’t be -1 on commons-math-ml, although at best I would be +0 
since it is still not obvious what it would contain.

Ralph

1. http://web.cecs.pdx.edu/~black/CS311/ML.html

> On Feb 9, 2021, at 3:43 PM, Gilles Sadowski  wrote:
> 
> Hi.
> 
> Because of an offered contribution, a discussion happened on
> JIRA[1] and in another thread[2] about improving the genetic
> algorithm (GA) implementation currently in the
>   org.apache.commons.math4.genetic
> package of the "Commons Math" component.
> It would make sense to group "machine learning" algorithms[3]
> (to which GA belongs) within a single component, where codes from
>  org.apache.commons.math4.ml.neuralnet
>  org.apache.commons.math4.ml.clustering
> would be moved too.
> This would be the fifth (and last) component resulting from my proposal
> (see e.g. [4] among other threads) for the reorganization of the "Commons
> Math"[5] code base into more maintainable components[6][7][8][9], each
> focused on actually related functionalities (thus *not* the wide expertise
> necessary for the maintenance of a full-fledged math library).
> 
> I suggest "ML" for the name of the component.
> 
> Regards,
> Gilles
> 
> [1] https://issues.apache.org/jira/projects/MATH/issues/MATH-1563
> [2] https://markmail.org/message/dnujdcxuaq5bwuwe
> [3] https://en.wikipedia.org/wiki/Machine_learning
> [4] https://markmail.org/message/75vuyhzblfadc5op
> [5] http://commons.apache.org/proper/commons-math/
> [6] http://commons.apache.org/proper/commons-rng/
> [7] http://commons.apache.org/proper/commons-numbers/
> [8] http://commons.apache.org/proper/commons-geometry/
> [9] http://commons.apache.org/proper/commons-statistics/
> 
> -
> 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: [exec][email] Java 7 to 8

[Ralph Goers]

We just concluded this same discussion for Log4j. I looked at the JRebel 2021 
report [1] to gauge the number of people using a particular Java version. 
Respondents were able to select multiple versions so the numbers don’t add up 
to 100%.

Java 7 or older.15%
Java 8  69%
Java 1136%
Java 12 or newer 16%

Jetbrains [2] has a 2020 survey. Since it is from last year you can be sure 
that the numbers for older versions have decreased somewhat.

Java 6   3%
Java 7.  7%
Java 8. 75%
Java 9.  6%
Java 10.6%
Java 11.32%
Java 12.10%
Java 13.14%

Snyk is still conducting their 2021 survey but their 2020 numbers [3] had

Java 7 or older 3%
Java 8. 64%
Java 9. 2%
Java 10.   2%
Java 11   25%
Java 124%

Take these numbers for whatever they are worth.

The questions I would ask are:
1. Why would customers using older virtually unsupported Java versions care 
about new features? Remember that Oracle’s paid support for Java 7 won’t 
include anything but critical security patches at this point. Java 6 is no 
longer supported at all.
2. If you want to continue to support older versions why can’t you just branch 
from the last version that supported an older Java version and create whatever 
bug fixes are required there.

To be clear, that is what we did for Java 6 and 7 with Log4j. We never had a 
single request for a bug fix for those older releases. We finally just voted to 
drop support for Java 6 & 7.

Ralph



[1] https://www.jrebel.com/blog/2021-java-technology-report
[2[ https://www.jetbrains.com/lp/devecosystem-2020/java/
[3] 
https://snyk.io/blog/developers-dont-want-to-leave-java-8-as-64-hold-firm-on-their-preferred-release/

> On Mar 20, 2021, at 4:55 AM, Gary Gregory  wrote:
> 
> They choose to update not, no one forces updates magically, unless you
> always pick up the latest by not specifying a version in a POM (bad
> practice).
> 
> If they are still on Java 6 or 7, then updating libraries might not be a
> priority.
> 
> Gary
> 
> On Sat, Mar 20, 2021, 07:27 John Patrick  wrote:
> 
>> Some customers might need to use Java 7, but what about the customers
>> who want to use it on Java 17 which will be in rampdown in 5 months
>> and released in 6 months?
>> Also from memory from conferences ~ 2018/2019 I thought Java 17 was
>> planning on removing the Classpath so everything needed to be Modules
>> as well as raising the support min Java version to 8 or maybe even 11.
>> 
>> Also I understand that some customers might still be running Java 6 or
>> 7 or 8, but would they be actively upgrading to newer versions and if
>> they have not found any bugs in the current version in the past ~10
>> years will they find any new ones in next 16 months...
>> 
>> On Sat, 21 Nov 2020 at 22:48, sebb  wrote:
>>> 
>>> On Sat, 21 Nov 2020 at 17:13, Gary Gregory 
>> wrote:
 
 On Sat, Nov 21, 2020 at 11:46 AM sebb  wrote:
 
> Note that Java 7 and later are all on lndefinite Sustaining Support:
> 
> 
>> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> 
> This is presumably because there are customers who need Java 7.
> 
 
 And those paying Oracle customers are welcome to NOT upgrade to new
 versions or provide PRs and request releases.
>>> 
>>> It's not just paying customers:
>>> 
>>> "The Extended Support fee will be waived for the period June 2019 -
>>> July 2022 for Java SE 7."
>>> 
>>> I don't see any pressing need to move to Java 8.
>>> 
 Gary
 
 
> 
> On Sat, 21 Nov 2020 at 16:18, Gary Gregory 
>> wrote:
>> 
>> I do not see a reason to maintain EXEC and EMAIL on Java 7 at this
>> point,
>> it's simpler to maintain Commons builds locally, on GitHub
>> Actions, and
>> Travis CI by using Java 8.
>> 
>> FYI, DAEMON is still on Java 6, presumably to support Tomcat. I
>> will
> start
>> a separate thread about that, just to check status.
>> 
>> Gary
> 
> -
> 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
>> 
>> 



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

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

FYI - I did the work of moving Logging Services site from the CMS to git. It 
really wasn’t that hard. The main web site is at 
https://github.com/apache/logging-site 
.  Each of the subproject has their own 
site such as https://github.com/apache/logging-log4j-site 
. Although the Logging Services 
site is small the Log4j site is very large. I can tell you that publishing the 
web site for each new releases is order of magnitudes faster than SVN was. I 
did have to modify how the logging services site gets built but all the 
subprojects use the Maven site plugin.

Ralph



> On Apr 16, 2021, at 5:27 AM, sebb  wrote:
> 
> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  wrote:
>> 
>> Hello.
>> 
>> [Sorry for jumping into the discussion while missing the meaning of
>> most of what is being said (and cutting it).]
> 
> In future please start a new thread in such cases.
> 
>>> [...]
 So why cause additional work for projects that no longer use the CMS?
>>> 
>>> I repeat, projects hopped on to the SVN area of the CMS , that is 
>>> unsupported
>>> and should not have been allowed to happen, it was a workaround by projects
>>> undocumented to support mainly javadocs etc from what I gather.
>>> 
>>> You caused the additional work yourselves in the beginning by not fully 
>>> removing
>>> from the CMS and all its infrastructure. Infra wants to clear out that area 
>>> as part
>>> of migrating away and provides a new space.
>> 
>> From what I recollect, each of the "Commons" projects (component) has its
>> own "trunk" area that is now a "git" repository.
>> "trunk" contains a sub-directory under SVN named "site-content".[1]
>> For quite some time now, the only thing I'm doing with this directory is 
>> along
>> the following:
>> $ mvn site site:stage
>> $ cd site-content
>> $ rm -rf *
>> $ cp -r ../target/staging/* .
>> ["svn add" for added files, "svn del" for removed files...]
>> $ svn commit
>> And the web site for that component was updated.
>> 
>> Is "site-content" being replaced by another location?
>> Is the consequence that in each component we'll have to
>> $ svn co https://new_location_of_site_content site-content
>> ?
> 
> Yes, that is what Infra want people to do.
> Effectively to rename
> 
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
> as
> https://svn.apache.org/repos/infra/sites/commons/content/proper/commons-math
> 
>> Could we perhaps take this opportunity to do away with SVN
>> and "site-content" and have some "mvn" target directly populate
>> the web site?
> 
> That would be a good idea, but will likely take more than 30 days to
> design and test.
> 
> The Commons website consists of lots of different parts which are
> separately built.
> 
> The overall website is served from
> 
> https://svn.apache.org/repos/infra/websites/production/commons/content/
> 
> The component sites are committed to the appropriate subtree, so when
> the whole is checked out it all fits together.
> 
>> Regards,
>> Gilles
>> 
>> [1] This has always seemed like a kludge and has repeatedly
>> caused issues (some of which have been worked around in the
>> POM, IIRC).
> 
> Yes, it is a bit of a kludge, but it was a reasonable solution at the time.
> 
> There are now more options, so it might be possible to improve things.
> 
> But this needs some thought and planning to ensure everything fits
> together, and to ensure it's possible to transition without breaking
> the website for too long.
> 
> Who is going to so the work?
> 
> Can it be done and implemented in the 30 day time limit?
> 
>> -
>> 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: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

Yes, I see there are pieces of missing information. 

When I was doing the work I referred to a couple of Infra web pages to figure 
out how things worked. The links are below. In particular, see "Specifying a 
sub-directory to publish to” in the second link.

The .asf.yaml file is the key. The subdir field identifies where the sub-site 
should appear in the directory structure of the web site.  Basically, you 
should consider that your web site is going to occupy a single directory 
structure wherever the web sites are hosted from. The subdir attribute directs 
the tooling as to where each repo should be copied when a commit is performed.

This means that you can break the web site into as few or as many repos as you 
want. The commons-site repo would host the basic shell of the site. 

If you look at the logging-site repo you will see that it has a source 
directory and a content directory.  The source directory contains the editable 
content.  After editing maven is used to convert the content to html and copy 
it to the content directory. The content directory is where the web tooling 
will pull the website from. 

The ask.yaml link says:
The staging and deployment servers support both the content/ sub-dir 
and the pelican build output/ sub-dir as the root directory for the web site. 
Thus, the website root can be any of:
• The root of the git branch
• The content/ directory at the root of the branch
• The output/ directory at the root of the branch

If you choose the root directory then it would be difficult to host the web 
site source in the same repo. So for the logging project I went with the 
content directory.  However, since all the subprojects are built from the 
individual projects using the Maven site plugin, they all use the root 
directory.

Hopefully, that helps explain how it works a little better.

Ralph


[1] 
https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
[2] https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features


> On Apr 17, 2021, at 6:48 AM, sebb  wrote:
> 
> On Fri, 16 Apr 2021 at 19:39, Ralph Goers  wrote:
>> 
>> FYI - I did the work of moving Logging Services site from the CMS to git. It 
>> really wasn’t that hard. The main web site is at 
>> https://github.com/apache/logging-site 
>> <https://github.com/apache/logging-site>.  Each of the subproject has their 
>> own site such as https://github.com/apache/logging-log4j-site 
>> <https://github.com/apache/logging-log4j-site>. Although the Logging 
>> Services site is small the Log4j site is very large. I can tell you that 
>> publishing the web site for each new releases is order of magnitudes faster 
>> than SVN was. I did have to modify how the logging services site gets built 
>> but all the subprojects use the Maven site plugin.
> 
> AFAICT, the logging-*-site repos are only used for staging and
> publication of the website.
> It looks like the sites are built elsewhere, and then copied into the
> appropriate repo.
> The process seems to be described here [1].
> 
> However the critical step is:
> "3. Add the new site under the content directory (or a subdirectory of
> that as appropriate)."
> This is not explained.
> 
> [1] 
> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites
>> Ralph
>> 
>> 
>> 
>>> On Apr 16, 2021, at 5:27 AM, sebb  wrote:
>>> 
>>> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  wrote:
>>>> 
>>>> Hello.
>>>> 
>>>> [Sorry for jumping into the discussion while missing the meaning of
>>>> most of what is being said (and cutting it).]
>>> 
>>> In future please start a new thread in such cases.
>>> 
>>>>> [...]
>>>>>> So why cause additional work for projects that no longer use the CMS?
>>>>> 
>>>>> I repeat, projects hopped on to the SVN area of the CMS , that is 
>>>>> unsupported
>>>>> and should not have been allowed to happen, it was a workaround by 
>>>>> projects
>>>>> undocumented to support mainly javadocs etc from what I gather.
>>>>> 
>>>>> You caused the additional work yourselves in the beginning by not fully 
>>>>> removing
>>>>> from the CMS and all its infrastructure. Infra wants to clear out that 
>>>>> area as part
>>>>> of migrating away and provides a new space.
>>>> 
>>>> From what I recollect, each of the "Commons" projects (component) has its
>>>> own "trunk" area that is now a

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

You should see my other message but I will reply to your questions also.

> On Apr 16, 2021, at 1:37 PM, Gilles Sadowski  wrote:
> 
> Hello.
> 
> Le ven. 16 avr. 2021 à 20:39, Ralph Goers  a 
> écrit :
>> 
>> FYI - I did the work of moving Logging Services site from the CMS to git. It 
>> really wasn’t that hard. The main web site is at 
>> https://github.com/apache/logging-site 
>> <https://github.com/apache/logging-site>.
> 
> So (IIUC this time), we can get things going by requesting/creating a new
> "git" repository that would be called "commons-site"?

You could either put everything under commons-site, host just the main site 
there and put the sub-projects in their own repos, host the main site and some 
of the sub-projects there with others in their own repos, or almost any other 
combination you want to dream up.


> 
>> Each of the subproject has their own site such as 
>> https://github.com/apache/logging-log4j-site 
>> <https://github.com/apache/logging-log4j-site>.
> 
> Is this an independent "git" repository?
> Do we also create those as would be a normal repository?

Yes, use the standard tool to create the repos. Infra isn’t involved.

> 
> I see that the log4j "components" are under
>   https://github.com/apache/logging-site/tree/master/docs/projects
> 
> And there is only one file (".asf.yaml") in
>   https://github.com/apache/logging-log4j-site

The default directory is probably master. Nothing actually happens there. The 
asf-site branch is where the live site is hosted and the asf-staging branch is 
where the staging site is hosted.

> 
>> Although the Logging Services site is small the Log4j site is very large. I 
>> can tell you that publishing the web site for each new releases is order of 
>> magnitudes faster than SVN was. I did have to modify how the logging 
>> services site gets built but all the subprojects use the Maven site plugin.
> 
> As noted previously, we seem to use that too in (all?) Commons
> components
>  $ mvn site
> 
> But, how does one go from the web files created in the
>target/site/staging
> directory, to them being moved (?) to the site repository?[1]

When I release Log4j I rum mvn site followed by "mvn site:stage 
-DstagingDirectory=$HOME/log4j” on my laptop. I validate the site locally and 
then zip the site, cd to my logging-log4j-site project and unzip it where I 
want it to go. 

If you look at https://github.com/apache/logging-log4j-site/tree/asf-staging 
<https://github.com/apache/logging-log4j-site/tree/asf-staging> you will notice 
that every release of log4j has its own web site in its own directory. This 
allows anyone to go and look at any past release of the web site. 
But if you only want to publish the current version of the site you can just 
overlay the previous version or set the stagingDirectory location to where the 
particular site is on your laptop. 


> 
> Regards,
> Gilles
> 
> [1] The "Manage the Git Hosted Web Site" link on
> https://github.com/apache/logging-site
>points to
> https://cwiki.apache.org/confluence

Thanks, I will fix that.

Ralph

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

One other think I should add. Although Infra’s pages mention tools that you can 
use those are just suggestions. As long as you use the .asf.yaml files and 
place the files in the correct locations in the repos you can use any tooling 
you want to create the sites. I used JBake because I felt it was pretty close 
to what we were doing in the CMS, but as long as the site gets converted from 
its source format (markdown, asciidoc, whatever) into HTML and gets placed into 
the correct directories you can do anything you want.

Ralph

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

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

> On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> 
> On Sat, 17 Apr 2021 at 22:57, Ralph Goers  <mailto:ralph.go...@dslextreme.com>> wrote:
>> 
>> 
>> When I release Log4j I rum mvn site followed by "mvn site:stage 
>> -DstagingDirectory=$HOME/log4j” on my laptop. I validate the site locally 
>> and then zip the site, cd to my logging-log4j-site project and unzip it 
>> where I want it to go.
> 
> In the Wiki that process is described as follows:
> 
> "3. Add the new site under the content directory (or a subdirectory of
> that as appropriate)."
> 
> This leaves out all the detail, making it seem simpler than it is.
> 
> We don't have to do that zip dance currently, because the
> site-content/ directory is checked out in the workspace.
> So the site can be built directly into the target.

Yes, a bit more explanation certainly would be helpful. I didn’t understand it 
either when I read it until I looked at the .asf.yaml files in the subproject. 

Yes, if you want to build the site directly into the target that shouldn’t be a 
problem.

Hopefully the information I’ve provided about how the git-based site support 
with .asf.yaml files will be helpful. I had to spend quite a bit of time 
figuring all this out on my own as the documents I linked to are even less 
clear than the Logging confluence page.

Ralph

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

> On Apr 18, 2021, at 6:38 AM, sebb  wrote:
> 
> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  wrote:
>> 
>> Note that git also has its gitlink and sub modules features that we could
>> use here.
> 
> Are they easy to use?

Submodules are documented at 
https://git-scm.com/book/en/v2/Git-Tools-Submodules. It is a pretty short read. 
In a sense it is a replacement for the .asf.yaml in the submodules. Every 
sub-project would still likely have its own repo but you could get them all 
just by cloning the parent repo with some extra flags on the clone. When you 
commit changes to the sub-module they still go back to the individual repos, 
not the parent.

> Who is going to design and test the replacement?
> Will such a design really be easier to use?
> There's no point changing the publication strategy if it is not an 
> improvement.

Unfortunately, I can’t answer that. I don’t recall ever updating any of the 
Commons web sites.

> 
> We do at least have a way forward if Infra insist on removing
> websites/production.
> Simple to implement, but tedious, as nearly every proper component POM
> will need updating, and existing checkouts will need replacing.
> At least it's a one-off change, and it won't change processes, except
> perhaps for the top-level site.

Having gone through a similar process and after reviewing 
http://commons.apache.org/site-publish.html I’d have to say that the effort 
isn’t really much different. Logging Services hasn’t implemented any automation 
around publishing to the main site as Commons seems to do, but it certainly 
wouldn’t be hard to create a GitHub action to do it.

The main difference I see is that the current commons process seems to deploy 
directly to the live site. With Git all your commits should go to the 
ash-staging branch and the automation should be building that. Making it go 
live is as simple as:

git checkout asf-site
git rebase asf-staging
git push

This allows you to validate the site before it goes live.

Ralph

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

Re: [Vote] Create a "machine learning" component

[Ralph Goers]

t;> 
>>> Le mer. 10 févr. 2021 à 13:19, sebb >> <mailto:seb...@gmail.com>> a écrit :
>>>> 
>>>> Likewise, commons-ml is too cryptic.
>>>> 
>>>> Also, the Spark project has a machine-learning library:
>>>> 
>>>> https://spark.apache.org/mllib/ <https://spark.apache.org/mllib/>
>>> 
>>> Thanks for the pointer.
>>> 
>>>> 
>>>> Maybe that would be better home?
>>> 
>>> On the face of it, probably.
>>> [For sure, Avijit should comment on the suggestion.]
>>> 
>>> On the other hand, "Commons" is the place where one can pick "bare
>>> bone" implementations, and add the functionality to one's application
>>> without necessarily comply with an overarching framework.
>>> [I don't mean that framework compliance is bad; quite the contrary, it is
>>> hopefully the result of a thorough reflection by experts.  But ... cf. the
>>> numerous "no-dependency" discussions ...]
>>> 
>>> Actually, concerning Avijit's proposed contribution, didn't I say:[1]
>>> ---CUT---
>>> Thus, I think that we must assess whether the "genetic algorithms"
>>> functionality has a reasonable future within "Apache Commons" (i.e.
>>> potential users and contributors) while there exist other libraries that
>>> seem much more advanced for any serious usage.
>>> ---CUT---
>>> 
>>>> I'm also a bit concerned as to whether there are sufficient developers
>>>> here with knowledge of the ML domain to be able to support the code in
>>>> the future.
>>> 
>>> An interesting point; by all means not a new one (see e.g. [2]).
>>> 
>>> Isn't it the same point I've been making about "Commons Math" (CM)?
>>> There has been no releases because nobody here is able (or is willing
>>> to) support it.
>>> 
>>> Concerning the support of the purported "machinelearning" component:
>>> 1. Package
>>>org.apache.commons.math4.ml.neuralnet
>>>* I've written it entirely and I have applications that depend on it
>>> (and I
>>>  cannot assume that I could easily switch to, or port it to, Spark),
>>> so I
>>>  can reasonably ensure that it would be supported.
>>> 2. Package
>>>org.apache.commons.math4.ml.clustering
>>>* Functionality is mentioned in Spark's "mllib" user guide.
>>>* When a new feature was last contributed[3], it was noticed[4][5][6]
>>>  that improvement were needed (but there was no follow-up).
>>>* I've an application that depend on it (from CM v3.6.1) but I wouldn't
>>>  support it if shipped in CM v4.0.
>>> 3. Package
>>>org.apache.commons.math4.genetics
>>>* Part of my "end-of-study" project consisted in a GA implementation.
>>>  I've never used the CM implementation, and I don't deny that there
>>>  could be perfectly fine uses of it but, just looking at the code, it
>>> seems
>>>  obvious that it cannot compete feature-wise with other libraries
>>> out there.
>>>* I've suggested long ago that, without anyone supporting it actively
>>> (and
>>>  no known user community), it should be dropped from CM.
>>>* Avijit expressed a willingness to improve the functionality:  Is
>>> this enough
>>>  for the PMC to create a new component?  From the experience with the
>>>  "clustering" package mentioned above, I'd tend to think
>>> (unfortunately)
>>>  that it isn't.  He should first explore whether the Spark community
>>> is
>>>  interested, that the GA functionality be moved over there.
>>> 
>>> Gilles
>>> 
>>> [1] https://issues.apache.org/jira/browse/MATH-1563 
>>> <https://issues.apache.org/jira/browse/MATH-1563>
>>> [2] https://markmail.org/message/26yxj5vhysdsoety 
>>> <https://markmail.org/message/26yxj5vhysdsoety>
>>> [3] https://issues.apache.org/jira/projects/MATH/issues/MATH-1509 
>>> <https://issues.apache.org/jira/projects/MATH/issues/MATH-1509>
>>> [4] https://issues.apache.org/jira/projects/MATH/issues/MATH-1524 
>>> <https://issues.apache.org/jira/projects/MATH/issues/MATH-1524>
>>> [5] https://issues.apache.org/jira/project

Re: [Vote] Create a "machine learning" component

[Ralph Goers]

> On Apr 21, 2021, at 2:25 AM, Gilles Sadowski  wrote:
> 
> Le mer. 21 avr. 2021 à 08:56, Paul King  a écrit :
>> 
>> On Wed, Apr 21, 2021 at 4:12 PM Ralph Goers  
>> wrote:
>>> 
>>> Why are y’all having a long discussion on Vote thread?
> 
> Paul King's comments is interesting information that could
> bear on people's decision on the proposal (especially the
> licence's issue).

The point is that discussions shouldn’t happen on a vote thread. The thread 
should be forked into its own  [DISCUSS][VOTE].

> As for the question of whether the purported functionality would
> find a better home elsewhere with the ASF, I'm sure what would
> be the conclusion (apart from Avijit Bask's plain preference (?) to
> develop a standalone component, as per Commons' requirement).
> 
>> 
>> Fair enough. I am +1 (non-binding).
> 
> So currently, IIRC the tally (on creating a dedicated component) is
>  Gilles Sadowski +1
>  Avijit Basak +1
>  Paul King +1
> And several -1 on the initially suggested name; but the proposed
> name has been changed early on to "commons-machinelearning"
> (in order to comply with Commons' tradition of full words and
> descriptive names).
> [Please correct if it doesn't reflect what has been expressed.]
> 
> Where does that lead us?

With a vote thread that has been open for over 2 months that apparently should 
have been a discussion thread.  I would suggest you cancel this vote and create 
a new Vote thread proposing commons-machinelearning.

Ralph

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

Re: [Vote] Create repository for "machine learning" algorithms.

[Ralph Goers]

+0

I am fine with the proposal but I won’t be contributing to it or helping to 
maintain it so I am hesitant to vote +1.

Ralph

> On Apr 21, 2021, at 10:05 AM, Gilles Sadowski  wrote:
> 
> Hi.
> 
> [This a reboot of the proposal for which the preceding vote
> has just been cancelled.]
> 
> Name of component: "Commons Machine Learning"
> Name of "git" repository: "commons-machinelearning"
> Top-level package name: "org.apache.commons.machinelearning"
> 
> Component rationale and scope (copied verbatim from the
> OP in the other thread):
> ---CUT---
> Because of an offered contribution, a discussion happened on
> JIRA[1] and in another thread[2] about improving the genetic
> algorithm (GA) implementation currently in the
>   org.apache.commons.math4.genetic
> package of the "Commons Math" component.
> It would make sense to group "machine learning" algorithms[3]
> (to which GA belongs) within a single component, where codes from
>  org.apache.commons.math4.ml.neuralnet
>  org.apache.commons.math4.ml.clustering
> would be moved too.
> This would be the fifth (and last) component resulting from my proposal
> (see e.g. [4] among other threads) for the reorganization of the "Commons
> Math"[5] code base into more maintainable components[6][7][8][9], each
> focused on actually related functionalities (thus *not* the wide expertise
> necessary for the maintenance of a full-fledged math library).
> ---CUT---
> 
> You might want to read the discussion that proceeded from the
> previous vote request. [10]
> 
> Please vote:
>  [ ] Yes.
>  [ ] No, because ...
> 
> Thanks,
> Gilles
> 
> [1] https://issues.apache.org/jira/projects/MATH/issues/MATH-1563
> [2] https://markmail.org/message/dnujdcxuaq5bwuwe
> [3] https://en.wikipedia.org/wiki/Machine_learning
> [4] https://markmail.org/message/75vuyhzblfadc5op
> [5] http://commons.apache.org/proper/commons-math/
> [6] http://commons.apache.org/proper/commons-rng/
> [7] http://commons.apache.org/proper/commons-numbers/
> [8] http://commons.apache.org/proper/commons-geometry/
> [9] http://commons.apache.org/proper/commons-statistics/
> [10] https://markmail.org/message/m7cyn4aq2rg47jxk
> 
> -
> 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: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

See below

> On Apr 18, 2021, at 3:21 PM, sebb  wrote:
> 
> On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski  <mailto:gillese...@gmail.com>> wrote:
>> 
>> Le dim. 18 avr. 2021 à 15:38, sebb  a écrit :
>>> 
>>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  wrote:
>>>> 
>>>> Note that git also has its gitlink and sub modules features that we could
>>>> use here.
>>> 
>>> Are they easy to use?
>>> Who is going to design and test the replacement?
>>> Will such a design really be easier to use?
>>> There's no point changing the publication strategy if it is not an 
>>> improvement.
>> 
>> Quoting Ralph Goers:
>> ---CUT---
>> When I release Log4j I rum mvn site followed by "mvn site:stage
>> -DstagingDirectory=$HOME/log4j” on my laptop. I validate the site
>> locally and then zip the site, cd to my logging-log4j-site project and
>> unzip it where I want it to go.
>> ---CUT---
>> 
>> Is that the "publication strategy" which you think is not worth
>> changing to?
>> 
>> That's not more complicated than what I do now (mentioned in the
>> other thread).
> 
> AFAIK the steps you mention in the other thread can be replaced by:
> 
> $ mvn clean site-deploy # for single module components
> OR
> $ mvn clean site site:stage scm-publish:publish-scm # multi module
> 
> I'm not sure that the proposed method is no more complicated than the
> present arrangements.
> 
> The proposal would be two local workspaces to maintain, and two repos
> for each component.
> 
> There's also the issue that most of the poms would likely need
> changing, and the change would not be as simple as changing a URL.

If you use "mvn site:stage -DstagingDirectory=wherever/my/local/site/is” then 
you don’t need to change the poms. 

> 
> As well as setting up all the extra Git branches and/or repos.
> 
> I don't know if a website can be served from a combination of SVN and
> Git sources, so the top-level website would need to be converted to
> Git, and something done about the dormant and sandbox sites - probably
> would need at least one more Git repo to hold them.

Why wouldn’t the dormant and sandbox sites just be part of the main web site? 

> 
> The only advantage I can see is that there could be a public staging
> repo for each site.
> 
> Is that worth all the extra setup?
> 
> And who is doing the work?

Well, someone will have to volunteer.

Ralph

Re: The case for a Commons component

[Ralph Goers]

How many committers will be active for this component?

Ralph

> On Apr 26, 2021, at 7:17 AM, Avijit Basak  wrote:
> 
> Hi
> 
>As per previous discussions, I have created a temporary repository
> in GitHub under my personal GitHub Id(avijitbasak). The artifacts have been
> copied from commons-numbers. A preliminary structure has been created for
> the proposed component.
> Please let me know if we want to proceed with this format. We can copy the
> same to any other team repository if required.
> 
>Repo URL: https://github.com/avijitbasak/commons-machinelearning
> 
> Thanks & Regards
> --Avijit Basak
> 
> On Mon, 26 Apr 2021 at 04:49, Paul King  wrote:
> 
>> On Mon, Apr 26, 2021 at 12:27 AM sebb  wrote:
>>> 
>>> I assume this thread is about the possible ML component.
>>> 
>>> If the code was developed by Commons, I assume it could be used as
>>> part of Spark.
>>> However Commons does not currently have many developers who are
>>> familiar with the field.
>>> So it would seem to me better to have development done by a project
>>> which does have relevant experience.
>>> 
>>> You say that Spark etc have lots of jars.
>>> Surely that allows for it to be implemented as a separate jar which
>>> can either be used as part of the Spark platform, or used
>>> independently?
>> 
>> The stats I gave were for the current minimal use of those algorithms.
>> Most algorithms are written in Scala, use RDD "dataframes" rather than
>> say double arrays, and assume you're running on "the platform" which
>> handles how you might get your data and return results and do logging
>> etc. in a potentially concurrent world. Some of those design choices
>> are key to scaling up but don't align with the goal of making the
>> algorithms runnable "independently".
>> 
>>> The only other option I see is for Commons to persuade some developers
>>> who are familiar with the field to join Commons to assist with the
>>> algorithms.
>> 
>> I agree that is the crux of the issue here. The "commons doesn't have
>> the bandwidth to absorb another algorithm" part of the discussion
>> seems perfectly legit to me. The "and there is an obvious home
>> elsewhere" part of the discussion seemed a little more dubious to me,
>> though obviously that is something which should be considered.
>> 
>>> Existing Commons developers can help manage the logistics of packaging
>>> and releasing the code, as this does not require in depth knowledge of
>>> the design.
>>> However this only makes sense if the developers skilled in the are are
>>> prepared to assist long-term.
>>> 
>>> 
>>> On Sat, 24 Apr 2021 at 23:32, Paul King 
>> wrote:
 
 Thanks Gilles,
 
 I can provide the same sort of stats across a clustering example
 across commons-math (KMeans) vs Apache Ignite, Apache Spark and
 Rheem/Apache Wayang (incubating) if anyone would find that useful. It
 would no doubt lead to similar conclusions.
 
 Cheers, Paul.
 
 On Sun, Apr 25, 2021 at 8:15 AM Gilles Sadowski 
>> wrote:
> 
> Hello Paul.
> 
> Le sam. 24 avr. 2021 à 04:42, Paul King 
>> a écrit :
>> 
>> I added some more comments relevant to if the proposed algorithm
>> belongs somewhere in the commons "math" area back in the Jira:
>> 
>> https://issues.apache.org/jira/browse/MATH-1563
> 
> Thanks for a "real" user's testimony.
> 
> As the ML is still the official forum for such a discussion, I'm
>> quoting
> part of your post on JIRA:
> ---CUT---
> For linear regression, taking just one example dataset, commons-math
> is a couple of library calls for a single 2M library and solves the
> problem in 240ms. Both Ignite and Spark involve "firing up the
> platform" and the code is more complex for simple scenarios. Spark
>> has
> a 181M footprint across 210 jars and solves the problem in about 20s.
> Ignite has a 87M footprint across 85 jars and solves the problem in >
> 40s. But I can also find more complex scenarios which need to scale
> where Ignite and Spark really come into their own.
> ---CUT---
> 
> A similar rationale was behind my developing/using the SOFM
> functionality in the "o.a.c.m.ml.neuralnet" package: I needed a
> proof of concept, and taking the "lightweight" path seemed more
> effective than experimenting with those platforms.
> Admittingly, at that epoch, there were people around, who were
> maintaining the clustering and GA codes; hence, the prototyping
> of a machine-learning library didn't look strange to anyone.
> 
> 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-unsubs

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

> On Apr 27, 2021, at 6:57 AM, Gilles Sadowski  wrote:
> 
> Le mar. 27 avr. 2021 à 12:32, sebb  > a écrit :
>> 
>> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  wrote:
>>> 
>> [...]
> 
> OK to create the
>commons-site
> "git" repository?
 
 Are you offering to do the work?
>>> 
>>> If the option is still on the table, I could test the
>>> website-related feature of ".asf.yaml":
>>>
>>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
>> 
>> Please do NOT attempt to use the 'publish' feature.
>> 
>> As I already wrote that will likely mangle the current website and may
>> require Infa assistance to untangle.
> 
> I certainly do not want to do that.
> 
>> Removal of a publish entry from .asf.yaml does not undo the checkout,
>> and only Infra have direct access to the TLP server.
> 
> Alas, there is a limit to INFRA's magics... ;-)
> 
>> However, you could experiment with the 'staging' feature, and see how
>> easy it is to publish the site to the asf-site branch.
> 
> I must be missing something because I don't see what there is
> to do then, apart from
>  $ git checkout asf-site
>  $ mvn site site:stage
> 
> And, just as now, the functional (except perhaps for the links to
> the top-level Commons site) static site will be under
>  target/staging
> 

ASF git-based web sites use two branches; asf-site for the live site and 
asf-staging for the 
taged site. So when Sebb is telling you to work on the staging site only he 
means commit 
only to the asf-staging branch.


>> 
>> Just don't attempt to publish that branch.
>> 
 
 BTW, I have found out that it is possible to combine site content from
 SVN and Git repos in order to create the website checkout.
 So there is no need to convert to Git.
>>> 
>>> Is it the solution straightforwardly applicable to the current
>>> setup of the Commons web site? [So that ".asf.yaml" should
>>> not be used for the projects' sites.]
>> 
>> AFAICT, yes.
>> 
>> The website is currently taken from:
>> 
>> https://svn-master.apache.org/repos/infra/websites/production/commons
>> 
>> This is done as a single checkout.
>> 
>> This could be changed to take the top-level website from its own
>> location, and the dormant, sandbox and proper trees could be checked
>> out into the relevant subdirectories.
>> 
>> This should be fine so long as the top-level site does not have any
>> files in those 3 subdirectories.
>> 
>> For an example of this, go to
>> https://infra-reports.apache.org/site-source/
>> and enter 'ant.apache.org' in the search box 'Find a web site'
>> 
>> You should see 4 entries at different levels derived from different SVN URLs.
>> Note that in each case the parent SVN tree does not have an entry for
>> its children.
>> E.g. The SVN location for ant.apache.org does not have a directory
>> easyant or ivy.
>> 
>> Note that .asf.yaml does not apply to SVN checkouts.
>> 
>> If we were to determine that Git was better for the proper websites,
> 
> How to do that without a playground for testing?


You create a repo that only has an .asf.yaml in the asf-staging branch. Until 
you 
merge the asf-staging branch to the asf-site branch nothing will be live from 
it as it 
will not have an .asf.yaml file. 


Ralph

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

> On Apr 29, 2021, at 3:58 AM, Gilles Sadowski  wrote:
> 
> 
>> There's no point converting to Git if that process is more involved
>> than the existing process.
> 
> I'm not sure that we mean the same with "the existing process".
> Earlier in the thread, I've described what I do:
> 
> $ mvn site site:stage
> $ cd site-content
> $ rm -rf *
> $ cd ../target/staging/
> $ cp -r * ../../site-content
> $ cd ../../site-content
> $ svn status
> [Use some commands to "svn add" all the new files and "svn del"
> to remove all the file that do not exist anymore.]
> $ svn commit
> 
> What I'd like to know is whether the "process" should be different
> with the current setup.
> 
> IIUC, the ".asf.yaml" approach is to create a subdirectory for each
> new version of the web site (in sync with versions of the code).

That is what Log4j does. It did that even when using CMS/SVN. It is not 
required nor should it be considered a best practice.

Ralph

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

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

> On Apr 29, 2021, at 4:49 AM, sebb  wrote:
> 
> On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski  wrote:
>> 
>> Le jeu. 29 avr. 2021 à 01:45, sebb  a écrit :
>>> 
>>> On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski  wrote:
 
 It occurs to me that we *should* create a specific "git" repository
 for holding web site contents; having the "asf-site" and "asf-staging"
 branches in the component's repository is looking for trouble: It will
 be too easy to commit the (generated) web files into "master"
 instead of the appropriate branch.  [If allowed (even recommended
 as per the doc) by INFRA, we should not frown upon the increased
 separation of concern (source code vs web site management).]
 
 "Logging" has one repository for the top-level site and a separate
 repository for every component.
 IMO, we should do the same (and copy their ".asf.yaml" layout).
>>> 
>>> You are proposing about 50 new Git repos.
>> 
>> Only because it seems that the functionality was intended that way.
> 
> Not as far as I know; many repos have asf-site and asf-staging
> branches alongside the code.

While that works it means that you have “code” branches and “web site” branches 
in the
same git repo. While Git certainly won’t care it will likely confuse new 
contributors for 10 minutes.

Ralph

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

[Discuss][Vote] Create repository for "machine learning" algorithms.

[Ralph Goers]

How long is this vote going to stay open? This vote has already been open for 
12 days.

To this point we have

Sebb - no actual vote but somewhere between 0 and -1. (Binding)
Ralph - +0 (Binding)
Emmanuel: -1 (Binding)
Paul King: +1 (Non-Binding)
Gilles: + 1 (Binding)
Arijit: +1 (Non-Binding)

So there have only been 4 votes from PMC members with only a single +1. 

I see no point in keeping the vote open if no one else is going to vote. 

Ralph 



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

Re: The case for a Commons component

[Ralph Goers]

I apologize. I started another thread regarding the vote before seeing this. 
Maybe that will get more attention?

Ralph

> On May 2, 2021, at 3:59 PM, Gilles Sadowski  wrote:
> 
> Hi.
> 
>> [... Discussion about GA data-structures...]
> 
> I'd suggest that we finalize the [Vote] before getting into the
> details...
> 
> Currently, there have been votes by:
>  Emmanuel Bourg (-1)
>  Sebastian Bazley (-0)
>  Ralph Goers (+0)
>  Paul King (+1)
> 
> So currently, the discussion should be focused on settling to the
> issues put forward by the opponents to having this new component:
>  * Problem 1: Functionality should go somewhere else (Emmanuel, Sebb)
>  * Problem 2: Who will contribute? (Ralph)
> 
> Partial answers have been given.
> We need more opinions (and votes).
> 
> 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: The case for a Commons component

[Ralph Goers]

> On May 5, 2021, at 6:38 AM, Gilles Sadowski  wrote:
> 
> Le mar. 4 mai 2021 à 02:49, Ralph Goers  a écrit :
>> 
>> I apologize. I started another thread regarding the vote before seeing this.
> 
> No problem.
> 
>> Maybe that will get more attention?
> 
> It doesn't seem so. :-}
> 
> IMHO, valid answers have been given to the statements/questions
> from people who didn't vote +1.
> The very low turnout makes the arithmetics of the result fairly subjective...
> 
> The optimistic view is that
>  1. most people don't care (that the repository is created),
>  2. there is no reason to doubt the infos provided by actual users of
> those codes,
>  3. there is an embryo of a community (perhaps not viable, but only
> the future can tell...),[1]
>  4. the same kind of welcoming gestures should apply for the proposed
> contributions, as for the attempt to resuscitate "Commons Graph"[2],
> even if some of the PMC might arguably prefer another option.

Regardless, following https://www.apache.org/foundation/voting.html 
<https://www.apache.org/foundation/voting.html> indicates that this vote is not 
going to pass. 
You can’t assert lazy consensus on an explicit vote.  If you had started this 
as a lazy consensus vote it 
is likely it would have still gotten a -1 vote since both Sebb and Emmanuel 
have voice opposition.

Ralph

Re: The case for a Commons component

[Ralph Goers]

> On May 5, 2021, at 11:13 AM, Gilles Sadowski  wrote:
> 
> Le mer. 5 mai 2021 à 17:44, Ralph Goers  a écrit :
>> 
>> 
>> 
>>> On May 5, 2021, at 6:38 AM, Gilles Sadowski  wrote:
>>> 
>>> Le mar. 4 mai 2021 à 02:49, Ralph Goers  a 
>>> écrit :
>>>> 
>>>> I apologize. I started another thread regarding the vote before seeing 
>>>> this.
>>> 
>>> No problem.
>>> 
>>>> Maybe that will get more attention?
>>> 
>>> It doesn't seem so. :-}
>>> 
>>> IMHO, valid answers have been given to the statements/questions
>>> from people who didn't vote +1.
>>> The very low turnout makes the arithmetics of the result fairly 
>>> subjective...
>>> 
>>> The optimistic view is that
>>> 1. most people don't care (that the repository is created),
>>> 2. there is no reason to doubt the infos provided by actual users of
>>> those codes,
>>> 3. there is an embryo of a community (perhaps not viable, but only
>>> the future can tell...),[1]
>>> 4. the same kind of welcoming gestures should apply for the proposed
>>> contributions, as for the attempt to resuscitate "Commons Graph"[2],
>>> even if some of the PMC might arguably prefer another option.
>> 
>> Regardless, following https://www.apache.org/foundation/voting.html 
>> <https://www.apache.org/foundation/voting.html> indicates that this vote is 
>> not going to pass.
> 
> How so?
> [It's not about a code change; and no "technical argument" can be invoked.]

It looks like you didn’t read the page. For clarity I am copying it here

"Votes on procedural issues follow the common format of majority rule unless 

otherwise stated. That is, if there are more favourable votes than unfavourable 
ones, 

the issue is considered to have passed -- regardless of the number of votes in 
each 

category. (If the number of votes seems too small to be representative of a 
community

 consensus, the issue is typically not pursued. However, see the description of 

lazy consensus <https://www.apache.org/foundation/voting.html#LazyConsensus> 
for a modifying factor.)"


So a procedural vote requires a majority. But note that it also calls out that 
if the number of voters 
seems too small then the issue is usually not pursued.  Both of these describe 
this situation perfectly. 
The vote did not get a majority of binding votes (it was a tie) and the number 
of votes was very small.


> 
>> You can’t assert lazy consensus on an explicit vote.  If you had started 
>> this as a lazy consensus vote it
>> is likely it would have still gotten a -1 vote since both Sebb and Emmanuel 
>> have voice opposition.
> 


> A "veto" does not apply here.
> Hence my remark on the "arithmetics" since the total tally is slightly
> "pro" although the PMC tally is slightly "con”.

Where did I use the word “veto”? I never used the word “veto”.  There are 
essentially 3 ways to vote, 
Yes, No, and Abstain. In a procedural vote + or -1 represent an abstention. 
Anything less than 0 is 
a No and anything greater is a Yes. So saying there were -1 votes implies there 
are “No” votes and 
therefore there is no consensus.

Ralph

Re: The case for a Commons component

[Ralph Goers]

> On May 6, 2021, at 8:06 AM, Gary Gregory  wrote:
> 
> What about the Commons Sandox? Would that be a good place to start?
> 

Emmanuel just sort of proposed doing away with it. As he put it, anyone can 
create a 
GitHub repo so why does it need to be under the apache user.  He hasn’t 
formally 
made a proposal for that and I’m not sure how I would vote on it if he did. He 
does 
have a point. At the same time I’m not sure I’d close off doing experimental or 
early development within the ASF space.

Ralph



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

Re: The case for a Commons component

[Ralph Goers]

> On May 6, 2021, at 3:04 AM, Gilles Sadowski  wrote:
>> 
>> It looks like you didn’t read the page.
> 
> I did, of course. And my interpretation differs.
> 
>> For clarity I am copying it here
>> 
>> "Votes on procedural issues follow the common format of majority rule unless
>> 
>> otherwise stated. That is, if there are more favourable votes than 
>> unfavourable ones,
>> 
>> the issue is considered to have passed -- regardless of the number of votes 
>> in each
>> 
>> category. (If the number of votes seems too small to be representative of a 
>> community
>> 
>> consensus, the issue is typically not pursued. However, see the description 
>> of
>> 
>> lazy consensus > > for a 
>> modifying factor.)"
>> 
>> 
>> So a procedural vote requires a majority.
> 
> There is a small majority (irrespective of the binding vs non-binding
> categories).

In votes ONLY PMC member votes are counted. Other votes are 
advisory. PMC members should take those votes into account 
when voting. If you don’t understand that concept you shouldn’t 
be on a PMC.

Trying to justify creating a new Commons component by endlessly
discussing the topic just isn’t going to work.

I’ll not be responding to more emails on this thread as I consider the 
matter closed.

Ralph

Re: [math] working on increasing performance for Math3

[Ralph Goers]

> On May 8, 2021, at 5:14 AM, Gilles Sadowski  wrote:
> 
> Hello.
> 
> Le sam. 8 mai 2021 à 08:42, Benjamin Marwell  > a écrit :
>> 
>> Instead of using byte buddy, why not just maven multi release jars? *1
> 
> Thanks for the suggestion.
> Again, I don't know how to do it concretely[1] nor the implications
> (IIRC, the mention of multi-release JARs was frowned upon some
> time ago).

Log4j 2 2.x has used multi-release jars for a few years. All the real issues 
have long been solved.
The remaining complications probably won’t be an issue for Commons. The main 
issue is that
some classes and/or methods were eliminated in Java 9 with new replacements 
added. This was 
a poor decision by the OpenJDK team/Oracle as it means that if you want to 
support both 
Java 8 and 11 and you use classes only available in Java 8 that you must have 
multiple compile 
steps in the build of your module and use toolchains to control which JDK gets 
used. If you don’t 
have dependencies on classes or methods that are no longer available then using 
the Java 11 
compiler should work fine.

> 
>> The Java9+ impl will go to META-INF/java9 or so. We did that in the
>> maven-jlink-plugin for example. *2
>> Will be much faster and work on Java 16+. Much easier to rest.
> 
> All good points, I guess.
> 
> However, what about the potential of having a user-selectable
> version of the implementations of the functions contained in
> the JDK's "Math" class?

Why? You should know how the JDK is going to behave. You can create classes 
that wrap JDK 
stuff where Java’s Math works well and have the wrapper call something else 
when it does not. 
You don’t need any logic to do that. You just provide a wrapper at the 
appropriate release levels 
and Java will take care of loading the correct one.

Ralph

Re: The case for a Commons component

[Ralph Goers]

I’ll be nice an summarize. Giles started two vote threads. The first was 
polluted with discussion and eventually closed. The second has not passed and 
is effectively dead but Giles hasn’t closed the vote.

So nothing has been approved.

Ralph

> On May 14, 2021, at 5:48 AM, Gary Gregory  wrote:
> 
> Are seriously asking someone else to read through 40 emails and summarize
> for you? Perhaps part of your contribution might be to do this yourself?
> 
> Gary
> 
> On Fri, May 14, 2021, 08:15 Avijit Basak  wrote:
> 
>> Hi All
>> 
>>This has been a long mail thread. It will be really helpful if
>> anyone can summarize the decisions.
>>Is the proposal of developing the new machine learning component
>> approved?
>>If the team repository is not provided is there any way to go
>> ahead?
>>Waiting for a response.
>> 
>> Thanks & Regards
>> --Avijit Basak
>> 
>> On Fri, 7 May 2021 at 02:26, sebb  wrote:
>> 
>>> On Thu, 6 May 2021 at 21:13, Gary Gregory 
>> wrote:
>>>> 
>>>> It is true that there much less friction these days to get a repository
>>>> going with GitHub, GitLab, and BitBucket, but, for now, the Commons
>>> Sandbox
>>>> is still available. If we want to do away with the sandbox, then let's
>>>> talk about that separately.
>>>> 
>>> 
>>> There is no need for a Sandbox component to use SVN, and it's easy to
>>> create a new Commons git repo.
>>> 
>>> A non-ASF code repo would require code to be checked for license
>>> compliance etc before it could become a Commons component.
>>> A Sandbox component does not require that.
>>> 
>>>> Gary
>>>> 
>>>> On Thu, May 6, 2021, 11:26 Ralph Goers 
>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> On May 6, 2021, at 8:06 AM, Gary Gregory 
>>> wrote:
>>>>>> 
>>>>>> What about the Commons Sandox? Would that be a good place to start?
>>>>>> 
>>>>> 
>>>>> Emmanuel just sort of proposed doing away with it. As he put it,
>> anyone
>>>>> can create a
>>>>> GitHub repo so why does it need to be under the apache user.  He
>> hasn’t
>>>>> formally
>>>>> made a proposal for that and I’m not sure how I would vote on it if
>> he
>>>>> did. He does
>>>>> have a point. At the same time I’m not sure I’d close off doing
>>>>> experimental or
>>>>> early development within the ASF space.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> 
>>>>> 
>>>>> -
>>>>> 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
>>> 
>>> 
>> 
>> --
>> Avijit Basak
>> 



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

Re: [REPORT][DRAFT] Apache Commons Board report for June 2021

[Ralph Goers]

> On Jun 6, 2021, at 11:44 AM, Gilles Sadowski  wrote:
> 
> Le dim. 6 juin 2021 à 14:54, Gary Gregory  a écrit :
>> 
>> Here is the draft I plan on submitting:
>> 
>> ## Description:
>> The mission of Apache Commons is the creation and maintenance of Java focused
>> reusable libraries and components
>> 
>> ## Issues:
>> There are no issues requiring board attention."
>> 
>> ## Membership Data:
>> Apache Commons was founded 2007-06-19 (14 years ago)
>> There are currently 149 committers and 41 PMC members in this project.
>> The Committer-to-PMC ratio is roughly 5:2.
>> 
>> Community changes, past quarter:
>> - Peter Lee was added to the PMC on 2021-03-09
>> - No new committers. Last addition was Peter Lee on 2020-03-13.
>> 
>> ## Project Activity:
>> Apache Commons has released feature and bug fix releases for:
>> - POOL-2.10.0 was released on 2021-06-01.
>> - IO-2.9.0 was released on 2021-05-26.
>> - VFS-2.8.0 was released on 2021-03-10.
>> 
>> ## Community Health:
>> The community is healthy and processessing more than the previous reporting
>> period on our mailing lists, JIRA, and GitHub. Most of the activity comes
>> from PRs on GitHubs which has become an extremely helpful tool through its 
>> PRs
>> and GitHub Actions builds. There are fewer commits than in the previous
>> reporting period but all other metrics as noted above are up.
>> 
>> Gary
>> 
> 
> I don't think that "No new committers" and "Most of the activity comes
> from PRs on GitHub" is particularly "healthy".
> And, again, the advertised numbers of committers and PMC members
> could be formally correct but is, for any purpose, misleading.
> 

I am not sure what you are asking be done. No new committers and most 
of the activity comes from GitHub is not at all unusual. Activity through PRs 
doesn’t equate to new committers. Someone has to demonstrate that they 
are planning on sticking around and a single PR doesn’t accomplish that.

The fact is that Commons has plenty of active PMC members and committers 
and there is a lot of development work going on. Unless there are problems 
the PMC can’t address that is pretty much all the board cares about.

Every PMC I am involved in reports numbers that don’t reflect reality. That 
is primarily because the numbers are derived from Apache Reporter which 
is simply counting numbers from LDAP.

Ralph



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

Re: [EXTERNAL] [Numbers][All] Separate Java target version for "src/test"

[Ralph Goers]

I don’t understand this. Log4j2 was one of the first adopters of multi-release 
jars. 
There were problems in the beginning but those have virtually all been 
resolved. 
We haven’t had any complaints in ages. Log4j 2 2.14.1 supports Java 8. 

Fully supporting JPMS (i.e. - adding a module-info.java file) while trying to 
support 
Java 8 is another thing entirely. I gave up on that and the minimum JDK version 
for that will be Java 11.

Ralph

> On Jun 13, 2021, at 3:37 PM, John Patrick  wrote:
> 
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a pure JPMS solution.
> 
> Potentially someone raise an enhancement to drop support for Java 1.8 which
> isn't happening for Java 17, but for Java 18 which is only 8 month away it
> could happen. So at that point it might be a shock for commons projects as
> you might be blocking open source projects, or they roll off commons
> projects... just a thought.
> 
> I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
> anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...
> 
> John
> 
> 
> On Thu, 10 Jun 2021 at 14:07, Gilles Sadowski  wrote:
> 
>> Le jeu. 10 juin 2021 à 14:42, John Patrick  a
>> écrit :
>>> 
>>> If the tests are valid and useful once post Java 1.8, what about
>>> starting the next release branch where the min version bumps to Java
>>> 11.
>> 
>> [Numbers] and related components were meant to replace and
>> improve some functionalities provided in [Math] v3.6.1 whose
>> target was Java 5 (!).
>> A few years ago, the bump to Java 8 was considered a bold move
>> (for "Commons"). :-}
>> 
>> If we are sure that Java 11 is no problem for anyone who'd go
>> through the upgrade effort, then indeed why not?
>> 
>> Gilles
>> 
>>> As Java 17 starting ramp down starts today I believe so in 3 months we
>>> will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
>>> development starts tomorrow and I expect 1.8 will be dropped shortly
>>> from backwards support as they want to get off the classpath fully and
>>> onto the modules path.
>>> 
>>> Anyway, just a thought.
>>> 
>>> John
>>> 
>>> On Thu, 10 Jun 2021 at 12:05, sebb  wrote:
 
 Thanks.
 
 I've updated the RELEASE-NOTES accordingly (feel free to tweak the
>> text)
 
 On Thu, 10 Jun 2021 at 00:58, Alex Herbert 
>> wrote:
> 
> I have removed the requirement for Java 9 from the build. It is
>> still used
> in the performance testing module.
> 
> Alex
>> 
>> -
>> 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: New component proposal: commons-plugins

[Ralph Goers]

ServliceLoader is used to locate plugins but what is loaded by ServiceLoader 
are not plugins.

Log4j Plugins are categorized into different groupings, primarily by where and 
how the plugins
 are used. For example, PatternConverters used by the PatternLayout are 
separate from 
Appenders, Filters and other things that can appear in a Log4j configuration 
file.

Loading all of Log4j’s plugins via ServiceLoader would be very slow and would 
require every 
plugin be listed in the service configuration file. This has several problems:
1. A service must have a constructor that accepts no parameters.
2. Manually configuring every plugin in the META-INF/services file would be 
painful.
3. Every plugin might have its own unique configuration. ServiceLoader provides 
no mechanism 
for configuration.

Log4j solves these problems by using the Java annotation processor to detect 
all the plugins 
defined in the compilation and generates the service instance ServiceLoader 
will load. This 
service instance maintains the list of all the plugins that were defined along 
with other information 
such as their category and type. The annotation processor also generates the 
META-INF/services 
file automatically.

In addition, every plugin has a Builder with annotated parameters. This allows 
a configuration 
system to easily construct all its components. For example, Log4j allows JSON, 
YAML, XML, 
and properties. All of these use the exact same code to instantiate the Log4j 
configuration.

I hope that answers your question.

Ralph

> On Apr 2, 2022, at 9:57 PM, Peter Verhas  wrote:
> 
> What is the feature not provided by Service Loader?
> 
> On Sat 2. Apr 2022 at 21:33, Matt Sicker  wrote:
> 
>> Hi all, I’ve got a proposal for a new Commons component that I’d like to
>> get feedback on. Essentially, I’d like to propose the creation of a Commons
>> Plugins component inspired by the plugin system developed for Log4j 3.x
>> [0]. This library would be a lightweight dependency injection and
>> configuration library where developers create pluggable classes that can be
>> referenced through plugin names via the configuration file (or
>> configuration source in general). In contrast with more typical dependency
>> injection frameworks like Spring and Guice, this library is for
>> applications where pluggable implementations of things is desired.
>> Developing a plugin system on top of DI frameworks is not a very
>> standardized domain, and each project ends up reinventing this from scratch
>> over time.
>> 
>> Some existing material on how the Log4j plugin and configuration system
>> works that I’d adapt from to form the basis for this component include:
>> -
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
>> <
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
>>> 
>> -
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
>> <
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
>>> 
>> 
>> The general goal of this library is to make it so that applications can
>> provide better configuration DSLs for their plugin components. As both a
>> developer and user, I absolutely despise configuring complex applications
>> with properties files, and YAML variants of properties aren’t that much
>> better. If there was a common plugin library we could reuse, then perhaps
>> more applications would support a better configuration system. This could
>> also provide a nice place for tooling integration similar to how JUnit is
>> supported by IDEs and other tools.
>> 
>> What do you think? Should this start in the Sandbox? Is anyone interested
>> in working on or using this?
>> 
>> [0]: https://github.com/apache/logging-log4j2/tree/master/log4j-plugins <
>> https://github.com/apache/logging-log4j2/tree/master/log4j-plugins>
>> 
>> —
>> Matt Sicker
>> 
>> --
> Peter Verhas
> pe...@verhas.com
> t: +41791542095
> skype: verhas


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

Re: New component proposal: commons-plugins

[Ralph Goers]

I don’t think so.  Commons Configuration (which I was working actively on when 
I started writing Log4j 2) is designed to provide access to the configuration 
data. 
The plugin system is design to convert configuration data into instantiated 
objects. 
I could easily see Commons Configuration being used as the input to the plugin 
system, but I think it would be a mistake to tightly couple them.

Ralph

> On Apr 3, 2022, at 3:23 AM, Gary Gregory  wrote:
> 
> Should this be in Commons Configuration?
> 
> Gary
> 
> On Sat, Apr 2, 2022, 15:33 Matt Sicker  wrote:
> 
>> Hi all, I’ve got a proposal for a new Commons component that I’d like to
>> get feedback on. Essentially, I’d like to propose the creation of a Commons
>> Plugins component inspired by the plugin system developed for Log4j 3.x
>> [0]. This library would be a lightweight dependency injection and
>> configuration library where developers create pluggable classes that can be
>> referenced through plugin names via the configuration file (or
>> configuration source in general). In contrast with more typical dependency
>> injection frameworks like Spring and Guice, this library is for
>> applications where pluggable implementations of things is desired.
>> Developing a plugin system on top of DI frameworks is not a very
>> standardized domain, and each project ends up reinventing this from scratch
>> over time.
>> 
>> Some existing material on how the Log4j plugin and configuration system
>> works that I’d adapt from to form the basis for this component include:
>> -
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
>> <
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
>>> 
>> -
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
>> <
>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
>>> 
>> 
>> The general goal of this library is to make it so that applications can
>> provide better configuration DSLs for their plugin components. As both a
>> developer and user, I absolutely despise configuring complex applications
>> with properties files, and YAML variants of properties aren’t that much
>> better. If there was a common plugin library we could reuse, then perhaps
>> more applications would support a better configuration system. This could
>> also provide a nice place for tooling integration similar to how JUnit is
>> supported by IDEs and other tools.
>> 
>> What do you think? Should this start in the Sandbox? Is anyone interested
>> in working on or using this?
>> 
>> [0]: https://github.com/apache/logging-log4j2/tree/master/log4j-plugins <
>> https://github.com/apache/logging-log4j2/tree/master/log4j-plugins>
>> 
>> —
>> Matt Sicker
>> 
>> 


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

Re: New component proposal: commons-plugins

[Ralph Goers]

Matt J,

I fully expect that if commons-plugins came into fruition it would bear a 
resemblance 
to the Log4j plugin system but there would be differences. For example, while 
Log4j 
integrates with Spring we don’t currently support having the logging 
configuration in 
application.yml. I also suspect it would an almost impossible abstraction to 
have the 
DI system be pluggable, but I could be wrong about that.

Of the bulleted items you listed Log4j’s plugin system handles all of them 
except that 
it doesn’t deal with dependencies. Instead, if your plugin is running in an 
OSGi 
environment it would be expected that the dependent modules would be available 
as 
described by the manifest for the module the plugin is included in.

The goals for the log4j-plugins are really pretty simple. 
* Allow applications to provide flexibility by exposing sets of pluggable 
component types. 
* Allow users to provide their own implementations of the pluggable components 
that 
are on an equal footing with the “standard” components.

Just by way of example, Apache Flume allows pluggable components such as 
Sources, 
Sinks and Channels. Writing a new Sink is fairly straightforward. But it will 
not be on 
an equal footing with the Sinks provided by Flume. This is because there is 
code in 
Flume that provides an alias (such as “avro” for the AvroSink) so that the 
plugin class 
can be named without having to specify the fully qualified class name. Custom 
components must be configured using the FQCN.  The Log4j plugin system solves 
this by requiring every plugin to have a “name” which is then used as the 
mechanism 
to locate it from the configuration.

Non-goals would be 
* It is meant to load plugins, not be a full DI system for every component.
* It leverages standard class loading methodologies, not a new one. i.e. it 
works with 
the standard Java class path, module path, or OSGi.

Ralph


> On Apr 3, 2022, at 8:49 AM, Matt Juntunen  wrote:
> 
> Hi Matt,
> 
> This is quite timely since I've spent the past week researching
> frameworks to modularize a monolithic application at my day job into
> separate components/plugins. Everything I've looked at so far is
> larger and more complicated than I need (e.g. OSGi, Spring, etc) so I
> was seriously considering writing my own, perhaps based on select
> components from the Plexus project [1]. I would be interested in this
> project if it could do the following:
> - provide a standardized plugin packaging format;
> - provide standardized configuration mechanisms;
> - handle plugin discovery and enumeration;
> - handle service discovery, enumeration, and dependency injection;
> - handle class loading and resolution of plugin dependencies (e.g. a
> plugin that depends on a different version of commons-lang than
> another plugin); and
> - provide plugin lifecycle methods.
> 
> It would also be great if the project was compatible with different
> frameworks. For example, if the dependency injection functionality
> could be swapped out for Spring if needed.
> 
> I haven't totally completed my research so I'm not sure if there is
> actually an existing framework out there that satisfies the above
> requirements. If not, I would be willing to help out to get this
> implemented, regardless of whether it ends up in commons or not.
> 
> One more thought: I think it would be equally important (if not more
> so) to define the non-goals of this potential project as the goals. Do
> you have an idea of what those would be?
> 
> Regards,
> Matt J
> 
> [1] https://codehaus-plexus.github.io/
> 
> On Sun, Apr 3, 2022 at 6:24 AM Gary Gregory  wrote:
>> 
>> Should this be in Commons Configuration?
>> 
>> Gary
>> 
>> On Sat, Apr 2, 2022, 15:33 Matt Sicker  wrote:
>> 
>>> Hi all, I’ve got a proposal for a new Commons component that I’d like to
>>> get feedback on. Essentially, I’d like to propose the creation of a Commons
>>> Plugins component inspired by the plugin system developed for Log4j 3.x
>>> [0]. This library would be a lightweight dependency injection and
>>> configuration library where developers create pluggable classes that can be
>>> referenced through plugin names via the configuration file (or
>>> configuration source in general). In contrast with more typical dependency
>>> injection frameworks like Spring and Guice, this library is for
>>> applications where pluggable implementations of things is desired.
>>> Developing a plugin system on top of DI frameworks is not a very
>>> standardized domain, and each project ends up reinventing this from scratch
>>> over time.
>>> 
>>> Some existing material on how the Log4j plugin and configuration system
>>> works that I’d adapt from to form the basis for this component include:
>>> -
>>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
>>> <
>>> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
 
>>> -
>>> https://github.com/

Re: New component proposal: commons-plugins

[Ralph Goers]

If you look at Log4j, we parse the configuration and convert it to a Node 
hierarchy. 
Variable interpolation occurs as the Nodes are constructed.

But again, Nothing says a Commons Plugins implementation has to work the same 
way.

Ralph

> On Apr 3, 2022, at 7:12 PM, Gary Gregory  wrote:
> 
> Nice thread :-)
> 
> Where does the parsing of configuration files mix in such a stack?
> 
> Where does variable interpolation come into play?
> 
> Gary
> 
> On Sun, Apr 3, 2022, 20:50 Ralph Goers  wrote:
> 
>> Matt J,
>> 
>> I fully expect that if commons-plugins came into fruition it would bear a
>> resemblance
>> to the Log4j plugin system but there would be differences. For example,
>> while Log4j
>> integrates with Spring we don’t currently support having the logging
>> configuration in
>> application.yml. I also suspect it would an almost impossible abstraction
>> to have the
>> DI system be pluggable, but I could be wrong about that.
>> 
>> Of the bulleted items you listed Log4j’s plugin system handles all of them
>> except that
>> it doesn’t deal with dependencies. Instead, if your plugin is running in
>> an OSGi
>> environment it would be expected that the dependent modules would be
>> available as
>> described by the manifest for the module the plugin is included in.
>> 
>> The goals for the log4j-plugins are really pretty simple.
>> * Allow applications to provide flexibility by exposing sets of pluggable
>> component types.
>> * Allow users to provide their own implementations of the pluggable
>> components that
>> are on an equal footing with the “standard” components.
>> 
>> Just by way of example, Apache Flume allows pluggable components such as
>> Sources,
>> Sinks and Channels. Writing a new Sink is fairly straightforward. But it
>> will not be on
>> an equal footing with the Sinks provided by Flume. This is because there
>> is code in
>> Flume that provides an alias (such as “avro” for the AvroSink) so that the
>> plugin class
>> can be named without having to specify the fully qualified class name.
>> Custom
>> components must be configured using the FQCN.  The Log4j plugin system
>> solves
>> this by requiring every plugin to have a “name” which is then used as the
>> mechanism
>> to locate it from the configuration.
>> 
>> Non-goals would be
>> * It is meant to load plugins, not be a full DI system for every component.
>> * It leverages standard class loading methodologies, not a new one. i.e.
>> it works with
>> the standard Java class path, module path, or OSGi.
>> 
>> Ralph
>> 
>> 
>>> On Apr 3, 2022, at 8:49 AM, Matt Juntunen 
>> wrote:
>>> 
>>> Hi Matt,
>>> 
>>> This is quite timely since I've spent the past week researching
>>> frameworks to modularize a monolithic application at my day job into
>>> separate components/plugins. Everything I've looked at so far is
>>> larger and more complicated than I need (e.g. OSGi, Spring, etc) so I
>>> was seriously considering writing my own, perhaps based on select
>>> components from the Plexus project [1]. I would be interested in this
>>> project if it could do the following:
>>> - provide a standardized plugin packaging format;
>>> - provide standardized configuration mechanisms;
>>> - handle plugin discovery and enumeration;
>>> - handle service discovery, enumeration, and dependency injection;
>>> - handle class loading and resolution of plugin dependencies (e.g. a
>>> plugin that depends on a different version of commons-lang than
>>> another plugin); and
>>> - provide plugin lifecycle methods.
>>> 
>>> It would also be great if the project was compatible with different
>>> frameworks. For example, if the dependency injection functionality
>>> could be swapped out for Spring if needed.
>>> 
>>> I haven't totally completed my research so I'm not sure if there is
>>> actually an existing framework out there that satisfies the above
>>> requirements. If not, I would be willing to help out to get this
>>> implemented, regardless of whether it ends up in commons or not.
>>> 
>>> One more thought: I think it would be equally important (if not more
>>> so) to define the non-goals of this potential project as the goals. Do
>>> you have an idea of what those would be?
>>> 
>>> Regards,
>>> Matt J
>>> 
>>> [1] https://codehaus-plexus.github.io/
>>>

Re: New component proposal: commons-plugins

[Ralph Goers]

It has been too long since I looked at Commons Configuration for me to answer 
that.

Ralph

> On Apr 3, 2022, at 7:25 PM, Gary Gregory  wrote:
> 
> So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration
> objects?
> 
> G
> 
> On Sun, Apr 3, 2022, 22:18 Ralph Goers  wrote:
> 
>> If you look at Log4j, we parse the configuration and convert it to a Node
>> hierarchy.
>> Variable interpolation occurs as the Nodes are constructed.
>> 
>> But again, Nothing says a Commons Plugins implementation has to work the
>> same way.
>> 
>> Ralph
>> 
>>> On Apr 3, 2022, at 7:12 PM, Gary Gregory  wrote:
>>> 
>>> Nice thread :-)
>>> 
>>> Where does the parsing of configuration files mix in such a stack?
>>> 
>>> Where does variable interpolation come into play?
>>> 
>>> Gary
>>> 
>>> On Sun, Apr 3, 2022, 20:50 Ralph Goers 
>> wrote:
>>> 
>>>> Matt J,
>>>> 
>>>> I fully expect that if commons-plugins came into fruition it would bear
>> a
>>>> resemblance
>>>> to the Log4j plugin system but there would be differences. For example,
>>>> while Log4j
>>>> integrates with Spring we don’t currently support having the logging
>>>> configuration in
>>>> application.yml. I also suspect it would an almost impossible
>> abstraction
>>>> to have the
>>>> DI system be pluggable, but I could be wrong about that.
>>>> 
>>>> Of the bulleted items you listed Log4j’s plugin system handles all of
>> them
>>>> except that
>>>> it doesn’t deal with dependencies. Instead, if your plugin is running in
>>>> an OSGi
>>>> environment it would be expected that the dependent modules would be
>>>> available as
>>>> described by the manifest for the module the plugin is included in.
>>>> 
>>>> The goals for the log4j-plugins are really pretty simple.
>>>> * Allow applications to provide flexibility by exposing sets of
>> pluggable
>>>> component types.
>>>> * Allow users to provide their own implementations of the pluggable
>>>> components that
>>>> are on an equal footing with the “standard” components.
>>>> 
>>>> Just by way of example, Apache Flume allows pluggable components such as
>>>> Sources,
>>>> Sinks and Channels. Writing a new Sink is fairly straightforward. But it
>>>> will not be on
>>>> an equal footing with the Sinks provided by Flume. This is because there
>>>> is code in
>>>> Flume that provides an alias (such as “avro” for the AvroSink) so that
>> the
>>>> plugin class
>>>> can be named without having to specify the fully qualified class name.
>>>> Custom
>>>> components must be configured using the FQCN.  The Log4j plugin system
>>>> solves
>>>> this by requiring every plugin to have a “name” which is then used as
>> the
>>>> mechanism
>>>> to locate it from the configuration.
>>>> 
>>>> Non-goals would be
>>>> * It is meant to load plugins, not be a full DI system for every
>> component.
>>>> * It leverages standard class loading methodologies, not a new one. i.e.
>>>> it works with
>>>> the standard Java class path, module path, or OSGi.
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>>> On Apr 3, 2022, at 8:49 AM, Matt Juntunen 
>>>> wrote:
>>>>> 
>>>>> Hi Matt,
>>>>> 
>>>>> This is quite timely since I've spent the past week researching
>>>>> frameworks to modularize a monolithic application at my day job into
>>>>> separate components/plugins. Everything I've looked at so far is
>>>>> larger and more complicated than I need (e.g. OSGi, Spring, etc) so I
>>>>> was seriously considering writing my own, perhaps based on select
>>>>> components from the Plexus project [1]. I would be interested in this
>>>>> project if it could do the following:
>>>>> - provide a standardized plugin packaging format;
>>>>> - provide standardized configuration mechanisms;
>>>>> - handle plugin discovery and enumeration;
>>>>> - handle service discovery, enumeration, and dependency injection;
>>>>> - handle class loading and resolution of pl

Re: New component proposal: commons-plugins

[Ralph Goers]

Matt,

I don’t see commons-plugins needing a configuration. Remember, there are 
several components 
in Log4j that don’t use a configuration file. Namely, Lookups, 
PatternConverters, KeyProviders, 
and Watchers, I view the plugin system as an API that a configuration system 
would use to 
instantiate the objects referenced in the configuration.

Ralph

> On Apr 4, 2022, at 8:30 AM, Matt Sicker  wrote:
> 
> From the Log4j side of things, I didn't exactly overhaul the
> configuration parsing or representation of it, so it would depend on
> how different that looks in this proposed component. Ideally, though,
> a commons-plugins component would replace log4j-plugins and
> log4j-plugin-processor along with some of the plugin types we have
> like type converters and config variable substitution.
> 
> From a high level point of view, the inputs would be a configuration
> source (e.g., a reloadable file or HTTPS link or whatever), and the
> output would be a graph of instantiated plugins from the
> configuration.
> 
> On Mon, Apr 4, 2022 at 8:12 AM Gary Gregory  wrote:
>> 
>> I am trying to figure out the input and output of a Commons Plugins
>> that Log4j would use.
>> 
>> Gary
>> 
>> On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers  
>> wrote:
>>> 
>>> It has been too long since I looked at Commons Configuration for me to 
>>> answer that.
>>> 
>>> Ralph
>>> 
>>>> On Apr 3, 2022, at 7:25 PM, Gary Gregory  wrote:
>>>> 
>>>> So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration
>>>> objects?
>>>> 
>>>> G
>>>> 
>>>> On Sun, Apr 3, 2022, 22:18 Ralph Goers  wrote:
>>>> 
>>>>> If you look at Log4j, we parse the configuration and convert it to a Node
>>>>> hierarchy.
>>>>> Variable interpolation occurs as the Nodes are constructed.
>>>>> 
>>>>> But again, Nothing says a Commons Plugins implementation has to work the
>>>>> same way.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Apr 3, 2022, at 7:12 PM, Gary Gregory  wrote:
>>>>>> 
>>>>>> Nice thread :-)
>>>>>> 
>>>>>> Where does the parsing of configuration files mix in such a stack?
>>>>>> 
>>>>>> Where does variable interpolation come into play?
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Sun, Apr 3, 2022, 20:50 Ralph Goers 
>>>>> wrote:
>>>>>> 
>>>>>>> Matt J,
>>>>>>> 
>>>>>>> I fully expect that if commons-plugins came into fruition it would bear
>>>>> a
>>>>>>> resemblance
>>>>>>> to the Log4j plugin system but there would be differences. For example,
>>>>>>> while Log4j
>>>>>>> integrates with Spring we don’t currently support having the logging
>>>>>>> configuration in
>>>>>>> application.yml. I also suspect it would an almost impossible
>>>>> abstraction
>>>>>>> to have the
>>>>>>> DI system be pluggable, but I could be wrong about that.
>>>>>>> 
>>>>>>> Of the bulleted items you listed Log4j’s plugin system handles all of
>>>>> them
>>>>>>> except that
>>>>>>> it doesn’t deal with dependencies. Instead, if your plugin is running in
>>>>>>> an OSGi
>>>>>>> environment it would be expected that the dependent modules would be
>>>>>>> available as
>>>>>>> described by the manifest for the module the plugin is included in.
>>>>>>> 
>>>>>>> The goals for the log4j-plugins are really pretty simple.
>>>>>>> * Allow applications to provide flexibility by exposing sets of
>>>>> pluggable
>>>>>>> component types.
>>>>>>> * Allow users to provide their own implementations of the pluggable
>>>>>>> components that
>>>>>>> are on an equal footing with the “standard” components.
>>>>>>> 
>>>>>>> Just by way of example, Apache Flume allows pluggable components such as
>>>>>>> Sources,
>>>>>>> Sinks and Channels. Writing a new Sink is fairly straightforward. But it
>>>>&

Re: New component proposal: commons-plugins

[Ralph Goers]

Matt,

The Logging Provider is not a plugin as it is required way before plugins are 
available.

That said, the plugin system certainly could have a way of performing version 
checking. 
But keep in mind, the versions would be defined by the “owner” of each plugin 
category 
and not tied to the plugin system.

Ralph

> On Apr 4, 2022, at 8:39 AM, Matt Sicker  wrote:
> 
> I used to work on the Jenkins project for a few years, so yes, I'm
> fairly familiar with those difficulties. I've also used OSGi in the
> past, and I like their approach to semantic versioning and dynamic
> "plugin" (well, bundle/component/etc.) lifecycles. I currently work on
> the Spinnaker project where we have a less sophisticated plugin system
> based on pf4j, and we've already found that to be incredibly
> burdensome to work with so far.
> 
> For version compatibility, I'd like to maintain the usual Commons
> standards of strict compatibility along semantic versioning. The
> existing Log4j plugin system already has some basic version check
> support (at least for the logging provider), and a more generic plugin
> system would definitely need the more sophisticated version check
> support. I'd also like a way for plugins to declare data compatibility
> related metadata for easier upgrades and such, but those are merely
> details.
> 
> On Mon, Apr 4, 2022 at 10:33 AM Xeno Amess  wrote:
>> 
>> If you really want to start this, it would be useful.
>> However it would be complicated, very very complicated.
>> For example, version management.
>> The plugins have their versions.
>> And the base program has its version.
>> And the plugin registration mechanism has its own version.
>> How to make it work would be a big challenge.
>> If we wanna make a useful plugin management system, maybe a good way is
>> first to learn about some existing usage of these things(although developed
>> in different groups/repos), like eclipse, jetbrains idea, even OSGI...
>> 
>> Gary Gregory  于2022年4月4日周一 21:11写道：
>> 
>>> I am trying to figure out the input and output of a Commons Plugins
>>> that Log4j would use.
>>> 
>>> Gary
>>> 
>>> On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers 
>>> wrote:
>>>> 
>>>> It has been too long since I looked at Commons Configuration for me to
>>> answer that.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Apr 3, 2022, at 7:25 PM, Gary Gregory 
>>> wrote:
>>>>> 
>>>>> So in a Commons centric fantasy, Log4j Nodes could be Commons
>>> Configuration
>>>>> objects?
>>>>> 
>>>>> G
>>>>> 
>>>>> On Sun, Apr 3, 2022, 22:18 Ralph Goers 
>>> wrote:
>>>>> 
>>>>>> If you look at Log4j, we parse the configuration and convert it to a
>>> Node
>>>>>> hierarchy.
>>>>>> Variable interpolation occurs as the Nodes are constructed.
>>>>>> 
>>>>>> But again, Nothing says a Commons Plugins implementation has to work
>>> the
>>>>>> same way.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Apr 3, 2022, at 7:12 PM, Gary Gregory 
>>> wrote:
>>>>>>> 
>>>>>>> Nice thread :-)
>>>>>>> 
>>>>>>> Where does the parsing of configuration files mix in such a stack?
>>>>>>> 
>>>>>>> Where does variable interpolation come into play?
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Sun, Apr 3, 2022, 20:50 Ralph Goers 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Matt J,
>>>>>>>> 
>>>>>>>> I fully expect that if commons-plugins came into fruition it would
>>> bear
>>>>>> a
>>>>>>>> resemblance
>>>>>>>> to the Log4j plugin system but there would be differences. For
>>> example,
>>>>>>>> while Log4j
>>>>>>>> integrates with Spring we don’t currently support having the logging
>>>>>>>> configuration in
>>>>>>>> application.yml. I also suspect it would an almost impossible
>>>>>> abstraction
>>>>>>>> to have the
>>>>>>>> DI system be pluggable, but I could be wrong about that.
>>&g

Re: New component proposal: commons-plugins

[Ralph Goers]

If I had known this was going to turn into a debate I wouldn’t have responded 
to the 
question. But it seems either my response wasn’t clear, you did not understand 
what I wrote, or you have some preconceived notion as to why anything beyond 
ServiceLoader is needed. I would suggest that before responding to this email 
that 
you go look at how log4j-plugins is implemented in the master branch.

> On Apr 4, 2022, at 8:13 PM, Peter Verhas  wrote:
> 
> Thank Ralph for the answer related ServiceLoader. I understand your
> concerns. A new commons plugin module is in place if we identify the needs
> unmet with modern Java. However, the shortcomings you listed are mainly
> related to Java 8 and older versions. Thus I would appreciate it if you
> could clarify the followings:
> 
>> Loading all of Log4j’s plugins via ServiceLoader would be very slow
> 
> What kind of measurements and benchmarks show that? I have never had any
> issue with speed using ServiceLoader, as it is a standard way to load
> classes and get their objects which may not be there during the compile
> time. For example, my Jamal macro language loads all the macros and
> debuggers as services.
> SLF4J relies on ServiceLoader.

From this it is clear that you completely misunderstand what the plugin system 
is doing.
First, the plugin system DOES use ServiceLoader. In fact, Log4j uses 
ServiceLoader 
in at least 7 different places. For one, it uses ServiceLoader to locate the 
Log4j 
implementation similar to how SLF4J does (although Log4j implemented it prior 
to SLF4J).

Consider that you have 150 or so plugins, of which maybe only 10 will get used. 
But 
you don’t know beforehand which 10. ServiceLoader would have to load all 150 
classes. 
This is indeed very slow. Yes we have benchmarked it. But the Plugin system IS 
a 
Java Service. So instead, you need to only load 1 class for every jar that 
contains plugins. 
The result is that you only need to load 4 or 5 classes. This is considerably 
faster.

In addition, services loaded by ServiceLoader are singletons. It is not unusual 
to require 
multiple instances of.a Plugin so this would be difficult to do with the 
ServiceLoader. 
But since the service loaded for the plugin system only contains the plugin 
definition 
this is not an issue.

> 
>> and would require every
>> plugin be listed in the service configuration file.
> 
> I do not understand what configuration file you are talking about.

META-INF/services/service.fully.qualified.class.name. Every plugin would need 
an 
entry in this file if every Plugin is a raw service. In addition, for JPMS they 
would need 
an additional entry in module-info.java. The Log4j annotation processor 
generates the 
META-INF/services file for you. 

> 
> You implement an interface when you develop a service to be loaded by the
> JDK ServiceLoader. In addition to that, you either list the full name of
> the class in a text file inside your library, and the name of the file is
> the fully qualified name of the interface (this is the old style,
> pre-Java-9, and Java module systems), or you declare your service in the
> module-info.java file.

I’m not sure why you are explaining how ServiceLoader works. As I said, I am 
quite 
familiar with it.


> 
>> This has several problems:
>> 1. A service must have a constructor that accepts no parameters.
> 
> You can also have a provider method in the service implementing class.
> There is some flexibility introduced in Java 9.

Nothing that helps. What ServiceLoader really does best is instantiating 
factories. 
You then use that factory to instantiate what you really want. Most uses of 
ServiceLoader 
in Log4j do that.

> 
>> 2. Manually configuring every plugin in the META-INF/services file would
> be painful.
> 
> This is opinionated. There is no point debating opinions.

This is not opinion. This is a fact. Adding 50 entries to the service loader 
file is much 
more painful than adding just 1. There is no way you can argue against that.

> Editing a text
> file and inserting the name of the fully qualified name of the class never
> felt painful significantly since editors like IntelliJ help you copy/paste
> the fully qualified names. If you find it cumbersome to maintain these
> files manually, you can also use annotation processors to generate them. I
> have never used it, but Spring @AutoService does something like that.
> 
> In addition to that, you do not need to have the old-style
> META-INF/services files if you use Java 9 or newer.

That is not correct. That may be true when using the module path but the 
javadoc 
for ServiceLoader is quite clear that the file is still required for jars on 
the classpath. 
Since the vast majority of Java users do not use JPMS this isn’t really 
helpful. I 
should also note that in fact the opposite is true. If your jar is an automatic 
module 
then JPMS will create the provides statement for you based on the presence of 
the 
META-INF/services file.

> 
>> 3. Every plugi

Re: New component proposal: commons-plugins

[Ralph Goers]

> On Apr 7, 2022, at 2:52 AM, Peter Verhas  wrote:
> 
> 
>> I would suggest that before responding to this email that
>> you go look at how log4j-plugins is implemented in the master branch.
>> 
> 
> Sure, if you propose to create a commons-plugin library that is an extract
> of the plugin handling of log4j so that log4j next releases do not need to
> keep the functionality inside log4j but rather as a dependency on this new
> library. On the other hand, if the goal is to create something that is
> useful generally then we should look at other solutions as well.

It remains to be seen whether Log4j would replace log4j-plugins with 
Commons-plugins. The point of looking at Log4j was to understand the 
problem it is solving and how it solves it.


> 
> 
>> From this it is clear that you completely misunderstand what the plugin
>> system is doing.
>> 
> 
> That may really be very much true.
> 
> 
>> First, the plugin system DOES use ServiceLoader. In fact, Log4j uses
>> ServiceLoader
>> in at least 7 different places. For one, it uses ServiceLoader to locate
>> the Log4j
>> implementation similar to how SLF4J does (although Log4j implemented it
>> prior to SLF4J).
>> 
>> Consider that you have 150 or so plugins, of which maybe only 10 will get
>> used. But
>> you don’t know beforehand which 10. ServiceLoader would have to load all
>> 150 classes.
> 
> 
> Not. It does not need to  create instances of all of them. This is what I
> explained, and this is the reason why I explained it. JPMS or not, the new
> ServiceLoader used by Java 9 and later will call the static factory method
> of the class if that exists. Then the plugin can decide if it wants itself
> to be instantiated or not. Somewhere there should be some logic that
> filters 10 from the 150. If that is in a central place implementing some
> industry-best-practice configuration based algorithm, or outsources the
> decision to the plugins themselves should not make a big difference in
> performance.
> 
> On  the second though, instantiating 150 lightweight classes must not be a
> big burden. The ServiceProvider JavaDoc documentation suggest that services
> should be implemented as proxies or factories instantiating their real
> working class lazily in case the instantiation is costly.

Class loading in general is slow. Perhaps not to you but we have customers who 
complain about all the things we do during startup and locating and 
instantiating
plugins is one of them. When we first switched to use the ServiceLoader we 
attempted to load the plugin classes simply by having the plugin definition 
include 
the Class.Performance was very bad. We now only include the class name and 
only access the Class when absolutely necessary.

Again, if you think about what the Plugin Manager is doing, it is using 
ServiceLoader 
to find all Plugin Service instances. Each of these contains the definitions of 
all the 
plugins. The Plugin Manager then uses these to create the actual plugins. So in 
essence, the services are used as part of the factory. Note that decisions 
about 
whether to load a plugin or not do not have to be made when the plugin service 
s accessed. That is deferred until the Plugin actually needs to be wired.

> 
> 
>> This is indeed very slow. Yes we have benchmarked it. But the Plugin
>> system IS a
>> Java Service. So instead, you need to only load 1 class for every jar that
>> contains plugins.
>> The result is that you only need to load 4 or 5 classes. This is
>> considerably faster.
>> 
> 
> Yes, this is the approach where you insert another layer above the service
> loader that does part of the job that the service loader can also do in a
> different way. Essentially you let the plugin libraries, each containing
> several plugin classes to implement their own service loaders.

Sort of. With Log4j’s plugin system Plugins are not aware of ServiceLoader 
at all. Other than that, it behaves the way you are describing.

> 
> 
>> In addition, services loaded by ServiceLoader are singletons.
> 
> 
> No, they are not. Every ServiceLoader instance will create new instances,
> and even a single ServiceLoader can be asked calling the `reload()` method
> to evict the instances from its cache and create new instances.

Umm. Even calling reload() doesn’t change it from being a singleton. You can 
only have a single instance at a time.

Yes, I suppose if you use multiple ServiceLoader instances then you can I
nstantiate multiple instances of the service. However, as you noted that 
wouldn’t 
be the best practice since the ServiceLoader really should be instantiating a 
factory that create as many instances as you want.

> 
> Perhaps developing a commons-plugin system is a good point to require
> application developers and plugin developers to use the module system.

Please no. I would never encourage anyone to use it. It has caused nothing 
but pain. Yes, that is opinion, but opinion based on experience.

> 
> 
>> Again, I would suggest you look at the 

Re: New component proposal: commons-foo or better commons-text

[Ralph Goers]

The Log4j variation used StrSubstitutor straight from Commons (wherever it was 
located at the time) but then had to modify some of the methods to accept 
LogEvents.
To do this StringSubstitutor would have to be modified to be 
StringSubstitutor and 
allow an object of type T to be passed to the replace and substitute methods. 

But the biggest impact would be that resolveVariable in Log4j calls Log4j’s 
version of 
StrLookup which does not define all the other lookups in it and has an evaluate 
method 
(Commons StrLookup uses a lookup method) that accepts the LogEvent.
So StrLookup would need significant modifications to be usable by Log4j.

Ralph

> On Apr 7, 2022, at 6:48 AM, Gary Gregory  wrote:
> 
> The log4j variable interpolation, the ${lookup:variable} type of logic is
> in many places: deprecated in Commons Lang, now in Commons Text, also
> implemented in Commons Configuration. We could bring in the Log4j version,
> now safer than other implementations into Commons Text or a new component
> and everyone depends on this new version.
> 
> Gary
> 
> On Thu, Apr 7, 2022, 05:55 Peter Verhas  wrote:
> 
>>> 
 The plugin system is design to convert configuration data into
>>> instantiated objects.
>>> 
>> 
>> For me that very much reads a dependency injection framework.
>> 
>> --
>> Peter Verhas
>> pe...@verhas.com
>> t: +41791542095
>> skype: verhas
>> 


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

Re: New component proposal: commons-plugins

[Ralph Goers]

See below

> On Apr 8, 2022, at 9:23 AM, Peter Verhas  wrote:
> 
> Thanks Ralph for the detailed explanation. I appreciate it and now I see
> the points.

I’ve removed the parts that I don’t think need any more discussion.

> - How will it be a “plugin" project and not another dependency injection
> framework?

This is a great question. I think the main difference is with examples like 
Log4j 
and Apache Flume, and even Apache Maven. All wire components together via 
user provided configuration, not code. Dependency injection could certainly be 
part of the plugin framework but that would be for implementors of plugins, 
not the users using them. Users of Maven don’t know that Plexus is used under 
the covers and neither should users of a commons-plugins implementation.

> - What will distinguish it from module systems, like OSGi and what will
> stop it from becoming another OSGi by the years as new features get added
> to the library.

OSGi is complicated. Implementing plugins should not be. Just as I described 
using ServiceLoader to locate plugins, plugins should also be accessible in 
OSGi bundles. Users should be required to do as little as possible to adapt the 
plugin system to the environment it is running in but plugins shouldn’t know or 
care anything about how they are located and loaded. Plugins are also to the 
application or framework that will be using them. They essentially define what 
the valid plugin types are and where they can be used.

> - What applications using plugins are the examples for different solutions?
> (Log4j is a good example to show that there is a need, you also explained
> patiently why it is not a simple ServiceLoader, but it is only one way to
> solve it. Other applications may approach the issue differently. Maven,
> Attlassian products, other build tools, JUnit 5 and so on.)

We’ve already mentioned Log4j. Apache Flume also sort of supports plugins, 
which I previously mentioned. The main ones are Sinks, Channels, and Sources. 
In the Flume configuration Sinks provided by Flume can be referenced by 
their “simple” name because they are manually registered in the code. User 
provided components have to provide the whole fully qualified class name to 
be located. 

In addition, Flume components must locate their own configuration. 
This limits the format the configuration can take. For example, Flume currently 
uses properties but I would like to support JSON and YAML Due to the way 
property support was implemented it is difficult to support either of those 
without 
impacting users who have built custom components. This is where using injection 
does help. The plugins would be insensitive to the configuration format so 
making 
changes would just require changing how the configuration binds to the plugin 
system.

> - Based on the gathered knowledge on the previous point, what is the high
> level architecture of a plugin system the library will support and what
> services will it provide?

I think that is TBD. Although we have suggested starting from Log4j’s code, 
that 
isn’t a requirement. I would suggest that some experimental code be placed in a 
project and then whoever is interested can collaborate and debate the pros and 
cons. 
That is exactly how Log4j 2 got started.

Ralph


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

Re: New component proposal: commons-plugins

[Ralph Goers]

> On Apr 12, 2022, at 6:56 PM, Thomas  wrote:
> 
> 
> On 11.04.2022 00:00, Ralph Goers wrote:
>> See below
>> 
>>> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
>>> 
>>> Thanks Ralph for the detailed explanation. I appreciate it and now I see
>>> the points.
>> I’ve removed the parts that I don’t think need any more discussion.
>> 
>>> - How will it be a “plugin" project and not another dependency injection
>>> framework?
>> This is a great question. I think the main difference is with examples like 
>> Log4j
>> and Apache Flume, and even Apache Maven. All wire components together via
>> user provided configuration, not code. Dependency injection could certainly 
>> be
>> part of the plugin framework but that would be for implementors of plugins,
>> not the users using them. Users of Maven don’t know that Plexus is used under
>> the covers and neither should users of a commons-plugins implementation.
>> 
>>> - What will distinguish it from module systems, like OSGi and what will
>>> stop it from becoming another OSGi by the years as new features get added
>>> to the library.
>> OSGi is complicated. Implementing plugins should not be. Just as I described
>> using ServiceLoader to locate plugins, plugins should also be accessible in
>> OSGi bundles. Users should be required to do as little as possible to adapt 
>> the
>> plugin system to the environment it is running in*but plugins shouldn’t know 
>> or care anything about how they are located and loaded.* Plugins are also to 
>> the
>> application or framework that will be using them. They essentially define 
>> what
>> the valid plugin types are and where they can be used.
> 
> This is impossible. The bare minimum, any system or artifact has to do, to be 
> recognized as a plugin, is advertising itself as one. That would be true, 
> even if your service locator is crawling through every class of the 
> classloader it can get hold of to determine, whether it is a candidate to 
> consider.
> 
> - OSGI does this by parsing the MANIFEST and OSGI-INF
> 
> - Spring uses a combination of XML and crawling annotations and packages
> 
> Every other CDI framework does it similar to these two, most of them heavily 
> reliying on XML- or property based configuration too. With one notable 
> exception: the dreaded ServiceLoader mechanism, which fixes this during 
> compile time in the module-info, if you use JPMS, else mapping it in 
> META-INF/services with simple plain text files, that require no parsing other 
> then getting the line breaks right - no reflection / premature loading 
> required. (Which btw, I think is the slickest solution so far, as it does 
> make service discovery very cheap for small systems, with few class path 
> entries. Complication is inevitably the result of large classpaths, that 
> require plugin arbitration to resolve ambiguities and filtering)
> 
> So no: at the very least, a plugin has to know, by what plugin system it is 
> going to be loaded. And - a different hyperbole: because of this, apache 
> commons has started to introduce the attributes required by OSGi into the 
> MANIFESTs of many of its components, just to bridge the gap, and to aleviate 
> the need to for OSGi-Users to introduce wrappers.
> 
> For me, this will be all well and fine, as long as none of the current or 
> future apache commons artefacts will  become unusable unless I also put 
> commons-plugin or some arcane configuration parser into the class path.

I never said a plugin shouldn’t know it is a plugin. Providing the manifest 
entries required to make a component usable in an OSGi environment doesn’t mean 
the Plugin has to know it is being used in a an OSGi environment. Likewise, 
providing a module-info.java doesn’t mean the plugin will be used as part of a 
module on a module path. Using Log4j as an example once again, its Plugins know 
that they are a Filter, Appender, Lookup, Layout, or whatever. But they have no 
knowledge of how they were loaded. They DO know that they are being used by 
Log4j for a specific purpose and what contract they have to implement for that, 
but that is exactly what plugins are for.

So I guess Log4j is doing the impossible?  

Ralph

Re: [ALL] Eventually, soon, Java 11

[Ralph Goers]

The primary reason for moving to Java 11 is to fully support JPMS. Most 
libraries have added an automatic module name to the Manifest but that doesn’t 
really make it fully JPMS enabled.  

To be honest, the number of people I’ve seen asking for full JPMS support is 
quite small though.

Ralph

> On Apr 23, 2023, at 10:10 AM, Glavo  wrote:
> 
> I don't think upgrading to Java 11 is a very attractive proposition.
> There are not many language features introduced in Java 9~11,
> so there are not enough benefits to upgrade to Java 11.
> 
> The lifecycle of Java 11 is much shorter than that of Java 8.
> Premier support for Java 11 will end this year, and the extended support
> will
> also end in 2026, but Java 8 will be supported until 2030.
> 
> I think if we want to stop supporting Java 8, then we have no reason to
> continue
> supporting Java 11. We can skip Java 11 and use Java 17.
> 
> Next, we can prepare for Java 25, as Project Valhalla may be waiting for us
> there.
> 
> Glavo
> 
> On Sun, Apr 23, 2023 at 9:47 PM Gary Gregory  wrote:
> 
>> Hi All,
>> 
>> In the year 2023, and with Java 21 in EA (https://jdk.java.net/21/), I
>> think it is time to start migrating our components from Java 8 to Java
>> 11. I imagine this to happen slowly and surely over the course of this
>> whole year.
>> 
>> In addition, originally, it should also be time to update our GitHub
>> builds to run on Java 21-EA.
>> 
>> Gary
>> 
>> -
>> 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: [LOGGING] 2.0

[Ralph Goers]

> On Feb 13, 2024, at 3:39 AM, Piotr P. Karwasz  wrote:
> 
> If such a thing is even possible, it would be nice if we can get
> `jakarta.logging` as the package prefix.


Creating a Jakarta logging would certainly be possible. I am not certain if 
that follows the JCP process though since Jakarta is JEE.

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

Re: svn commit: r1658276 - in /commons/proper/csv/trunk: pom.xml src/test/java/org/apache/commons/csv/CSVBenchmark.java

[Ralph Goers]

JMH is a tool used during the build. The source code for the product does not 
depend on it. See http://www.apache.org/legal/resolved.html#prohibited 
.

Ralph


> On Feb 15, 2015, at 2:23 AM, Benedikt Ritter  wrote:
> 
> 2015-02-09 2:40 GMT+01:00 sebb :
> 
>> On 8 February 2015 at 23:47,   wrote:
>>> Author: ebourg
>>> Date: Sun Feb  8 23:47:27 2015
>>> New Revision: 1658276
>>> 
>>> URL: http://svn.apache.org/r1658276
>>> Log:
>>> Added a JMH benchmark to compare the most commons CSV parsers
>> 
>> -1
>> 
>> This has broken the Continuum build.
>> 
>> Also the JMH website says:
>> 
>> "The recommended way to run a JMH benchmark is to use Maven to setup a
>> standalone project that depends on the jar files of your application.
>> This approach is preferred to ensure that the benchmarks are correctly
>> initialized and produce reliable results. It is possible to run
>> benchmarks from within an existing project, and even from within an
>> IDE, however setup is more complex and the results are less reliable."
>> 
>> Further, it's not clear to me what the JMH license is.
>> It rather looks like GPL.
>> 
> 
> +1 for this change in general. It's far superior to the manual benchmark we
> had before.
> 
> Regarding the problems mentioned by sebb:
> 
> - Is the continuum build fixed already?
> - if we add further functionality, we will eventually end up with a multi
> module build that has modules like: core, beans, annotations, benchmarks.
> For now we should follow KISS and simply add it to the project until
> unresolvable problems show up.
> - regarding the license issue: since log4j seems to use it, I think we are
> on the save side. Maybe someone from the log4j team can comment (ping at
> bodewig, ggregory)
> 
> 
>> 
>>> Added:
>>> 
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVBenchmark.java
>> (with props)
>>> Modified:
>>>commons/proper/csv/trunk/pom.xml
>>> 
>>> Modified: commons/proper/csv/trunk/pom.xml
>>> URL:
>> http://svn.apache.org/viewvc/commons/proper/csv/trunk/pom.xml?rev=1658276&r1=1658275&r2=1658276&view=diff
>>> 
>> ==
>>> --- commons/proper/csv/trunk/pom.xml (original)
>>> +++ commons/proper/csv/trunk/pom.xml Sun Feb  8 23:47:27 2015
>>> @@ -73,6 +73,12 @@ CSV files of various types.
>>>   The Apache Software Foundation
>>> 
>>> 
>>> +  Emmanuel Bourg
>>> +  ebourg
>>> +  ebo...@apache.org
>>> +  Apache
>>> +
>>> +
>>>   Gary Gregory
>>>   ggregory
>>>   ggreg...@apache.org
>>> @@ -357,6 +363,112 @@ CSV files of various types.
>>> 
>>>   
>>> 
>>> +  
>>> +
>>> +  
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +  benchmark
>>> +
>>> +  
>>> +
>>> +  org.openjdk.jmh
>>> +  jmh-core
>>> +  1.5.2
>>> +  test
>>> +
>>> +
>>> +
>>> +  org.openjdk.jmh
>>> +  jmh-generator-annprocess
>>> +  1.5.2
>>> +  test
>>> +
>>> +
>>> +
>>> +  genjava
>>> +  gj-csv
>>> +  1.0
>>> +  test
>>> +
>>> +
>>> +
>>> +net.sourceforge.javacsv
>>> +javacsv
>>> +2.0
>>> +  test
>>> +
>>> +
>>> +
>>> +  com.opencsv
>>> +  opencsv
>>> +  3.1
>>> +  test
>>> +
>>> +
>>> +
>>> +  net.sf.supercsv
>>> +  super-csv
>>> +  2.2.1
>>> +
>>> +
>>> +
>>> +
>>> +  org.skife.kasparov
>>> +  csv
>>> +  1.0
>>> +  system
>>> +  ${basedir}/csv-1.0.jar
>>> +
>>> +  
>>> +
>>> +  
>>> +true
>>> +org.apache
>>> +  
>>> +
>>> +  
>>> +
>>> +  
>>> +  
>>> +maven-compiler-plugin
>>> +
>>> +  
>>> +**/*
>>> +  
>>> +
>>> +  
>>> +
>>> +  
>>> +  
>>> +org.codehaus.mojo
>>> +exec-maven-plugin
>>> +
>>> +  
>>> +benchmark
>>> +test
>>> +
>>> +  exec
>>> +
>>> +
>>> +  test
>>> +  java
>>> +  
>>> +-classpath
>>> +
>>> +org.openjdk.jmh.Main
>>> +-rf
>>> +json
>>> +-rff
>>> +target/jmh-result.json
>>> +${benchmark}
>>> +  
>>> +
>>> +  
>>> +
>>>   
>>> 
>>>   
>>> 
>>> Added:
>> commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVBenchmark.java

[lang] Re: releasing maintenance 2.2.1

[Ralph Goers]

Although it may be on the wrong list it probably is a good question for the git 
discussion regarding commons lang.  When Log4j 2 switched to git we didn’t have 
all the details for doing a release worked out. It turned out it wasn’t too 
much different than what we were doing with SVN, especially since we use the 
Maven release plugin.  If you have documentation on your current release 
process I suspect that you can pretty much just change the svn commands to 
their git equivalents.

Ralph


> On Mar 6, 2015, at 8:21 AM, Gary Gregory  wrote:
> 
> Yep, sorry!
> 
> Gary
> 
> On Fri, Mar 6, 2015 at 12:32 AM, Benedikt Ritter  wrote:
> 
>> Was this supposed to go to log4j?
>> 
>> 2015-03-06 0:45 GMT+01:00 Gary Gregory :
>> 
>>> Ralph,
>>> 
>>> How much work is it to cut an RC and push out a release for you ATM?
>>> 
>>> Are the instructions up to date?
>>> 
>>> Just curious as to opinions as to when we should release a maintenance
>>> release. What are the must haves for folks out there?
>>> 
>>> Thank you,
>>> Gary
>>> 
>>> --
>>> 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
>>> 
>> 
>> 
>> 
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>> 
> 
> 
> 
> -- 
> 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


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

Re: [DISCUSS] Rotate PMC Chair

[Ralph Goers]

I am perfectly happy to let Gary do it for another year.

Ralph

> On Mar 31, 2015, at 7:37 AM, Gary Gregory  wrote:
> 
> Hello all,
> 
> I am happy to continue to server our community and I am grateful for the
> opportunity. I am also happy to let someone else step in.
> 
> Gary
> 
> On Mon, Mar 30, 2015 at 11:50 PM, Benedikt Ritter 
> wrote:
> 
>> Hello,
>> 
>> we probably all agree, that Gary is doing a great job as our PMC chair.
>> Nevertheless, it is important to rotate important roles from time to time,
>> so that work is distributed on many shoulders.
>> I think we decided to discuss rotation every year during the time of the
>> annual member's meeting. Since the member's meeting took place last week,
>> it is time to ask Gary:
>> 
>> Do you want to continue being PMC Chair or do you want to resign from that
>> position?
>> 
>> Regards,
>> Benedikt
>> 
>> 
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>> 
> 
> 
> 
> -- 
> 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


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

Re: Missing release on reporter.a.o

[Ralph Goers]

It would seem that for each commons subproject you need to add the Jira project 
and specify a prefix (such as LANG, VFS) etc, so that you can associate the 
release numbers with the project name. Of course, I expect you actually have to 
have recorded the releases in Jira.

Ralph

> On May 11, 2015, at 5:39 PM, Gary Gregory  wrote:
> 
> I do not know much about it but Ralph Goers just fixed Log4j for us in this
> dept. You may want to ask him (on the log4j dev ML?)
> 
> Gary
> 
> On Sun, May 10, 2015 at 10:55 PM, Benedikt Ritter 
> wrote:
> 
>> If you're talking about [lang] 3.4, then I'm the one to blame :-) I had
>> problems using the reporter and didn't received feedback [1]. Then I forgot
>> to take care of that. Sorry! Maybe you can help me? If not, you can I get
>> in touch with?
>> 
>> Benedikt
>> 
>> [1] http://markmail.org/message/ooz5aw3x4tqiphsf
>> 
>> 2015-05-10 17:33 GMT+02:00 Gary Gregory :
>> 
>>> We have no 3.4 release under reporter.a.o. Any ideas why? You must be PMC
>>> member to view this site.
>>> Gary
>>> 
>>> 
>> 
>> 
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



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

Re: Missing release on reporter.a.o

[Ralph Goers]

I did it myself.

Ralph

> On May 11, 2015, at 10:54 PM, Benedikt Ritter  wrote:
> 
> Hello Ralph,
> 
> 2015-05-12 7:34 GMT+02:00 Ralph Goers  <mailto:ralph.go...@dslextreme.com>>:
> 
>> It would seem that for each commons subproject you need to add the Jira
>> project and specify a prefix (such as LANG, VFS) etc, so that you can
>> associate the release numbers with the project name. Of course, I expect
>> you actually have to have recorded the releases in Jira.
>> 
> 
> Yes we handle releases in JIRA. It's part of your release process [1]. Who
> do I have to get in touch with to associate the JIRA projects? The
> reporter.a.o website says that the service is owend by dev@community.a.o 
> <mailto:dev@community.a.o>
> but nobody responded to my request. Should I ask infra?
> 
> Thank you!
> Benedikt
> 
> [1] http://commons.apache.org/releases/release.html 
> <http://commons.apache.org/releases/release.html>
> 
> 
>> 
>> Ralph
>> 
>>> On May 11, 2015, at 5:39 PM, Gary Gregory 
>> wrote:
>>> 
>>> I do not know much about it but Ralph Goers just fixed Log4j for us in
>> this
>>> dept. You may want to ask him (on the log4j dev ML?)
>>> 
>>> Gary
>>> 
>>> On Sun, May 10, 2015 at 10:55 PM, Benedikt Ritter 
>>> wrote:
>>> 
>>>> If you're talking about [lang] 3.4, then I'm the one to blame :-) I had
>>>> problems using the reporter and didn't received feedback [1]. Then I
>> forgot
>>>> to take care of that. Sorry! Maybe you can help me? If not, you can I
>> get
>>>> in touch with?
>>>> 
>>>> Benedikt
>>>> 
>>>> [1] http://markmail.org/message/ooz5aw3x4tqiphsf
>>>> 
>>>> 2015-05-10 17:33 GMT+02:00 Gary Gregory :
>>>> 
>>>>> We have no 3.4 release under reporter.a.o. Any ideas why? You must be
>> PMC
>>>>> member to view this site.
>>>>> Gary
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>> <mailto:dev-unsubscr...@commons.apache.org>
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>> <mailto:dev-h...@commons.apache.org>

Re: Missing release on reporter.a.o

[Ralph Goers]

I did the same thing in log4j - I added stuff with no prefix originally. I have 
no idea how to remove that.

Ralph

> On May 12, 2015, at 6:38 AM, James Carman  wrote:
> 
> In case anyone comes across it, I was playing around and added Math twice,
> using two different prefixes (thinking it wouldn't actually add twice but
> change the prefix), so you'll see MATH-x and math-x releases both in
> there.  I'm trying to figure out how to clean it up.  Sorry for the noise.
> 
> On Tue, May 12, 2015 at 8:30 AM James Carman 
> wrote:
> 
>> I added Lang-3.4 to the reporter.a.o site by clicking on "Fetch releases
>> from JIRA" and selecting LANG as the JIRA project name and "Lang" as the
>> prefix.  That seems to have done the trick.  I'm asking about automating
>> this, but right now the answer is to do it manually.
>> 
>> 
>> On Sun, May 10, 2015 at 11:33 AM Gary Gregory 
>> wrote:
>> 
>>> We have no 3.4 release under reporter.a.o. Any ideas why? You must be PMC
>>> member to view this site.
>>> Gary
>>> 
>>> 



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

Re: [Math] Utilitzation of SLF4J?

[Ralph Goers]

I don’t normally participate in Math but I do feel the need to stick my nose in 
here.
1. You are absolutely correct to determine whether you need logging at all 
before discussing what to choose.
2. If you do decide logging is required:
  a. Please stay away from java.util.logging. It really would be the best 
solution for a framework like math except it is extremely difficult to redirect 
efficiently to some other logging framework. The methods used by SLF4J and 
Log4j are imperfect to say the least.
  b. Log4j 1.x has reached eol. It effectively has not been supported for 5 
years.
  c. Log4j 2 has an API that can be redirected to another logging framework if 
desired.
  d. Commons logging still works but its API is very primitive by todays 
standards. That said, it does work.

Ralph


> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
> 
> Le 26/09/2015 18:42, Gilles a écrit :
>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
 On 09/26/2015 01:11 PM, Gilles wrote:
> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>> On 09/26/2015 02:33 AM, Gilles wrote:
>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
 On 25 September 2015 at 16:47, Gilles 
 wrote:
 
> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
> 
>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
>> 
>> wrote:
>> 
>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>> On 9/25/15 7:03 AM, Gilles wrote:
 On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
> Hi Ole,
>> for a start, I think you are asking the wrong question.
>> First of all we need to agree that we want to add some kind of
>> logging
>> facility to CM.
>> If the outcome is positive, there are a handful of
>> alternatives,
>> some of
>> them more viable than slf4j in the context of CM (e.g. JUL or
>> commons-logging).
>> 
>> 
> Could someone summarize why those alternatives were deemed
> "more
> viable"?
> 
> btw. the same discussion has been done for other commons
> 
>> components as
>> well, and the result usually was: do not add logging
>> 
>> 
> What was the rationale?
> 
> 
 Look at the archives.  We have discussed this multiple times
 in the
 past in [math] and each time came to the conclusion that Thomas
 succinctly states above.  What has changed now?
 
 
>>> We also discussed several times to stick with Java 5.
>>> Fortunately, that has changed. [Although sticking with Java 7 is
>>> still
>>> a bad decision IMHO.]
>>> 
>>> As for logging, IIRC, the sole argument was "no dependency"
>>> because
>>> (IIRC) of the potential "JAR hell".
>>> 
>>> 
>> that's not correct. The decision to not include any
>> dependencies has
>> nothing to do with "JAR hell".
>> 
> Although I can't find it now, I'm pretty sure that I more than once
> got such an answer.
> 
> In order to prevent JAR hell, commons components strictly stick
> to the
>> "Versioning guidelines" [1]
>> 
> I can't see how it relates.
> But if you mean that no JAR hell can emerge from using a logging
> framework,
> then that's good news.
> 
> The no-dependency rule is more related to the proposal of the
> component,
>> see [2]
>> 
> Thanks for the reminder; in that document, we read:
> 
>  (1) Scope of the Package
>   [...]
>   5. Limited dependencies. No external dependencies beyond Commons
> components and the JDK
> 
> So we are fine if use "Log4j 2" as kindly offered by Gary.
>> log4j is not a commons component btw.
> Too bad for me. :-/
> Case resolved, then, by the argument of authority?
 I just pointed out that log4j is not a commons component and did not
 imply anything else.
 
> "Commons" is OK but not another Apache project, by virtue of a
> document that still refers to "JDK 1.2", "CVS", "Bugzilla" (not to
> mention that the "scope" of CM currently goes well beyond "the most
> common practical problems not immediately available in the Java
> programming language")...
> 
> What's the _technical_ rationale for accepting this dependency and
> not accepting that dependency?
> 
>> I have not seen a single example of a useful logging message that
>> could
>> be added to commons-mat

Re: [Math] Utilitzation of SLF4J?

[Ralph Goers]

The Log4j API has no dependencies.  Log4j-core only requires log4j-api.  It has 
lots of optional features and so has lots of optional dependencies, but none 
are required.

Ralph


> On Sep 26, 2015, at 1:09 PM, Luc Maisonobe  wrote:
> 
> Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
>> Le 26 sept. 2015 12:07, "Luc Maisonobe"  a écrit :
>>> 
>>> Le 26/09/2015 20:59, Ralph Goers a écrit :
>>>> I don’t normally participate in Math but I do feel the need to stick my
>> nose in here.
>>>> 1. You are absolutely correct to determine whether you need logging at
>> all before discussing what to choose.
>>>> 2. If you do decide logging is required:
>>>>  a. Please stay away from java.util.logging. It really would be the
>> best solution for a framework like math except it is extremely difficult to
>> redirect efficiently to some other logging framework. The methods used by
>> SLF4J and Log4j are imperfect to say the least.
>>>>  b. Log4j 1.x has reached eol. It effectively has not been supported
>> for 5 years.
>>>>  c. Log4j 2 has an API that can be redirected to another logging
>> framework if desired.
>>>>  d. Commons logging still works but its API is very primitive by
>> todays standards. That said, it does work.
>>> 
>>> From what I have seen, if I ever were to choose a logging framework for
>>> any project, I agree log4j 2 is currently the best choice. I was
>>> impressed by slf4j a few years ago, but think now the step further is
>>> log4j 2 (without any accurate reason, just a rough feeling).
>>> 
>> 
>> And in 2 years foolog4j will be better. JUL is not perfect for sure but
>> ensures:
>> - no dep
>> - always usable
>> - allows to let the user integrate with the lib without having to fork it
>> to get rid of a logging dep - think to tomee which consumes N commons deps,
>> if all uses a different logging framework it is worse to configure and
>> highly inconsistent - that is why we chose jul by default
>> 
>> That is for the logging framework choice.
>> Now commons shouldnt log much IMO otherwise it would start to loose commons
>> in sense of shareable component cause of the integration issues it
>> generates in the final application.
> 
> Big +1 to this. For the [math] case (and commons at whole), dependencies
> should be avoided. In fact looking at log4j pom (even the core pom) one
> can notice it depends on several commons components. This makes me think
> more and more that commons components are the lowest possible level,
> just above java itself.
> 
> So I think my message above was already out of scope. It may apply to
> some applications, but not to commons.
> 
> thanks for reminding me about that, Romain!
> 
> best regards,
> Luc
> 
>> 
>> - Romain
>> 
>>> best regards,
>>> Luc
>>> 
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe  wrote:
>>>>> 
>>>>> Le 26/09/2015 18:42, Gilles a écrit :
>>>>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>>>>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>>>>>>> On 09/26/2015 01:11 PM, Gilles wrote:
>>>>>>>>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>>>>>>>>>> On 09/26/2015 02:33 AM, Gilles wrote:
>>>>>>>>>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>>>>>>>>>>> On 25 September 2015 at 16:47, Gilles <
>> gil...@harfang.homelinux.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>>>>>>>>>>>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>>>>>>>>>>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>>>>>>>>>>>>>> Hi Ole,
>>>>>>>