Rahul Akolkar schrieb:
On Fri, Dec 19, 2008 at 7:41 PM, Ralph Goers wrote:
On Dec 19, 2008, at 4:29 PM, Rahul Akolkar wrote:
What OS and JVM? I ran it on my Mac with 1.5 and 1.6 as well as Ubuntu
with
Sun JDK 1.6 and did not see that.
Interesting. XP (and Sun 1.6, as already noted). Can
This is a vote for releasing Commons Configuration 1.6 based on the 2nd
release candidate.
Changes since RC1 are the following:
- Problems reported by the RAT report have been addressed.
- Some problems reported by findbugs have been fixed. Findbugs still
reports some issues, but the remaining
This vote is canceled. A new RC will be created.
Oliver
Oliver Heger schrieb:
This is a vote for releasing Commons Configuration 1.6.
A first release candidate was created, the artifacts (including release
notes and a clirr report) can be found here:
http://people.apache.org/~oheger
Ralph Goers schrieb:
On Dec 14, 2008, at 1:10 PM, Oliver Heger wrote:
Luc Maisonobe schrieb:
Oliver Heger a écrit :
This is a vote for releasing Commons Configuration 1.6.
A first release candidate was created, the artifacts (including release
notes and a clirr report) can be found here
All looks good except for the folder name used in the source
distribution: "commons-exec-2.4.1-src". I think this is caused by a
Maven bug, I've seen this before...
Another point is that I was not able to find your public key for
verifying the signatures. It does not seem to be in KEYS [1].
Ralph Goers schrieb:
On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
Ralph Goers schrieb:
The problem I have is with the interface. Forcing applications to use
AbstractHierarchicalConfiguration as the "base" configuration object
they code to is wrong, IMO. Either they shou
Luc Maisonobe schrieb:
Oliver Heger a écrit :
This is a vote for releasing Commons Configuration 1.6.
A first release candidate was created, the artifacts (including release
notes and a clirr report) can be found here:
http://people.apache.org/~oheger/configuration-1.6rc1/
When building
Ralph Goers schrieb:
On Dec 13, 2008, at 7:28 AM, Oliver Heger wrote:
There are of course configurations like MapConfiguration that are not
hierarchical by nature. The classes in the "flat" package provide a
hierarchical view on these classes. The idea is that when a
hierarc
This is a vote for releasing Commons Configuration 1.6.
A first release candidate was created, the artifacts (including release
notes and a clirr report) can be found here:
http://people.apache.org/~oheger/configuration-1.6rc1/
The site for 1.6 is also available at
http://people.apache.org/~
Ralph Goers schrieb:
On Nov 13, 2008, at 1:13 PM, Oliver Heger wrote:
Ralph Goers schrieb:
The problem is that in applications using commons config they would
like to specify an interface in lots of places.
HierarchicalConfiguration would be perfect for that. It should just
extend the
want to have a look or should
I deal with them?
Thanks
Oliver
Ralph
On Dec 3, 2008, at 1:11 PM, Oliver Heger wrote:
In the last weeks I put some energy in solving some of the open Jira
tickets. The list of changes and bug fixes since the 1.5 release is
now pretty long, so a new relea
In the last weeks I put some energy in solving some of the open Jira
tickets. The list of changes and bug fixes since the 1.5 release is now
pretty long, so a new release is more than justified.
Are there any specific wishes for features to be added in a 1.6 release?
Otherwise I would like to
+1
There are lots of checkstyle warnings, but I guess they are all uncritical.
Oliver
Rahul Akolkar schrieb:
This is a vote to release the following artifacts as Commons SCXML 0.9:
http://people.apache.org/builds/commons/scxml/0.9/RC1/
[ ] +1 for release
[ ] +0
[ ] -0
[ ] -1 f
pported by
this class have been converted to the new model.
Oliver
Ralph
Oliver Heger wrote:
Ralph Goers schrieb:
I've noticed that HierarchicalConfiguration isn't part of the
inheritance for the various hierarchical implementations. This seems
rather odd. What base class are appli
Ralph Goers schrieb:
I've noticed that HierarchicalConfiguration isn't part of the
inheritance for the various hierarchical implementations. This seems
rather odd. What base class are applications migrating to configuration2
supposed to convert all their references to? In fact, I'm wondering i
ralph.goers @dslextreme.com schrieb:
I don't understand why getSource throws an Exception when a property can be
found in multiple configurations. If the property is not a list or if
escaping is disabled then the value from the first Configuration the key is
found in will be used. Shouldn't an Ex
Jörg Schaible schrieb:
Hi,
Ralph Goers wrote:
I believe this is the only discussion on 2.0 I've seen on the
dev list.
I went and scanned the archives a while ago. Rereading this thread I
don't really see a decision to use an Abstract class. I'm not sure I
understand the discussion about which
James Carman schrieb:
On Fri, Oct 31, 2008 at 4:01 PM, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Ralph,
Ralph Goers wrote:
FWIW, I agree. I must have missed the earlier discussion as well. I
definitely prefer having an interface that can be used whenever a
specific implementation is not re
A while ago we discussed whether in Configuration 2.0 the fundamental
Configuration object should be an interface or an (abstract) class, and
- as usual ;-) - we could not agree on a way to go.
Therefore I suggest the following compromise:
We keep an interface - let's call it ConfigurationSource
+1
Oliver
Rory Winston schrieb:
Hi all
you know the drill, so I'll keep it short...
Tag:
https://svn.apache.org/viewvc/commons/proper/net/tags/NET_2_0_RC_5/
Site:
http://people.apache.org/~rwinston/commons-net-2.0/site/
Release notes:
http://people.apache.org/~rwinston/commons-net-2.0/RE
Ralph Goers wrote:
> Thanks, Oliver. My ICLA is already on file as I'm an ASF member and a
> committer on several Apache projects already.
>
> Ralph
Oh, that's of course even better :-)
Oliver
>
> Oliver Heger wrote:
>
>> Ralph Goers schrieb:
>>
Ralph Goers schrieb:
My company has recently switched from a proprietary configuration
framework to using Commons Configuration. I will need to submit some
enhancements, the first of which is Configuration 337. I would
appreciate it if someone could review it and apply it. One of the goals
o
+1
Artifacts look good, build works fine under JDK 1.6.
One nit: I think the release notes should be contained at least in the
binary distribution. And they should start with a short paragraph giving
an introduction into what the component does. Well, I leave the decision
to you and do not ve
+1
The only (very minor) inconsistency I found is in the manifests of the
jars: Only the main beanutils jar contains the entries for OSGI; they
are lacking in the core and the bean-collection jar.
Oliver
Niall Pemberton schrieb:
BeanUtils 1.8.0 RC3 is available for review here:
http://peopl
+1
Oliver
Matt Benson wrote:
> The codebase is available for perusal at:
>
> http://people.apache.org/~mbenson/flatfile-proposal/
>
> The IP clearance template has been started and is
> available at:
>
> http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/commons-fl
+1
(One strange effect: When building the site I got 161 checkstyle errors
with the message "File does not end with a newline.". This has probably
to do with different line endings on Windows and Unix (I am on Windows).
Of course no blocker.)
Oliver
Matt Benson schrieb:
Thanks to anyone wh
Hi George,
Georgi Yonchev schrieb:
Hi, list :)
I have couple of questions about XMLConfiguration, but the most
important is:
is it possible to add a CDATA in setProperty (some how)? because now
everything is escaped...
for me this is not a solution to "auto" escape all input values...
can you
Just to make sure I don't step on somebody's toes:
In the last two weeks I have created some patches for CLI2. I would like
to add myself as committer and go ahead and apply them. Any objections?
Oliver
-
To unsubscribe, e-ma
Emmanuel Bourg schrieb:
I wouldn't push for a 2.0 release in the current state, I'm not
convinced by the design of the new API. It seems more reasonable to
stabilize the 1.x branch before considering a major refactoring with CLI2.
As I understand it, CLI2 is currently in use. So there are peop
Henri Yandell schrieb:
On Sat, Jul 12, 2008 at 9:12 AM, Russel Winder
<[EMAIL PROTECTED]> wrote:
On Sat, 2008-07-12 at 16:02 +0100, Niall Pemberton wrote:
I saw from the following blog[1] that Hadoop is using CLI
2.0-SNAPSHOT, but they're considering rolling back (HADOOP-3676[2])
because of the
Are there any objections against switching to jUnit 4 on the
configuration2 branch?
Because the new version is backwards compatible we don't have to change
the existing tests. New tests however can be written in the 4.0 style.
Oliver
--
Everything looks fine, but a mvn site:site fails for me with the error
message "Embedded error: conf\findbugs-exclude-filter.xml (File cannot
be found.)" This file seems to be missing in the source distribution
(there is no conf directory at all).
Oliver
Matt Benson schrieb:
Thanks to anyone
sebb schrieb:
On 14/06/2008, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Oliver Heger <[EMAIL PROTECTED]> wrote:
> +1
>
> Artifacts look very good. I also ran the tests for
> commons configuration
> with the new version successfully.
>
> The only thing
Matt Benson schrieb:
--- Oliver Heger <[EMAIL PROTECTED]> wrote:
+1
Artifacts look very good. I also ran the tests for
commons configuration
with the new version successfully.
The only thing that makes me a bit uneasy is the
findbugs report showing
133 errors. Did you have a look at
+1
Artifacts look very good. I also ran the tests for commons configuration
with the new version successfully.
The only thing that makes me a bit uneasy is the findbugs report showing
133 errors. Did you have a look at those?
Oliver
Matt Benson schrieb:
Thanks to anyone who reported issue
+1
The artifacts look good to me, building in all variants on a JDK 1.6
succeeds.
WRT the site, I remember there was a discussion about the issues
reported by findbugs, so I think this is okay.
I had a problem when building the site using mvn site:site: The clirr
report gaves a fatal error
+1
Oliver
Niall Pemberton wrote:
> The main changes since RC1 are that the ant build now works on JDK 1.3
> and the Logging dependency has been upgraded to the latest 1.1.1
>
> The artifacts are here:
> http://people.apache.org/~niallp/chain_1_2_RC2/
>
> SVN Tag:
> http://svn.apache.org/viewvc/
+1
Build works fine on JDK 1.6, all artifacts look good.
The only minor nit I have is the checkstyle report containing 164
errors, but I guess this is of minor importance.
Oliver
Rahul Akolkar schrieb:
This is a vote to release the following artifacts as Commons SCXML 0.8:
http://people.
Just noticed that a test is failing on this branch (see below). Is there
a test configuration file missing?
Oliver
Results :
Tests in error:
testConfigurationBuilder(org.apache.commons.configuration2.TestDatabaseConfigu
ration)
Tests run: 1639, Failures: 0, Errors: 1, Skipped: 0
[INFO]
---
Luc Maisonobe wrote:
> Mauro Talevi recently proposed a new package for general linear
> regression (https://issues.apache.org/jira/browse/MATH-203). This patch
> needs Java 5, mainly for annotations.
>
> Mauro suggested to take the opportunity of the next [math] major version
> to switch to Java
Artifacts look good, build works in all variants on JDK 1.6. I tested
the new 1.3 jar with configuration and all tests succeeded.
So +1 from me.
Some minor remarks:
- When building with ant the resulting jar does not contain license and
notice. But I think, this is not a problem because ant is
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
I have added a new method to the NodeHandler interface for
distinguishing between the node types.
Great, will that work with the getKeys() iterator and the expression
engines ?
Yes, it should. A major part of the basic functionality provided by
Oliver Heger schrieb:
Emmanuel Bourg schrieb:
I'm trying to write a PreferencesConfiguration and I'm facing some
issues with the NodeHandler interface. NodeHandler assumes the
existence of container nodes and value nodes. However this is not true
for a Preferences tree, the
Emmanuel Bourg schrieb:
I'm trying to write a PreferencesConfiguration and I'm facing some
issues with the NodeHandler interface. NodeHandler assumes the existence
of container nodes and value nodes. However this is not true for a
Preferences tree, the only node available is a container node (t
Some comments:
- I wonder whether it is possible to implement the JNDINodeHandler so
that it directly operates on Context objects. The main reason why I
introduced NodeHandlers was that it would no longer be necessary to
implement specific node classes. This would also be more efficient in
te
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
The main reason for the restructuring of the packages was to increase
modularity, which is especially important in environments like OSGi
where you have fine control over the packages to import. An "all
configurations in the main pa
Emmanuel Bourg schrieb:
We have two classes in the main package, ConfigurationComparator and
StrictConfigurationComparator that are only useful for comparing the
configurations in the test cases, they are used nowhere else in the API.
I have personally never used theses classes and I wonder wha
+1
Artifacts look good.
On the site I found that the Javadoc (3.2.1 release) link in the main
menue does not work, but I assume it will when the site is deployed.
Oliver
Niall Pemberton wrote:
> The Sling project has requested an OSGi enabled release of Commons
> Collections and since it seems
Emmanuel Bourg wrote:
> Oliver Heger a écrit :
>
>>> XMLConfiguration and XMLPropertiesConfiguration remain in the main
>>> package.
>>
>> Why?
>
>
> The purpose of the package is to group only the SAX readers as they form
> a hierarchy provi
I noticed that MapConfiguration was almost identical to
BaseConfiguration. So I removed duplicate code and reimplemented it
based on BaseConfiguration in the experimental branch.
This change could also be ported to trunk.
Oliver
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
Would XMLConfiguration also go into this package?
XMLConfiguration and XMLPropertiesConfiguration remain in the main
package.
Why?
Oliver
In this regard the package name o.a.c.c.sax would make more sense.
Emmanuel Bourg
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
I would like to keep main package pretty small, so that it only
contains the basic interfaces and abstract base classes.
Sub packages would group classes with similar functionality. The plist
and web packages are good examples for that, but I
[EMAIL PROTECTED] schrieb:
Author: ebourg
Date: Mon Apr 7 10:24:32 2008
New Revision: 645622
URL: http://svn.apache.org/viewvc?rev=645622&view=rev
Log:
First stab at implementing a pluggable conversion system
- The Converter interface provides a general contract for transforming values,
a defa
Emmanuel Bourg schrieb:
+1 for removing the old configurations, otherwise that would be
confusing for the users.
Regarding the package structure do you have other plans besides the
'flat' package ?
I would like to keep main package pretty small, so that it only contains
the basic interfaces
Hi Hao,
I am one of the active committers for Commons Configuration. What you
write sounds very good, and I am pleased that you are interested in this
component.
I was not involved in the creation of the project proposal, so I don't
know the details. I think this was done by Emmanuel Bourg (
Jörg Schaible wrote:
> Oliver Heger wrote:
>
>>I have added new hierarchical configuration implementations
>>based on the
>>node handler approach.
>>
>>There is now a new AbstractHierarchicalConfiguration class
>>providing basic functionality
+1
Oliver
Henri Yandell wrote:
> Here's the Lang 2.4 RC3 for your delectation:
>
> http://people.apache.org/~bayard/staging/commons-lang-2.4-rc3/
>
> It's built from an export of
> https://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_2_4_RC3
> and the Ant build built fine for me un
I have added new hierarchical configuration implementations based on the
node handler approach.
There is now a new AbstractHierarchicalConfiguration class providing
basic functionality for dealing with hierarchical structures.
Derived from that is InMemoryConfiguration, which is almost equiva
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
Do we need to specify a date format?
Because a configuration file is not intended to be viewed or edited by
an end user we could define our own format (e.g. the format used by
the java.sql date types) and always use it for date <->
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
This looks pretty good to me. Just a question about the convert()
methods: What is the meaning of the params var arg parameter and where
do the actual values come from?
That's the same vararg used currently by PropertyConverter.to(), it&#x
Emmanuel Bourg schrieb:
Hi,
I've been working on the type conversion lately, it's almost complete, I
still have to refactor the unit tests and write the docs. Here is what I
plan to commit:
- A new Converter interface is introduced in the o.a.c.c.converter
package. This interface has a sing
package org.apache.commons.configuration2.expr;
import java.util.Collections;
import java.util.LinkedList;
@@ -48,10 +48,10 @@
* @since 1.3
* @author Oliver Heger
*/
-public class NodeAddData
+public class NodeAddData
{
/** Stores the parent node of the add operation. */
-priva
Okay, now it works for me. So +1 for the release.
Oliver
James Carman schrieb:
On 2/24/08, sebb <[EMAIL PROTECTED]> wrote:
Can you perhaps regenerate the sigs manually and upload them so we can
re-check them?
Done. Sorry about the mix-up. I should have verified them myself. I
think what
The artifacts look good to me. Everything is fine, but I had a problem
with veryfying the signatures.
I am not sure whether I have imported the correct key of James because
there have been some commits to KEYS later on. So this may be a problem
with my setup. Did anybody else check the signatures?
James Carman schrieb:
On 2/20/08, Oliver Heger <[EMAIL PROTECTED]> wrote:
Niall Pemberton schrieb:
I'm +0 on this release because I like to review the actual artifacts
> that are going to be distributed. The distros IMO meet ASF release
> requirements but if I run comma
Emmanuel Bourg schrieb:
Emmanuel Bourg a écrit :
I haven't seen this error, could this be a conflict with your JDK and
a Xerces lib somewhere in your classpath ?
Actually I reproduced the same error by switching to JDK 1.6, it works
fine with JDK 1.5.
Emmanuel Bourg
Yes, I can confirm thi
Niall Pemberton schrieb:
I'm +0 on this release because I like to review the actual artifacts
that are going to be distributed. The distros IMO meet ASF release
requirements but if I run command "mvn -Prc site assembly:assembly"
then the binary distro created also includes the javadocs and also
-
Luc Maisonobe schrieb:
Oliver Heger a écrit :
The distributions look good. All build variants worked for me on a JDK
1.6.
Regarding the site: The clirr report shows some errors. According to
the release notes there are no binary incompatible changes. Is this okay?
Yes. Clirr flags as
Emmanuel Bourg schrieb:
Hi,
I noticed that several tests fail on the 2.x branch since the removal of
the commons collections dependency. We now have digester 1.8 and
beanutils 1.7 which should work fine without commons collections, but I
keep getting a NoSuchMethodError on running the tests w
The distributions look good. All build variants worked for me on a JDK 1.6.
Regarding the site: The clirr report shows some errors. According to the
release notes there are no binary incompatible changes. Is this okay?
A minor point are the 292 checkstyle errors.
Oliver
Phil Steitz schrieb:
sebb schrieb:
On 17/02/2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote:
Oliver Heger a écrit :
This commit contains a lot of noise related to formatting changes. This
makes it very difficult to find out what you actually changed.
Can you please try to minimize reformatting as much as po
Emmanuel Bourg schrieb:
sebb a écrit :
The static DateFormat is not private, so the synchronization is not
guaranteed.
I'll make it private. I added a comment mentioning that it must be
synchronized.
Likewise the instance DateFormat.
Indeed that is worse, since the format is temporarily
This commit contains a lot of noise related to formatting changes. This
makes it very difficult to find out what you actually changed.
Can you please try to minimize reformatting as much as possible?
Thanks
Oliver
[EMAIL PROTECTED] schrieb:
Author: ebourg
Date: Sat Feb 16 16:20:15 2008
New Re
In most points I agree. Some comments below:
Emmanuel Bourg schrieb:
Hi,
I'd like to open the discussion on the changes we'll implement on the
2.x branch. Here is a list of the things I have in mind :
Cleanup
- Remove ConfigurationFactory, its use is deprecated since the
introduction of C
With regards to the build files: I was thinking about dropping the maven
1 build at all and make maven 2 to the default build tool. An ant build
could still be provided, but hopefully it is possible to generate
build.xml from the pom.
Oliver
[EMAIL PROTECTED] schrieb:
Author: ebourg
Date: Th
I can't remember that there was a consensus to switching to
java.util.logging.
I would really prefer if you could discus such changes first before
committing. Especially because your contributions had not been on a
regular basis in the past.
Oliver
[EMAIL PROTECTED] schrieb:
Author: ebourg
Henri Yandell schrieb:
On Jan 17, 2008 1:17 PM, Oliver Heger <[EMAIL PROTECTED]> wrote:
Henri Yandell schrieb:
Should the DatabaseConfiguration class be responsible for protecting
against SQL Injection, or should we make sure the javadoc states that
it offers no protection and leave t
+1
The build works for me in all variants as expected (on JDK 1.6). The
only minor nit I have is that the Copyright in the Javadocs still looks
a bit wired (at least on my browser): Instead of the Copyright character
I only get a "?".
Oliver
Jochen Wiedmann schrieb:
Hi,
I have prepared a
+1
Oliver
Niall Pemberton schrieb:
The changes since RC2 are:
- Separate out tests requiring JDK 1.4 and change ant build to run
tests depending on JDK version
- Correct m1 and ant builds to use the same "target" option as the m2 build
The artifacts are here:
http://people.apache.org/~niall
Henri Yandell schrieb:
Should the DatabaseConfiguration class be responsible for protecting
against SQL Injection, or should we make sure the javadoc states that
it offers no protection and leave that up to the user?
Hen
Adding a note about this topic to the documentation would certainly do
I found no problems with the artifacts. All build variants worked for me
on JDK 1.6. The only thing I noticed is that the md5 files do not follow
the default format used for most commons components (they do not contain
the flags and the file name).
The argument with the JDK 1.3 compatibility t
The artifacts look good, the build also succeeded in all variants (on a
JDK 1.6). So I am +1 for this release.
Two minor points:
- On my first attempt to build with maven 2 I got the test failure
below. However this was not reproducable, further builds succeeded. Has
anybody else seen this?
The artifacts look all good to me.
So if a solution/consensus for the problems with NOTICE is found, I am
+1 for this release.
Oliver
Jochen Wiedmann wrote:
> Hi,
>
> I have prepared a third release candidate of commons-fileupload
> 1.2.1. A list of changes since rc2 and things that I haven't c
The source distros look okay, but can it be that the binary distros are
missing the binaries? Both the zip and the tar.gz only contain LICENSE
and NOTICE and the site directory.
Other than that I only found a few (very minor) points:
- When building with the different build systems the resulting j
[EMAIL PROTECTED] wrote:
> Author: rahul
> Date: Sun Dec 30 11:01:33 2007
> New Revision: 607578
>
> URL: http://svn.apache.org/viewvc?rev=607578&view=rev
> Log:
> Fix 404. Suggestion for better pointer welcome.
>
> Modified:
> commons/proper/commons-build/trunk/xdocs/components.xml
>
> Modi
Hi,
the artifacts look good to me. I found the following issues:
- The pom.xml is missing the license header.
- The maven 1 build declares its version as 1.3-SNAPSHOT and has a
dependency to commons-io 1.4-SNAPSHOT. In the section an
element for the current release is missing.
- The ant bu
+1
Oliver
Rahul Akolkar wrote:
This is a vote for releasing the following artifacts as Commons SCXML 0.7:
http://people.apache.org/~rahul/commons/scxml-0.7/rc2/
[ ] +1 for release
[ ] +0
[ ] -0
[ ] -1 for release because...
Vote closes no sooner than Tuesday, Dec 1
Jörg Schaible wrote:
Oliver Heger wrote:
(There was a similar discussion about commons lang recently.)
Configuration used to support JDK 1.3. For the next release (either
1.6 or 2.0) I would like to drop this compatibility. The number
of feature
requests that require a newer JDK version is
(There was a similar discussion about commons lang recently.)
Configuration used to support JDK 1.3. For the next release (either 1.6
or 2.0) I would like to drop this compatibility. The number of feature
requests that require a newer JDK version is increasing.
This raises a couple of questio
Everything looks good to me.
Oliver
Rahul Akolkar wrote:
I've incorporated Sebb and Niall's feedback on RC1 and produced RC2.
Tag:
http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_7_RC2/
Artifacts:
http://people.apache.org/~rahul/commons/scxml-0.7/rc2/
Staged site:
htt
Hi,
(I am not an active CLI committer, but have some interest in this
component.)
The best way of providing patches is by creating a new ticket in our bug
tracking system Jira [1]. This guarantees that the stuff won't get lost
in the high traffic of the mailing list.
Thanks
Oliver
[1] http://co
can be found at the
Configuration main site at
http://commons.apache.org/configuration/
The changes report contains a list with all changes since the last
release and is available at
http://commons.apache.org/configuration/changes-report.html
Oliver Heger
on behalf of the Commons community
with the correct path and create new checksums? Or should I do a
complete release cycle once more?
Strange. However a new release cycle is not necessary IMO.
Oliver
Oliver Heger wrote:
Sorry, just noticed one more thing: The source distributions unpack in
a directory "commons-logging-
Sorry, just noticed one more thing: The source distributions unpack in a
directory "commons-logging-2.4.1-src". This version number is really
future-proof ;-)
Oliver
Oliver Heger wrote:
Dennis Lundberg wrote:
Oliver Heger wrote:
+1
Some minor remarks (which are not too probl
Dennis Lundberg wrote:
Oliver Heger wrote:
+1
Some minor remarks (which are not too problematic IMO):
- The format of the md5 files is a bit unusual. Other components
typically use a format like
f88520ed791673aed6cc4591bc058b55 *commons-logging-1.1.1-bin.zip
I created them on people.a.o
+1
Some minor remarks (which are not too problematic IMO):
- The format of the md5 files is a bit unusual. Other components
typically use a format like
f88520ed791673aed6cc4591bc058b55 *commons-logging-1.1.1-bin.zip
- When building the source distribution with maven2 LICENSE and NOTICE
are n
The vote for releasing Commons Configuration 1.5 has passed with the
following votes:
+1:
Niall Pemberton (*)
Ben Speakmon
Jörg Schaible (*)
Rahul Akolkar (*)
Nicolas de Loof
Oliver Heger (*)
(*) = binding votes
There were no other votes.
Thanks to all who participated in the vote and
For the records: Here is my +1.
Oliver
Oliver Heger wrote:
Here is the 3rd (and hopefully last) attempt for the release vote for
Commons Configuration 1.5.
The artifacts of the release candidate can be found at
http://people.apache.org/~oheger/commons-configuration-1.5rc3/
The site is
Don't know how important this is, but the "Implementation-Version:"
entry in the manifests of the jars seems to be incorrect. It runs
"1.1.1-SNAPSHOT".
Building the source distribution with maven 1 and 2 works for me,
however the artifacts produced by maven 1 also have the -SNAPSHOT suffix.
Here is the 3rd (and hopefully last) attempt for the release vote for
Commons Configuration 1.5.
The artifacts of the release candidate can be found at
http://people.apache.org/~oheger/commons-configuration-1.5rc3/
The site is available under
http://people.apache.org/~oheger/commons-configurati
901 - 1000 of 1045 matches
Mail list logo
