You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by david delbecq <da...@oma.be> on 2008/03/28 20:17:54 UTC
Best practices for java version?
Hello,
using maven2, i notice that, while there are options to specify which
java version to use when compiling, there is little information on
released jars in repo about which version there are compiled for. It's a
problem in an environment where the java version has limitation. For
example, we are working now on a tomcat using java 1.4. After upgrading
to maven and making a test deploy, we noticed that some of the
transitive dependencies are build with java 1.5. But nothing on project
makes it visible until you deploy and requires one of those jars.
So question is, are there any recommendations on how to handle java
version in releases and in dependencies. If, in the build, i set the
"target" and "source" in compiler, will the compiler check that
dependencies respect those target (so in my case, if i point to 1.4, it
will build error because some transitive dep are java 5?)
What are the best practice when deploying artifact about java version
used for compiling? I read somewhere that the purpose of maven release
process is to make the build "reproductible", but if that build does not
include aimed compiler, we can't assure a "rebuild" will be fully
compatible with previous build, if the java version changed...
Thanks for giving information :)
Regards,
David Delbecq
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Wim Deblauwe <wi...@gmail.com>.
You can use the Maven Enforcer plugin (
http://maven.apache.org/plugins/maven-enforcer-plugin/ ) to force a specifc
JDK for the modules you are building yourself. But I don't think there is
anything for your dependencies that you can specify.
regards,
Wim
2008/3/28, david delbecq <da...@oma.be>:
>
> Hello,
>
> using maven2, i notice that, while there are options to specify which
> java version to use when compiling, there is little information on
> released jars in repo about which version there are compiled for. It's a
> problem in an environment where the java version has limitation. For
> example, we are working now on a tomcat using java 1.4. After upgrading
> to maven and making a test deploy, we noticed that some of the
> transitive dependencies are build with java 1.5. But nothing on project
> makes it visible until you deploy and requires one of those jars.
>
> So question is, are there any recommendations on how to handle java
> version in releases and in dependencies. If, in the build, i set the
> "target" and "source" in compiler, will the compiler check that
> dependencies respect those target (so in my case, if i point to 1.4, it
> will build error because some transitive dep are java 5?)
>
> What are the best practice when deploying artifact about java version
> used for compiling? I read somewhere that the purpose of maven release
> process is to make the build "reproductible", but if that build does not
> include aimed compiler, we can't assure a "rebuild" will be fully
> compatible with previous build, if the java version changed...
>
> Thanks for giving information :)
>
> Regards,
> David Delbecq
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Best practices for java version?
Posted by Martin Gainty <mg...@hotmail.com>.
Richard and Graham
I've been using ANT since 02 placing all environmental (path/classpath) information into buildName.propertiesAnyone who is hardcoding paths in Ant is'nt using it to its full capability and is negating the original design intent
please reference Use Property Files from Steve Loughran's Ant in Anger paper at
http://ant.apache.org/ant_in_anger.htmlThanks,Martin______________________________________________Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.> From: minfrin@sharp.fm> To: users@maven.apache.org> Subject: Re: Best practices for java version?> > Richard Chamberlain wrote:> > > It works internally at our company as we all have build tools (jdk etc)> > in a standard place. This makes it repeatable and > > guaranteed not to blow up on a 1.4 environment.> > There is no such thing as a "standard" place for build tools - a new > contractor comes in, and suddenly has to rearrange their laptop to > accommodate some weird directory structure that is different to their > existing setup. That's a significant waste of time and money.> > Then you decide to upgrade from Win2k to XP, and from XP to Vista, and > Vista to whatever, and suddenly the default location of the JDK changes > for whatever reason and all your code breaks.> > Hard coding paths is one of the exact things that was rife in ant builds > and that maven moves away from, and that makes code management > significantly less painful and more robust.> > Regards,> Graham> --
_________________________________________________________________
How well do you know your celebrity gossip?
http://originals.msn.com/thebigdebate?ocid=T002MSN03N0707A
Re: Best practices for java version?
Posted by Milos Kleint <mk...@gmail.com>.
On Tue, Apr 1, 2008 at 1:54 AM, Dirk Olmes <di...@xanthippe.ping.de> wrote:
> Milos Kleint wrote:
>
> > On Mon, Mar 31, 2008 at 2:57 AM, Dirk Olmes <di...@xanthippe.ping.de>
> wrote:
> >
> > > Milos Kleint wrote:
> > > > check the toolchains proposal that is supposed to address this issue.
> > > >
> > > > http://docs.codehaus.org/display/MAVEN/Toolchains
> > >
> > > The way the toolchain proposal chooses is somewhat doable with Maven
> > > right now: define a set of VM specific properties in each developers'
> > > settings.xml and use that in the config of the various plugins.
> > >
> >
> > toolchains also ensures that any plugin that understands toochains
> > will ue them, thus instead of configuring compiler-plugin,
> > surefire-plugin, javadoc-plugin etc. you just configure the toolchain.
> >
>
> But I would still have to tell the plugins which jdk to use from the
> toolchain config, would I?
>
you only tell the toolchains-plugin, the rest of the plugins grabs the
active toolchain from build context.
>
>
> >
> > > What I don't like about the appraoch is that one has to hand-maintain
> > > the properties/toolchain.xml still. If I update my JDK, I still have to
> > > remember updating the settings or the build will break.
> > >
> >
> > oh well, what do you mean by "update my jdk"? the default jdk you run
> > stuff with on your computer?
> >
>
> No, it's about the various JDKs that are needed to do the build. Example:
> you need JDK 1.4 and JDK 5 for building, that's currently jdk-1.4.2.17 and
> jdk-1.5.0.15 on my machine. I use both JDKs to build the software, only one
> at a time.
That would mean including profile(s) with different toolchain-plugin
configuration.
>
> I have to update the PATH, JAVA_HOME etc each time a JDK is updated (ok I'm
> on Gentoo so that's all done for my by the distro but for the sake of the
> discussion let's image I would be on windows). With the toolchain I don't
> only have to update my environment but also update the toolchain.xml and
> maybe even some more config locations e.g. netbeans' JDK config comes to
> mind.
yes, you have to include the your build environment setup in the
toolchains file, however you can avoid any updates with smart use of
symlinks I guess. Have ~/javatools/jdk15 and ~/javatools/jdk14
symlinked to the latest and greatest stuff you have.
The netbeans JDK config will by automatically synchronized with
toolchains (actually that's why I actually wrote the toolchains, to
have a way to figure what jdk is used in the project.)
Milos
>
> -dirk
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Best practices for java version?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I bet the dependency plugin and/or the enforcer could use ASM to inspect
all transitive dependencies to check the class version. (I'm just
guessing that ASM can do this).
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: Sunday, March 30, 2008 2:47 PM
To: Maven Users List
Subject: Re: Best practices for java version?
delbd wrote:
> So, can we consider that a successfull build using a 1.4 JDK +
"source"
> and "target" in build are enough to guarantee that none of the
> transitive dependencies require jre 5 or higher?
No, but a test suite can.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Graham Leggett <mi...@sharp.fm>.
delbd wrote:
> So, can we consider that a successfull build using a 1.4 JDK + "source"
> and "target" in build are enough to guarantee that none of the
> transitive dependencies require jre 5 or higher?
No, but a test suite can.
Regards,
Graham
--
Re: Best practices for java version?
Posted by Dirk Olmes <di...@xanthippe.ping.de>.
Milos Kleint wrote:
> On Mon, Mar 31, 2008 at 2:57 AM, Dirk Olmes <di...@xanthippe.ping.de> wrote:
>> Milos Kleint wrote:
>> > check the toolchains proposal that is supposed to address this issue.
>> >
>> > http://docs.codehaus.org/display/MAVEN/Toolchains
>>
>> The way the toolchain proposal chooses is somewhat doable with Maven
>> right now: define a set of VM specific properties in each developers'
>> settings.xml and use that in the config of the various plugins.
>
> toolchains also ensures that any plugin that understands toochains
> will ue them, thus instead of configuring compiler-plugin,
> surefire-plugin, javadoc-plugin etc. you just configure the toolchain.
But I would still have to tell the plugins which jdk to use from the
toolchain config, would I?
>> What I don't like about the appraoch is that one has to hand-maintain
>> the properties/toolchain.xml still. If I update my JDK, I still have to
>> remember updating the settings or the build will break.
>
> oh well, what do you mean by "update my jdk"? the default jdk you run
> stuff with on your computer?
No, it's about the various JDKs that are needed to do the build.
Example: you need JDK 1.4 and JDK 5 for building, that's currently
jdk-1.4.2.17 and jdk-1.5.0.15 on my machine. I use both JDKs to build
the software, only one at a time.
I have to update the PATH, JAVA_HOME etc each time a JDK is updated (ok
I'm on Gentoo so that's all done for my by the distro but for the sake
of the discussion let's image I would be on windows). With the toolchain
I don't only have to update my environment but also update the
toolchain.xml and maybe even some more config locations e.g. netbeans'
JDK config comes to mind.
-dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Milos Kleint <mk...@gmail.com>.
On Mon, Mar 31, 2008 at 2:57 AM, Dirk Olmes <di...@xanthippe.ping.de> wrote:
> Milos Kleint wrote:
> > check the toolchains proposal that is supposed to address this issue.
> >
> > http://docs.codehaus.org/display/MAVEN/Toolchains
>
> The way the toolchain proposal chooses is somewhat doable with Maven
> right now: define a set of VM specific properties in each developers'
> settings.xml and use that in the config of the various plugins.
toolchains also ensures that any plugin that understands toochains
will ue them, thus instead of configuring compiler-plugin,
surefire-plugin, javadoc-plugin etc. you just configure the toolchain.
>
> What I don't like about the appraoch is that one has to hand-maintain
> the properties/toolchain.xml still. If I update my JDK, I still have to
> remember updating the settings or the build will break.
oh well, what do you mean by "update my jdk"? the default jdk you run
stuff with on your computer? that's a scenario that works even now. If
you don't configure anything in maven but make sure you run with the
jdk you want, you're safe. The toolchains proposal tries to separate
the jdk you run maven build with and the jdk that shall be used to
build your project. That's essential in embedded environment for
example.
Milos
>
> The great benefit of the toolchain approach is that it provides a
> standard definition of the JDK and that could also abstract from some
> platform specific difficulties (rt.jar on linux/win vs classes.jar on Mac).
>
> Still, I don't like the way how I have to manually distribute the path
> to the current JDK into various config files.
>
> -dirk
>
>
>
> > Milos Kleint
> >
> > On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay <wa...@gmail.com> wrote:
> >> On 3/30/08, delbd <da...@oma.be> wrote:
> >> > Yeah, that's what i thought. So we can consider that maven is missing
> >> > one important thing in dependency management: the jvm dependency. I
> >>
> >> Check JIRA, and if its not already posted, file it. Perhaps it can be
> >> incorporated in 2.1. Or, perhaps there's already a way to do it that I
> >> haven't considered...
> >>
> >> Wayne
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Dirk Olmes <di...@xanthippe.ping.de>.
Michael McCallum wrote:
> On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote:
>> Still, I don't like the way how I have to manually distribute the path
>> to the current JDK into various config files.
> you have to anyway it just happens you set an environment variable which is a
> bit average at the best of times.
Good point.
> Packaged OS's do most of the hard work for you
> e.g. Gentoo manages the JAVA_HOME, MAVEN_HOME during script invocation, I
> think debian based linuxes do as well
I'm a big fan of gentoo in this area and already make good use of
java-config-2 in my custom scripts. What about those poor Windows users,
though? I know I'm a bit philosophical here ...
Anyway, I have just voted for the respective JIRA (MNG-468) and can't
wait to get my hands on Maven 2.1 with toolchain support :-)
-dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Michael McCallum <gh...@apache.org>.
On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote:
> Still, I don't like the way how I have to manually distribute the path
> to the current JDK into various config files.
you have to anyway it just happens you set an environment variable which is a
bit average at the best of times.
Packaged OS's do most of the hard work for you
e.g. Gentoo manages the JAVA_HOME, MAVEN_HOME during script invocation, I
think debian based linuxes do as well
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Dirk Olmes <di...@xanthippe.ping.de>.
Milos Kleint wrote:
> check the toolchains proposal that is supposed to address this issue.
>
> http://docs.codehaus.org/display/MAVEN/Toolchains
The way the toolchain proposal chooses is somewhat doable with Maven
right now: define a set of VM specific properties in each developers'
settings.xml and use that in the config of the various plugins.
What I don't like about the appraoch is that one has to hand-maintain
the properties/toolchain.xml still. If I update my JDK, I still have to
remember updating the settings or the build will break.
The great benefit of the toolchain approach is that it provides a
standard definition of the JDK and that could also abstract from some
platform specific difficulties (rt.jar on linux/win vs classes.jar on Mac).
Still, I don't like the way how I have to manually distribute the path
to the current JDK into various config files.
-dirk
> Milos Kleint
>
> On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay <wa...@gmail.com> wrote:
>> On 3/30/08, delbd <da...@oma.be> wrote:
>> > Yeah, that's what i thought. So we can consider that maven is missing
>> > one important thing in dependency management: the jvm dependency. I
>>
>> Check JIRA, and if its not already posted, file it. Perhaps it can be
>> incorporated in 2.1. Or, perhaps there's already a way to do it that I
>> haven't considered...
>>
>> Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Milos Kleint <mk...@gmail.com>.
check the toolchains proposal that is supposed to address this issue.
http://docs.codehaus.org/display/MAVEN/Toolchains
Milos Kleint
On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay <wa...@gmail.com> wrote:
> On 3/30/08, delbd <da...@oma.be> wrote:
> > Yeah, that's what i thought. So we can consider that maven is missing
> > one important thing in dependency management: the jvm dependency. I
>
> Check JIRA, and if its not already posted, file it. Perhaps it can be
> incorporated in 2.1. Or, perhaps there's already a way to do it that I
> haven't considered...
>
> Wayne
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Wayne Fay <wa...@gmail.com>.
On 3/30/08, delbd <da...@oma.be> wrote:
> Yeah, that's what i thought. So we can consider that maven is missing
> one important thing in dependency management: the jvm dependency. I
Check JIRA, and if its not already posted, file it. Perhaps it can be
incorporated in 2.1. Or, perhaps there's already a way to do it that I
haven't considered...
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by delbd <da...@oma.be>.
Dirk Olmes a écrit :
> delbd wrote:
>> Dirk Olmes a écrit :
>>> Graham Leggett wrote:
>>>> Richard Chamberlain wrote:
>>>>
>>>>> I agree it's not ideal, but I'm open to suggestions as to how to
>>>>> guarantee code from a particular project works in a java 1.4
>>>>> environment?
>>>>
>>>> Use Continuous Integration and a test suite.
>>>
>>> That's what we do here, too. We use profiles that are auto-activated
>>> by the JDK type and have modules declarations only inside the
>>> profiles. WE evaluated going through the hassle of specifying the RT
>>> jar etc but in the end decided that it wouldn't be worthwhile so we
>>> just use -source and -target to bulid.
>>>
>>> Our CI server has two build plans: one for regular JDK5 builds (that
>>> runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring
>>> JDK1.4 source compatability for the modules that require it.
>>>
>>> Even greater care must be taken now when managing the dependecies:
>>> does any module bring in JDK5 compatible third party deps in? Do
>>> JDK14 modules depend on JDK5 modules?
>>>
>>> Cross-JDK builds are doable with Maven, is's just another pile of
>>> complexity on top of what you're already having to deal with.
>
>> So, can we consider that a successfull build using a 1.4 JDK +
>> "source" and "target" in build are enough to guarantee that none of
>> the transitive dependencies require jre 5 or higher?
>
> Not really. After a successful build with JDK1.4 you know that none of
> your direct dependencies (the ones you're importing in your Java
> classes) don't use JDK5. At runtime this may be a completely different
> story as transitive dependencies on which you don't have compile time
> dependencies might still be JDK5. You *might* be safe once all your
> tests run green on JDK1.4 as well but that requires proper coverage,
> of course.
Yeah, that's what i thought. So we can consider that maven is missing
one important thing in dependency management: the jvm dependency. I
think it should be possible for a dependency to specify that it aims a
specific jvm and as such if a project aims a lower dependency, you'll
have a conflict that would appear in report (there is already such
report for regular dependencies)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Dirk Olmes <di...@xanthippe.ping.de>.
delbd wrote:
> Dirk Olmes a écrit :
>> Graham Leggett wrote:
>>> Richard Chamberlain wrote:
>>>
>>>> I agree it's not ideal, but I'm open to suggestions as to how to
>>>> guarantee code from a particular project works in a java 1.4
>>>> environment?
>>>
>>> Use Continuous Integration and a test suite.
>>
>> That's what we do here, too. We use profiles that are auto-activated
>> by the JDK type and have modules declarations only inside the
>> profiles. WE evaluated going through the hassle of specifying the RT
>> jar etc but in the end decided that it wouldn't be worthwhile so we
>> just use -source and -target to bulid.
>>
>> Our CI server has two build plans: one for regular JDK5 builds (that
>> runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4
>> source compatability for the modules that require it.
>>
>> Even greater care must be taken now when managing the dependecies:
>> does any module bring in JDK5 compatible third party deps in? Do JDK14
>> modules depend on JDK5 modules?
>>
>> Cross-JDK builds are doable with Maven, is's just another pile of
>> complexity on top of what you're already having to deal with.
> So, can we consider that a successfull build using a 1.4 JDK + "source"
> and "target" in build are enough to guarantee that none of the
> transitive dependencies require jre 5 or higher?
Not really. After a successful build with JDK1.4 you know that none of
your direct dependencies (the ones you're importing in your Java
classes) don't use JDK5. At runtime this may be a completely different
story as transitive dependencies on which you don't have compile time
dependencies might still be JDK5. You *might* be safe once all your
tests run green on JDK1.4 as well but that requires proper coverage, of
course.
-dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by delbd <da...@oma.be>.
Dirk Olmes a écrit :
> Graham Leggett wrote:
>> Richard Chamberlain wrote:
>>
>>> I agree it's not ideal, but I'm open to suggestions as to how to
>>> guarantee code from a particular project works in a java 1.4
>>> environment?
>>
>> Use Continuous Integration and a test suite.
>
> That's what we do here, too. We use profiles that are auto-activated
> by the JDK type and have modules declarations only inside the
> profiles. WE evaluated going through the hassle of specifying the RT
> jar etc but in the end decided that it wouldn't be worthwhile so we
> just use -source and -target to bulid.
>
> Our CI server has two build plans: one for regular JDK5 builds (that
> runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4
> source compatability for the modules that require it.
>
> Even greater care must be taken now when managing the dependecies:
> does any module bring in JDK5 compatible third party deps in? Do JDK14
> modules depend on JDK5 modules?
>
> Cross-JDK builds are doable with Maven, is's just another pile of
> complexity on top of what you're already having to deal with.
>
> -dirk
So, can we consider that a successfull build using a 1.4 JDK + "source"
and "target" in build are enough to guarantee that none of the
transitive dependencies require jre 5 or higher?
David Delbecq
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Dirk Olmes <di...@xanthippe.ping.de>.
Graham Leggett wrote:
> Richard Chamberlain wrote:
>
>> I agree it's not ideal, but I'm open to suggestions as to how to
>> guarantee code from a particular project works in a java 1.4
>> environment?
>
> Use Continuous Integration and a test suite.
That's what we do here, too. We use profiles that are auto-activated by
the JDK type and have modules declarations only inside the profiles. WE
evaluated going through the hassle of specifying the RT jar etc but in
the end decided that it wouldn't be worthwhile so we just use -source
and -target to bulid.
Our CI server has two build plans: one for regular JDK5 builds (that
runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4
source compatability for the modules that require it.
Even greater care must be taken now when managing the dependecies: does
any module bring in JDK5 compatible third party deps in? Do JDK14
modules depend on JDK5 modules?
Cross-JDK builds are doable with Maven, is's just another pile of
complexity on top of what you're already having to deal with.
-dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Graham Leggett <mi...@sharp.fm>.
Richard Chamberlain wrote:
> I agree it's not ideal, but I'm open to suggestions as to how to
> guarantee code from a particular project works in a java 1.4
> environment?
Use Continuous Integration and a test suite.
The CI server will ensure that your code is built automatically and
regularly, and will moan and complain on your behalf if a developer
broke the build. If an attempt is made to compile code using a v1.4 JDK
against v1.5 dependencies, this step will fail are your developers will
be warned.
The CI server is also able to run your test suite. If an attempt is made
to run the test suite and there are 1.5 transistive dependencies
present, your tests will fail and your developers will get moaned at to
fix the problem.
Regards,
Graham
--
RE: Best practices for java version?
Posted by Richard Chamberlain <ri...@caplin.com>.
I agree it's not ideal, but I'm open to suggestions as to how to
guarantee code from a particular project works in a java 1.4
environment?
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: 29 March 2008 00:25
To: Maven Users List
Subject: Re: Best practices for java version?
Richard Chamberlain wrote:
> It works internally at our company as we all have build tools (jdk
etc)
> in a standard place. This makes it repeatable and
> guaranteed not to blow up on a 1.4 environment.
There is no such thing as a "standard" place for build tools - a new
contractor comes in, and suddenly has to rearrange their laptop to
accommodate some weird directory structure that is different to their
existing setup. That's a significant waste of time and money.
Then you decide to upgrade from Win2k to XP, and from XP to Vista, and
Vista to whatever, and suddenly the default location of the JDK changes
for whatever reason and all your code breaks.
Hard coding paths is one of the exact things that was rife in ant builds
and that maven moves away from, and that makes code management
significantly less painful and more robust.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Wayne Fay <wa...@gmail.com>.
And in response to Martin, in the project I'm recently involved in,
the paths are not hard-coded into the build script itself but rather
in various build.properties files. It is still a total pain and a
hack, IMO. You can't honestly tell me that you enjoy configuring
properties files for every environment/machine, do you? I have better
things to do with my time.
After a lot of time with Maven over the last few years, it will be a
cold day in hell when I go back to making Ant scripts. Instead, I'm
fixing the mistakes of others and getting rid of their Ant scripts.
Wayne
On 3/28/08, Wayne Fay <wa...@gmail.com> wrote:
> On 3/28/08, Graham Leggett <mi...@sharp.fm> wrote:
> > Hard coding paths is one of the exact things that was rife in ant builds
> > and that maven moves away from, and that makes code management
> > significantly less painful and more robust.
>
> I just got pulled into a project at my work place where they are
> having significant build problems, and guess what, its Ant-city with
> hard-coded paths like you wouldn't believe. For some reason, this
> approach is starting to have problems now that more than 2 devs are
> involved, and the project is getting ready to hit production for the
> first time.
>
> Wayne
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Wayne Fay <wa...@gmail.com>.
On 3/28/08, Graham Leggett <mi...@sharp.fm> wrote:
> Hard coding paths is one of the exact things that was rife in ant builds
> and that maven moves away from, and that makes code management
> significantly less painful and more robust.
I just got pulled into a project at my work place where they are
having significant build problems, and guess what, its Ant-city with
hard-coded paths like you wouldn't believe. For some reason, this
approach is starting to have problems now that more than 2 devs are
involved, and the project is getting ready to hit production for the
first time.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Graham Leggett <mi...@sharp.fm>.
Richard Chamberlain wrote:
> It works internally at our company as we all have build tools (jdk etc)
> in a standard place. This makes it repeatable and
> guaranteed not to blow up on a 1.4 environment.
There is no such thing as a "standard" place for build tools - a new
contractor comes in, and suddenly has to rearrange their laptop to
accommodate some weird directory structure that is different to their
existing setup. That's a significant waste of time and money.
Then you decide to upgrade from Win2k to XP, and from XP to Vista, and
Vista to whatever, and suddenly the default location of the JDK changes
for whatever reason and all your code breaks.
Hard coding paths is one of the exact things that was rife in ant builds
and that maven moves away from, and that makes code management
significantly less painful and more robust.
Regards,
Graham
--
RE: Best practices for java version?
Posted by Richard Chamberlain <ri...@caplin.com>.
It works internally at our company as we all have build tools (jdk etc)
in a standard place. This makes it repeatable and
guaranteed not to blow up on a 1.4 environment.
I agree that this could certainly be a problem. Maybe there's a nicer
solution with profiles etc?
Regards,
Richard
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: 28 March 2008 22:50
To: Maven Users List
Subject: Re: Best practices for java version?
Richard Chamberlain wrote:
> If you using java 5 as your JAVA_HOME I would also recommend setting
the
> executable compiler to use.
>
> <executable>path.to.jdk\1.4.2\bin\javac.exe</executable>
The side effect of this is that you produce code that now only compiles
on one person's machine, and that is *very* un-repeatable.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Wendy Smoak <ws...@gmail.com>.
On Fri, Mar 28, 2008 at 3:50 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Richard Chamberlain wrote:
>
> > If you using java 5 as your JAVA_HOME I would also recommend setting the
> > executable compiler to use.
> >
> > <executable>path.to.jdk\1.4.2\bin\javac.exe</executable>
>
> The side effect of this is that you produce code that now only compiles
> on one person's machine, and that is *very* un-repeatable.
You can use a property like ${JAVA_1_4_HOME} as suggested in the
compiler plugin docs.
It's more configuration (devs may have to set that property in
settings.xml) but if you need to compile with a certain JDK, you can d
This assumes you have control of the release environment, as
you'd want to make sure the property was _really_ set to the location
of a 1.4 JDK.
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Graham Leggett <mi...@sharp.fm>.
Richard Chamberlain wrote:
> If you using java 5 as your JAVA_HOME I would also recommend setting the
> executable compiler to use.
>
> <executable>path.to.jdk\1.4.2\bin\javac.exe</executable>
The side effect of this is that you produce code that now only compiles
on one person's machine, and that is *very* un-repeatable.
Regards,
Graham
--
Re: Best practices for java version?
Posted by Stuart McCulloch <st...@jayway.net>.
On 29/03/2008, Richard Chamberlain <ri...@caplin.com> wrote:
>
> If you using java 5 as your JAVA_HOME I would also recommend setting the
> executable compiler to use.
>
> <executable>path.to.jdk\1.4.2\bin\javac.exe</executable>
>
> Whilst <source> and <target> go some way to making sure the language is
> correct, they won't pick up the fact that java 1.4 doesn't have a
> certain version of a runtime library.
>
> For example you could have happily used <source> and <target> to compile
> an class that does some XML parsing using java 5 libraries. However when
> you run the code in a 1.4 environment it'll blow up.
you could always set the compiler bootclasspath, as mentioned here:
http://docs.codehaus.org/x/9fE
so no matter what JDK you use, it will compile against the right classlib:
<configuration>
<source>1.3</source>
<target>1.3</target>
<compilerArguments>
<bootclasspath>${some.property}/path/to/some/rt.jar</bootclasspath>
</compilerArguments>
</configuration>
then it's just a matter of getting the relevant rt.jar and either putting it
in
a repository, or providing it as part of your project / developer setup.
HTH
Regards,
>
> Rich
>
>
>
> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: 28 March 2008 19:29
> To: Maven Users List
> Subject: Re: Best practices for java version?
>
> david delbecq wrote:
>
> > What are the best practice when deploying artifact about java version
> > used for compiling? I read somewhere that the purpose of maven release
>
> > process is to make the build "reproductible", but if that build does
> not
> > include aimed compiler, we can't assure a "rebuild" will be fully
> > compatible with previous build, if the java version changed...
>
> Configure the maven-compiler-plugin to specify the specific java version
>
> you need for that particular build. This will ensure your future rebuild
>
> is repeatable, even with a newer JDK version.
>
> Regards,
> Graham
> --
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Cheers, Stuart
RE: Best practices for java version?
Posted by Richard Chamberlain <ri...@caplin.com>.
If you using java 5 as your JAVA_HOME I would also recommend setting the
executable compiler to use.
<executable>path.to.jdk\1.4.2\bin\javac.exe</executable>
Whilst <source> and <target> go some way to making sure the language is
correct, they won't pick up the fact that java 1.4 doesn't have a
certain version of a runtime library.
For example you could have happily used <source> and <target> to compile
an class that does some XML parsing using java 5 libraries. However when
you run the code in a 1.4 environment it'll blow up.
Regards,
Rich
-----Original Message-----
From: Graham Leggett [mailto:minfrin@sharp.fm]
Sent: 28 March 2008 19:29
To: Maven Users List
Subject: Re: Best practices for java version?
david delbecq wrote:
> What are the best practice when deploying artifact about java version
> used for compiling? I read somewhere that the purpose of maven release
> process is to make the build "reproductible", but if that build does
not
> include aimed compiler, we can't assure a "rebuild" will be fully
> compatible with previous build, if the java version changed...
Configure the maven-compiler-plugin to specify the specific java version
you need for that particular build. This will ensure your future rebuild
is repeatable, even with a newer JDK version.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by david delbecq <da...@oma.be>.
Graham Leggett a écrit :
> david delbecq wrote:
>
>> What are the best practice when deploying artifact about java version
>> used for compiling? I read somewhere that the purpose of maven
>> release process is to make the build "reproductible", but if that
>> build does not include aimed compiler, we can't assure a "rebuild"
>> will be fully compatible with previous build, if the java version
>> changed...
>
> Configure the maven-compiler-plugin to specify the specific java
> version you need for that particular build. This will ensure your
> future rebuild is repeatable, even with a newer JDK version.
>
> Regards,
> Graham
> --
>
>
Thank you all for all solutions, but my concern is very particular about
"dependencies", when i pickup dependencies on maven repository, how do i
know about it's transititive dependencies java requirement, there
doesn't seems to be anything about it in the pom.xml. So when i pickup,
for example, richfaces, i have absolutely no way to know
1) does it requires a java 1.4, java 5 or java 6 runtime
2) do it's transitive dependency depends on java 1.4, java 5 or java 6
3) in the end, will it run on my java 1.4 server?
It's very frustrating to work 2 weeks porting from maven1 to maven2 and
in the end discover the transitive dependecies brings up java 5
requirement our production server can't cope with :)
Now that mean i either
1) upgrade server (seems resonnable) to java 5
2) go to each classload exception, one at a time, to pickup a wrong java
requirement library, rebuild it on java 1.4 and the publish it in
internal repo, hoping it won't collide with the "official" builded file.
It's a very long process, since the exceptions doe not occur at init
time, but in middle of day work.
Even if i do 1) i have no garantee that none of the jar are build on
java 6, which would be a problem since our prod environnement has,
afaik, absolutely no java 6 jvm available.
Considering Those point, a sideway question too, could it be possible to
ask maven to recompile very dependencies when building a project? Since
sources are published along jar and scm informations is present in
pom.xml, it should be faisible, no?
And another one, could this (information about jvm or even "java
version", be added to jar? using the extension mecanism, in future maven
version?)
Regards,
David Delbecq
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practices for java version?
Posted by Graham Leggett <mi...@sharp.fm>.
david delbecq wrote:
> What are the best practice when deploying artifact about java version
> used for compiling? I read somewhere that the purpose of maven release
> process is to make the build "reproductible", but if that build does not
> include aimed compiler, we can't assure a "rebuild" will be fully
> compatible with previous build, if the java version changed...
Configure the maven-compiler-plugin to specify the specific java version
you need for that particular build. This will ensure your future rebuild
is repeatable, even with a newer JDK version.
Regards,
Graham
--