, and bar gets initialized to
null twice. So there is a minor inefficiency. This style of coding is a
hold-over from C/C++ style coding, and it shows that the developer isn't
really confident that Java really initializes instance variables to
default values.
Emmanuel bourg
Le 28/11/2013 13:01, Gary Gregory a écrit :
This backward IMO and an anti-pattern: an interface should only define a
contract for a service, not constants.
I know, but that's more idiomatic than a class with only public static
final fields.
The class is private now, so it doesn't matter
bridge, but I don't know how they implemented that.
https://github.com/blog/1178-collaborating-on-github-with-subversion
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail
Le 27/11/2013 11:46, Gilles a écrit :
Do we really have to allow them? Or do they have the right to do as
they please?
Well, I thought after the last vote/discussion about Git that we had a
consensus to experiment with Git at a component level.
Do we want to vote formally for cli?
Emmanuel
stash pop
This is enough to get started. You can then learn gradually how to play
with branches, tags, remotes.
http://git-scm.com/book
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
Le 27/11/2013 19:50, Gary Gregory a écrit :
The next step IMO would be to break the ant-pattern for good and change
types like ImagingConstants from interfaces to classes (or enums if
appropriate).
Yes I plan to look into that. The MapString, Object to pass parameters
to the parsers isn't
indeed. I prefer having the current developments on
the master branch and create topic branches to experiment with more
involved changes. I don't think we have enough active developers per
component to require a more sophisticated model.
Emmanuel Bourg
.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 26/11/2013 14:42, Benedikt Ritter a écrit :
What's the point of using git then?
To provide a better collaboration tool for the external contributors,
and thus increasing the external contributions?
Emmanuel Bourg
Le 26/11/2013 17:48, Damjan Jovanovic a écrit :
Why are we excluding those? Final variables are a good thing.
Yes but final everywhere is a bit extreme and makes the code too verbose.
Emmanuel Bourg
-
To unsubscribe, e-mail
and increase the verbosity
of the code, for example:
public ImageReadException(final String message) {
super(message);
}
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands
API.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
What about experimenting the migration to Git with cli?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
to run a
successful project.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
of:
PredicateFoo predicate = FalsePredicate.INSTANCE;
This will fail to compile.
I suggest declaring the INSTANCE fields as ungenerified Predicates, such
that the above example compiles with an unchecked warning. That's
similar to the EMPTY_LIST and similar constants in java.util.Collections.
Emmanuel Bourg
Also, I'm +1 for the release if this can be fixed later without breaking
the compatibility.
Emmanuel Bourg
Le 20/11/2013 10:45, Emmanuel Bourg a écrit :
After an ultimate round of code review I have another observation
regarding the functor API.
In FalsePredicate the INSTANCE singleton
:
http://qa.debian.org/popcon.php?package=libcommons-logging-java
http://qa.debian.org/popcon.php?package=libslf4j-java
We'll soon have an opportunity to improve commons-logging while
preserving backward compatibility thanks to the default methods in Java 8.
Emmanuel Bourg
)
Emmanuel Bourg
[1]
http://people.apache.org/builds/commons/collections/4.0/RC2/release_4_0.html
Le 08/11/2013 10:59, Thomas Neidhart a écrit :
Hi,
I'd like to call a vote for releasing Commons Collections 4.0 based on RC2.
Changes since RC1:
* release notes are now also included
to get 100%
test coverage on a library that exists for 10 years only by myself.
Ok for classes like ComparatorUtils, but some of the cases I mentioned
are new.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
What about our own dog food?
http://commons.apache.org/primitives/
Emmanuel
Le 06/11/2013 02:39, Gary Gregory a écrit :
Hi All:
I'm looking for a Map implementation that takes a String as a key and a
long as the value (and another taking a double as the value). I'd rather
not take the
Le 24/10/2013 15:17, Gary Gregory a écrit :
Committed revision 1535372.
Isn't the trademark on Apache Commons Configuration and not just
Commons Configuration ? If we don't use Apache of the feather in the
logo I'm not sure it qualifies for a TM symbol.
Emmanuel Bourg
the strong crypto is not installed.
Emmanuel Bourg
[1]
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
Le 23/10/2013 06:56, Stefan Bodewig a écrit :
Compress 1.6 RC3 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress
Le 22/10/2013 00:33, Mark Thomas a écrit :
On 21/10/2013 23:31, Emmanuel Bourg wrote:
Thatis using Fileupload as a noun which isn't the correct usage of the
trademark.
But how is it different from Apache Tomcat or Apache Qpid? We don't
say The Apache Tomcat component or The Apache Qpid
to servlets and web applications.
I would either say The Foo component or Apache Commons Foo, but The
Apache Commons Foo component is a bit a mouthful.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
Le 21/10/2013 19:37, sebb a écrit :
the component name must not be used as a noun.
Must not? Why that? It is a noun, that's how people name it.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
flexible...
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
these days? :-) ).
Welcome back Henning! :) +1 for a maintenance branch of configuration 1.x
The release documentation you are looking for is there:
http://wiki.apache.org/commons/UsingNexus
Emmanuel Bourg
-
To unsubscribe, e-mail
://central.maven.org/maven2/commons-configuration/commons-configuration/1.9/commons-configuration-1.9-sources.jar
The files generated by JavaCC have this header:
/* Generated By:JavaCC: Do not edit this line. x.java Version 5.0 */
Emmanuel Bourg
Le 17/10/2013 13:03, Jonathan Bernwieser a écrit :
Hi
+1
If a new RC is needed I would suggest looking at SevenZOutputFile, there
are several chunks of untested code:
http://people.apache.org/~bodewig/cc-1.6/site/cobertura/org.apache.commons.compress.archivers.sevenz.SevenZOutputFile.html
Emmanuel Bourg
Le 15/10/2013 20:26, Stefan Bodewig
only,
otherwise you catch the pom/doap updates.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 15/10/2013 14:35, Gary Gregory a écrit :
the web site can say last released on -mm-dd, no new
releases planned.
I like this idea, but unless you automate the site update it adds an
extra manual step to the release process.
Emmanuel Bourg
also encourage people to review more the functional aspects of
the release (e.g. are the new features properly tested? Does the API
look right?) than commenting on the PMD/Checkstyle reports.
Emmanuel Bourg
-
To unsubscribe, e
Le 14/10/2013 02:48, Gary Gregory a écrit :
One small step for man, one giant leap backward for mankind ;)
Should we vote to migrate back to Bugzilla then ? ;)
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
a major release.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
preserving the
repositories read only.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
+1
Emmanuel Bourg
Le 09/10/2013 17:21, Emmanuel Bourg a écrit :
This is a vote to release Apache Commons JCI 1.1 based on RC1.
This is a bug fix release and an update to work with more recent
versions of its dependencies.
Tag:
http://svn.apache.org/repos/asf/commons/proper/jci/tags
This vote passes with five +1 votes from the following people:
Olivier Lamy
James Carman
Torsten Curdt
Matt Benson
Emmanuel Bourg
Thank you for your reviews, I'll proceed with the release.
Emmanuel Bourg
Le 09/10/2013 17:21, Emmanuel Bourg a écrit :
This is a vote to release Apache Commons
Thanks to the infra team we now have JIRA and svn commit notifications
on the channel. Enjoy :)
Emmanuel Bourg
Le 10/10/2013 18:15, James Carman a écrit :
As a reminder, we do have an IRC channel set up on freenode. It's
#asfcommons. Matt Benson and I are usually the only ones hanging out
/
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
for projects.
Do we want to switch?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
, but scxml
isn't in Debian yet and I'm updating the packages to use Maven instead.
So go for it.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
and
pull the artifacts from /usr/share/maven-repo instead of Maven Central.
It also patches the pom.xml at the beginning of the build to adjust the
version of the dependencies to the ones available in Debian.
For non official packages I just use jdeb [3].
Emmanuel Bourg
[1] https://wiki.debian.org
reports, patches, or suggestions for improvement, see the
Apache Commons JCI website:
http://commons.apache.org/jci/
Emmanuel Bourg, on behalf of the Apache Commons community
signature.asc
Description: OpenPGP digital signature
creating tag manually? I believe release plugin does it.
I'm just not used to it, so I picked the safest solution for me. This is
where the test component will be useful, it will allow new release
managers to experiment with the tools involved.
Emmanuel Bourg
The parent pom currently attaches the -bin and -src archives to the
deploy phase, which means we have to delete them manually in Nexus.
Can we agree to change that?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
commons-jci-core 1.1.
There is no risk of jar hell in this case.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
:
org.apache.commons.experimental.csv8
org.apache.commons.experimental.csv9
The package translation could probably be automated by the shade plugin,
such that we keep developing with the org.apache.commons.csv package.
Emmanuel Bourg
-
To unsubscribe, e
of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
in Thunderbird the vote thread is distinct.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 10/10/2013 16:57, Gary Gregory a écrit :
Could you please restart the thread with a [VOTE] in the subject?
There is one though:
http://www.mail-archive.com/dev@commons.apache.org/msg40574.html
Emmanuel Bourg
and besides for tagging I didn't have to interact much with SVN (I
didn't use the Maven release plugin).
With Git you would just have to create a branch, and push a commit that
changes the version (1.0-SNAPSHOT - 1.0). The rest of the procedure is
the same.
Emmanuel Bourg
be free to cut a release at any
time.
Ah sure, excellent idea. You may want two projects then, a simple one
and another with modules.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
commons-jci-core 1.1
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Commons SCXML has only one reverse dependency in Maven Central,
flexistate, so I wouldn't bother with the binary compatibility and just
keep the package as is.
http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9
Emmanuel Bourg
There is a note about the site deployment in the parent pom and I wonder
if it's still relevant:
Site deployment
===
Cannot define this here at present, see
https://issues.apache.org/jira/browse/COMMONSSITE-26.
The following should be added to the component POM:
the pom as much as I could, but most reporting plugins
still have to be redeclared to specify the aggregate property.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
candidate and vote.
This vote will close no sooner that 72 hours from now.
[ ] +1 Release it!
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thank you for your reviews,
Emmanuel Bourg
signature.asc
Description: OpenPGP digital signature
, you can ignore it.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
shouldn't be instantiated outside of JCI so the impact is negligible.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
processes:
- no separate ACLs to manage proper/sandbox permissions
- no need to move the sources in the repository upon promotion
- no need to modify the links on the site
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
if we stay with SVN.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
.
Some incompatible changes are much less risky than others. For example,
adding a new method in an interface released less than 6 months ago
shouldn't be vetoed, but renaming public methods in a code that has been
in the wild for years shouldn't happen.
Emmanuel Bourg
is near to zero (it's just a link to it's
repo).
I don't think using SVN is a barrier to private modifications like this.
People just fork the mirror on Github, or import the code with git-svn.
Emmanuel Bourg
-
To unsubscribe
the compatibilities, and this is causing pain and
wasting time to a lot of smart people.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
The Eclipse compiler now supports source/target 1.7
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 08/10/2013 16:04, James Carman a écrit :
Are there any other features of JDK8 that we think could be
used by our projects?
You may want to rethink [functor] in a Java 8 context.
Emmanuel Bourg
-
To unsubscribe, e-mail
Le 08/10/2013 18:29, Benedikt Ritter a écrit :
there was this issue with the failing test related to the eclipse compiler.
Can you comment on this? Is it fix? If it's broken, should we document it?
As I understand it already exists in JCI 1.0, so nothing new on this side.
Emmanuel Bourg
] BUILD ERROR
[INFO]
[INFO] Error assembling JAR
Embedded error: Manifest file: /home/ebourg/jci/target/osgi/MANIFEST.MF
does not exist.
Any idea?
Emmanuel Bourg
?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 08/10/2013 21:25, sebb a écrit :
However, there are other commons components with multiple modules; it
should be possible to get some clues from them.
Thank you for the suggestion, I found the solution in vfs.
Emmanuel Bourg
I made some progress but I still have an issue with 'mvn site', see
http://apaste.info/pOvS
Again, any idea is welcome.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
.
As veteran ASF committers I trust them to work directly on proper.
Emmanuel Bourg
signature.asc
Description: OpenPGP digital signature
to post process the classes with Ant and Maven.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
doesn't tell much about the purpose of the component and
how it's supposed to be used.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
+1
Emmanuel
Le 20/09/2013 19:49, Matt Benson a écrit :
Hi Commons developers,
I hereby propose a vote to promote the [weaver] sandbox component to
Commons proper. My intent is that the promotion would be followed by a
release of Apache Commons Weaver v1.0.
This vote will be open for at
it be possible to use an UnmodifiableMap for headerMap? That would
avoid the need to copy the map on calling getHeaderMap().
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
Le 18/09/2013 21:32, Benedikt Ritter a écrit :
Furthermore the contributor should be added to pom.xml and changes.xml.
Isn't this a bit far fetched for a one line NPE check?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev
Le 15/09/2013 21:05, Michele Rossi a écrit :
If values() was public I could use the data read from one CSV to directly
feed another CSV.
Hi Michele,
Thank you very much for the feedback. Would a printRecord(CSVRecord)
method in CSVPrinter help solving your issue?
Emmanuel Bourg
.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
weird to me. It should be prefixed when it really makes sense.
'Quote' is short and not likely to conflict with other classes (unlike
Parser and Format). I would keep it as is.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
Le 14/09/2013 11:27, sebb a écrit :
There is one other inconsistency that might be worth addressing: all
the classes are final apart from CSVFormat.
Should it be final? If not, the reason needs documenting as it is
different from the rest of the code.
+1 for making CSVFormat final.
Emmanuel
Le 14/09/2013 13:14, Benedikt Ritter a écrit :
Like http://svn.apache.org/r1523213 ?
Yes, thank you for enhancing the documentation.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
as the
exception message is explicit.
Emmanuel Bourg
signature.asc
Description: OpenPGP digital signature
+if (parameter == null) {
+throw new IllegalArgumentException(Parameter ' +
parameterName + ' must not be null!);
+}
+}
+}
Isn't a null value supposed to throw a NPE ?
Emmanuel Bourg
like:
Integer columnInt = to(Integer.class, record.getValue(1));
That being said, [convert] could offer several patterns to perform type
conversion, and the use of proxies could be one of them.
Emmanuel Bourg
to figure it was caused by a
null value if no NPE is thrown.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
]
* getCurrentLineNumber() : to be moved into CSVRecord?
* getHeaderMap() : removed or moved into CSVRecord?
* getRecordNumber() : already available in CSVRecord
* getRecords() : to be removed. I guess [collections] or [lang] already
has a method turning an Iterable into a List?
Emmanuel
Thank you for pointing this, I didn't notice this recent addition.
I'm not fond of the parseType(Type t) methods, I'd prefer parse(Type t).
Btw I would have kept these methods out of csv 1.0, this is again
delaying the release with another discussion...
Emmanuel Bourg
Le 08/08/2013 10:24
rather keep
the resource management out of CSVParser.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
realize they could belong to CSVFormat, because
they all need one to operate.
format.parse(file):
instead of:
CSVParser.parse(file, format);
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
Le 08/08/2013 16:27, Benedikt Ritter a écrit :
A format can parse something... That sounds strange to me.
That's pretty common though. NumberFormat, DateFormat are good examples.
Let's rename it to
format.createParser(file)
Please, no :)
Emmanuel
at this point though.
CSVFormat will be the only place to create CSVParsers.
Plus the constructor of CSVParser of course.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail
with other components and force the users to
write the fully qualified class name. For example we already have a
Parser class in [cli], [jexl] and [jxpath]. Format also exists in java.text.
Emmanuel Bourg
-
To unsubscribe, e-mail
wrapping. I usually restrain myself to 120 columns for
the code and 80 columns for comments.
Feel free to reformat as you like, you are reading this code more
frequently than I do.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev
.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Le 05/08/2013 23:59, Gary Gregory a écrit :
Do we want to do anything about this for 1.0? 1.x? Ever?
I'm fine with the IOException, I suggest closing this issue.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr
Le 05/08/2013 19:34, Gary Gregory a écrit :
Thoughts?
-0, that's not very friendly to people willing to extend [csv].
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
class: CSVFormat.Quote.
- I personally, prefer the prefix Csv, but I might be in the minority
here.
I believe we have already discussed this, the upper case variant is more
common for short acronyms.
Emmanuel Bourg
Le 06/08/2013 18:47, Gary Gregory a écrit :
Thoughts?
Well, it's invisible to the end user. Feel free to rename it
YodaBufferedReader if you want :)
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
501 - 600 of 1071 matches
Mail list logo