In a single-module project, I don't see how to get a 'classified' artifact from the project itself into the descriptor and thus the assembly. Do I list it as a dependency?
Did you try the Build Helper Maven Plugin (I'm thinking to build-helper:attach-artifact)? See Attach additional artifacts to your project in the plugin Usage page.
If it doesn't work, then indeed declare your 'classified' artifact as dependency using one of the advanced identity pattern.
Related
In fact I have 2 different problems, but I think they are kind of related:
I have an artifact, with an assembly descriptor set which will build an extra JAR (with extra classifier). By default, Maven2/3 will deploy the assembly generated together with the main artifact to remove Maven repository. Is there any way that I can deploy only the main artifact but not the assembly?
I have an artifact, in which I have jar plugin generate another artifact with different classifier (more specific, an EJB artifact, and I generate an client JAR). I want to deploy only the client JAR to Maven repo coz I think the main EJB artifact is not really going to be shared by other project. Is it possible to do so?
Thanks a lot
editied to provide more info:
The reason for avoiding deploy the EJB, is because the EJB main artifact is not going to be depended by other project except the containing project. The containing project will build a EAR (which contains the EJB), and normally we only need that build locally (by mvn package). However, the EJB client is something that we will deploy to our repo to let other project share when they need to communicate with our application.
Honestly it doesn't harm to deploy the EJB too, but I just want to see if I can save unnecessary waste of disk space on our repository.
Similarly, for deploying assembly, it is because the project is something we want to deploy to let other project to depends on. However, when building that project, we also have a separate assembly created on the same time (for example, an all-in-one executable jar) which we only need that built locally, and it is not something that other projects will depends on.
Turn off the 'attach' option to the assembly plugin. Then it won't be officially an artifact and it won't deploy; it will just lurk in the target directory, sulking that you don't love it as much as it's elder sibling and plot revenge.
Based on your first question i would like to know why do you create the supplemental assembly which is usually deployed as well as the main artifact. If you wan't to prevent you can put the creation of the assembly into a profile but this means you will not generate the supplemental artifact in your usual build only by activating the profile.
How to convert a Ant project to Maven project? A sample project that would link (a Wicket project)
Thanks
The nice part of using maven is that most standard stuff works automatically once you do things the maven way. For a simple webapp:
Create a pom with groupId, artifactId and version (packaging: war)
Add the required dependencies to the pom
move the
java sources to src/main/java,
resources to src/main/resources,
webapp content to src/main/webapp,
test content to src/test/java and src/test/resources
set the compiler compliance version using the maven compiler plugin
That should get you up 'n' running.
http://www.sonatype.com/people/2009/04/how-to-convert-from-ant-to-maven-in-5-minutes/
I don't know what your ant script looks like, but assuming its a basic script for building, you will need to create a pom.xml file for your project, add your dependencies, and then build it via maven.
For anyone who lands here in future, there is an easier way to find dependencies for maven using the file hashes. So, you won't have to guess artifact versions.
As per the below article, the idea is to generate a SHA1 checksum of the dependency that you want to find the information, then do a reverse search in Nexus repository manager using that hash. For the checksum generation, you can use Microsoft's FCIV (free) utility.
https://devreads.xyz/ant-to-maven-conversion-the-painless-method/
Inovking maven2 goal mvn dependency:list on an artifact pom causes to download the whole dependent artifact packages. I think only those pom files are necessary for resolving dependencies. Aren't they?
On the dependecy plugin documentation you can read that dependency:list is an alias for dependency:resolve. What you need is dependency:tree which :
Displays the dependency tree for this project.
Even with dependency:tree you will have to download dependencies.
From Arnaud Héritier (developer on Maven Project)
This is a problem in maven core which doesn't allow in 2.x to resolve dependencies without downloading artifacts.
Each mojo (plug-in in the Apache Maven) has a functionality description. See all dependency plugin functionality.
I am working with the current edition of Maven (the plug-in that shipped with Eclipse Neon), and I'm still working to get my head around how to make it do all the magical things it is claimed to be able to do.
I have the screen pictured below, in which the dependency highlighted in the left pane is unresolved.
!Dependency tree, showing missing dependency1
I thought that selecting (executing) the Update Project item off the project's context menu, as shown in the following image, would resolve it, but it left me with three errors, all, one way or another, the result of a missing dependency.
!Maven fly-out menu in project context menu2
By examining the file system, I have confirmed that the dependency is, in fact, absent.
Color me confused; why didn't that action download the missing dependency?
I'm new to Maven and have skimmed over the documentation as I am following the Hibernate tutorial at http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#tutorial-firstapp-mvn.
I have installed Maven and successfully setup a web-app but this does not contain all of the standard directories mentioned in the tutorial. Am I going mad?
When building my Maven project I am using the maven-archetype-webapp. This gives me the arh-webapp\src\main\resources and arh-webapp\src\main\webapp directories but I'm missing quite a few directories mentioned on the link http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html.
Surely I don't have to manually add these? If not then the Hibernate documentation does not mention what archetype to use in order to achieve the directory structure used in their tutorial. Please can someone enlighten me.
What archetype do I need to use in order to have the above directory plus the src/main/java directory? If there is no such archetype then can easily append these using Maven? and how?
Surely you'll have to manually add these.
Just create those directories that according to the Maven convention are missing. Remember, a Maven Archetype is just a starting point to save you time configuring your workspace. After encountering many problems in some Archetypes myself I've been accustomed to just use a basic-web-app-archetype and then customize it myself, as a beginner with Maven you'll be better off doing that, and will learn a lot.
Regards.
Not all the directories mentioned are required for your standard web application. In fact, the reason behind the presence of the src/main/java, src/main/resources and the src/main/webapp directories is due to the archetype that you've used.
IMHO, the book titled "Better Builds with Maven" will serve you better; the Sonatype books on Maven might also help. The complete Maven documentation is also available as a PDF file, for future reference.
But just in case, you need some clarity on the terms used, here's some:
Archetype: A pattern for projects. Simple web applications (with no dependencies on other frameworks/libraries) have their own archetypes, so do applications using Spring, Hibernate, Seam, etc. Some archetypes will result in creation of different directories, as they are coded that way. You might be able to change the directory structures in most cases, although I cannot vouch for every archetype. For instance, it is quite possible to place your sources in 'src' instead of 'src/main/java', although this requires additional configuration in the POM.
Lifecycles, Phases and Goals: A Maven build lifecycle is a series of phases, with each phase executing a set of goals. Maven can be commanded to execute a build phase, which results in execution of all phases until and including the specified phase.
Maven plugins: Maven plugins contain one or more goals. Goals need not be bound to phases, but usually you would bind them to particular phases. Plugins are the basis for everything operational in Maven; you're using plugins even though you are just compiling the application (the Maven compiler plugin is a core plugin that is present in the Maven distribution).
I hope the above helps, but I would suggest that the reference books be followed.
I have an issue when reading properties from a dependent project.
I have a core project, and my application has a dependency on it.
under classpath of core, it has file core.properties.
and my application need to read this property file, but it couldn't. It requires the core.properties in my classpath of my application, instead of core.
Is there an solution for that? One solution in my mind is that when I build my application.war, can I explictly declare that I want the core dependency be exploded?
Thanks for help!
What do you mean by "read this property file"?
Since it will be on the classpath it should be accessible with getClass().getResourceAsStream().
If you really need it as a file, you can use the Dependency plugin's unpack-dependencies goal to unpack particular files as part of the build process.