Re: No compile errors with plexus-compiler-eclipse
Hello, Am 30.11.2012 um 21:41 schrieb Olivier Lamy : > 2012/11/30 Peter Palmreuther : >> [...] >> 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
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
2012/11/30 Peter Palmreuther : > Hello, > > I'm trying to make use of plexus-compiler-eclipse by setting > > > maven-compiler-plugin > 3.0 > > eclipse > > > > org.codehaus.plexus > plexus-compiler-eclipse > 2.0 > > > > > 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 Hashtable 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
No compile errors with plexus-compiler-eclipse
Hello, I'm trying to make use of plexus-compiler-eclipse by setting maven-compiler-plugin 3.0 eclipse org.codehaus.plexus plexus-compiler-eclipse 2.0 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 Hashtable 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: 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 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 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?
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 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?
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: 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 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 > >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 > > > --
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 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-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: 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: 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 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
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?
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: [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 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"
> wrote:
>
> >Can you please raise a JIRA for the NPE
> >
> >
> >On 28 November 2012 08:04, Wheeler, Dennis
> >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
> >>
> >> |
> >> twitter | blog
> >>
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: 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 wrote: > 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 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
