Why is ear:generate-application-xml used by eclipse:eclipse?

[jdboer]

I'm trying to find the problem why no Eclipse project files can be
generated of an Ear project without installing the required dependencies
first.
I've seen that it's caused by the ear:generate-application-xml goal, but
I don't understand why, how and where it's starten. I checkout out the
sources of both the Eclipse and Ear plugin, created a custom ear plugin
version where I removed all annotation from the ApplicationXmlMojo and
installed it in the local repository.
The test project, just a generated simple j2ee project, used this custom
ear plugin. When running eclipse:eclipse still the
ear:generate-application-xml goal is sought but this goal does not exist
anymore.

Anyone knows why it's still used? I cannot find anything in either the
Eclipse or Ear plugin which references to it.

Regards,
Joost



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

J. den Boer wrote:

> The test project, just a generated simple j2ee project, used this custom
> ear plugin. When running eclipse:eclipse still the
> ear:generate-application-xml goal is sought but this goal does not exist
> anymore.

I assume your custom plugin has the same groupId and artifactId as the
real plugin, otherwise you can't override the plugin execution
contributed from the lifecycle bindings for the "ear" packaging.

Did you verify the debug logs, i.e. "mvn <goal> -X", that both builds
really use the plugin version you intend? Also make sure to explicitly
declare the plugin version you want in the POM, otherwise you would get
a default version from the super POM (assuming a recent Maven version).

A workaround for your original dependency resolution problem should be
running something like
   mvn package eclipse:eclipse -D skipTests
While still quite expensive, it at least does not install stuff into the
local repo.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[baerrach]

On Fri, Jul 10, 2009 at 6:19 AM, J. den Boer<jdboer@...> wrote:

> I'm trying to find the problem why no Eclipse project files can be generated
> of an Ear project without installing the required dependencies first.
> I've seen that it's caused by the ear:generate-application-xml goal, but I
> don't understand why, how and where it's starten. I checkout out the sources
> of both the Eclipse and Ear plugin, created a custom ear plugin version
> where I removed all annotation from the ApplicationXmlMojo and installed it
> in the local repository.
> The test project, just a generated simple j2ee project, used this custom ear
> plugin. When running eclipse:eclipse still the ear:generate-application-xml
> goal is sought but this goal does not exist anymore.
>
> Anyone knows why it's still used? I cannot find anything in either the
> Eclipse or Ear plugin which references to it.

The eclipse plugin uses the standard lifecycles (see
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
But only runs up to "generate-resources" (via @execute
phase="generate-resources" in EclipsePlugin.java)

Your ear project would have a package type of ear (via
<packaging>ear</packaging> in pom.xml)

If you look at the standard lifecycle for ear (Default Lifecycle
Bindings - Packaging ear) it uses the following phases with these
bound plugins

generate-resources ear:generateApplicationXml
process-resources resources:resources
package ear:ear
install install:install
deploy deploy:deploy

You can see from the ear plugin documentation for
ear:generateApplicationXml  that it requires dependency resolution of
artifacts in scope: test
(http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html)

If the ear's dependencies do not yet exist then they can not be resolved.
If they can not be resolved they can not be included in the
eclipse:eclipse output.

As Benjamin points out you need these built first.

Personally I would do the following.

mvn install
mvn eclipse:eclipse

That way all your dependencies have been built.

If you try
  mvn package eclipse:eclipse
it may not work as there have been bugs in the past where plugins do
not pickup artifacts built during the reactor build but instead rely
on the artifacts being in the local repository.
YMMV.

Hope this helps
Barrie

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jdboer]

baerrach wrote:

On Fri, Jul 10, 2009 at 6:19 AM, J. den Boer<[e-mail]> wrote:
> I'm trying to find the problem why no Eclipse project files can be generated
> of an Ear project without installing the required dependencies first.
> I've seen that it's caused by the ear:generate-application-xml goal, but I
> don't understand why, how and where it's starten. I checkout out the sources
> of both the Eclipse and Ear plugin, created a custom ear plugin version
> where I removed all annotation from the ApplicationXmlMojo and installed it
> in the local repository.
> The test project, just a generated simple j2ee project, used this custom ear
> plugin. When running eclipse:eclipse still the ear:generate-application-xml
> goal is sought but this goal does not exist anymore.
>
> Anyone knows why it's still used? I cannot find anything in either the
> Eclipse or Ear plugin which references to it.

The eclipse plugin uses the standard lifecycles (see
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
But only runs up to "generate-resources" (via @execute
phase="generate-resources" in EclipsePlugin.java)

Your ear project would have a package type of ear (via
<packaging>ear</packaging> in pom.xml)

If you look at the standard lifecycle for ear (Default Lifecycle
Bindings - Packaging ear) it uses the following phases with these
bound plugins

generate-resources ear:generateApplicationXml
process-resources resources:resources
package ear:ear
install install:install
deploy deploy:deploy

You can see from the ear plugin documentation for
ear:generateApplicationXml  that it requires dependency resolution of
artifacts in scope: test
(http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html)

If the ear's dependencies do not yet exist then they can not be resolved.
If they can not be resolved they can not be included in the
eclipse:eclipse output.

As Benjamin points out you need these built first.

Personally I would do the following.

mvn install
mvn eclipse:eclipse

That way all your dependencies have been built.

If you try
  mvn package eclipse:eclipse
it may not work as there have been bugs in the past where plugins do
not pickup artifacts built during the reactor build but instead rely
on the artifacts being in the local repository.
YMMV.

Hope this helps
Barrie

I know about the lifecycle and I've seen the ear lifecycle.
Because the ear:generateApplicationXml goal is causing the problem (probably) I created a custom Ear plugin with version 2.3.2-TEST in which I removed the generateApplicationXml goal (by removing all annotations from GenerateApplicationXmlMojo class). The generateApplicationXml goal is not in the plugin.xml file anymore. When I run 'mvn help:effective-pom' on the test project, I can see the ear project uses the 2.3.2-TEST version of the Ear plugin.
But when running 'mvn eclipse:eclipse' still the ear:generateApplicationXml goal is sought. An error occurs now because I cannot be found. Logical because it doesn't exist anymore, but why, who, where still searches for it?

Running 'mvn install' before 'mvn eclipse:eclipse' is not an option for us. We have a very big Ear project with lots of jars and multiple wars. We want a developer to be able to checkout the project and generate the Eclipse project files without having the install everything first.

Another solution I though of was adjusting the GenerateApplicationXmlMojo class so it can resolve the dependencies via the reactor just like the Eclipse plugin does. Both run in the generate:resources cycle so if the Eclipse plugin is able to resolve the reactor dependencies, the GenerateApplicationXmlMojo must be as well.

[baerrach]

On Fri, Jul 10, 2009 at 6:17 PM, jdboer<jdboer@...> wrote:

> I know about the lifecycle and I've seen the ear lifecycle.
> Because the ear:generateApplicationXml goal is causing the problem
> (probably) I created a custom Ear plugin with version 2.3.2-TEST in which I
> removed the generateApplicationXml goal (by removing all annotations from
> GenerateApplicationXmlMojo class). The generateApplicationXml goal is not in
> the plugin.xml file anymore. When I run 'mvn help:effective-pom' on the test
> project, I can see the ear project uses the 2.3.2-TEST version of the Ear
> plugin.
> But when running 'mvn eclipse:eclipse' still the ear:generateApplicationXml
> goal is sought. An error occurs now because I cannot be found. Logical
> because it doesn't exist anymore, but why, who, where still searches for it?

Because the standard lifecycles are defined in plexus components -
outside the plugins.
You need to fiddle with the maven core if you want to pull out
ear:generateApplicationXml from the build process.

> Running 'mvn install' before 'mvn eclipse:eclipse' is not an option for us.
> We have a very big Ear project with lots of jars and multiple wars. We want
> a developer to be able to checkout the project and generate the Eclipse
> project files without having the install everything first.

Do you have continuous integration happening?
If your CI server has already run mvn deploy (to your internal
snapshot repository) then maven can pull down prebuilt dependencies.
(They do not have to be the LATEST they just need to exist - since
eclipse:eclipse will be resolving the projects to local files anyway)

> Another solution I though of was adjusting the GenerateApplicationXmlMojo
> class so it can resolve the dependencies via the reactor just like the
> Eclipse plugin does. Both run in the generate:resources cycle so if the
> Eclipse plugin is able to resolve the reactor dependencies, the
> GenerateApplicationXmlMojo must be as well.

That sounds feasible and probably a better solution.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...