cargo offline deploy fails
I have a maven war project and am using maven-cargo-plugin to deploy the war
to the container and also to start/stop the container for functional
testing. All works well on an internet-connected machine, but when I try to
execute my build on a disconnected machine, the cargo:deploy fails. I have
copied the source tree and my maven repository to the disconnected machine
and am running "mvn -o". All other parts of the build complete
successfully. If I manually deploy the war and start the container, the
functional tests run successfully. The disconnected machine is on a
completely isolated network, not just behind a firewall. I have read the
cargo documentation and do not see anything that addresses this use-case.
Judging from the trace, it appears to be trying to contact
www.jboss.org(perhaps trying to validate the war???) Is there a
mistake in my
configuration, or a way to work around this issue?
The failure: (hand typed so possible typos...)
[cargo:deploy {execution: copy-to-jboss}]
Parsed JBoss version = [5.1.0]
--
FATAL ERROR
-
Failed to create deployable with implementation class
org.codehaus.cargo.container.jboss.deployable.JBossWAR for the parameters
(container [id = [jboss51x]], deployable type [war])
www.jboss.org
Trace
org.codehaus.cargo.container.ContainerException: Failed to create...
at
org.codehaus.cargo.generic.spi.AbstractGenericHintFactory.createImplementation(AbstractGenericHintFactory.java:154)
---snip---
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
---snip---
Caused by: org.codehaus.cargo.container.ContainerException: Failed to parse
JBoss WAR file in [correct_path_name_here]
at:
org.codehaus.cargo.container.jboss.deployable.JBossWAR.(JBossWAR.java:56)
---snip---
Caused by: java.net.UnknownHostException: www.jboss.org
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
---snip---
maven version 2.2.1
cargo version 1.1.1
java version 1.6.0_20 (connected)/1.6.0_23(disconnected)
OS: ubuntu 11.04 (connected)/RedHat (disconnected)
container: jBoss 5.1
This is the cargo configuration, as specified in the pluginManagement
section of my parent/aggregator pom:
org.codehaus.cargo
cargo-maven2-plugin
${version.cargo}
${project.build.directory}/${project.build.finalName}.${project.packaging}
jboss51x
${jboss.home}
installed
XXX
XXX
XXX
XXX
${jena.config.file}
existing
${jboss.server.dir}
-XX:PermSize=512m
-XX:MaxPermSize=1024
default
https
8443
true
1099
true
${jboss.hostname}
Re: help - how to reduce the build time using mvn and cargo
In addition to trimming the war (definitely a good idea)...
In your first post, you mentioned mvn.bat - so I will assume you are in a
Windows environment. Where is your ${user.home} located: local or remote?
I have seen at least one corporate environment where (for Sysadmin
convenience) home directories were kept on a central server. This was not a
big deal to Word and PowerPoint users, who only download one file at a time,
but a huge hit to maven as people were constantly hitting .m2/repository
*ACROSS-THE-WIRE*.
On Fri, May 13, 2011 at 5:10 PM, EJ Ciramella wrote:
> Heh - I see 30 dependencies mentioned below, is this a trick answer?
>
> (sorry, trolling as I wait for posts to my questions)
>
> -Original Message-
> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> Sent: Friday, May 13, 2011 5:08 PM
> To: users@maven.apache.org
> Subject: Re: help - how to reduce the build time using mvn and cargo
>
> Getting the 70 dependencies out of the build will yield the biggest ROI.
>
> Ron
>
> On 13/05/2011 4:29 PM, Wayne Fay wrote:
> >> Bunch of thanks to all for sharing the info. Yes my war is very big.
> Its
> >> size is almost 62MB. It builds in 7 mins than other machines. It uses
> 30
> >> dependencies and xml resources.
> > 7 minutes is a long time just to build what is essentially a zip file.
> > Perhaps invest in some SSD hardware and perform your builds on
> > server-class machines rather than pokey laptops via a CI server like
> > Jenkins/Hudson or something along those lines.
> >
> > Wayne
> >
> > -
> > 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
>
>
> CONFIDENTIALITY NOTICE: This e-mail and the information transmitted within
> including any attachments is only for the recipient(s) to which it is
> intended and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of; or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> send the e-mail back by replying to the sender and permanently delete the
> entire message and its attachments from all computers and network systems
> involved in its receipt.
>
Re: help - how to reduce the build time using mvn and cargo
Well, the first step would be determining exactly where your build is spending its time - compiling, building the war, deploying the war (locally and/or remotely)? If your current build output doesn't give enough information, try "mvn -X" for more verbose output. Then you will have a better idea where to look for improvement. I doubt that the maven memory footprint is the source of your speed issues. On Thu, May 12, 2011 at 12:53 PM, javadaisy wrote: > Hi, > > I am using maven 2.2.1 with cargo plugin to deploy into the local and > remote > host. It takes around 7 to 8 minutes to build and deploy the war. I would > like to reduce the time to 3 minutes or less than 3 minutes. can anybody > please tell me how to do that?. > > I tried adding set MAVEN_OPTS=-DXms_1024M -DXmx=1024M in mvn.bat. It > didn't > work > > Thanks in advance. > > -- > View this message in context: > http://maven.40175.n5.nabble.com/help-how-to-reduce-the-build-time-using-mvn-and-cargo-tp4390836p4390836.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: How can I have a goal depend on another goal?
Trant, Look at the cargo plugin (http://cargo.codehaus.org/). It is useful for starting/stopping J2EE containers and deploying modules to them. With proper configuration of the plugin (, and elements), you just need something like this in your build section: org.codehaus.cargo cargo-maven2-plugin start-container pre-integration-test deploy start stop-container post-integration-test stop undeploy We use this everyday on our CI machine and it does pretty much what I understand you need. On Wed, May 11, 2011 at 3:25 PM, trant wrote: > Yep, I didn't understand that concept. > > So what I tried now is I added an execution to my plugin, as follows: > > > >install > > deploy > > > > > under the assumption that maven will now consider this plugin as part of > the > deploy goal of the install phase? > > I tried running it and it actually does do what I want, it now does all the > steps prior to deploy - build, test, package, etc... > > So that's good. Not sure if I did it the right way though or just lucked > out. > > But now what if I also wanted the other goal I mentioned called > weblogic:start to run prior to this deploy? What would I need to do to the > pom? I am thinking maybe put that goal in the executions prior to the > existing deploy goal? like: weblogic:start ?? Somehow I dont > think thats the correct way to do it > > -- > View this message in context: > http://maven.40175.n5.nabble.com/How-can-I-have-a-goal-depend-on-another-goal-tp4384674p4388271.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: Problem with maven-war-plugin
It appears this was fixed in version 2.2 of m-w-p, try updating. http://jira.codehaus.org/browse/MWAR-235 Cheers, John 2010/10/28 Marcin Trościańczyk > Hi, > > I have a problem with maven-war-plugin version 2.1. Below, I paste build > section fragment from my pom.xml: > > > > >org.apache.maven.plugins >maven-compiler-plugin > > > 1.6 > 1.6 > > > >org.apache.maven.plugins >maven-war-plugin >2.1 > > > > > Unfotunetly, generated artifact (war) contains two web.xml. When I use > maven-war-plugin version 2.0.1 all works fine (generated war archive > contains one web.xml). How can I solve this problem. > > Cheers, > Marcin >
Re: Maven SQL plugin
http://jira.codehaus.org/browse/MSQL-53 addresses exactly this issue... On Thu, Oct 14, 2010 at 5:12 PM, John Singleton wrote: > Hi Chris, > > It has been my experience of ~2.5 years that the order is maintained with a > list, though I see nothing in the plugin docs that specifically > mentions this, nor have I had the time (or inclination) to read the > source... We have a relatively small number of sql files, 4 in one place, 2 > in another, so it is not too bad for us to list them all by name. FWIW, we > are using version 1.4 of the plugin. > > Cheers, > John > > > On Thu, Oct 14, 2010 at 10:27 AM, Chris Odney wrote: > >> Hi John, >> >> I never noticed the option of as against >> >> My understanding is the list of files specified using are >> executed in the order they are specified whereas it is not so in the case >> of >> (this is when orderFile attribute is not specified). Am I wrong? >> >> Thanks for the reply, >> Chris. >> >> On Thu, Oct 14, 2010 at 7:33 PM, John Singleton > >wrote: >> >> > Hi Chris, >> > >> > #2 is probably the best to ensure repeatability in the order you want. >> It >> > also prevents inadvertent re-ordering if a new sql file is introduced >> into >> > the sql directory. In our project, we use srcFiles rather than fileset: >> > >> > >> >[file1] >> >[file2} >> >... >> > >> > >> > HTH, >> > John Singleton >> > >> > On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney >> > wrote: >> > >> > > Hi, >> > > >> > > I am facing some problem in ordering the sql execution. >> > > >> > > We have one sql script file for each table under one directory. Ex: >> There >> > > is >> > > user.sql and role.sql in the directory c:\SqlScripts. We are using the >> > sql >> > > maven plugin to execute these sql files. >> > > >> > > The role table has a Foriegn key to the user table and the execution >> is >> > > failing because the plugin is trying to execute the role.sql before >> > > user.sql. I cannot use the orderfile attribute as we specify the >> > >> > > as c:\SqlScripts\*.sql. >> > > >> > > How do I overcome this problem? >> > > >> > > I see 2 solutions: >> > > >> > > 1) Merge all scripts into one file in the creation order, the script >> to >> > > create role comes after the script to create user. >> > > >> > > 2)Remove the * wildcard and specify each file in the >> attribute >> > > in >> > > the order of execution. >> > > >> > > 3)Number the name of the files according to the execution order ex: >> > > 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not >> > sure >> > > if this would work though, as the ordering may not be applied) >> > > >> > > Any more elegant solutions? >> > > >> > > Thank you, >> > > Chris. >> > > >> > >> > >
Re: Maven SQL plugin
Hi Chris, It has been my experience of ~2.5 years that the order is maintained with a list, though I see nothing in the plugin docs that specifically mentions this, nor have I had the time (or inclination) to read the source... We have a relatively small number of sql files, 4 in one place, 2 in another, so it is not too bad for us to list them all by name. FWIW, we are using version 1.4 of the plugin. Cheers, John On Thu, Oct 14, 2010 at 10:27 AM, Chris Odney wrote: > Hi John, > > I never noticed the option of as against > > My understanding is the list of files specified using are > executed in the order they are specified whereas it is not so in the case > of > (this is when orderFile attribute is not specified). Am I wrong? > > Thanks for the reply, > Chris. > > On Thu, Oct 14, 2010 at 7:33 PM, John Singleton >wrote: > > > Hi Chris, > > > > #2 is probably the best to ensure repeatability in the order you want. > It > > also prevents inadvertent re-ordering if a new sql file is introduced > into > > the sql directory. In our project, we use srcFiles rather than fileset: > > > > > >[file1] > >[file2} > >... > > > > > > HTH, > > John Singleton > > > > On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney > > wrote: > > > > > Hi, > > > > > > I am facing some problem in ordering the sql execution. > > > > > > We have one sql script file for each table under one directory. Ex: > There > > > is > > > user.sql and role.sql in the directory c:\SqlScripts. We are using the > > sql > > > maven plugin to execute these sql files. > > > > > > The role table has a Foriegn key to the user table and the execution is > > > failing because the plugin is trying to execute the role.sql before > > > user.sql. I cannot use the orderfile attribute as we specify the > > > > > as c:\SqlScripts\*.sql. > > > > > > How do I overcome this problem? > > > > > > I see 2 solutions: > > > > > > 1) Merge all scripts into one file in the creation order, the script to > > > create role comes after the script to create user. > > > > > > 2)Remove the * wildcard and specify each file in the > attribute > > > in > > > the order of execution. > > > > > > 3)Number the name of the files according to the execution order ex: > > > 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not > > sure > > > if this would work though, as the ordering may not be applied) > > > > > > Any more elegant solutions? > > > > > > Thank you, > > > Chris. > > > > > >
Re: Maven SQL plugin
Hi Chris, #2 is probably the best to ensure repeatability in the order you want. It also prevents inadvertent re-ordering if a new sql file is introduced into the sql directory. In our project, we use srcFiles rather than fileset: [file1] [file2} ... HTH, John Singleton On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney wrote: > Hi, > > I am facing some problem in ordering the sql execution. > > We have one sql script file for each table under one directory. Ex: There > is > user.sql and role.sql in the directory c:\SqlScripts. We are using the sql > maven plugin to execute these sql files. > > The role table has a Foriegn key to the user table and the execution is > failing because the plugin is trying to execute the role.sql before > user.sql. I cannot use the orderfile attribute as we specify the > as c:\SqlScripts\*.sql. > > How do I overcome this problem? > > I see 2 solutions: > > 1) Merge all scripts into one file in the creation order, the script to > create role comes after the script to create user. > > 2)Remove the * wildcard and specify each file in the attribute > in > the order of execution. > > 3)Number the name of the files according to the execution order ex: > 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure > if this would work though, as the ordering may not be applied) > > Any more elegant solutions? > > Thank you, > Chris. >
Re: Plans to release Maven 3.0
Unfortunately, our bcel dependency is a transitive dependency from a jBoss pom, so I can't easily change that one either. For the record, I do not disagree that strict pom validation is a good idea, nor do I disagree that it is the responsibility of the artifact producer to produce a correct pom. I just wanted to point out that introducing mandatory validation without some sort of escape (e.g. -Dskip.pom.validation=true) will inconvenience some developers. For now, I have to choose between hosting a few extra artifacts or remaining with maven 2.2.1 while pinging on a few developers to update their artifacts... John Singleton On Thu, Sep 9, 2010 at 2:14 PM, Wayne Fay wrote: > > bcel/bcel/5.1 and ant-contrib/ant-contrib/1.0b3. Both of these poms are > > structurally incorrect: > > bcel moved to o.a.bcel and has a 5.2 release with a proper pom file: > > http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/bcel/bcel/5.2/bcel-5.2.pom > > ant-contrib 1.03b does look to be wrong, you should ping that > team/list to ask them to push a new build (1.03b is from Jan 2009) > that has, among other things, a proper pom file (and hopefully a more > sensible version number) > > > original question remains - is this maven behavior intended and, if so, > can > > we increase the urgency of fixing bad poms in maven central ( > repo1.maven.org) > > so I don't have to host a lot of already-available artifacts just to fix > > their metadata? > > Fixing bad metadata is generally the responsibility of the dev team > who is producing the artifacts. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Plans to release Maven 3.0
Thanks, Yoav. This was indeed the case, at least for this pom. I'm not happy about turning off consistency checks but it did get me beyond the colt 1.2.0 problem. Unfortunately, two other errors were not solved by this fix: bcel/bcel/5.1 and ant-contrib/ant-contrib/1.0b3. Both of these poms are structurally incorrect: 2010-09-09 11:32:07,935 [pool-1-thread-16] [WARN ] (o.a.e.DownloadServiceImpl:205) - Sending HTTP error code 409: Failed to read POM for 'bcel/bcel/5.1/bcel-5.1.pom': Unrecognised association: 'groupId' (position: START_TAG seen ...\n... @7:14) .. 2010-09-09 11:33:46,867 [pool-1-thread-21] [WARN ] (o.a.e.DownloadServiceImpl:205) - Sending HTTP error code 409: Failed to read POM for 'ant-contrib/ant-contrib/1.0b3/ant-contrib-1.0b3.pom': Unrecognised association: 'url' (position: START_TAG seen ...\n ... @10:10) .. Even with consistency checks turned off, these produce 409 responses which kills the build under maven3. Of course, the same 409 responses were sent to maven 2.2.1 which silently ignored them and completed the build. So my original question remains - is this maven behavior intended and, if so, can we increase the urgency of fixing bad poms in maven central (repo1.maven.org) so I don't have to host a lot of already-available artifacts just to fix their metadata? Thanks, John Singleton On Wed, Sep 8, 2010 at 6:51 PM, Yoav Landman wrote: > This may be a result of pom validation checks by Artifactory itself. See: > http://wiki.jfrog.org/confluence/display/RTF/Advanced - suppressing pom > consistency checks. You should see a message in the server log - if you do > try turning it off or deploy a fixed pom version locally. > > On Wed, Sep 8, 2010 at 11:31 PM, John Singleton > wrote: > > > I have tried to use Maven 3.0 (all beta versions) on our project but the > > build fails due to a metadata error in an artifact in the central > > repository. The error message is: > > > > Error transferring file: Server returned HTTP response code: 409 for URL: > > > > > http://blackbook.jhuapl.edu:8080/artifactory/repo/colt/colt/1.2.0/colt-1.2.0.pom- > > > > > [Help 1] > > > > Is this behavior intended? (our project builds fine with maven 2.2.1, > but > > I > > understand that m3 does more extensive pom verification) > > > > If so, will there be more urgency to fixing bad data in central? The bad > > colt pom is already identified in MEV-618 (05MAR09) and is still > > unassigned. > > > > Until that happens, what is the recommended fix or workaround? > > > > Thanks, > > John Singleton > > > > On Wed, Sep 8, 2010 at 9:49 AM, Brian Fox wrote: > > > > > So if you haven't > > > yet, we would like you to grab the latest 3.x build and give us your > > > feedback. > > > > > > --Brian > > > Apache Maven PMC Chair > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > >
Re: Plans to release Maven 3.0
I have tried to use Maven 3.0 (all beta versions) on our project but the build fails due to a metadata error in an artifact in the central repository. The error message is: Error transferring file: Server returned HTTP response code: 409 for URL: http://blackbook.jhuapl.edu:8080/artifactory/repo/colt/colt/1.2.0/colt-1.2.0.pom-> [Help 1] Is this behavior intended? (our project builds fine with maven 2.2.1, but I understand that m3 does more extensive pom verification) If so, will there be more urgency to fixing bad data in central? The bad colt pom is already identified in MEV-618 (05MAR09) and is still unassigned. Until that happens, what is the recommended fix or workaround? Thanks, John Singleton On Wed, Sep 8, 2010 at 9:49 AM, Brian Fox wrote: > So if you haven't > yet, we would like you to grab the latest 3.x build and give us your > feedback. > > --Brian > Apache Maven PMC Chair > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
3.0-beta-2 pom checking fails build
I tried building my project with the latest maven 3.0-beta-2 but it fails the build because of a pom error in the colt-1.2.0 artifact on maven central. This error has already been reported (MEV-618, MEV-652) but is currently unassigned. I can't see any maven configuration or command-line option that will get me over this issue. Is there a workaround, or do I just need to host a repaired artifact on my local repository server? This is not the first time that stricter checking in maven-3 has caused me grief, but until now I was always able to proceed by improving my poms (generally a good thing). This one, however, is beyond my control and more of a deal-breaker. John
Re: [ANN] Maven Compiler Plugin 2.3 Released
It works for me, too - Thanks! John Singleton On Fri, Apr 23, 2010 at 4:04 AM, Thomas Sundberg < thomas.k.sundb...@gmail.com> wrote: > Hi! > > I just upgraded the project I'm working on and it worked fine. > > /Thomas > > On Fri, Apr 23, 2010 at 09:54, Milos Kleint wrote: > > The checksums on central shall be fixed now. My apologies to everyone. > > > > Milos > > > > On Wed, Apr 21, 2010 at 10:22 PM, Brett Porter wrote: > > > >> > >> On 21/04/2010, at 11:13 PM, John Singleton wrote: > >> > >> > Thanks, Brett. > >> > > >> > FWIW, I also noticed this problem with the 2.2 version of Compiler > >> plugin, > >> > which was released a couple of weeks ago. > >> > >> Yes, they both use the same version of the shared component. It's being > >> taken care of. > >> > >> - Brett > >> > >> -- > >> Brett Porter > >> br...@apache.org > >> http://brettporter.wordpress.com/ > >> > >> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > -- > Thomas Sundberg > M. Sc. in Computer Science > > Mobile: +46 70 767 33 15 > Blog: http://thomassundberg.wordpress.com/ > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [ANN] Maven Compiler Plugin 2.3 Released
Thanks, Brett.
FWIW, I also noticed this problem with the 2.2 version of Compiler plugin,
which was released a couple of weeks ago.
On Tue, Apr 20, 2010 at 8:08 PM, Brett Porter wrote:
> Yes, the checksums seem to be incorrect on central. I'll forward this to
> the dev list.
>
> On 21/04/2010, at 5:48 AM, Raphael Ackermann wrote:
>
> > I get the same/similar checksum errors with nexus 1.6.
> > I deleted the plexus-compiler artefacts both from my local and the
> > nexus repository but got the same error still.
> >
> > Raphael
> >
> > On Tue, Apr 20, 2010 at 21:09, John Singleton
> wrote:
> >> I tried to upgrade to this version of the plugin, but am getting
> download
> >> errors on some of its dependencies, namely:
> >>
> >> org.codehaus.plexus:plexus-compiler-api:jar:1.8
> >> org.codehaus.plexus:plexus-compiler-manager:jar:1.8
> >> org.codehaus.plexus:plexus-compiler-javac:jar:1.8
> >>
> >> sample error message from artifactory log:
> >>
> >> repo1: Downloaded '
> >>
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-compiler-javac/1.8/plexus-compiler-javac-1.8.jar
> '
> >> with return code: 200.
> >> 2010-04-20 14:24:17,955 [pool-1-thread-30] [WARN ]
> >> (o.a.e.DownloadServiceImpl:194) - Sending HTTP error code 409: Checksum
> >> policy 'GEN_IF_ABSENT' rejected the artifact
> >> 'plexus-compiler-javac-1.8.jar'. Checksums info:
> [ChecksumInfo{type=SHA-1,
> >> original='69203d97d835ff6851ed1e622ebde635a54ef681',
> >> actual='8e8e1d4ef6c19ab4daaabe387218a74ea44b17c6'},
> ChecksumInfo{type=MD5,
> >> original='dde75ac45679d2a639d25f01da55663e',
> >> actual='41a5a8bc0e92ace66d918c487b5fa345'}].
> >>
> >> Is there really an error in the posted checksums, or is this a problem
> on my
> >> end?
> >>
> >> This error occurs with artifactory 2.2.2 runing on Ubuntu Linux 9.10
> (Karmic
> >> Koala), called from Maven 2.2.1
> >>
> >>
> >> On Sat, Apr 17, 2010 at 6:43 AM, Benjamin Bentmann >wrote:
> >>
> >>> The Maven team is pleased to announce the release of the Maven Compiler
> >>> Plugin, version 2.3.
> >>>
> >>> This plugin is used to compile the sources of your project. See the
> >>> plugin's site for more details:
> >>>
> >>> http://maven.apache.org/plugins/maven-compiler-plugin/
> >>>
> >>> To use the updated plugin in your projects, you need to add the
> >>> following snippet to the plugins or plugin management section of your
> POM:
> >>>
> >>>
> >>>org.apache.maven.plugins
> >>>maven-compiler-plugin
> >>>2.3
> >>>
> >>>
> >>> Release Notes - Maven 2.x Compiler Plugin - Version 2.3
> >>>
> >>> ** Improvement
> >>>* [MCOMPILER-80] - Change default source level to 1.5
> >>>
> >>> Enjoy,
> >>>
> >>>
> >>> -The Maven team
> >>>
> >>>
> >>> -
> >>> 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
> >
>
> --
> Brett Porter
> br...@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: [ANN] Maven Compiler Plugin 2.3 Released
I tried to upgrade to this version of the plugin, but am getting download
errors on some of its dependencies, namely:
org.codehaus.plexus:plexus-compiler-api:jar:1.8
org.codehaus.plexus:plexus-compiler-manager:jar:1.8
org.codehaus.plexus:plexus-compiler-javac:jar:1.8
sample error message from artifactory log:
repo1: Downloaded '
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-compiler-javac/1.8/plexus-compiler-javac-1.8.jar'
with return code: 200.
2010-04-20 14:24:17,955 [pool-1-thread-30] [WARN ]
(o.a.e.DownloadServiceImpl:194) - Sending HTTP error code 409: Checksum
policy 'GEN_IF_ABSENT' rejected the artifact
'plexus-compiler-javac-1.8.jar'. Checksums info: [ChecksumInfo{type=SHA-1,
original='69203d97d835ff6851ed1e622ebde635a54ef681',
actual='8e8e1d4ef6c19ab4daaabe387218a74ea44b17c6'}, ChecksumInfo{type=MD5,
original='dde75ac45679d2a639d25f01da55663e',
actual='41a5a8bc0e92ace66d918c487b5fa345'}].
Is there really an error in the posted checksums, or is this a problem on my
end?
This error occurs with artifactory 2.2.2 runing on Ubuntu Linux 9.10 (Karmic
Koala), called from Maven 2.2.1
On Sat, Apr 17, 2010 at 6:43 AM, Benjamin Bentmann wrote:
> The Maven team is pleased to announce the release of the Maven Compiler
> Plugin, version 2.3.
>
> This plugin is used to compile the sources of your project. See the
> plugin's site for more details:
>
> http://maven.apache.org/plugins/maven-compiler-plugin/
>
> To use the updated plugin in your projects, you need to add the
> following snippet to the plugins or plugin management section of your POM:
>
>
>org.apache.maven.plugins
>maven-compiler-plugin
>2.3
>
>
> Release Notes - Maven 2.x Compiler Plugin - Version 2.3
>
> ** Improvement
>* [MCOMPILER-80] - Change default source level to 1.5
>
> Enjoy,
>
>
> -The Maven team
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
