Hi,
while looking through the Gump setup for JCS I realized the artifactId
inside the POM had been changed to commons-jcs while the groupId still
is org.apache.jcs. Does it make sense to keep the old groupId when
you change the artifactId anyway?
Stefan
IMHO unless the main package name has to change due to binary
incompatibilities in the new version I would stick to the original
groupId/artifactId (ie org.apache.jcs/jcs).
Emmanuel Bourg
Le 12/08/2011 08:41, Stefan Bodewig a écrit :
Hi,
while looking through the Gump setup for JCS I
On 2011-08-12, Emmanuel Bourg wrote:
IMHO unless the main package name has to change due to binary
incompatibilities in the new version I would stick to the original
groupId/artifactId (ie org.apache.jcs/jcs).
I agree with you. But if jcs changes the artifactId (which has happened
in trunk)
Emmanuel Bourg wrote:
IMHO unless the main package name has to change due to binary
incompatibilities in the new version I would stick to the original
groupId/artifactId (ie org.apache.jcs/jcs).
+1
otherwise Stefan is right and we can adjust the groupId also.
- Jörg
I've just noticed this thread.
I'd like to ask those involved to consider if they can find a route
where the package name and group do *not* change.
- Changing to JDK 5 does not require a a package name change (generics
are backward compatible if the erased signatures don't change).
- Removing
Stefan Bodewig wrote:
On 2011-08-12, Emmanuel Bourg wrote:
IMHO unless the main package name has to change due to binary
incompatibilities in the new version I would stick to the original
groupId/artifactId (ie org.apache.jcs/jcs).
I agree with you. But if jcs changes the artifactId
Hi,
.xz is to LZMA what .gz is to the DEFLATE compression algorithm, and it
starts to get used by quite a few tools/systems in the Unix/Linux
world. For example more recent GNU tar versions use -J to support the
format (like -z for gzip and -j for bzip2), the GNU core utils come
with an xz
We basically have two options:
* forking the required classes of XZ in Java into Compress (Lasse
already has a CLA on file and I'm sure we could arrange for the two
code bases to stay in sync)
* add a (optional) binary dependency on XZ in Java. Currently the
package is not available
On 2011-08-12 Stefan Bodewig wrote:
the GNU core utils come with an xz command
Minor correction: GNU coreutils doesn't include compression tools.
GNU gzip is its own package and so are bzip2 (bzip.org) and xz
(tukaani.org).
--
Lasse Collin | IRC: Larhzu @ IRCnet Freenode
On 2011-08-12, Lasse Collin wrote:
On 2011-08-12 Stefan Bodewig wrote:
the GNU core utils come with an xz command
Minor correction: GNU coreutils doesn't include compression tools.
GNU gzip is its own package and so are bzip2 (bzip.org) and xz
(tukaani.org).
Thank you.
Stefan
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-configuration has an issue affecting its community integration.
On 12 August 2011 08:37, Stephen Colebourne scolebou...@joda.org wrote:
I've just noticed this thread.
I'd like to ask those involved to consider if they can find a route
where the package name and group do *not* change.
- Changing to JDK 5 does not require a a package name change (generics
This is codec moving to the codec2 package.
I'll do the usual dance of adding a project defintion for the
CODEC_1_X branch and redirecting all current dependencies there together
with updating the project definition for codec's trunk.
Stefan
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-proxy-test has an issue affecting its community integration.
This
On 12 August 2011 08:14, Emmanuel Bourg ebo...@apache.org wrote:
IMHO unless the main package name has to change due to binary
incompatibilities in the new version I would stick to the original
groupId/artifactId (ie org.apache.jcs/jcs).
+1, otherwise users will be forced to edit and recompile
Le 12/08/2011 00:30, Patrick Meyer a écrit :
I like the idea of adding this feature. What about an abstract class
that implements DifferentiableMultivariateRealFunction and provides the
method for partialDerivative (). People could then override the
partialDerivative method if they have an
On 12 August 2011 10:00, Stefan Bodewig bode...@apache.org wrote:
Hi,
.xz is to LZMA what .gz is to the DEFLATE compression algorithm, and it
starts to get used by quite a few tools/systems in the Unix/Linux
world. For example more recent GNU tar versions use -J to support the
format (like
Hi Bruce,
Le 12/08/2011 00:47, Bruce A Johnson a écrit :
I'd be quite interested in seeing Numerical Derivatives in CM. There are some
interesting ideas about Numerical Differentiation here:
http://www.holoborodko.com/pavel/numerical-methods/
Thanks for the link.
Do you think we should
On 12 August 2011 11:19, sebb seb...@gmail.com wrote:
- Removing deprecated methods does not require a package name change
How so?
If there are any external references to them in an application that
cannot be removed, then both old and new jars will need to be
deployed.
Which cannot be
Shading a binary dependency could provide some middle ground.
Just curious - what is the advantage of shading the jar?
It becomes again just one jar with no dependencies ...almost as if we
forked the code.
cheers,
Torsten
-
Hi Sébastien,
Le 12/08/2011 07:50, Sébastien Brisard a écrit :
As Patrick suggested, this approach should really be extended to
multivariate functions. To cite but one example, I recently attended a
conf where Pr. Prevost (Princeton) talked about non-linear finite
elements calcs. The long
On 2011-08-12, sebb wrote:
On 12 August 2011 10:00, Stefan Bodewig bode...@apache.org wrote:
We basically have two options:
* forking the required classes of XZ in Java into Compress (Lasse
already has a CLA on file and I'm sure we could arrange for the two
code bases to stay in sync)
Hi Luc,
I don't fully agree with this. Both numerical and analytical approach are
useful and have advantages and drawbacks.
Wowww!
I certainly did not want to start a debate on this topic. I'm just
reporting on a conference I heard which lead me think that CM users
might find such a feature
Thanks for the information Luc. I didn't know those existed. I'm happy
to keep the discussion at the implementation levels.
On 8/12/2011 6:23 AM, Luc Maisonobe wrote:
Le 12/08/2011 00:30, Patrick Meyer a écrit :
I like the idea of adding this feature. What about an abstract class
that
The Apache Commons Daemon team is pleased to announce the
commons-daemon-1.0.7 release!
Version 1.0.7 is bug fix release fixing the
CVE-2011-2729 security issue.
Source and binary distributions are available for download
from the Apache Commons download site:
On 12/08/2011 13:23, Mladen Turk wrote:
The Apache Commons Daemon team is pleased to announce the
commons-daemon-1.0.7 release!
Version 1.0.7 is bug fix release fixing the
CVE-2011-2729 security issue.
Source and binary distributions are available for download
from the Apache Commons
On 08/12/2011 02:47 PM, Mark Thomas wrote:
On 12/08/2011 13:23, Mladen Turk wrote:
The Apache Commons Daemon team is pleased to announce the
commons-daemon-1.0.7 release!
Version 1.0.7 is bug fix release fixing the
CVE-2011-2729 security issue.
Source and binary distributions are available for
On 12 August 2011 14:33, Gary Gregory garydgreg...@gmail.com wrote:
Can we proceed like so?
- I'll save my generified codec in an svn branch ASAP.
- we can discuss that and get the best design
- is it binary compatible?
Or can it be made binary-compatible without excessive compromises?
-
On 12 August 2011 14:54, sebb seb...@gmail.com wrote:
We have lang3 and digester3 under our belts now with new packages. Are
we going to change policy again? I hope not. We sure spent a lot of
time on this and thought we made a sane decision as a community.
Joda-time is its own world can do
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11215projectId=74
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 12 Aug 2011 14:21:28 +
Finished at: Fri 12 Aug 2011 14:21:44 +
Total time: 15s
Build Trigger: Schedule
Build
On Fri, Aug 12, 2011 at 9:54 AM, sebb seb...@gmail.com wrote:
On 12 August 2011 14:33, Gary Gregory garydgreg...@gmail.com wrote:
Can we proceed like so?
- I'll save my generified codec in an svn branch ASAP.
- we can discuss that and get the best design
- is it binary compatible?
Or can
On 12 August 2011 15:29, Gary Gregory garydgreg...@gmail.com wrote:
On Fri, Aug 12, 2011 at 9:54 AM, sebb seb...@gmail.com wrote:
On 12 August 2011 14:33, Gary Gregory garydgreg...@gmail.com wrote:
Can we proceed like so?
- I'll save my generified codec in an svn branch ASAP.
- we can
I have a working prototype for real univariate functions that uses
finite differences. The code is very small and simple, but quite
messy. I'll clean it up soon. It's trivial to extend this to
univariate vectorial and matrix functions. I think it's also worth add
Savitzky-Golay smoothing filters
Hi,
I installed an evaluation version of WinZip, created the 5GB and
100k_Files archives I've already created for InfoZIP, 7ZIP, Windows
Compressed Folders and OpenJDK7 jar and the reading tests work just
fine.
All tools I've tried (except for jar) have been able to extract the
archives written
On Fri, Aug 12, 2011 at 10:35 AM, sebb seb...@gmail.com wrote:
On 12 August 2011 15:29, Gary Gregory garydgreg...@gmail.com wrote:
On Fri, Aug 12, 2011 at 9:54 AM, sebb seb...@gmail.com wrote:
On 12 August 2011 14:33, Gary Gregory garydgreg...@gmail.com wrote:
Can we proceed like so?
- I'll
Hi Fran,
Le 12/08/2011 16:51, Fran Lattanzio a écrit :
I have a working prototype for real univariate functions that uses
finite differences. The code is very small and simple, but quite
messy. I'll clean it up soon. It's trivial to extend this to
univariate vectorial and matrix functions. I
[configuration] still has build files for Maven 1. Any objections if I
remove them?
Oliver
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On the [configuration] main site there is a link to old how-to documents
targeting the ancient version 1.2. As nobody is supposed to still work
with this version, I guess it should be okay to remove them. If there
are no objections, I will do this.
Oliver
Hello All:
For a first cut at generics support in Codec, please checkout the
branch https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
I wrote a migration guide in the root of the project called
Codec2-Migration.htm.
Let's discuss.
I plan on not touching trunk until the
On Fri, Aug 12, 2011 at 3:17 PM, Oliver Heger
oliver.he...@oliver-heger.de wrote:
[configuration] still has build files for Maven 1. Any objections if I
remove them?
Remove it! :)
Gary
Oliver
-
To unsubscribe, e-mail:
No
On Aug 12, 2011, at 12:17 PM, Oliver Heger wrote:
[configuration] still has build files for Maven 1. Any objections if I remove
them?
Oliver
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
Hi All:
Where are we WRT [pool] and generics in a release?
Thank you,
Gary
--
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
-
To unsubscribe,
BSF [1] needs to move out of Jakarta.
It's not really big enough to warrant its own TLP.
IMO Commons would be a good alternative home for BSF.
Can we please vote to:
1. Accept BSF as a Commons Component
2. Offer Commons karma to BSF developers.
The ones who made commits since the start of
+1 for both sub-votes.
Matt
On Fri, Aug 12, 2011 at 7:13 PM, sebb seb...@gmail.com wrote:
BSF [1] needs to move out of Jakarta.
It's not really big enough to warrant its own TLP.
IMO Commons would be a good alternative home for BSF.
Can we please vote to:
1. Accept BSF as a Commons
Hello All,
Before I chum the water with more JIRA tickets, I thought I would see
whether people thought this was important.
In the SimpleRegression you have two methods:
public void addData(double x, double y) {
...some code that is not germane to discussion..
if (n 2) {
+1.
On Fri, Aug 12, 2011 at 5:28 PM, Matt Benson gudnabr...@gmail.com wrote:
+1 for both sub-votes.
Matt
On Fri, Aug 12, 2011 at 7:13 PM, sebb seb...@gmail.com wrote:
BSF [1] needs to move out of Jakarta.
It's not really big enough to warrant its own TLP.
IMO Commons would be a good
On 2011-08-13, sebb wrote:
1. Accept BSF as a Commons Component
+1
2. Offer Commons karma to BSF developers.
The ones who made commits since the start of 2008 and are not already
in Commons are:
2a) Rony G. Flatscher (rony)
2b) Ant Elder (antelder)
+1
Stefan
On 8/12/11 7:16 PM, Greg Sterijevski wrote:
Hello All,
Before I chum the water with more JIRA tickets, I thought I would see
whether people thought this was important.
In the SimpleRegression you have two methods:
public void addData(double x, double y) {
...some code that is not
+1 from me, on all counts! -Greg
On Fri, Aug 12, 2011 at 11:30 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 8/12/11 7:16 PM, Greg Sterijevski wrote:
Hello All,
Before I chum the water with more JIRA tickets, I thought I would see
whether people thought this was important.
In the
One more thing... (ala Detective Colombo).
In add and remove observation there is a snippet which looks like:
sumXX += dx * dx * (double) n / (n + 1d);
sumYY += dy * dy * (double) n / (n + 1d);
sumXY += dx * dy * (double) n / (n + 1d);
xbar += dx /
50 matches
Mail list logo
