On Sat, Mar 7, 2009 at 10:26 PM, Dan Fabulich wrote:
> The the API in the "java5" branch is backward compatible; the generics and
> varargs are erased at compile time. Of course, the code has to be compiled
> with target=1.5, but on a Java 1.5 VM you could swap it in and not notice
> the differen
Henri Yandell wrote:
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
The the API in the "java5" branch is backward compatible; the generics and
varargs are erased at
Henri Yandell wrote:
I believe we can call it 1.2 - as long as it's API compatible then tis good.
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
There's also an argume
I believe we can call it 1.2 - as long as it's API compatible then tis good.
The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.
There's also an argument that wants the packa
You're in the unix group now.
On Sat, Mar 7, 2009 at 10:16 AM, Henri Yandell wrote:
> I'll mail infra to get that sorted. We're supposed to do it for each
> new committer, but I tend not to bother as it's only those who end up
> doing release management that need the unix group.
>
> Hen
>
> On Fr
Good catch. :-(
Uh, if dbutils 1.1 was compatible with java 1.3, and we want to depend on
java 1.4 in the next version, do we have to call it "dbutils 2.0"?
I assume not; I think we can still call it "dbutils 1.2" even though we
depend on java 1.4 now. Is that OK?
Similarly, could/should
I'll mail infra to get that sorted. We're supposed to do it for each
new committer, but I tend not to bother as it's only those who end up
doing release management that need the unix group.
Hen
On Fri, Mar 6, 2009 at 11:16 PM, Dan Fabulich wrote:
>
> Thanks, got that sorted. Now I have a new qu
I am fine with both points and also agree with the comments of Ralph.
1) sounds that the current implementation is buggy - or at least
inconsistent; so this should really be improved.
2) seems to be an interesting extension of the lookups we have so far.
Here it would be really cool if you could
The pom.xml does not specify a java source or target version, so
defaults to 1.3 (from the parent pom)
As far as I can tell, the component requires at least 1.4 so the POM
needs to be updated.
[IMO the compiler settings should never be delegated to the parent POM]
---
