Re: NOTE! Re: [ANN] Maven Compiler Plugin 3.1 Released
Note that as a general rule do not look at JIRA to understand how a plugin should be configured. Look at the doc, which actually seems correctly up to date: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html Cheers Le 8 avr. 2013 16:06, "Matthew Adams" a écrit : > It's worth noting that the property to control skipping the compilation of > main sources is "maven.main.skip" (like "maven.test.skip"), not > "maven.compiler.main.skip", > despite what the title of the issue says. It was changed during the course > of discussion. > > Further, the plugin configuration boolean parameter is called "skipMain": > true > > -matthew > > > On Mon, Apr 8, 2013 at 5:15 AM, Olivier Lamy wrote: > > > The Apache Maven team is pleased to announce the release of the Maven > > Compiler Plugin, version 3.1 > > > > The Compiler Plugin is used to compile the sources of your project. > > The default compiler is javac and is used to compile Java sources. > > Also note that at present the default source setting is 1.5 and the > > default target setting is 1.5, independently of the JDK you run Maven > > with. > > > > http://maven.apache.org/plugins/maven-compiler-plugin/ > > > > You should specify the version in your project's plugin configuration: > > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > 3.1 > > > > > > Release Notes - Apache Maven 2.x Compiler Plugin - Version 3.1 > > > > ** Bug > > * [MCOMPILER-178] - can't specify -Xlint:-path option without > > violation of XML well-formness > > * [MCOMPILER-187] - incremental stuff detect changes even if > > nothing has changed means too much compilation > > * [MCOMPILER-190] - No compile errors with plexus-compiler-eclipse > > * [MCOMPILER-192] - No error reporting with forked compiler when > > Compiler includes non java files > > * [MCOMPILER-198] - Some parameters introduced in version 3.0 are > > annoted with since 2.6 > > * [MCOMPILER-199] - Plugin 3.0 does not compile src/main/groovy if > > neither src/main/java nor src/main/resources folders exist > > > > ** Improvement > > * [MCOMPILER-188] - Add a flag to be able to disable incremental > > feature > > > > ** New Feature > > * [MCOMPILER-132] - Provide general "maven.compiler.main.skip" > > attribute > > > > > > Have Fun, > > -- > > The Apache Maven team > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > -- > mailto:matt...@matthewadams.me > skype:matthewadams12 > googletalk:matt...@matthewadams.me > http://matthewadams.me > http://www.linkedin.com/in/matthewadams >
how did I get a snapshot into my archetype list?
Can someone tell me how to fix this, or is the official version of the archetype catalog on central in fact wrong? 750: local -> org.apache.cxf:cxf-jaxrs-service-archetype (Simple CXF JAX-RS webapp service using Spring configuration) Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 254: 750 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 10.302s [INFO] Finished at: Mon Apr 08 17:42:46 EDT 2013 [INFO] Final Memory: 9M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: The desired archetype does not exist (org.apache.cxf:cxf-jaxrs-service-archetype:2.5.1-SNAPSHOT) -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to customize build-classpath goal?
I need to build a property file that has all the classpath entries and build-classpath does that, but I also need to prefix the classpath with some custom entries, how can I do that? If build-classpath can't support this is there a way in maven were I could apply the custom changes after the file is generated? Or as last resort I could even add a new property to that same file that has the custom prefix. Is there a maven plugin that lets me add/modify properties in existing property files? Any ideas how to do this?
Re: Issue with ManifestResourceTransformer and string length limit for main class
> I've added a maven-shade-plugin for the infamous Spring issues when creating > an uber jar. Anyway in my ManifestResourceTransformer I specify my Which "infamous" Spring issues are you talking about? > jar, I get a class not found issue. When I expand the jar file that Maven > created and opened the Manifest.MF file, the class name for Main-Class was > placed in two lines. This is what it looks like: ... > Main-Class: com.albeingters.buslogics.variablespeedcontroller.BusVSGat > e Read the manifest spec again. [1] The line split is legal and required. The executing JRE should handle it just fine. If it is not, that is a bug in your JRE. Wayne [1] http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Notes_on_Manifest_and_Signature_Files Notes on Manifest and Signature Files Following is a list of additional restrictions and rules that apply to manifest and signature files. ... Line length: No line may be longer than 72 bytes (not characters), in its UTF8-encoded form. If a value would make the initial line longer than this, it should be continued on extra lines (each starting with a single SPACE). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to create maven plugin using archetype
> I am very new in Maven. I need to create maven plugin which should print > names. Look at the (free, open source) code for the plugins provided by the Apache Maven team to get some advice on how to proceed. Ideally you would pick a plugin which performs a similar function to what you desire as a base on which you could build your own plugin. > I have tried to look for any tutorial in creating plugin using archetype. no > success Need help or you can provide good source on maven plugin Tell us more about what you expect the plugin to do and maybe we'll have advice. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Handle XSDs with Maven and Nexus?
> How would you publish a XSD for a project and make it available for > other Maven builds? I expect that MRRP would be a part of the solution: http://maven.apache.org/plugins/maven-remote-resources-plugin/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: simple maven 2 report plugin example
Please, did you find a solution ? I've got the same pbm (NPE DefaultLifecycleExecutor.java:931) -- View this message in context: http://maven.40175.n5.nabble.com/simple-maven-2-report-plugin-example-tp4529029p5753182.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
NOTE! Re: [ANN] Maven Compiler Plugin 3.1 Released
It's worth noting that the property to control skipping the compilation of main sources is "maven.main.skip" (like "maven.test.skip"), not "maven.compiler.main.skip", despite what the title of the issue says. It was changed during the course of discussion. Further, the plugin configuration boolean parameter is called "skipMain": true -matthew On Mon, Apr 8, 2013 at 5:15 AM, Olivier Lamy wrote: > The Apache Maven team is pleased to announce the release of the Maven > Compiler Plugin, version 3.1 > > The Compiler Plugin is used to compile the sources of your project. > The default compiler is javac and is used to compile Java sources. > Also note that at present the default source setting is 1.5 and the > default target setting is 1.5, independently of the JDK you run Maven > with. > > http://maven.apache.org/plugins/maven-compiler-plugin/ > > You should specify the version in your project's plugin configuration: > > > org.apache.maven.plugins > maven-compiler-plugin > 3.1 > > > Release Notes - Apache Maven 2.x Compiler Plugin - Version 3.1 > > ** Bug > * [MCOMPILER-178] - can't specify -Xlint:-path option without > violation of XML well-formness > * [MCOMPILER-187] - incremental stuff detect changes even if > nothing has changed means too much compilation > * [MCOMPILER-190] - No compile errors with plexus-compiler-eclipse > * [MCOMPILER-192] - No error reporting with forked compiler when > Compiler includes non java files > * [MCOMPILER-198] - Some parameters introduced in version 3.0 are > annoted with since 2.6 > * [MCOMPILER-199] - Plugin 3.0 does not compile src/main/groovy if > neither src/main/java nor src/main/resources folders exist > > ** Improvement > * [MCOMPILER-188] - Add a flag to be able to disable incremental > feature > > ** New Feature > * [MCOMPILER-132] - Provide general "maven.compiler.main.skip" > attribute > > > Have Fun, > -- > The Apache Maven team > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- mailto:matt...@matthewadams.me skype:matthewadams12 googletalk:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
how to create maven plugin using archetype
I am very new in Maven. I need to create maven plugin which should print names. So if I want to use this plugin in my other projects I need to have below plugin configuration test1 test2 test3 true I have tried to look for any tutorial in creating plugin using archetype. no success Need help or you can provide good source on maven plugin -- View this message in context: http://maven.40175.n5.nabble.com/how-to-create-maven-plugin-using-archetype-tp5753137.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
Issue with ManifestResourceTransformer and string length limit for main class
Hi,
I've added a maven-shade-plugin for the infamous Spring issues when creating
an uber jar. Anyway in my ManifestResourceTransformer I specify my
executable class. When I run mvn clean/install and then try to execute the
jar, I get a class not found issue. When I expand the jar file that Maven
created and opened the Manifest.MF file, the class name for Main-Class was
placed in two lines. This is what it looks like:
--
Manifest-Version: 1.0
Build-Jdk: 1.7.0_17
Built-By: Dell
Created-By: Apache Maven
Main-Class: com.albeingters.buslogics.variablespeedcontroller.BusVSGat
e
Archiver-Version: Plexus Archiver
--
Notice above that the "e" was put on the next line. For testing purposes,
when I truncated the class name a couple of characters, everything seemed to
work fine. So looks like Maven has some type of string length limit for the
main class. Below is my pom configuration for that shader:
org.apache.maven.plugins
maven-shade-plugin
2.0
package
shade
true
META-INF/spring.handlers
META-INF/spring.schemas
${app.main.class}
Using JDK 1.7_17 and Maven 3.0.5 command line
--
View this message in context:
http://maven.40175.n5.nabble.com/Issue-with-ManifestResourceTransformer-and-string-length-limit-for-main-class-tp5752842.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: Multiple JDK Versions
http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
On 8 April 2013 12:41, virg g <06v...@gmail.com> wrote:
> Thank you for the reply. As a developer i would be knowing, whether it is
> compiled with which jdk version. Once project's jars/wars released, they
> will be validated/tracked with Build-Jdk of manifest info of jars and wars,
> which is actually showing different than actual. At least how to override
> this property in maven-jar-plugin. What is the property is generates
> Build-JDK
> value? so that atelast i cna use this.
> Thank you. Help is highly appreciated
>
>
> On Mon, Apr 8, 2013 at 4:51 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > The manifest is not generated by JavaC but by the tool used to JAR up the
> > files. That would be the Maven Jar Plugin which does not fork the build
> but
> > actually generates the JAR file using the JRE that you launch Maven with.
> >
> > It should not matter whether you use Java 1.2 or Java 1.8 to JAR up the
> > files as the JAR specification has not changed. What should matter to you
> > is the bytecode version, and there are tools such as AnimalSniffer that
> can
> > help you verify that the bytecode version is the version you believe it
> > should be
> >
> >
> > On 8 April 2013 11:41, virg g <06v...@gmail.com> wrote:
> >
> > > Hi,
> > > I want to compile my code with multiple JDK versions 1.4, 1.5, 1.6. I
> am
> > > using maven-compiler-plugin 3.0.
> > > i am changing ${JAVA_1_5_HOME}/bin/javac
> > parameter
> > > in maven-compiler-plugin and also set source and target to 1.5. But my
> > > default JAVA_HOME is 1.6. The source is getting compiled with 1.5 java
> > > compiler. But if the the manifest file version always shows Build-Jdk:
> > as
> > > 1.6. It is picking from my JAVA_HOME, Not the the javac version it is
> > > built. I have tried same thing even with maven-toolchains-plugin
> plugin
> > > also by setting all jdk paths. How to change manifest info to point to
> > > correct jdk? Do i have to reset JAVA_HOME everytime if i change jdk?
> > >
> >
>
Re: Multiple JDK Versions
Thank you for the reply. As a developer i would be knowing, whether it is
compiled with which jdk version. Once project's jars/wars released, they
will be validated/tracked with Build-Jdk of manifest info of jars and wars,
which is actually showing different than actual. At least how to override
this property in maven-jar-plugin. What is the property is generates Build-JDK
value? so that atelast i cna use this.
Thank you. Help is highly appreciated
On Mon, Apr 8, 2013 at 4:51 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> The manifest is not generated by JavaC but by the tool used to JAR up the
> files. That would be the Maven Jar Plugin which does not fork the build but
> actually generates the JAR file using the JRE that you launch Maven with.
>
> It should not matter whether you use Java 1.2 or Java 1.8 to JAR up the
> files as the JAR specification has not changed. What should matter to you
> is the bytecode version, and there are tools such as AnimalSniffer that can
> help you verify that the bytecode version is the version you believe it
> should be
>
>
> On 8 April 2013 11:41, virg g <06v...@gmail.com> wrote:
>
> > Hi,
> > I want to compile my code with multiple JDK versions 1.4, 1.5, 1.6. I am
> > using maven-compiler-plugin 3.0.
> > i am changing ${JAVA_1_5_HOME}/bin/javac
> parameter
> > in maven-compiler-plugin and also set source and target to 1.5. But my
> > default JAVA_HOME is 1.6. The source is getting compiled with 1.5 java
> > compiler. But if the the manifest file version always shows Build-Jdk:
> as
> > 1.6. It is picking from my JAVA_HOME, Not the the javac version it is
> > built. I have tried same thing even with maven-toolchains-plugin plugin
> > also by setting all jdk paths. How to change manifest info to point to
> > correct jdk? Do i have to reset JAVA_HOME everytime if i change jdk?
> >
>
Re: Multiple JDK Versions
The manifest is not generated by JavaC but by the tool used to JAR up the
files. That would be the Maven Jar Plugin which does not fork the build but
actually generates the JAR file using the JRE that you launch Maven with.
It should not matter whether you use Java 1.2 or Java 1.8 to JAR up the
files as the JAR specification has not changed. What should matter to you
is the bytecode version, and there are tools such as AnimalSniffer that can
help you verify that the bytecode version is the version you believe it
should be
On 8 April 2013 11:41, virg g <06v...@gmail.com> wrote:
> Hi,
> I want to compile my code with multiple JDK versions 1.4, 1.5, 1.6. I am
> using maven-compiler-plugin 3.0.
> i am changing ${JAVA_1_5_HOME}/bin/javac parameter
> in maven-compiler-plugin and also set source and target to 1.5. But my
> default JAVA_HOME is 1.6. The source is getting compiled with 1.5 java
> compiler. But if the the manifest file version always shows Build-Jdk: as
> 1.6. It is picking from my JAVA_HOME, Not the the javac version it is
> built. I have tried same thing even with maven-toolchains-plugin plugin
> also by setting all jdk paths. How to change manifest info to point to
> correct jdk? Do i have to reset JAVA_HOME everytime if i change jdk?
>
Multiple JDK Versions
Hi,
I want to compile my code with multiple JDK versions 1.4, 1.5, 1.6. I am
using maven-compiler-plugin 3.0.
i am changing ${JAVA_1_5_HOME}/bin/javac parameter
in maven-compiler-plugin and also set source and target to 1.5. But my
default JAVA_HOME is 1.6. The source is getting compiled with 1.5 java
compiler. But if the the manifest file version always shows Build-Jdk: as
1.6. It is picking from my JAVA_HOME, Not the the javac version it is
built. I have tried same thing even with maven-toolchains-plugin plugin
also by setting all jdk paths. How to change manifest info to point to
correct jdk? Do i have to reset JAVA_HOME everytime if i change jdk?
[ANN] Maven Compiler Plugin 3.1 Released
The Apache Maven team is pleased to announce the release of the Maven Compiler Plugin, version 3.1 The Compiler Plugin is used to compile the sources of your project. The default compiler is javac and is used to compile Java sources. Also note that at present the default source setting is 1.5 and the default target setting is 1.5, independently of the JDK you run Maven with. http://maven.apache.org/plugins/maven-compiler-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-compiler-plugin 3.1 Release Notes - Apache Maven 2.x Compiler Plugin - Version 3.1 ** Bug * [MCOMPILER-178] - can't specify -Xlint:-path option without violation of XML well-formness * [MCOMPILER-187] - incremental stuff detect changes even if nothing has changed means too much compilation * [MCOMPILER-190] - No compile errors with plexus-compiler-eclipse * [MCOMPILER-192] - No error reporting with forked compiler when Compiler includes non java files * [MCOMPILER-198] - Some parameters introduced in version 3.0 are annoted with since 2.6 * [MCOMPILER-199] - Plugin 3.0 does not compile src/main/groovy if neither src/main/java nor src/main/resources folders exist ** Improvement * [MCOMPILER-188] - Add a flag to be able to disable incremental feature ** New Feature * [MCOMPILER-132] - Provide general "maven.compiler.main.skip" attribute Have Fun, -- The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Handle XSDs with Maven and Nexus?
I thought I had written that down... but it would appear that I didn't!
Be a good idea for somebody (hint, if you are reading this, that somebody
is you) to contribute such a packaging type plugin over at mojo... remove a
lot of people's confusion though
On 8 April 2013 10:18, Anders Hammar wrote:
> One could even create a custom packaging type "xsd" to use. That's what
> I've done for wsdl files for a customer. It's meta data and having a
> specific packaging type instead of a general (and incorrect) "pom"
> packaging type is good.
>
> /Anders
>
>
> On Mon, Apr 8, 2013 at 10:06 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > There are many ways to skin this cat...
> >
> > If I were doing this I would take the following slant...
> >
> > 1. I like to keep to publishing 1 build-consumable artifact per GAV... (I
> > don't see javadoc or sources as artifacts in this regard as they are
> > *typically* consumed by people and not builds)
> > 2. I really don't mind having lots of modules.
> >
> > The XSD can be generated in one of two ways:
> >
> > a) The XSD is generated by hand
> > b) The XSD is generated from code
> >
> > With the generated by hand, I would just create a separate module for the
> > XSD only. Unless I was doing a lot of XSDs I would hijack
> > pom and use buildhelper-m-p to attach the XSD to
> the
> > reactor that would result in the XSD being downloadable directly over
> > http(s) from the Maven repo that the project gets deployed to at
> >
> >
> http(s)://{hostname}/{context-path}/{groupIdwithdotsreplacedbyslashes}/{artifactId}/{version}/{artifactId}-{version}.xsd
> > I would very much try to avoid doing anything else in that module, IOW
> when
> > generating code against the XSD I would do that in a different module
> that
> > depends on the XSD and uses dependency:copy-dependencies to copy the XSD
> > into a location where it can be fed to the code generation tools.
> >
> > With the generating from code, things get a tad trickier... my goal would
> > be to be able to produce the XSD from the .jar by e.g. parsing
> annotations,
> > or perhaps even by unpacking the .jar and pulling out the XSD that was
> > embedded in the .jar if the code generation strategy puts the XSD inside
> > the .jar as a necessary side-effect of the code generation process... all
> > those would allow me to basically treat as before... *but* reality may
> > hit... e.g. annotations may not be retained in the compiled code, the XSD
> > could be generated from the javadoc comments in the source code and not
> > java1.5 annotations, etc... in those cases I would just attach the XSD
> as a
> > side artifact to the .jar module using buildhelper-m-p as, while it is a
> > noble goal to keep to 1 artifact per module, sometimes you need to do
> what
> > you need to do
> >
> > On 8 April 2013 08:53, Thomas Sundberg wrote:
> >
> > > Hi!
> > >
> > > We seem to want to publish XSDs (XML Schema Definitions) in a project.
> > > I have been told that we want to make XSDs available at a well known
> > > url.
> > >
> > > We are using Maven and I tried to sell the idea that we create a jar
> > > that contains the XSD and add this as a dependency in a Maven build.
> > > This wasn't a good enough solution.
> > >
> > > How would you publish a XSD for a project and make it available for
> > > other Maven builds?
> > >
> > > We are using Nexus so publishing there is an option.
> > >
> > > /Thomas
> > >
> > > --
> > > Thomas Sundberg
> > > M. Sc. in Computer Science
> > >
> > > Mobile: +46 70 767 33 15
> > > Blog: http://thomassundberg.wordpress.com/
> > > Twitter: @thomassundberg
> > >
> > > Better software through faster feedback
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>
Re: Handle XSDs with Maven and Nexus?
One could even create a custom packaging type "xsd" to use. That's what
I've done for wsdl files for a customer. It's meta data and having a
specific packaging type instead of a general (and incorrect) "pom"
packaging type is good.
/Anders
On Mon, Apr 8, 2013 at 10:06 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> There are many ways to skin this cat...
>
> If I were doing this I would take the following slant...
>
> 1. I like to keep to publishing 1 build-consumable artifact per GAV... (I
> don't see javadoc or sources as artifacts in this regard as they are
> *typically* consumed by people and not builds)
> 2. I really don't mind having lots of modules.
>
> The XSD can be generated in one of two ways:
>
> a) The XSD is generated by hand
> b) The XSD is generated from code
>
> With the generated by hand, I would just create a separate module for the
> XSD only. Unless I was doing a lot of XSDs I would hijack
> pom and use buildhelper-m-p to attach the XSD to the
> reactor that would result in the XSD being downloadable directly over
> http(s) from the Maven repo that the project gets deployed to at
>
> http(s)://{hostname}/{context-path}/{groupIdwithdotsreplacedbyslashes}/{artifactId}/{version}/{artifactId}-{version}.xsd
> I would very much try to avoid doing anything else in that module, IOW when
> generating code against the XSD I would do that in a different module that
> depends on the XSD and uses dependency:copy-dependencies to copy the XSD
> into a location where it can be fed to the code generation tools.
>
> With the generating from code, things get a tad trickier... my goal would
> be to be able to produce the XSD from the .jar by e.g. parsing annotations,
> or perhaps even by unpacking the .jar and pulling out the XSD that was
> embedded in the .jar if the code generation strategy puts the XSD inside
> the .jar as a necessary side-effect of the code generation process... all
> those would allow me to basically treat as before... *but* reality may
> hit... e.g. annotations may not be retained in the compiled code, the XSD
> could be generated from the javadoc comments in the source code and not
> java1.5 annotations, etc... in those cases I would just attach the XSD as a
> side artifact to the .jar module using buildhelper-m-p as, while it is a
> noble goal to keep to 1 artifact per module, sometimes you need to do what
> you need to do
>
> On 8 April 2013 08:53, Thomas Sundberg wrote:
>
> > Hi!
> >
> > We seem to want to publish XSDs (XML Schema Definitions) in a project.
> > I have been told that we want to make XSDs available at a well known
> > url.
> >
> > We are using Maven and I tried to sell the idea that we create a jar
> > that contains the XSD and add this as a dependency in a Maven build.
> > This wasn't a good enough solution.
> >
> > How would you publish a XSD for a project and make it available for
> > other Maven builds?
> >
> > We are using Nexus so publishing there is an option.
> >
> > /Thomas
> >
> > --
> > Thomas Sundberg
> > M. Sc. in Computer Science
> >
> > Mobile: +46 70 767 33 15
> > Blog: http://thomassundberg.wordpress.com/
> > Twitter: @thomassundberg
> >
> > Better software through faster feedback
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
Re: Installing local dependency with the maven-install-plugin before the build
In order to ensure that the build plan is sequenced correctly, Maven needs to map out the requirements of all the plugins that will be invoked as part of the build plan. If any of the plugins that are involved in the build plan indicate that they require dependency resolution, then that means that there is a possibility that the modules within the reactor on which those plugins will execute may have dependencies within the reactor which could impact the build plan. Therefore Maven will try to resolve the dependencies of those modules *before* the build starts in order to establish if the dependencies of that module indirectly depend on artifacts within the reactor which would therefore mandate a resequencing of the reactor build plan. When you try the install:install-file hack, the very first time you run, there is no way for Maven to resolve the dependency, and therefore Maven says: "Hmmm, cannot find this at all, therefore the build will faile, and fail fast is what we do... java.lang.System.exit(1)!" The solutions you can choose are all rather similar to those I outline in this blog post: http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html HTH -Stephen On 8 April 2013 09:53, Eugen Paraschiv wrote: > Hi, > I am having a problem with the following scenario - I'm attempting to use > the *maven-install-plugin* to install a jar in my local repository. I am > binding the *install-file* goal to the *validate* phase (very early on), so > that the jar would be installed before anything else, and so that the build > process will have it available. > However, that doesn't seem to work as expected - the dependency I'm trying > to install is for some reason required even earlier, and so I get: > *[ERROR] Failed to execute goal on project my-project: Could not resolve > dependencies for project org:my-project:jar:0.16-SNAPSHOT: Could not find > artifact org:new-dep:jar:0.16-SNAPSHOT in jboss-public-repository-group ( > https://repository.jboss.org/nexus/content/repositories/central/) -> [Help > 1]* > With debug mode on - it looks like the default plugins are executed, and > the first thing they require is the full dependency tree to be OK: > [ERROR] Failed to execute goal on project launchpad-touchdata-api: Could > not resolve dependencies for project > org:launchpad-touchdata-api:jar:0.16-SNAPSHOT: The repository system is > offline but the artifact org:launchpad-security-api:jar:0.16-SNAPSHOT is > not available in the local repository. -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal on project launchpad-touchdata-api: Could not resolve dependencies for > project org:launchpad-touchdata-api:jar:0.16-SNAPSHOT: The repository > system is offline but the artifact > org:launchpad-security-api:jar:0.16-SNAPSHOT is not available in the local > repository. > at > > org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210) > at > > org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117) > at > > org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258) > at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201) > at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher
Installing local dependency with the maven-install-plugin before the build
Hi, I am having a problem with the following scenario - I'm attempting to use the *maven-install-plugin* to install a jar in my local repository. I am binding the *install-file* goal to the *validate* phase (very early on), so that the jar would be installed before anything else, and so that the build process will have it available. However, that doesn't seem to work as expected - the dependency I'm trying to install is for some reason required even earlier, and so I get: *[ERROR] Failed to execute goal on project my-project: Could not resolve dependencies for project org:my-project:jar:0.16-SNAPSHOT: Could not find artifact org:new-dep:jar:0.16-SNAPSHOT in jboss-public-repository-group ( https://repository.jboss.org/nexus/content/repositories/central/) -> [Help 1]* With debug mode on - it looks like the default plugins are executed, and the first thing they require is the full dependency tree to be OK: [ERROR] Failed to execute goal on project launchpad-touchdata-api: Could not resolve dependencies for project org:launchpad-touchdata-api:jar:0.16-SNAPSHOT: The repository system is offline but the artifact org:launchpad-security-api:jar:0.16-SNAPSHOT is not available in the local repository. -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project launchpad-touchdata-api: Could not resolve dependencies for project org:launchpad-touchdata-api:jar:0.16-SNAPSHOT: The repository system is offline but the artifact org:launchpad-security-api:jar:0.16-SNAPSHOT is not available in the local repository. at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Is that correct? If so, is there no way to use maven-install-plugin to install the local dependency before the build will actually require the dependency? I will mention that, if the jar is installed like this, but it's not required by this project directly as a dependency - it gets installed just fine. Any help is appreciated. Thanks. Eugen. -- Eugen Paraschiv Senior Java Programmer, Optaros Mobile: +40728896170 Blog: www.baeldung.com Twitter: https://twitter.com/baeldung
Re: Handle XSDs with Maven and Nexus?
Even once XSDs are published at a well-known location (necessary for non-Maven validating parsers), I still like bundling XSDs for offline Maven builds (why should your CI go down when a web server is offline?). JAR bundling is great. Defeat the jar-haters by turning it around: publish static XSDs and then bundle them into JARs for Maven. For example, GeoSciML is published as a bunch of static files on an apache instance: http://www.geosciml.org/geosciml/2.0/ But I needed tests that worked offline, so for GeoTools I bundled some artifacts that I pushed onto a Maven repo: https://github.com/geotools/geotools/tree/master/modules/extension/app-schema/app-schema-packages These do not get run as part of the standard build; publication is a manual process because the schemas are outside GeoTools governance. Then the code has some wrappers: https://github.com/geotools/geotools/tree/master/modules/extension/app-schema/app-schema-resolver around a resolver that maps the original HTTP URL onto a classpath (avoiding jar:file: URLs and enabling relative imports): https://github.com/geotools/geotools/blob/master/modules/library/xml/src/main/java/org/geotools/xml/resolver/SchemaResolver.java Test dependencies on online resources are bad news; JARs are so much better. Your bigger problems are governance: versioning and change control of your XSDs. How does this occur? Are these static committee/ISO-governed XSDs, or the representation of a local changeable information model? If your XSDs change often, you will quickly tire of updating poms and repackaging artifacts. Please automate the process and tell me how. :-) Kind regards, Ben. On 08/04/13 15:53, Thomas Sundberg wrote: Hi! We seem to want to publish XSDs (XML Schema Definitions) in a project. I have been told that we want to make XSDs available at a well known url. We are using Maven and I tried to sell the idea that we create a jar that contains the XSD and add this as a dependency in a Maven build. This wasn't a good enough solution. How would you publish a XSD for a project and make it available for other Maven builds? We are using Nexus so publishing there is an option. /Thomas -- Thomas Sundberg M. Sc. in Computer Science Mobile: +46 70 767 33 15 Blog: http://thomassundberg.wordpress.com/ Twitter: @thomassundberg Better software through faster feedback - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to include 'src/main/webapp' in a jar file?
You may also try maven-assembly-plugin. It may be a little difficult to
configure without experience, but it is very flexible.
Regards,
htfv (Aliaksei Lahachou)
On Wed, Mar 20, 2013 at 1:31 AM, Ron Wheeler wrote:
> You might think about building the jar as a project first and then making
> the war project depend on the jar project.
> This will give you the jar that you want and the war as well.
>
> Ron
>
>
> On 19/03/2013 4:38 PM, Sankaran, Nambi wrote:
>
>> Hi All
>>
>> I have a maven web project that has packaging as "war". the package
>> generates war file that confirms to war format. But, i like to package the
>> project as a "jar" as well along with the default "war" format. So, I am
>> trying to use "maven jar" plugin to achieve that. I am using the following
>> jar plugin configuration.
>>
>>
>>
>> org.apache.maven.**plugins
>> maven-jar-plugin
>>
>>
>> make-a-jar
>> package
>>
>> jar
>>
>>
>>
>>
>> ${project.**build.outputDirectory}> classesDirectory>
>>
>> ../../src/main/**webapp/**
>> **/*
>>
>>
>>
>>
>> The "package" command produces a jar file that contains the classes and
>> the contents of 'resources' folder and war file produces a proper 'war'
>> file. But the contents of 'src/main/webapp' are not included in the jar
>> file. How to include the contents of src/main/webapp in the jar using the
>> jar plugin?
>>
>> Stack Overflow Question
>> http://stackoverflow.com/**questions/15509893/how-to-**
>> create-a-war-and-jar-from-a-**web-project
>>
>>
>
> --
> 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.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Handle XSDs with Maven and Nexus?
There are many ways to skin this cat...
If I were doing this I would take the following slant...
1. I like to keep to publishing 1 build-consumable artifact per GAV... (I
don't see javadoc or sources as artifacts in this regard as they are
*typically* consumed by people and not builds)
2. I really don't mind having lots of modules.
The XSD can be generated in one of two ways:
a) The XSD is generated by hand
b) The XSD is generated from code
With the generated by hand, I would just create a separate module for the
XSD only. Unless I was doing a lot of XSDs I would hijack
pom and use buildhelper-m-p to attach the XSD to the
reactor that would result in the XSD being downloadable directly over
http(s) from the Maven repo that the project gets deployed to at
http(s)://{hostname}/{context-path}/{groupIdwithdotsreplacedbyslashes}/{artifactId}/{version}/{artifactId}-{version}.xsd
I would very much try to avoid doing anything else in that module, IOW when
generating code against the XSD I would do that in a different module that
depends on the XSD and uses dependency:copy-dependencies to copy the XSD
into a location where it can be fed to the code generation tools.
With the generating from code, things get a tad trickier... my goal would
be to be able to produce the XSD from the .jar by e.g. parsing annotations,
or perhaps even by unpacking the .jar and pulling out the XSD that was
embedded in the .jar if the code generation strategy puts the XSD inside
the .jar as a necessary side-effect of the code generation process... all
those would allow me to basically treat as before... *but* reality may
hit... e.g. annotations may not be retained in the compiled code, the XSD
could be generated from the javadoc comments in the source code and not
java1.5 annotations, etc... in those cases I would just attach the XSD as a
side artifact to the .jar module using buildhelper-m-p as, while it is a
noble goal to keep to 1 artifact per module, sometimes you need to do what
you need to do
On 8 April 2013 08:53, Thomas Sundberg wrote:
> Hi!
>
> We seem to want to publish XSDs (XML Schema Definitions) in a project.
> I have been told that we want to make XSDs available at a well known
> url.
>
> We are using Maven and I tried to sell the idea that we create a jar
> that contains the XSD and add this as a dependency in a Maven build.
> This wasn't a good enough solution.
>
> How would you publish a XSD for a project and make it available for
> other Maven builds?
>
> We are using Nexus so publishing there is an option.
>
> /Thomas
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Handle XSDs with Maven and Nexus?
Hi! We seem to want to publish XSDs (XML Schema Definitions) in a project. I have been told that we want to make XSDs available at a well known url. We are using Maven and I tried to sell the idea that we create a jar that contains the XSD and add this as a dependency in a Maven build. This wasn't a good enough solution. How would you publish a XSD for a project and make it available for other Maven builds? We are using Nexus so publishing there is an option. /Thomas -- Thomas Sundberg M. Sc. in Computer Science Mobile: +46 70 767 33 15 Blog: http://thomassundberg.wordpress.com/ Twitter: @thomassundberg Better software through faster feedback - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
