Re: Error compiling with jasperreports after installing iText 2.1.4
> Kindly let me know if we there are any plans for adding the latest version > of itext jar into maven repository. You'd have to ask the dev team responsible for iText about that. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: war dependent on another war
> i am having trouble having classes of a war in the classpath for another war.. > am using maven 2.x jdk1.5 windows 7 Your classes should be moved to a library jar that both wars depend upon. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: logging level in Mojo - only INFO?
mvn -X ?
--
Best Regards,
AdRiAN ShUM
-Original Message-
From: asookazian [mailto:asookaz...@gmail.com]
Sent: Thursday, July 08, 2010 12:48 AM
To: users@maven.apache.org
Subject: Re: logging level in Mojo - only INFO?
I'm used to using a jboss-log4j.xml with the JBoss AS app to control
logging to console and file appenders. Any answers? thx.
--
View this message in context:
http://maven.40175.n5.nabble.com/logging-level-in-Mojo-only-INFO-tp51099
9p1044783.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
This email is confidential. If you are not the intended recipient, please
delete it from your system and notify the sender immediately. Any unauthorized
use, disclosure, dissemination or copying of this email is prohibited. Taifook
Securities Group, its group companies and their content providers ("Parties")
shall not be responsible for the accuracy or completeness of this email or its
attachment, if any, which could contain virus, be corrupted, destroyed,
incomplete, intercepted, lost or arrive late. The Parties do not accept
liability for any damage caused by this email.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven SPI plugin
haven't seen one, but have thought about implementing it before, open questions were: * source retention, and then mark dep as optional? * annotation takes an optional class argument for when service type is ambiguous? e.g. service type is distant ancestor class * add osgi ds entries? -- sent from a device with a tiny keyboard, so message might be brief. (and if you're like, "hey, that doesn't make any sense cause typing this notice must have taken just as long as typing the original message", please understand that this notice is my preconfigured email signature, so that means I only had to type it once) -- On Aug 8, 2010, at 12:47 PM, Justin Lee wrote: Before I go and write one, has anyone seen a mavenized APT that will scan for annotated classes and build the appropriate SPI manifest for them? It wouldn't be hard to write but it'd save me some time... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Scm 1.4 Released
Hi, The Maven team is pleased to announce the release of the Maven Scm, version 1.4. http://maven.apache.org/scm/ Release Notes - Maven SCM - Version 1.4 ** Bug * [SCM-431] - Username and Password cause NumberFormatException in scm:hg:http URLS * [SCM-444] - Git provider does 'git push' during 'mvn release:prepare' which causes unwanted problems * [SCM-469] - Auto-generated config spec during release:perform contains line element * null * [SCM-525] - Need to specify full outputDirectory for export * [SCM-526] - scm:checkout and scm:export ignores excludes and includes configuration * [SCM-539] - Unparseable date with Mercurial SCM provider * [SCM-551] - Blame command : Unparseable date when locale is not US * [SCM-564] - scm:export does not use "includes" and "excludes" properties * [SCM-568] - Exception No such command 'blame' ** Improvement * [SCM-445] - Extend command coverage of AccuRev provider for use with Continuum and Release Plugin * [SCM-528] - Provide Util.setSettingsDirectory for starteam * [SCM-529] - Provide Xpp3Writers for providers * [SCM-534] - expose getSettingsFile * [SCM-535] - Cache Settings in SvnUtil * [SCM-550] - expose StarteamUtil.getSettingsFile * [SCM-561] - Final cleanup accurev provider for 1.4 ** New Feature * [SCM-521] - Please add support for optional push / merge to the bazaar provider * [SCM-532] - Please add support for blame command * [SCM-542] - Add blame command to Perforce provider * [SCM-543] - Add blame command to ClearCase provider * [SCM-544] - Add blame command to AccuRev provider * [SCM-545] - Add blame command to TFS provider * [SCM-562] - Don't overwrite SVN auth cache Have Fun ! -- The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to build Project which uses specific version of jar not existing in Maven Repo
On Sun, Aug 8, 2010 at 1:16 PM, Dilip wrote: > Is there any way to build the project using maven if there is no specific > version not jar not existing in the maven repository? Until you get that repository manager up and running, you can use "mvn install:install-file ... " to put the jar into your local repo. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Anyone familiar with the maven-nar-plugin?
Hi, I am trying to use this plugin, and I have few problems: 1) On Solaris, he does not manage to work with the CC 2) On WIndows, I don't manage to make it compile a debug mode (I switch the debug flag to true, but the /MD flag does not change to /MDd), and I can't override the /MD. 3) On Windows I have to modify the DLL manfest, althougt I added the options to the linker, it keeps the original value also, and not override it. Any idea? -- View this message in context: http://maven.40175.n5.nabble.com/Anyone-familiar-with-the-maven-nar-plugin-tp2268244p2268244.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 to build Project which uses specific version of jar not existing in Maven Repo
On 08/08/2010 1:16 PM, Dilip wrote: I'm currently using maven for building the existing ant project. I have some of the jar files like itext5.jar, aspectrttools jars for which there are no specific version of the jar (eg: itext5.0 jar file) exists in the maven repository. Is there any way to build the project using maven if there is no specific version not jar not existing in the maven repository? Thanks in advance, Dilip Yes. You install your own repository - Nexus, for example, and upload the artifacts manually into it. This is a common problem since some projects have licenses that prevent it being put into public repositories. One of the many reasons to have your own repostory if you are going to use Maven. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven SPI plugin
Before I go and write one, has anyone seen a mavenized APT that will scan for annotated classes and build the appropriate SPI manifest for them? It wouldn't be hard to write but it'd save me some time...
How to build Project which uses specific version of jar not existing in Maven Repo
I'm currently using maven for building the existing ant project. I have some of the jar files like itext5.jar, aspectrttools jars for which there are no specific version of the jar (eg: itext5.0 jar file) exists in the maven repository. Is there any way to build the project using maven if there is no specific version not jar not existing in the maven repository? Thanks in advance, Dilip -- View this message in context: http://maven.40175.n5.nabble.com/How-to-build-Project-which-uses-specific-version-of-jar-not-existing-in-Maven-Repo-tp2268124p2268124.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: force maven to redownload/refresh "released" dependencies
>> I rapidly browsed the thread, please excuse me if I missed something. >> Isn't mvn dependency:purge-local-repository the solution? > > The issue identified by the OP is that there's no way to (pro-actively) > detect that a release has changed. I apologize in advance for a TERRIBLE suggestion... assuming you are running a local MRM and thus merely consuming local bandwith... you could bind purge-local-repo to init phase. PS- Don't do this! Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 8, 2010, at 5:32 AM, Baptiste MATHUS wrote: > Hi, > > I rapidly browsed the thread, please excuse me if I missed something. > Isn't mvn dependency:purge-local-repository the solution? The issue identified by the OP is that there's no way to (pro-actively) detect that a release has changed. > > Please note that I'm 100% with people saying releases must never change. And > it's so important it's not something specific to maven world. Imagine you > release a 1.0 to some client, and try to find the corresponding sources when > encountering a blocking bug. You're either going not to be able to find the > right sources, or to have to do some ugly thing like storing svn-revision in > the MANIFEST while packaging the jar... That's just something that should > not be done in the software world, period. > > Cheers > > Le 5 août 2010 22:08:03 UTC+2, Wayne Fay a écrit : > >>> The network traffic that that would cause in a modern project with dozens >> of >>> dependencies would create a real nuisance. >> >> If every artifact had md5 and sha1 hashes etc, then the traffic would >> merely be to check the hashes against the local artifact... which >> Maven already does, and complains when things don't match. >> >> Note: I'm not encouraging this approach. Releases must never change, >> period, end of story. Push another release if you find a given release >> is broken. >> >> Wayne >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 08/08/2010 5:32 AM, Baptiste MATHUS wrote: Hi, I rapidly browsed the thread, please excuse me if I missed something. Isn't mvn dependency:purge-local-repository the solution? Please note that I'm 100% with people saying releases must never change. And it's so important it's not something specific to maven world. Imagine you release a 1.0 to some client, and try to find the corresponding sources when encountering a blocking bug. You're either going not to be able to find the right sources, or to have to do some ugly thing like storing svn-revision in the MANIFEST while packaging the jar... That's just something that should not be done in the software world, period. That is exactly what happened to us using an open source project. Caused grief for a long time. One is never really sure which artifact or set of sources match up with what you are running. Ron Cheers Le 5 août 2010 22:08:03 UTC+2, Wayne Fay a écrit : The network traffic that that would cause in a modern project with dozens of dependencies would create a real nuisance. If every artifact had md5 and sha1 hashes etc, then the traffic would merely be to check the hashes against the local artifact... which Maven already does, and complains when things don't match. Note: I'm not encouraging this approach. Releases must never change, period, end of story. Push another release if you find a given release is broken. 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
Re: war dependent on another war
An alternative is an overlay. This is perhaps overkill for just some classes. org.apache.maven.plugins maven-war-plugin com.basistech.jug gate-home gate-home zip WEB-INF On Sun, Aug 8, 2010 at 5:53 AM, Mark Struberg wrote: > checked our Jira and found http://jira.codehaus.org/browse/MWAR-73 from 2006. > I'll check if parts are still missing and fix it or set the jira to resolved > if > all is ok nowadays. > > LieGrue, > strub > > > > - Original Message >> From: Mark Struberg >> To: Maven Users List >> Sent: Sun, August 8, 2010 11:48:57 AM >> Subject: Re: war dependent on another war >> >> Hi! >> >> Use the 'archiveClasses' and 'attachClasses' [1] options of the >>maven-war-plugin >> >> in your first WAR file. This way all your classes of this war will get jared >>and >> >> used this way in WEB-INF/lib as jar instead of WEB-INF/classes. The 2nd >> option >> >> will tell maven to treat this jar as 'attached artifact' [2]. If you look at >> your local repository in ~/.m2/repository/... for your WAR, you will see a >> '..-webclasses.jar' (not 100% sure about the qualifier name, this got >> changed > >> since I first hacked this years ago). You can then use this jar as >> dependency > >> with this classifier. The groupId and artifactId are the ones from your WAR >> file. >> >> >> LieGrue, >> strub >> >> [1] >>http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses >> [2] >>http://docs.codehaus.org/display/MAVEN/Packaging+vs+Type+-+Derived+and+Attached+Artifacts >>s >> >> >> >> - - Original Message >> > From: Aneesh K raj >> > To: users@maven.apache.org >> > Sent: Sun, August 8, 2010 11:39:00 AM >> > Subject: war dependent on another war >> > >> > hi, >> > >> > i am having trouble having classes of a war in the classpath for another >> war.. >> > am using maven 2.x jdk1.5 windows 7 >> > >> > i had added the below to the pom.xml for the dependent war but it didnt >>work >> >> >out.. >> > >> > >> > .. >> > .. >> > .. >> > war >> > .. >> > >> >> >> >> >> - >> 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 > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: war dependent on another war
checked our Jira and found http://jira.codehaus.org/browse/MWAR-73 from 2006. I'll check if parts are still missing and fix it or set the jira to resolved if all is ok nowadays. LieGrue, strub - Original Message > From: Mark Struberg > To: Maven Users List > Sent: Sun, August 8, 2010 11:48:57 AM > Subject: Re: war dependent on another war > > Hi! > > Use the 'archiveClasses' and 'attachClasses' [1] options of the >maven-war-plugin > > in your first WAR file. This way all your classes of this war will get jared >and > > used this way in WEB-INF/lib as jar instead of WEB-INF/classes. The 2nd > option > > will tell maven to treat this jar as 'attached artifact' [2]. If you look at > your local repository in ~/.m2/repository/... for your WAR, you will see a > '..-webclasses.jar' (not 100% sure about the qualifier name, this got > changed > since I first hacked this years ago). You can then use this jar as > dependency > with this classifier. The groupId and artifactId are the ones from your WAR > file. > > > LieGrue, > strub > > [1] >http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses > [2] >http://docs.codehaus.org/display/MAVEN/Packaging+vs+Type+-+Derived+and+Attached+Artifacts >s > > > > - - Original Message > > From: Aneesh K raj > > To: users@maven.apache.org > > Sent: Sun, August 8, 2010 11:39:00 AM > > Subject: war dependent on another war > > > > hi, > > > > i am having trouble having classes of a war in the classpath for another > war.. > > am using maven 2.x jdk1.5 windows 7 > > > > i had added the below to the pom.xml for the dependent war but it didnt >work > > >out.. > > > > > > .. > > .. > > .. > >war > >.. > > > > > > > - > 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: war dependent on another war
Hi! Use the 'archiveClasses' and 'attachClasses' [1] options of the maven-war-plugin in your first WAR file. This way all your classes of this war will get jared and used this way in WEB-INF/lib as jar instead of WEB-INF/classes. The 2nd option will tell maven to treat this jar as 'attached artifact' [2]. If you look at your local repository in ~/.m2/repository/... for your WAR, you will see a '..-webclasses.jar' (not 100% sure about the qualifier name, this got changed since I first hacked this years ago). You can then use this jar as dependency with this classifier. The groupId and artifactId are the ones from your WAR file. LieGrue, strub [1] http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses [2] http://docs.codehaus.org/display/MAVEN/Packaging+vs+Type+-+Derived+and+Attached+Artifacts - Original Message > From: Aneesh K raj > To: users@maven.apache.org > Sent: Sun, August 8, 2010 11:39:00 AM > Subject: war dependent on another war > > hi, > > i am having trouble having classes of a war in the classpath for another war.. > am using maven 2.x jdk1.5 windows 7 > > i had added the below to the pom.xml for the dependent war but it didnt work > >out.. > > > .. > .. > .. > war >.. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Hi, I rapidly browsed the thread, please excuse me if I missed something. Isn't mvn dependency:purge-local-repository the solution? Please note that I'm 100% with people saying releases must never change. And it's so important it's not something specific to maven world. Imagine you release a 1.0 to some client, and try to find the corresponding sources when encountering a blocking bug. You're either going not to be able to find the right sources, or to have to do some ugly thing like storing svn-revision in the MANIFEST while packaging the jar... That's just something that should not be done in the software world, period. Cheers Le 5 août 2010 22:08:03 UTC+2, Wayne Fay a écrit : > > The network traffic that that would cause in a modern project with dozens > of > > dependencies would create a real nuisance. > > If every artifact had md5 and sha1 hashes etc, then the traffic would > merely be to check the hashes against the local artifact... which > Maven already does, and complains when things don't match. > > Note: I'm not encouraging this approach. Releases must never change, > period, end of story. Push another release if you find a given release > is broken. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: adding non-class files to a JAR
Your plugin should always generate into the outputDirectory (or
testOutputDirectory).
Please be aware not using "target" in the code. This name can always be
redefined in the pom. Always refer to it as
${project.build.outputDirectory}.
Cheers
Le 5 août 2010 17:16:04 UTC+2, Haszlakiewicz, Eric
a écrit :
> >-Original Message-
> >From: asookazian [mailto:asookaz...@gmail.com]
> >
> >Wayne Fay wrote:
> >>
> >>> anybody know how to get Maven to include non-class files into a JAR?
> >>>
> >>> i have .jrxml files that I precompile into .jasper files via a
> custom
> >>> plugin
> >>> but maven is not including them in the EAR AFAIK.
> >>
> >> Put them in the correct directory (src/main/resources in general) and
> >> they should be bundled into the Jar properly.
>
> >thx for the response. the compiled .jasper files are in
> sub-directories
> >inside src/main/resources, so perhaps that is the problem and they all
> need
> >to be placed in src/main/resources directly so they are included in the
> >JAR.
> >let me give that a shot! thx.
>
> If you're trying to include compiled files, I think they should be
> created in the *target* directory. Putting build output (the .jasper
> files) into the source directories seems wrong. I just tried a quick
> test, and maven will happily include anything I put in target/classes
> into the jar file. You probably need to adjust how your .jasper files
> are created so they go in the right place.
>
> eric
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Baptiste MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
