Maven - Revision history

JaroslavTulach: /* Lessons Learned */

JaroslavTulach — Sun, 29 Sep 2013 11:09:45 GMT

Lessons Learned

←Older revision		Revision as of 11:09, 29 September 2013
Line 11:		Line 11:
	Time to wrap this episode up. [[Maven]] seems to have alive community which is really helpful [[Talk:Maven\|answering questions]].		Time to wrap this episode up. [[Maven]] seems to have alive community which is really helpful [[Talk:Maven\|answering questions]].

-	The best way to learn [[Maven]] is not to read its manual! There is online version of [http://~~www~~.sonatype.com/~~books/maven~~-book/reference/~~public-book~~.html Maven ~~Definitive Guide~~]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the ''shade'' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://~~www~~.sonatype.com/~~books/maven~~-book/reference/~~public-book~~.html Maven ~~Definitive Guide~~] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some link from the (incomplete) manual to such a good on-line ''definitive'' tutorial.	+	The best way to learn [[Maven]] is not to read its manual! There is online version of [http://books.sonatype.com/mvnref-book/reference/index.html Maven Complete Reference]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the ''shade'' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://books.sonatype.com/mvnref-book/reference/index.html Maven Complete Reference] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some link from the (incomplete) manual to such a good on-line ''definitive'' tutorial.

	{{:DocumentDeclarativeAPI}}		{{:DocumentDeclarativeAPI}}

	<comments/>		<comments/>

JaroslavTulach at 05:54, 16 September 2009

JaroslavTulach — Wed, 16 Sep 2009 05:54:57 GMT

←Older revision		Revision as of 05:54, 16 September 2009
Line 5:		Line 5:
	In work, while working on [[NetBeans]], I rely mostly on [[Ant]]. However for my Saturday night project, I decided to try [[Maven]]. It's management of dependencies is really awesome. I do not need to take care about locations of actual libraries, I can just spell their name and version and the [[Maven]] downloads them automatically during the build. Perfect, I love this part of the system.		In work, while working on [[NetBeans]], I rely mostly on [[Ant]]. However for my Saturday night project, I decided to try [[Maven]]. It's management of dependencies is really awesome. I do not need to take care about locations of actual libraries, I can just spell their name and version and the [[Maven]] downloads them automatically during the build. Perfect, I love this part of the system.

-	On the other hand, compared to [[Ant]], I have huge problems to configure the system to do exactly what I want. For example, I want to package my application (two my own [[JAR]] files, plus all the dependency [[JAR]]s) into a single ZIP file that everyone could download. This is not easy at all. The only tool that does something similar seems to be ''shade'' plugin. But its functionality is still far from optimal.	+	{{:LibrariesAndClassPathBuildProblem}}
-		+
-	It seems to me that development of simple [[Java]] desktop applications is not really well supported by current [[Maven]] plugins. Packaging to a compound ZIP is unsupported, execution of a main method is supported, but not by official [[Apache]]'s plugin. It seems to me that [[Java]] desktop is second class citizen in [[Maven]].	+
-		+
-	On the other hand one can find tons of tools for server side. Packaging to ''WAR'' file is possible (this is almost the ZIP file requested above, and I even wanted to create ''WAR'' instead of ''ZIP'', but it does not work, it requires some ''web.xml'' file, which I obviously don't have). Execution on glashfish, grizzly, etc. is easy. All these application servers have their own plugins and thus are easy to start with.	+
-		+
-	~~All this leads to me following question~~: ~~is [[Maven]] really ready for development of [[Java]] desktop applications? And a follow up: Why it is not?~~	+
-		+
-	~~=== It is Ready! It is Just Different. ===~~	+
-		+
-	Thanks to all your [[Talk:Maven\|overwhelming responses]] I managed to find solution of the packaging. I can confirm that [[Maven]] can be used to package [[Java]] desktop applications. Just give up on ''shade'' and use ''assembly'' plugin. This is the configuration in my ''pom.xml'' file:	+
-		+
-	~~<source lang="xml">~~	+
-	~~<plugin>~~	+
-	~~<artifactId>maven-assembly-plugin</artifactId>~~	+
-	~~<version>2.2-beta-2</version>~~	+
-	~~<executions>~~	+
-	~~<execution>~~	+
-	~~<id>create-executable-jar</id>~~	+
-	~~<phase>package</phase>~~	+
-	~~<goals>~~	+
-	~~<goal>single</goal>~~	+
-	~~</goals>~~	+
-	~~<configuration>~~	+
-	~~<descriptors>~~	+
-	~~<descriptor>all-zip.xml</descriptor>~~	+
-	~~</descriptors>~~	+
-	~~<finalName>myapp-${version~~}~~</finalName>~~	+
-	~~</configuration>~~	+
-	~~</execution>~~	+
-	~~</executions>~~	+
-	~~</plugin>~~	+
-	~~<plugin>~~	+
-	~~<groupId>org.apache.maven.plugins</groupId>~~	+
-	~~<artifactId>maven-jar-plugin</artifactId>~~	+
-	~~<configuration>~~	+
-	~~<archive>~~	+
-	~~<manifest>~~	+
-	~~<addClasspath>true</addClasspath>~~	+
-	~~<classpathPrefix>lib/</classpathPrefix>~~	+
-	~~<mainClass>myapp.Main</mainClass>~~	+
-	~~</manifest>~~	+
-	~~</archive>~~	+
-	~~</configuration>~~	+
-	~~</plugin>~~	+
-	~~</source>~~	+
-		+
-	~~One also needs to create additional assembly file. In my case it is located next to the ''pom.xml'' and named ''all-zip.xml'':~~	+
-		+
-	~~<source lang="xml">~~	+
-	~~<?xml version="1.0" encoding="UTF-8"?>~~	+
-	~~<assembly>~~	+
-	~~<id>all</id>~~	+
-	~~<formats>~~	+
-	~~<format>zip</format>~~	+
-	~~</formats>~~	+
-	~~<dependencySets>~~	+
-	~~<dependencySet>~~	+
-	~~<useProjectArtifact>false</useProjectArtifact>~~	+
-	~~<outputDirectory>lib</outputDirectory>~~	+
-	~~</dependencySet>~~	+
-	~~</dependencySets>~~	+
-	~~<files>~~	+
-	~~<file>~~	+
-	~~<source>target/myapp-${version~~}~~.jar<source>~~	+
-	~~<outputDirectory>/</outputDirectory>~~	+
-	~~</file>~~	+
-	~~</files>~~	+
-	~~</assembly>~~	+
-	~~</source>~~	+
-		+
-	And that is all. I have to admit that at the end this is much simpler than using plain [[Ant]]. In [[Ant]] it would be an enormous amount of [[XML]] code to generate the ''Class-Path'' attribute tons of ''<pathconvert>'' magic. In [[Maven]] this is for almost free (as soon as you know which plugin is the right one to use). My application now has executable main [[JAR]] and all the libraries in subfolder ''lib''. It can be executed as ''java -jar myapp-1.8/myapp-1.8.jar''. Perfect!	+
-		+
-	~~<source lang="bash">~~	+
-	~~myapp-1.8/myapp-1.8.jar~~	+
-	~~myapp-1.8/lib/jersey-core-1.1.0-ea.jar~~	+
-	~~myapp-1.8/lib/jsr311-api-1.1.jar~~	+
-	~~myapp-1.8/lib/jersey-server-1.1.0-ea.jar~~	+
-	~~myapp-1.8/lib/asm-3.1.jar~~	+
-	~~myapp-1.8/lib/jersey-json-1.1.0-ea.jar~~	+
-	~~myapp-1.8/lib/jettison-1.1.jar~~	+
-	~~myapp-1.8/lib/jaxb-impl-2.1.10.jar~~	+
-	~~myapp-1.8/lib/jackson-asl-0.9.4.jar~~	+
-	~~myapp-1.8/lib/org-netbeans-libs-freemarker-RELEASE67.jar~~	+
-	~~myapp-1.8/lib/org-netbeans-modules-queries-RELEASE67.jar~~	+
-	~~myapp-1.8/lib/org-openide-filesystems-RELEASE67.jar~~	+
-	~~myapp-1.8/lib/org-openide-util-RELEASE67.jar~~	+
-	~~myapp-1.8/lib/jersey-client-1.1.0-ea.jar~~	+
-	~~myapp-1.8/lib/freemarker-2.3.8.jar~~	+
-	~~</source>~~	+
-		+
-	I am surprised this is not one of the standard archetypes. As I wrote in [[Chapter 9]], one of the best [[API]]s is wizard. Good wizard can turn any [[API]], regardless how bad, complicated and hidden, into perfectly shining, beautiful [[star]]. [[Good Technology\|Good tools]] make everything easier. Having ''Java Application Archetype'' would save me a lot of hours of googling and blogging (if I could find the archetype, of course).	+

	=== Lessons Learned ===		=== Lessons Learned ===

JaroslavTulach: /* Lessons Learned */

JaroslavTulach — Tue, 15 Sep 2009 09:15:47 GMT

Lessons Learned

←Older revision		Revision as of 09:15, 15 September 2009
Line 100:		Line 100:
	=== Lessons Learned ===		=== Lessons Learned ===

-	Time to wrap this episode up. [[Maven]] seems to have alive community which is helpful ~~when~~ [[Talk:Maven\|answering questions]].	+	Time to wrap this episode up. [[Maven]] seems to have alive community which is really helpful [[Talk:Maven\|answering questions]].

	The best way to learn [[Maven]] is not to read its manual! There is online version of [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the ''shade'' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some link from the (incomplete) manual to such a good on-line ''definitive'' tutorial.		The best way to learn [[Maven]] is not to read its manual! There is online version of [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the ''shade'' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some link from the (incomplete) manual to such a good on-line ''definitive'' tutorial.

JaroslavTulach: /* Lessons Learned */

JaroslavTulach — Tue, 15 Sep 2009 07:38:56 GMT

Lessons Learned

←Older revision		Revision as of 07:38, 15 September 2009
Line 102:		Line 102:
	Time to wrap this episode up. [[Maven]] seems to have alive community which is helpful when [[Talk:Maven\|answering questions]].		Time to wrap this episode up. [[Maven]] seems to have alive community which is helpful when [[Talk:Maven\|answering questions]].

-	The best way to learn [[Maven]] is not to read its manual! There is online version of [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the 'shade' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some ~~reference~~ from the (incomplete) manual to such a good on-line ''definitive'' tutorial.	+	The best way to learn [[Maven]] is not to read its manual! There is online version of [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the ''shade'' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some link from the (incomplete) manual to such a good on-line ''definitive'' tutorial.

	{{:DocumentDeclarativeAPI}}		{{:DocumentDeclarativeAPI}}

	<comments/>		<comments/>

JaroslavTulach at 07:37, 15 September 2009

JaroslavTulach — Tue, 15 Sep 2009 07:37:14 GMT

←Older revision		Revision as of 07:37, 15 September 2009
Line 13:		Line 13:
	All this leads to me following question: is [[Maven]] really ready for development of [[Java]] desktop applications? And a follow up: Why it is not?		All this leads to me following question: is [[Maven]] really ready for development of [[Java]] desktop applications? And a follow up: Why it is not?

		+	=== It is Ready! It is Just Different. ===
		+
		+	Thanks to all your [[Talk:Maven\|overwhelming responses]] I managed to find solution of the packaging. I can confirm that [[Maven]] can be used to package [[Java]] desktop applications. Just give up on ''shade'' and use ''assembly'' plugin. This is the configuration in my ''pom.xml'' file:
		+
		+	<source lang="xml">
		+	<plugin>
		+	<artifactId>maven-assembly-plugin</artifactId>
		+	<version>2.2-beta-2</version>
		+	<executions>
		+	<execution>
		+	<id>create-executable-jar</id>
		+	<phase>package</phase>
		+	<goals>
		+	<goal>single</goal>
		+	</goals>
		+	<configuration>
		+	<descriptors>
		+	<descriptor>all-zip.xml</descriptor>
		+	</descriptors>
		+	<finalName>myapp-${version}</finalName>
		+	</configuration>
		+	</execution>
		+	</executions>
		+	</plugin>
		+	<plugin>
		+	<groupId>org.apache.maven.plugins</groupId>
		+	<artifactId>maven-jar-plugin</artifactId>
		+	<configuration>
		+	<archive>
		+	<manifest>
		+	<addClasspath>true</addClasspath>
		+	<classpathPrefix>lib/</classpathPrefix>
		+	<mainClass>myapp.Main</mainClass>
		+	</manifest>
		+	</archive>
		+	</configuration>
		+	</plugin>
		+	</source>
		+
		+	One also needs to create additional assembly file. In my case it is located next to the ''pom.xml'' and named ''all-zip.xml'':
		+
		+	<source lang="xml">
		+	<?xml version="1.0" encoding="UTF-8"?>
		+	<assembly>
		+	<id>all</id>
		+	<formats>
		+	<format>zip</format>
		+	</formats>
		+	<dependencySets>
		+	<dependencySet>
		+	<useProjectArtifact>false</useProjectArtifact>
		+	<outputDirectory>lib</outputDirectory>
		+	</dependencySet>
		+	</dependencySets>
		+	<files>
		+	<file>
		+	<source>target/myapp-${version}.jar<source>
		+	<outputDirectory>/</outputDirectory>
		+	</file>
		+	</files>
		+	</assembly>
		+	</source>
		+
		+	And that is all. I have to admit that at the end this is much simpler than using plain [[Ant]]. In [[Ant]] it would be an enormous amount of [[XML]] code to generate the ''Class-Path'' attribute tons of ''<pathconvert>'' magic. In [[Maven]] this is for almost free (as soon as you know which plugin is the right one to use). My application now has executable main [[JAR]] and all the libraries in subfolder ''lib''. It can be executed as ''java -jar myapp-1.8/myapp-1.8.jar''. Perfect!
		+
		+	<source lang="bash">
		+	myapp-1.8/myapp-1.8.jar
		+	myapp-1.8/lib/jersey-core-1.1.0-ea.jar
		+	myapp-1.8/lib/jsr311-api-1.1.jar
		+	myapp-1.8/lib/jersey-server-1.1.0-ea.jar
		+	myapp-1.8/lib/asm-3.1.jar
		+	myapp-1.8/lib/jersey-json-1.1.0-ea.jar
		+	myapp-1.8/lib/jettison-1.1.jar
		+	myapp-1.8/lib/jaxb-impl-2.1.10.jar
		+	myapp-1.8/lib/jackson-asl-0.9.4.jar
		+	myapp-1.8/lib/org-netbeans-libs-freemarker-RELEASE67.jar
		+	myapp-1.8/lib/org-netbeans-modules-queries-RELEASE67.jar
		+	myapp-1.8/lib/org-openide-filesystems-RELEASE67.jar
		+	myapp-1.8/lib/org-openide-util-RELEASE67.jar
		+	myapp-1.8/lib/jersey-client-1.1.0-ea.jar
		+	myapp-1.8/lib/freemarker-2.3.8.jar
		+	</source>
		+
		+	I am surprised this is not one of the standard archetypes. As I wrote in [[Chapter 9]], one of the best [[API]]s is wizard. Good wizard can turn any [[API]], regardless how bad, complicated and hidden, into perfectly shining, beautiful [[star]]. [[Good Technology\|Good tools]] make everything easier. Having ''Java Application Archetype'' would save me a lot of hours of googling and blogging (if I could find the archetype, of course).
		+
		+	=== Lessons Learned ===
		+
		+	Time to wrap this episode up. [[Maven]] seems to have alive community which is helpful when [[Talk:Maven\|answering questions]].
		+
		+	The best way to learn [[Maven]] is not to read its manual! There is online version of [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide]. Ten minutes of reading its chapter 12 helped me more than hours of browsing in [[Maven]] manual. This is good, yet surprising. The [[Ant]] manual is perfect and almost definitive source of information. I never needed any book to learn something about [[Ant]]. The [[Maven]] manual on the other hand seems incomplete (e.g. not describing all the options of each plugin) and low level (e.g. describing only how to do something, not what a plugin can be useful for). As a result I have incorrectly chosen the 'shade' plugin, while I should have point all my attention to ''assembly'' one. Last, but not least. The [http://www.sonatype.com/books/maven-book/reference/public-book.html Maven Definitive Guide] does not seem to be indexed by google. At least it showed up in none of my queries. That is unfortunate. There shall be some reference from the (incomplete) manual to such a good on-line ''definitive'' tutorial.
		+
		+	{{:DocumentDeclarativeAPI}}

	<comments/>		<comments/>

JaroslavTulach: /* Is Maven ready for Desktop? */

JaroslavTulach — Sun, 13 Sep 2009 19:23:49 GMT

Is Maven ready for Desktop?

←Older revision		Revision as of 19:23, 13 September 2009
Line 9:		Line 9:
	It seems to me that development of simple [[Java]] desktop applications is not really well supported by current [[Maven]] plugins. Packaging to a compound ZIP is unsupported, execution of a main method is supported, but not by official [[Apache]]'s plugin. It seems to me that [[Java]] desktop is second class citizen in [[Maven]].		It seems to me that development of simple [[Java]] desktop applications is not really well supported by current [[Maven]] plugins. Packaging to a compound ZIP is unsupported, execution of a main method is supported, but not by official [[Apache]]'s plugin. It seems to me that [[Java]] desktop is second class citizen in [[Maven]].

-	On the other hand one can find tons of tools for server side. Packaging to ''WAR'' file is possible (this is almost the ZIP file requested above, and I even wanted to create ''WAR'' instead of ''ZIP'', but it does not work, it requires some ''web.xml'' file, which I obviously don't have). Execution on glashfish, grizzly, etc. have their own plugins and thus are easy to start with.	+	On the other hand one can find tons of tools for server side. Packaging to ''WAR'' file is possible (this is almost the ZIP file requested above, and I even wanted to create ''WAR'' instead of ''ZIP'', but it does not work, it requires some ''web.xml'' file, which I obviously don't have). Execution on glashfish, grizzly, etc. is easy. All these application servers have their own plugins and thus are easy to start with.

-	All this leads to me following question: is [[Maven]] really ready for development of [[Java]] desktop applications?	+	All this leads to me following question: is [[Maven]] really ready for development of [[Java]] desktop applications? And a follow up: Why it is not?
		+
		+
		+	<comments/>

JaroslavTulach at 19:18, 13 September 2009

JaroslavTulach — Sun, 13 Sep 2009 19:18:29 GMT

←Older revision		Revision as of 19:18, 13 September 2009
Line 1:		Line 1:
-	~~#REDIRECT~~ [[wikipedia::~~Apache_Maven~~]]	+	[[wikipedia::Apache Maven\|Apache's Maven]] is an advanced, high level concept build system. Compared to [[Ant]] or make, it feel like a modern programming language, compared to assembly. While the other build systems describe step by step, what shall be done and how, the [[Maven]] is build around automatic management of dependencies and configuration of various plugins. It is kind of [[module system]], in fact.
		+
		+	=== Is [[Maven]] ready for Desktop? ===
		+
		+	In work, while working on [[NetBeans]], I rely mostly on [[Ant]]. However for my Saturday night project, I decided to try [[Maven]]. It's management of dependencies is really awesome. I do not need to take care about locations of actual libraries, I can just spell their name and version and the [[Maven]] downloads them automatically during the build. Perfect, I love this part of the system.
		+
		+	On the other hand, compared to [[Ant]], I have huge problems to configure the system to do exactly what I want. For example, I want to package my application (two my own [[JAR]] files, plus all the dependency [[JAR]]s) into a single ZIP file that everyone could download. This is not easy at all. The only tool that does something similar seems to be ''shade'' plugin. But its functionality is still far from optimal.
		+
		+	It seems to me that development of simple [[Java]] desktop applications is not really well supported by current [[Maven]] plugins. Packaging to a compound ZIP is unsupported, execution of a main method is supported, but not by official [[Apache]]'s plugin. It seems to me that [[Java]] desktop is second class citizen in [[Maven]].
		+
		+	On the other hand one can find tons of tools for server side. Packaging to ''WAR'' file is possible (this is almost the ZIP file requested above, and I even wanted to create ''WAR'' instead of ''ZIP'', but it does not work, it requires some ''web.xml'' file, which I obviously don't have). Execution on glashfish, grizzly, etc. have their own plugins and thus are easy to start with.
		+
		+	All this leads to me following question: is [[Maven]] really ready for development of [[Java]] desktop applications?

JaroslavTulach: Redirecting to wikipedia:Apache Maven

JaroslavTulach — Sun, 14 Sep 2008 20:32:24 GMT

Redirecting to wikipedia:Apache Maven

New page

#REDIRECT [[wikipedia::Apache_Maven]]