(OGNL committer) +1
2011/8/15 Christian Grobmeier :
> OGNL [1] has checked off all status items in the incubator.
>
> Most of the OGNL developers are already commons developers and the
> risk of failure is pretty small, even without having made a release.
> As the Commons project is already very e
Hello,
See maven3 migration documentation page
I recommend you don't remove it. Your submodules won't inherits the
correct site.xml (with links to vfs submodules)
Thanks,
--
Olivier Lamy
Talend : http://talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
[1]
http://maven.apache.o
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11319&projectId=74
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue 16 Aug 2011 06:23:13 +
Finished at: Tue 16 Aug 2011 06:23:19 +
Total time: 5s
Build Trigger: Schedule
Buil
That's OK. At least getting agreement on tackling the interfaces first gives
us somewhere to start. Then we can debate if or where generics, etc. should be
used.
The reason I still prefer to base on the Hierarchical is that the current way
of hooking in the File configuration support is just u
Am 15.08.2011 23:02, schrieb Ralph Goers:
I don't know. I think it really needs a refactoring. We always said that all
configurations should be based on HierarchicalConfiguration but that still
hasn't happened. Attribute splitting and delimiter parsing have been a pain.
I think it would be
I understood what he was suggesting. I still disagree. Dynamic dispatch
and non-lattice typing structure is still required to make this all work.
Java doesn't really do that. Pretending that what Java does is sufficient
is hammer-looking-for-a-nail, not solving the problems at hand.
On Mon, Au
On 16 August 2011 00:48, Ralph Goers wrote:
> I am using Maven 3 to do my release of Commons VFS and have noticed that I am
> getting way more junk than I expected in Nexus. The first thing I'm
> investigating are the site.xml files being deployed. Do we have a
> requirement that these should
On 15 August 2011 23:53, Gary Gregory wrote:
> On Mon, Aug 15, 2011 at 10:12 AM, sebb wrote:
>
>> On 14 August 2011 22:38, Gary Gregory wrote:
>> > Hi,
>> >
>> > On Aug 14, 2011, at 10:19, sebb wrote:
>> >
>> >> On 14 August 2011 03:02, sebb wrote:
>> >>> On 12 August 2011 20:56, Gary Gregory
Forgive me for pushing my nose under the tent... I couldn't resist.
I think Gilles is saying that each specialization of the matrix/vector
objects would need to support pre (and post) multiplication with a dense. So
the type issue would not be problematic.
On Mon, Aug 15, 2011 at 6:34 PM, Ted Dun
I am using Maven 3 to do my release of Commons VFS and have noticed that I am
getting way more junk than I expected in Nexus. The first thing I'm
investigating are the site.xml files being deployed. Do we have a requirement
that these should be deployed? Why does commons parent have the site p
No.
You can't. This is because the type is lost as you enter the generic
library.
On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> > They know that their own object is dense, but they don't know what kind
> of
> > input they were given. They should stil
> Well, no they wouldn't.
>
> They would often need to write something like
>
> dense.times(unknown)
An actual code excerpt would help me understand what you think is or isn't
or should be possible with CM.
If "dense" and "unknown" are vectors, then in "ArrayRealVector", "dotProduct"
uses a
On Mon, Aug 15, 2011 at 10:12 AM, sebb wrote:
> On 14 August 2011 22:38, Gary Gregory wrote:
> > Hi,
> >
> > On Aug 14, 2011, at 10:19, sebb wrote:
> >
> >> On 14 August 2011 03:02, sebb wrote:
> >>> On 12 August 2011 20:56, Gary Gregory wrote:
> Hello All:
>
> For a first cut
Well, no they wouldn't.
They would often need to write something like
dense.times(unknown)
They know that their own object is dense, but they don't know what kind of
input they were given. They should still run fast if the input is sparse.
On Mon, Aug 15, 2011 at 3:06 PM, Gilles Sadowski <
> > > I'm in favor of moving some methods to the SparseXXX interface, but
> > > got voted down at the time. For application developers (like me),
> > > that can expect in advance if the Vector/Matrix is sparse or not it
> > > isn't a big deal. But I can see how it may cause problems for other
> > >
I don't know. I think it really needs a refactoring. We always said that all
configurations should be based on HierarchicalConfiguration but that still
hasn't happened. Attribute splitting and delimiter parsing have been a pain.
I think it would be great to start with clean interfaces and the
+1 (Commons PMC)
Gary
On Mon, Aug 15, 2011 at 9:51 AM, Christian Grobmeier
wrote:
> OGNL [1] has checked off all status items in the incubator.
>
> Most of the OGNL developers are already commons developers and the
> risk of failure is pretty small, even without having made a release.
> As the C
+1 (Commons PMC)
Oliver
Am 15.08.2011 15:51, schrieb Christian Grobmeier:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a release.
As the Commons project i
Am 14.08.2011 23:28, schrieb Emmanuel Bourg:
Le 13/08/2011 20:53, Oliver Heger a écrit :
Hi,
as you may have noticed, I have started some work in order to prepare a
release (version 1.7) of [configuration]. I assume this will be the last
release compatible with Java 1.4.
So the release after
Just in case anyone wants to use Maven to download the Java part of
Commons Daemon (this has been requested in the past), I thought it
would be useful to create and upload the Maven artifacts to the Nexus
staging repo.
The uploads contain source, so although the main release votes have
already pas
Hi Matt,
Thanks for the advice. I've created a JIRA issue for the patch
(https://issues.apache.org/jira/browse/CHAIN-53) and signed and
submitted the CLA.
As for JSF, I believe I made a mistake in changing the API to use the
office jsf API instead of the myfaces API that was previously being
used
+1
OGNL committer
Maurizio Cucchiara
On 15 August 2011 15:51, Christian Grobmeier wrote:
> OGNL [1] has checked off all status items in the incubator.
>
> Most of the OGNL developers are already commons developers and the
> risk of failure is pretty small, even without having made a release.
>
On 15 August 2011 14:51, Christian Grobmeier wrote:
> OGNL [1] has checked off all status items in the incubator.
>
> Most of the OGNL developers are already commons developers and the
> risk of failure is pretty small, even without having made a release.
> As the Commons project is already very e
+1
On Mon, Aug 15, 2011 at 10:19 AM, Henri Yandell wrote:
> +1 (Commons PMC).
>
> On Mon, Aug 15, 2011 at 6:51 AM, Christian Grobmeier
> wrote:
>> OGNL [1] has checked off all status items in the incubator.
>>
>> Most of the OGNL developers are already commons developers and the
>> risk of failu
+1 (Commons PMC).
On Mon, Aug 15, 2011 at 6:51 AM, Christian Grobmeier
wrote:
> OGNL [1] has checked off all status items in the incubator.
>
> Most of the OGNL developers are already commons developers and the
> risk of failure is pretty small, even without having made a release.
> As the Common
On Mon, Aug 15, 2011 at 4:04 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> Hello.
>
> > I'm in favor of moving some methods to the SparseXXX interface, but
> > got voted down at the time. For application developers (like me),
> > that can expect in advance if the Vector/Matrix is sp
On 14 August 2011 22:38, Gary Gregory wrote:
> Hi,
>
> On Aug 14, 2011, at 10:19, sebb wrote:
>
>> On 14 August 2011 03:02, sebb wrote:
>>> On 12 August 2011 20:56, Gary Gregory wrote:
Hello All:
For a first cut at generics support in Codec, please checkout the
branch
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a release.
As the Commons project is already very experienced with releasing
components, there is no need for OGN
On Mon, Aug 15, 2011 at 8:22 AM, Matt Benson wrote:
> Hi, Elijah--
>
> I am neither a develop nor even a user of chain, so my comments will
[SNIP]
Nay, nor even a develop[er]. :|
Matt
-
To unsubscribe, e-mail: dev-unsubscr...
Hi, Elijah--
I am neither a develop nor even a user of chain, so my comments will
be high-level. Firstly, by all means upgrade to whatever JUnit 4
release version you like, e.g. 4.8.2. Next, I personally am a big fan
of Mockito, so no complaints here on that account. I can't guarantee
noone e
On 2011-08-15, sebb wrote:
> /home/continuum/continuum-base/data/working-directory/64/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveException.java:[38,8]
> cannot find symbol
> symbol : constructor IOException(java.lang.Throwable)
> That's Java 1.6+
Yes, will fix it in one
On 15 August 2011 09:56, Stefan Bodewig wrote:
> Hi,
>
> while working on the Zip64 stuff I deliberately created some invalid
> archives to test I get the expected exceptions. While doing so I
> realized I couldn't close the underlying stream because
> ZipArchiveOutputStream's close would throw a
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11273&projectId=64
Build statistics:
State: Failed
Previous State: Failed
Started at: Mon 15 Aug 2011 12:20:55 +
Finished at: Mon 15 Aug 2011 12:21:20 +
Total time: 25s
Build Trigger: Schedule
Bui
/home/continuum/continuum-base/data/working-directory/64/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveException.java:[38,8]
cannot find symbol
symbol : constructor IOException(java.lang.Throwable)
That's Java 1.6+
On 15 August 2011 12:20, Continuum@vmbuild wrote:
> Online
On 15 August 2011 09:50, Luc Maisonobe wrote:
> Le 14/08/2011 17:29, sebb a écrit :
>>
>> FastMath.java:1008 says:
>>
>> * for extra precision (i.e. exp(x) = result[0] ° result[1]
>>
>> The operator symbol is mangled (probably due to conversion between
>> encodings).
>>
>> I'm not sure what
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11271&projectId=64
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 15 Aug 2011 11:20:24 +
Finished at: Mon 15 Aug 2011 11:20:47 +
Total time: 23s
Build Trigger: Schedule
Build N
Hello.
> I'm in favor of moving some methods to the SparseXXX interface, but
> got voted down at the time. For application developers (like me),
> that can expect in advance if the Vector/Matrix is sparse or not it
> isn't a big deal. But I can see how it may cause problems for other
> libraries t
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
Hi.
> > Also, I think that further cleanup is possible (cf. "wantu" and "wantv"
> > checks that don't seem very useful).
>
> This is residual from the JAMA code and is not required with our current
> interface.
I removed them in r1157281.
> I wonder if we could implement something around this.
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 has an issue affecting its community integration.
This issue
Hi,
while working on the Zip64 stuff I deliberately created some invalid
archives to test I get the expected exceptions. While doing so I
realized I couldn't close the underlying stream because
ZipArchiveOutputStream's close would throw an exception as finish()
failed before ever closing the wrap
Le 14/08/2011 17:29, sebb a écrit :
FastMath.java:1008 says:
* for extra precision (i.e. exp(x) = result[0] ° result[1]
The operator symbol is mangled (probably due to conversion between encodings).
I'm not sure what the operator should be - dot product perhaps?
Hi Sebb,
It should h
> Also, I think that further cleanup is possible (cf. "wantu" and "wantv"
> checks that don't seem very useful).
This is residual from the JAMA code and is not required with our current
interface.
I wonder if we could implement something around this. I can conceive of
cases where users may only
43 matches
Mail list logo
