make jetty:run auto load dependences during running - java

I have a maven project which own the following structure:
api(with packaging pom)
pom.xml
api-common(with packaging jar)
pom.xml
api-webapp(with packaging war)
pom.xml
The api is the parent of api-common and api-webapp.
api-webapp have a dependency of api-common.
Now when I run mvn jetty:run inside the api/api-webapp,jetty can not auto load the change of the module api-common.
Any idea?
BTW,I use maven3

Since api-webapp depends on api-common and they are separate projects, api-webapp will look for it's dependencies in the maven repository: your .m2 directory, then the remote repo. You'll need to compile and install your changes in api-common first before api-webapp can see them.
api-webapp has no knowledge of the location of the source of api-common so it can not detect changes. The fact that they share a common parent does not give them the ability to see each other.
That's the general maven answer, but the jetty plugin does provide a workaround to this issue by letting you provide additional classpath for the container. See this defect

Related

Use maven local module in Intellij

I currently have the following setup:
parent-pom:
has our common as dependency
service-pom:
is child of parent-pom
contains purge for common, so its always the newest
If I now import the modules in Intellij, the common dependency is used from .m2 folder. The problem is that I cant do refactoring across modules or add something inside a class, I don't have autocomplete.
I tried then changing the project structure. First I've added my local common module as dependency for the service and placed it over the .m2/repository dependency. That worked for autocompletion and refactoring, but can get confusing if I want to use the .m2/repository version.
But compiling and starting spring-boot with it don't works. I added a field to a class from common and referenced it in the service. And when I compiled it, it failed due to this field.
Then I read that I need to configure an artifact (containing common) and added a run configuration and enabled "resolve workspace artifacts". But that also did not work as expected.
Then I've added my local common module to the parent-pom module and added the parent-pom module to the service. In addition I've configured an artifact for the parent-pom.
But that didn't work either.
How can I compile and start my service with the local version of my common (and also be able to use the .m2 if needed)
How do you declare the dependencies between these modules in maven?
Do you have these modules imported into the same IDE project as Maven projects?
For IDE to resolve dependencies to the Maven modules with sources instead of the jars from the local repository, these requirements should be met:
Those Maven modules with sources which you have on your local machine must be added to the same IDE project;
The Maven coordinates (groupId, artifactId, versionId) of these dependencies must match to coordinates of maven modules with sources.
To be able to switch to a local .m2 dependency instead of modules, I think a Maven profile may be used indeed.

In Maven, do modules get effected by the repository's updatePolicy?

This is just like this other question I asked, but instead of dependencies, this is about modules. Let me give a scenario. You've got a multi-module project and a continuous integration server that deploys the project. This deploys to a repository that your local settings.xml has an updatePolicy of always. Now imagine you run mvn compile right after the CI deploys the project.
Will you end up compiling against the remote server's modules, or your local modules?
In other words, does the updatePolicy of a repository have any effect on the module tags?
modules tag is an aggregation. It is not treated the same as dependencies. Notice that the value that you specify in dependency and module is different. When you declare a dependency, you specify maven coordinates. Whilst for module, you specify relative directories.
Will you end up compiling against the remote server's modules, or your local modules?
You will always end up compiling against your local module if you run the mvn compile in the aggregator module (NOT in the child module!) and the child module dependency is a sibling dependency. When you mvn compile in an aggregator module, the dependency lookup when it is compiling the child module will be special. It will look from the sibling modules target folder ONLY. I can't find documentation on this, but you can try it out.
Imagine that you have these aggregator pom
...
<modules>
<module>child-a</module>
<module>child-b</module>
</modules>
....
child-b pom is declaring a dependency against child-a. (Make sure you have a real output classes)
Next, when you mvn compile the aggregator pom, child-b will be able to compile even if you have NOT mvn install child-a before. That means, child-a is not even in your local repository. This is possible because maven will look into child-a's target folder for the classes. To confirm this, you can try to run mvn compile clean (yes, clean after compile).
Again, do note that this behavior only applies when you run it from the aggregator pom. If your current working directory is child-b (which is dependent on child-a), it will respect the updatePolicy when it tries to look for child-a.

Including the Jar of a Maven Project in another Maven Project does not work but including the Project in another Maven Project works

I have 2 Projects namely Project_1 and Project_2.
Both projects are Maven and I am using Netbeans.
I want to include the jar of Project_1 in Project_2 which I am doing like this.
The problem is when I include the jar I do not get any compile time error, however I get a NoClassDefFoundError exception at runtime.
When I include the Project_1 in Project_2 by performing the steps mentioned here. (The Open Project example). I do not get any errors. Neither runtime nor compile time.
Can you please explain me what am I missing here?
Update
Project_2 is deployed on a Server which is not in my local machine however Project_1 is in my local machine.
Inclusion of Project_1 into Project_2 as a project was done for testing in my local machine.
First of all, a good rule of thumb to adopt is never use the system scope and system path to pull in dependencies. In my experience there's always a better way :-)
If Project_2 depends on Project_1, then first install it's jar into the local repository:
cd Project_1
mvn clean install
Watch the output you'll discover the jar is placed somewhere under the following directory:
$HOME/.m2/repository
Once this is done the jar will be available as a normal dependency to the second build
cd Project_2
mvn clean compile
The local repository ensures the projects are now decoupled from each other. Assuming you're using snapshot revisions of Project_1, the Project_2 build will always retrieve the latest revision built and tested.
Update
You should use a Maven repository manager to share jars between machines/teams. Recommendations are contained in the following answer:
Share jar of the module with another team
How to configure Maven to use a repository like Nexus is described in it's documentation.
As described in the deploy plugin documentation you'll need to add a distributionManagement section to your POM (detailing the repository URL) and then upload the project's jar to your repository as follows:
cd Project_1
mvn clean deploy

What is "pom" packaging in maven?

I was given a maven project to compile and get deployed on a tomcat server. I have never used maven before today, but I have been googling quite a bit. It seems like the top level pom.xml files in this project have the packaging type set as pom.
What am I supposed to do after mvn install to get this application deployed? I was expecting to be able to find a war file somewhere or something, but I guess I am looking in the wrong place or missing a step.
pom is basically a container of submodules, each submodule is represented by a subdirectory in the same directory as pom.xml with pom packaging.
Somewhere, nested within the project structure you will find artifacts (modules) with war packaging. Maven generally builds everything into /target subdirectories of each module. So after mvn install look into target subdirectory in a module with war packaging.
Of course:
$ find . -iname "*.war"
works equally well ;-).
pom packaging is simply a specification that states the primary artifact is not a war or jar, but the pom.xml itself.
Often it is used in conjunction with "modules" which are typically contained in sub-directories of the project in question; however, it may also be used in certain scenarios where no primary binary was meant to be built, all the other important artifacts have been declared as secondary artifacts
Think of a "documentation" project, the primary artifact might be a PDF, but it's already built, and the work to declare it as a secondary artifact might be desired over the configuration to tell maven how to build a PDF that doesn't need compiled.
Packaging of pom is used in projects that aggregate other projects, and in projects whose only useful output is an attached artifact from some plugin. In your case, I'd guess that your top-level pom includes <modules>...</modules> to aggregate other directories, and the actual output is the result of one of the other (probably sub-) directories. It will, if coded sensibly for this purpose, have a packaging of war.
To simply answer your question when you do a mvn:install, maven will create a packaged artifact based on (packaging attribute in pom.xml), After you run your maven install you can find the file with .package extension
In target directory of the project workspace
Also where your maven 2 local repository is search for (.m2/respository) on your box, Your artifact is listed in .m2 repository under (groupId/artifactId/artifactId-version.packaging) directory
If you look under the directory you will find packaged extension file and also pom extension (pom extension is basically the pom.xml used to generate this package)
If your maven project is multi-module each module will two files as described above except for the top level project that will only have a pom
Packaging an artifact as POM means that it has a very simple lifecycle
package -> install -> deploy
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
This is useful if you are deploying a pom.xml file or a project that doesn't fit with the other packaging types.
We use pom packaging for many of our projects and bind extra phases and goals as appropriate.
For example some of our applications use:
prepare-package -> test -> package -> install -> deploy
When you mvn install the application it should add it to your locally .m2 repository. To publish elsewhere you will need to set up correct distribution management information. You may also need to use the maven builder helper plugin, if artifacts aren't automatically attached to by Maven.
I suggest to see the classic example at: http://maven.apache.org/guides/getting-started/index.html#How_do_I_build_more_than_one_project_at_once
Here my-webapp is web project, which depends on the code at my-app project. So to bundle two projects in one, we have top level pom.xml which mentions which are the projects (modules as per maven terminology) to be bundled finally. Such top level pom.xml can use pom packaging.
my-webapp can have war packaging and can have dependency on my-app. my-app can have jar packaging.
“pom” packaging is nothing but the container, which contains other packages/modules like jar, war, and ear.
if you perform any operation on outer package/container like mvn clean compile install. then inner packages/modules also get clean compile install.
no need to perform a separate operation for each package/module.
Real life use case
At a Java-heavy company we had a python project that needed to go into a Nexus artifact repository. Python doesn't really have binaries, so simply just wanted to .tar or .zip the python files and push. The repo already had maven integration, so we used <packaging>pom</packaging> designator with the maven assembly plugin to package the python project as a .zip and upload it.
The steps are outlined in this SO post
https://maven.apache.org/pom.html
The packaging type required to be pom for parent and aggregation (multi-module) projects. These types define the goals bound to a set of lifecycle stages. For example, if packaging is jar, then the package phase will execute the jar:jar goal. If the packaging is pom, the goal executed will be site:attach-descriptor
POM(Project Object Model) is nothing but the automation script for building the project,we can write the automation script in XML,
the building script files are named diffrenetly in different Automation tools
like we call build.xml in ANT,pom.xml in MAVEN
MAVEN can packages jars,wars, ears and POM which new thing to all of us
if you want check WHAT IS POM.XML

How do I implement maven source dependency among sibling projects?

I have a java project that is composed of 3 sub projects that generate a .jar artifact each (and have sub-dependencies among them).
In addition there is a web projects that depends on the first 3 projects and generate a war file. The war file is my final artifact, i.e. what I ship my customers.
Additionally I have a parent module that encompasses all the other projects:
<modules>
<module>../core</module>
<module>../commons</module>
<module>../api</module>
<module>../web</module>
</modules>
I generate eclipse files (mvn eclipse:eclipse) and work with eclipse. The problem is if I modify one of the non-web projects I must manually install it before deploying the web project to my web container. How can I make that the web project depends directly on the source code of the others and not on the version installed in the repository.
In your web application properties (right clic on the project in the Package explorer, then "properties"), add the three modules (core, commons and api) in the "J2EE Module Dependencies" (the others modules must be opened in the Eclipse workspace).
Do you want to add a dependency on the source jars deployed to the repository?
If so you can do it by adding the sources classifier to the dependency. See this answer for more details.
If not, can you clarify further please.
I think your problem is that you are just building just the war project. If you are building it from the command line, then what you have to build is the parent module. "mvn package" in the directory that contains the parent module should be enough. Of course this means that you have to build all the packages every time, but that is the way maven works.
The dependency:tree goal by itself will look things up in the repository rather than the reactor. You can work around this by mvn installing, as previously suggested, or doing something less onerous that invokes the reactor, such as
mvn compile dependency:tree
Works for me.
Edit: D'oh! Posted this answer to the wrong question. Was meant to be answering this

Categories

Resources