Re: why axis-1.4.jar is dependent upon wsdl4j-1.5.1 jar file in maven
If you want to use your WSDL4J and not the one from Axis and because it seems they have different groupId/artifactId, you should include an exclusion inside the Axis dependency declaration in order to exclude the WSDL4J dependency from Axis Regards Jeff On Fri, Nov 30, 2012 at 3:02 AM, Benson Margulies bimargul...@gmail.comwrote: You will have to consult the Axis project. This is because their POM declares this dependency. On Thu, Nov 29, 2012 at 7:26 AM, koti koti.a...@gmail.com wrote: HI all, My application is already using wsdl4j-1.6.2.jar and will not support with wsdl4j-1.5.1.jar file. I have observed that when I have written only axis1.4 dependency code in my pom.xml like below / axis axis 1.4 jar compile / (nabble_embed tag is added to display code.. it is not having in my actual code... )it downloading wsdl4j-1.5.1.jar file (not sure how it is downloading) due to that my existing application is not working. So, I have modified code like /wsdl4jwsdl4j1.6.2 jar compile axis axis 1.4 jar compile/ now it automatically downloading axis-wsdl4j-1.5.1.jar file which is also creating problem to my existing application. could you please let me know, why axis jar is internally downloading wsdl file and how to remove this internal dependency.Please let me if another version of axis jar will download wsdl4j-1.6.2.jar file.Thanks in advance. -- View this message in context: http://maven.40175.n5.nabble.com/why-axis-1-4-jar-is-dependent-upon-wsdl4j-1-5-1-jar-file-in-maven-tp5734252p5734255.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Jeff MAURY Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: why axis-1.4.jar is dependent upon wsdl4j-1.5.1 jar file in maven
Thanks Jeff. seems it will solve my problem. Thanks for your help. -- View this message in context: http://maven.40175.n5.nabble.com/why-axis-1-4-jar-is-dependent-upon-wsdl4j-1-5-1-jar-file-in-maven-tp5734252p5734492.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Versions Maven Plugin 2.0 released
Responding to all, as MVERSIONS-200 is important enough to flag the
potential issue if you are using deprecated properties (the ones that Maven
3 warns you about if you use them)
@Dennis Wheeler: I suspect you have hit
https://jira.codehaus.org/browse/MVERSIONS-200
The right thing to do is to update your poms replacing:
${pom.parent.groupId} with ${project.parent.groupId}
${pom.parent.artifactId} with ${project.parent.artifactId}
${pom.parent.version} with ${project.parent.version}
${pom.groupId} with ${project.groupId},
${pom.artifactId} with ${project.artifactId},
${pom.version} with ${project.version},
${parent.groupId} with ${project.parent.groupId}
${parent.artifactId} with ${project.parent.artifactId}
${parent.version} with ${project.parent.version}
${groupId} with ${project.groupId},
${artifactId} with ${project.artifactId},
${version} with ${project.version},
as that will ensure that your poms are compatibile with future versions of
Maven.
It is still to be decided whether to roll a patch release of 2.0 with
workaround code for this (use of deprecated properties) edge case.
-Stephen
On 28 November 2012 23:31, Wheeler, Dennis dwhee...@cobaltgroup.com wrote:
While I would love to assist, this issue has not been consistently
reproducible. It hasn't yet failed on our automated trunk builds, but
consistently fails on our automated branch builds (it consistently fails
for me locally both in the trunk and the branch, but the project's primary
developer claims is doesn't fail for him at all (and I don't yet believe
he's using the exact same steps -- I think he only wants access to our
automated servers)).
I am extremely backlogged with other pressing tasks, and my boss doesn't
want me to spend the time debugging this issue any further now that we
have a workaround solution. Not to mention that we're working within a
closed source environment and I'm unsure about how much of our build logs
and environment info we can share.
Perhaps I can pass this off to one of our other developers who is also
more experienced using maven who can then help debug and better report on
the NPE.
I'm just guessing (and its just a wild unfounded guess at this point),
that our project contains some circular dependencies and the new versions
plugin is attempting to be more strict in that area.
Thanks for all the assistance.
On 11/28/12 5:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Can you please raise a JIRA for the NPE
On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com
wrote:
Someone please help me from navigating through the forest of no return,
that is Google, and tell me how to force our projects back to using the
older 1.2 version of the Versions plugin, instead of this newer 2.0
version which is now giving us null pointer exceptions with this simple
command:
mvn -U versions:set -DnewVersion=12345
I don't really know anything about maven myself, I only plugin what the
devs give me into our build configuration system.
Can I make a global setting in the settings.xml, or does it have to be
in
each project's pom.xml?
Dennis Wheeler
Release Engineer II
ADP Digital Marketing Solutions
p 206.219.8049 | c 206.375.6781 | e dwhee...@cobalt.com
http://www.cobalt.com/
Join the conversation facebook http://www.facebook.com/#!/adpdmc|
twitter http://twitter.com/#!/adp_cobalt | blog
http://www.digitalmileage.com/
This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and
confidential.
If the reader of the message is not the intended recipient or an
authorized representative of the intended recipient, you are hereby
notified that any dissemination of this communication is strictly
prohibited. If you have received this communication in error, please
notify us immediately by email and delete the message and any
attachments
from your system.
On 11/27/12 5:57 AM, Stephen Connolly
stephen.alan.conno...@gmail.com
wrote:
The Mojo team is pleased to announce the release of the Versions
Maven Plugin, version 2.0
NOTE: This release requires Maven 2.2.1 or newer and consequently JRE
1.5
or newer.
NOTE: This is the *last* planned release that will support running on
Maven
2.2.x
The Versions Plugin has the following goals.
* versions:compare-dependencies compares the dependency versions of
the current project to the dependency management section of a remote
project.
* versions:display-dependency-updates scans a project's dependencies
and produces a report of those dependencies which have newer versions
available.
* versions:display-plugin-updates scans a project's plugins and
produces a report of those plugins which have newer versions
available.
* versions:display-property-updates scans a projectand produces a
report of those properties which are
Re: Re: Why does mvn compiile using java 1.3?
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
Solved: shareing resources in multi-module projects
Hi list, yesterday i had an hour to burn and tried maven-remote-resource-plugin instead. It just worked as expected. - cheers, Philip On Mon, 2012-11-26 at 13:03 +0100, Philip wrote: Hi list, i have a multi-module project and would like to share some common resources. Easily found the reference, Brian Fox: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/ but i cannot get the example-project http://blogs.sonatype.com/people/wp-content/uploads/2009/01/resource-sharing.zip to make some test before merging it into my main project. Does someone know a valid location? greetings, Philip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Why does mvn compiile using java 1.3?
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.h...@vkb.dewrote: 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
Re: Some musings on Maven profiles and the Maven way
Very nice! Ron On 30/11/2012 7:12 AM, Stephen Connolly wrote: It's a tad rough, but I'm fed up writing it, and I think it's useful for people anyway: http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html Just some of my random thoughts -Stephen -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Match syntax?
On Thu, Nov 29, 2012 at 07:12:37PM +0100, Robert Scholte wrote: These patterns were introduced with Ant. Well, glob matching goes back at least as far as Unix v1 http://en.wikipedia.org/wiki/Glob_%28programming%29 Ant improved on this by adding the double-asterisk that matches any depth of hierarchy levels (treating a level as an atom, not a string). They're clearly not REs: *.something viewed as an RE begins with a quantifier which has nothing to quantify. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu I don't do doorbusters. pgpVhzB81DDVS.pgp Description: PGP signature
Re: Why does mvn compiile using java 1.3?
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.h...@vkb.dewrote: 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: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why does mvn compiile using java 1.3?
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 rwhee...@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.h...@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: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional
Re: Re: Why does mvn compiile using java 1.3?
On 30 November 2012 13:42, 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 I too am in favour of maintaining the current behaviour, explicit declaration of version, or you get 1.3. Explicit versioning is what Maven is all about! cheers Tim -- Tim Pizey - http://pizey.net/~timp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Why does mvn compiile using java 1.3?
Actually the current behaviour is 1.5 is using Maven Compiler Plugin 2.5 or newer (might be 2.4 but I'd need to check) With Maven 3.1.0, the version of the Maven Compiler Plugin that you get if you have not locked down plugin versions will be upped to a version with this new default. So if you don't lock things down and live on the latest Maven, out of the box you will get Java 1.5 compatible classes until you lock things down. On 30 November 2012 15:35, Tim Pizey tim.pi...@gmail.com wrote: On 30 November 2012 13:42, 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 I too am in favour of maintaining the current behaviour, explicit declaration of version, or you get 1.3. Explicit versioning is what Maven is all about! cheers Tim -- Tim Pizey - http://pizey.net/~timp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Why does mvn compiile using java 1.3?
BTW I favour keeping at 1.5. That is the highest version we can guarantee a user of Maven 3.1.0's JDK can compile at (because in order to run Maven 2.2.1+ you need Java 1.5) so unless they are using toolchains (which to be honest, given the lack of bugs reported around toolchains and my knowledge of what kind of bugs we should expect to see reported [xyz plugin doesn't support toolchains] they are not using) that is a good and sensible default. If we set the default higher, then a user will download Maven 3.1.0 having seen it say (all you need is JDK 1.5 or higher) and try and build some code and bomb out with -source 1.6 is unknown and say Maven is shit. So as I see it. The Core plugins (i.e. the ones hosted at org.apache.maven.plugins) or maybe the core plugins involved in the default lifecycles, cannot assume Java higher than the minimum required to run the Maven version they run on. Core is still at 1.5. So therefore the highest default the compiler plugin can consider at this point in time is 1.5. I will -1 any change to that default above the min required by core unless somebody gives a compelling argument for the change, and I do not see such a compelling argument. (I am not saying I will -1 upping the min JDK required by Maven, just that compiler's default cannot be higher than the minimum version required by Maven) -Stephen On 30 November 2012 15:53, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Actually the current behaviour is 1.5 is using Maven Compiler Plugin 2.5 or newer (might be 2.4 but I'd need to check) With Maven 3.1.0, the version of the Maven Compiler Plugin that you get if you have not locked down plugin versions will be upped to a version with this new default. So if you don't lock things down and live on the latest Maven, out of the box you will get Java 1.5 compatible classes until you lock things down. On 30 November 2012 15:35, Tim Pizey tim.pi...@gmail.com wrote: On 30 November 2012 13:42, 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 I too am in favour of maintaining the current behaviour, explicit declaration of version, or you get 1.3. Explicit versioning is what Maven is all about! cheers Tim -- Tim Pizey - http://pizey.net/~timp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
No compile errors with plexus-compiler-eclipse
Hello, I'm trying to make use of plexus-compiler-eclipse by setting plugin artifactIdmaven-compiler-plugin/artifactId version3.0/version configuration compilerIdeclipse/compilerId /configuration dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-eclipse/artifactId version2.0/version /dependency /dependencies /plugin in pom.xml. mvn compile works, but in fact I still have errors in my code (I'm actually porting an ant and xdoclet based project to maven). But instead of getting errors I see a lot of warnings and build succeeds. The warnings are not only about Hashtable is a raw type. References to generic type HashtableK,V should be parameterized which I'd expect as a warning only, but also Type mismatch: cannot convert from Object to MyBusinessFacadeRemote or MyBusinessServlet cannot be resolved or Unreachable catch block for RemoteException. This exception is never thrown from the try statement body or The import foo.bar.Bla cannot be resolved or even whole types (formerly xdoclet generated types I partially need to create manually by myself and haven't done yet). These I'd expect to pop up as an error and fail the build. Instead it's only printed as a warning and build continues. Am I configuring maven-compiler-plugin - and plexus-compile-eclipse - the wrong way? Or is plexus-compiler-eclipse not raising these errors as such at all, which would render it quite a bit useless at the moment? -- Thanks in advance, and best regards, Peter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: No compile errors with plexus-compiler-eclipse
2012/11/30 Peter Palmreuther pitpa...@gmail.com: Hello, I'm trying to make use of plexus-compiler-eclipse by setting plugin artifactIdmaven-compiler-plugin/artifactId version3.0/version configuration compilerIdeclipse/compilerId /configuration dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-eclipse/artifactId version2.0/version /dependency /dependencies /plugin in pom.xml. mvn compile works, but in fact I still have errors in my code (I'm actually porting an ant and xdoclet based project to maven). But instead of getting errors I see a lot of warnings and build succeeds. The warnings are not only about Hashtable is a raw type. References to generic type HashtableK,V should be parameterized which I'd expect as a warning only, but also Type mismatch: cannot convert from Object to MyBusinessFacadeRemote or MyBusinessServlet cannot be resolved or Unreachable catch block for RemoteException. This exception is never thrown from the try statement body or The import foo.bar.Bla cannot be resolved or even whole types (formerly xdoclet generated types I partially need to create manually by myself and haven't done yet). These I'd expect to pop up as an error and fail the build. Instead it's only printed as a warning and build continues. Am I configuring maven-compiler-plugin - and plexus-compile-eclipse - the wrong way? Or is plexus-compiler-eclipse not raising these errors as such at all, which would render it quite a bit useless at the moment? maybe an issue. Can you raise a jira entry with a sample project ? -- Thanks in advance, and best regards, Peter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Why does mvn compiile using java 1.3?
You have been getting 1.5 by default for a long time. At least since the 2.3 release of the compiler plugin.. On Fri, November 30, 2012 7:35 am, Tim Pizey wrote: On 30 November 2012 13:42, 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 I too am in favour of maintaining the current behaviour, explicit declaration of version, or you get 1.3. Explicit versioning is what Maven is all about! cheers Tim -- Tim Pizey - http://pizey.net/~timp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: No compile errors with plexus-compiler-eclipse
Hello, Am 30.11.2012 um 21:41 schrieb Olivier Lamy ol...@apache.org: 2012/11/30 Peter Palmreuther pitpa...@gmail.com: [...] Am I configuring maven-compiler-plugin - and plexus-compile-eclipse - the wrong way? Or is plexus-compiler-eclipse not raising these errors as such at all, which would render it quite a bit useless at the moment? maybe an issue. Can you raise a jira entry with a sample project ? http://jira.codehaus.org/browse/PLXCOMP-215 -- Regards, Peter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
