Ok i just tested it it really goes wrong (in eclipse and with javac)
i have this test:
public class Main
{
public static void main(String[] args)
{
StringBuffer sb1 = new StringBuffer("sb1");
StringBuffer sb2 = new StringBuffer("sb2");
sb1.append(sb2);
System.er
Note that provided your dependencies don't use JDK5 classes, javac
-target 1.4 won't somehow statically link against JDK5 code. It's the
nature of Java that all the linking is done at runtime. Provided all
your code compiles using -target 1.4 and you didn't use the 1.5 rt.jar
it'll all be fine.
Martijn Dashorst wrote:
I have been thinking about forcing the JVM in the plugin section of
the 1.4 projects. This is possible, but it is highly installation
dependent, and therefore not implemented (yet). I was hoping for a
1.4 section in the pom, which would then load the
corresponding platform
no no, if you look at how bamboo is configured it is actually building the
projects against 1.4jdk, not against 1.5jdk with compatibility set to 1.4
it does what you do when you release, sets javahome to point to 1.4 jdk
instead of the 1.5 one. check out the link almaw provided and look under
bui
I still am not convinced that using a JDK 1.5 for building a 1.4
library will not complain about a JDK 1.5 dependency.
And if bamboo compiles running inside a JDK 1.4 I still don't trust us
to actively keep supporting the continuous integration server, just as
we still don't always run the unit t
On 2/5/07, Alastair Maw <[EMAIL PROTECTED]> wrote:
You've evidently been bitten by this and have a set-up that fixes the
issue and works, and are therefore reluctant to change it. I respect
that and shall now politely stop haranguing you, even if I think I know
better. ;)
Note that I'm not oppo
On 2/5/07, Alastair Maw <[EMAIL PROTECTED]> wrote:
You've evidently been bitten by this and have a set-up that fixes the
issue and works, and are therefore reluctant to change it. I respect
that and shall now politely stop haranguing you, even if I think I know
better. ;)
If you have spent your
Igor Vaynberg wrote:
i guess almaw played around with it w/out telling us :)
We have some projects that are, err, "significantly" more complex than
Wicket in terms of Maven 2 builds, class version compatibility (which
gets interesting when you bring RMI classloaders into account) and stuff.
so really if bamboo actually compiles against 1.4 we shouldnt have any
problems "trusting" that the code is correct martijn?
That would be a lot better than the semi-manual check which Martijn
does now. I think the whole build should ideally be one step, and it
would be best to filter out wrongl
i guess almaw played around with it w/out telling us :)
so really if bamboo actually compiles against 1.4 we shouldnt have any
problems "trusting" that the code is correct martijn?
-igor
On 2/5/07, Al Maw <[EMAIL PROTECTED]> wrote:
Johan Compagner wrote:
> first of all will javac -source 1.4
Johan Compagner wrote:
first of all will javac -source 1.4 -target 1.4 always do the right thing?
It does for us, at least.
And then i thing about the changes in StringBuilder/StringBuffer
I guess StringBuilder will not be used but StringBuffer will
Sun deliberately design it so that you ca
first of all will javac -source 1.4 -target 1.4 always do the right thing?
And then i thing about the changes in StringBuilder/StringBuffer
I guess StringBuilder will not be used but StringBuffer will
And then i guess java 5 methods of StringBuffer will be used when appending
for example:
*
Hi Martijn,
You've evidently been bitten by this and have a set-up that fixes the
issue and works, and are therefore reluctant to change it. I respect
that and shall now politely stop haranguing you, even if I think I know
better. ;)
Regarding Bamboo going the way of Continuum, I'd like to n
On 2/5/07, Al Maw <[EMAIL PROTECTED]> wrote:
Martijn Dashorst wrote:
> I have thought about it and *hard*. The issue is that if I run mvn
> install, then *EVERYTHING* in my local repo is overwritten with JDK 5
> compiled artifacts. That is a definite no go.
I must be missing something here...
W
I have thought about it and *hard*. The issue is that if I run mvn
install, then *EVERYTHING* in my local repo is overwritten with JDK 5
compiled artifacts. That is a definite no go.
The issue is not convenience but ensuring correctness. The only way I
can exclude any fuck ups with JDK compilatio
Frank Bille wrote:
javac -source -target ?? I'm almost sure this work, but I don't know if you
can tell maven to use those (it worked with ant AFAIK)
Yes, we already do this, obviously. :-)
This prevents you from using language features like generics.
However, it doesn't stop you from using JR
Al Maw wrote:
javac -source -target ?? I'm almost sure this work, but I don't
know if you can tell maven to use those (it worked with ant AFAIK)
Yes, we already do this, obviously. :-)
Only now I look, actually, we don't. :-)
To clarify: We do for wicket, but not for wicket-extensions and s
Alastair Maw wrote:
Frank Bille wrote:
javac -source -target ?? I'm almost sure this work, but I don't
know if you can tell maven to use those (it worked with ant AFAIK)
Yes, we already do this, obviously. :-)
Only now I look, actually, we don't. :-)
We certainly should do, but that's only
Alastair Maw wrote:
Frank Bille wrote:
javac -source -target ?? I'm almost sure this work, but I don't know
if you
can tell maven to use those (it worked with ant AFAIK)
Yes, we already do this, obviously. :-)
Only now I look, actually, we don't. :-)
We certainly should do, but that's only
org.apache.maven.plugins
maven-compiler-plugin
1.4
1.4
perhaps, haven't tested it though?
Frank
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/5/07, Al Maw <[EMAIL PROTECTE
On 2/5/07, Al Maw <[EMAIL PROTECTED]> wrote:
Frank Bille wrote:
> Yes I agree with Martijn. We really want to catch if any 1.5 stuff is
> in 1.4projects. But Al, if you can get maven to do that (forcing
> 1.4 in 1.4 projects) it would be nice. I don't know if maven can do
that,
> though.
See my
Frank Bille wrote:
Yes I agree with Martijn. We really want to catch if any 1.5 stuff is
in 1.4projects. But Al, if you can get maven to do that (forcing
1.4 in 1.4 projects) it would be nice. I don't know if maven can do that,
though.
See my other reply. The thing that matters is what your JAV
Martijn Dashorst wrote:
-1
I have set this up so that I can run with jdk 1.4 and build the 1.4
projects *USING* only 1.4, and ONLY the 1.5 projects when I run using
1.5. This is to prevent any 1.5 stuff from entering our project.
But I don't think it does that exactly - let me explain...
This
On 2/5/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
-1
I have set this up so that I can run with jdk 1.4 and build the 1.4
projects *USING* only 1.4, and ONLY the 1.5 projects when I run using
1.5. This is to prevent any 1.5 stuff from entering our project.
Yes I agree with Martijn. We re
-1
I have set this up so that I can run with jdk 1.4 and build the 1.4
projects *USING* only 1.4, and ONLY the 1.5 projects when I run using
1.5. This is to prevent any 1.5 stuff from entering our project.
Martijn
On 2/5/07, Al Maw <[EMAIL PROTECTED]> wrote:
Hi.
At the moment, you need to run
Hi.
At the moment, you need to run wicket-parent's "mvn install" with a
profile (-Pjdk1.4) to get it to build things if you have a JDK5 install.
This isn't terribly obvious, to say the least.
I'd like to propose we move the JDK1.4 modules in that profile out into
the main build, as we *alway
26 matches
Mail list logo
