maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aliaksei Lahachou <aliaksei.lahac...@gmail.com>
Subject Re: Why does mvn compiile using java 1.3?
Date Fri, 30 Nov 2012 15:07:10 GMT
I understand that it's not about making Maven run on 7.

The problem is that people build artifacts on 7 (which will become more
often if it's default) and deploy these artifacts to repository, then
people who are using JDK 6 will not be able to compile with this artifacts
(the target JDK is written somewhere in .class files and older compilers
will refuse to accept them).

Try building a project on JDK 6 which depends on
com.adobe.xmp:xmpcore:5.1.2, it will fail. But the XMP core source can be
built with JDK 5. Whoever uploaded this artifact to Maven central made it
unusable with JDK 5 or 6 simply because he compiled it with JDK 7.


On Fri, Nov 30, 2012 at 3:39 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> We are not talking about making Maven only run on 7.
> We just want to move the default compiler to 6 (at least) or 7.
> You can always set it back to 1.3.
> It is just odd for new projects to start up with Maven and suddenly find
> than Maven wants to use 1.3 to compile code.
>
> Please, no more warnings about perfectly correct behaviour.
> I already get a bogus warning message if my parent pom and my project are
> in the same group which is exactly the way its supposed to be.
>
> There is nothing wrong with building with Java 7 if that is the run-time
> that you want.
>
> Your point about people building shared libraries is very good.
> I don't know of any convention or build process that will indicate that a
> Maven Artifact requires 1.7 (or 1.6 or 1.5) to run properly.
> I guess that the library author will have to decide how far back into Java
> history needs to be supported.
>
> Does Apache have any policies or guidelines or Best Practices with regard
> to the choice of Java version with which to publish libraries?
>
> Ron
>
>
>
> On 30/11/2012 8:42 AM, Aliaksei Lahachou wrote:
>
>> Hello everyone,
>>
>> I'm am against updating default version to 1.7. My favourite option would
>> be to use the lowest possible version of JDK and give a warning if version
>> is not specified explicitly (similar to what resources plugin does with
>> encoding). I would actually go as far as warning people if they explicitly
>> specify version 1.7. There are a lot of folks who think they are so great
>> using the newest versions, but it actually may cause problems.
>>
>> We have a pretty big and old application which is currently developed and
>> run on JDK 1.6. There were issues with 1.7, but they were fixed. The real
>> problem is updating customers - there are about 300 different
>> installations
>> supported by our teams. It's actually pretty difficult to get on customers
>> servers, for each you have to contact their IT and schedule a session and
>> downtime.
>>
>> The problem is the following. Real life experience: I wanted to use Adobe
>> XMP core and luckily, it was in Maven central. But not so luckily, it was
>> compiled with JDK 1.7 (without any need) and JDK 1.6 refused to compile
>> with it. I had to get the sources, compile with JDK 1.6 and put it to our
>> local Nexus. If maven-compiler-plugin default version is updated to 1.7, I
>> expect more artifacts built for 1.7 without any need.
>>
>> Regards,
>> htfv (Aliaksei Lahachou)
>>
>>
>> On Fri, Nov 30, 2012 at 12:01 PM, Thorsten Heit <thorsten.heit@vkb.de
>> >wrote:
>>
>>  Hi,
>>>
>>>  I have never seen any java application fail just because I run the
>>>> version 7 VM. Even really old code still runs.
>>>>
>>> A couple of Atlassian applications I work with in our department that
>>> didn't run (fine) with Java 7:
>>>
>>> - JIRA <= 5.1.x (5.2 was released ~3 weeks ago)
>>> - Bamboo <= 3.2.x (3.3 was released 11 october 2011)
>>> - Confluence <= 4.1.x (4.2 was released 10 april 2012)
>>>
>>> etc.
>>> It took quite a long time for the manufacturer to implement the necessary
>>> changes to let their products work with Java 7. JIRA for example wouldn't
>>> even start correctly when using 1.7.* and instead threw lots of
>>> exceptions
>>> in its log, whereas for at least Confluence 4.1.x there were some
>>> workarounds to let it run with a JVM 7...
>>>
>>>
>>> In our department we had a very old legacy application written by some
>>> colleagues back in the days of Java 1.2 when the first Swing UI came out.
>>> They told me they had lots of problems with former Swing UI bugs and
>>> programmed workarounds to get the application finally work with Java 1.4.
>>> These workarounds didn't work correct anymore with Java 5 (Swing bugs
>>> were
>>> fixed?), i.e. the application's UI had some nice "features" a.k.a bugs
>>> :-o
>>>
>>> Unfortunately they weren't given the time to fix them (you know, the
>>> usual
>>> problems with sales that had other priorities...) so they had to stick
>>> with Java 1.4 until ~2.5 years ago (!), until the application finally
>>> died
>>> about one year ago. That's life...
>>>
>>>
>>> Regards
>>>
>>> Thorsten
>>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message