Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] War overlays in m2e-wtp with workspace projects - is it possible?
Following up on this issue, I decided to file a bug against the jetty plugin at https://bugs.eclipse.org/bugs/show_bug.cgi?id=398207

I believe Jan Bartel might be interesting. He said:

I'm open to changing the jetty plugin, but I'm not too sure what it is that the jetty plugin could/should do. Here's what we currently do:

+ The plugin uses "@requiresDependencyResolution test" for its execution. 
+ We use "@parameter _expression_="${project.artifacts}"" to obtain the list of project dependent artifacts at runtime.
+ We check each org.apache.maven.artifact.Artifact.getType() == war
+ For those that report they are of type war, we call org.apache.maven.artifact.Artifact.getFile().

It seems with "Resolve Workspace Artifacts" unchecked - as with the command line - this returns a reference to the actual .war file. However, with that box checked, it just returns a reference to the classes directory of the dependent war. Here's the output from a run with the box checked:

[INFO] Dependent war artifact test:overlayProject:war:1.0-SNAPSHOT
INFO:oejw.WebInfConfiguration:main: Unpacking overlay: jar:file:/home/janb/src/tmp/bug-398207/new-test-harness/test/target/classes/!/ [test,overlayProject,,,false,false,, **/*.xml;**/*.properties;**/WEB-INF/lib/*.jar;**/*.jar]

So, as you can see, if the Artifact interface is only going to give us back a reference to the classes of the dependent war artifact, this is not going to work, as we would need a reference that includes the static resources, web.xml etc.

I don't believe that it's the jetty plugin's responsibility to work out the environment in which it is executing - maven command line or maven-embedded-in-eclipse. We should be able to rely on the maven apis to work consistently in either environment.

So we're really at the bridge between the two tools, but it would be interesting to see if the m2e and jetty team could talk and see if there is something that can be done to bring these two sides closer.

Perhaps someone at m2e could shed some light from the m2e side on that conversation? Jan says something I had already noticed - even *if* the jetty-plugin could resolve the directory dependencies, m2e would only expose the classes directory - it would still miss the webapp directory.

Any thoughts?

Miguel


On Tue, Jan 15, 2013 at 7:11 PM, Miguel Almeida <migueldealmeida@xxxxxxxxx> wrote:
Joakim Erdfelt suggested that maybe the integration should be between m2e and the maven-war-plugin (which is used by jetty plugin). And, in fact, this may be correct. As far as I know this integration isn't perfect either. For instance, if you try to run the "package" goal inside Eclipse on the project I attached you'll get an error saying projectB shouldn't be a directory.


Webby seems like a good bet, but still needs some work (namely, the ability to parse and configure more options of the jetty-plugin, such as jettyXmlCfg. I'm investigating the https://github.com/sonatype/m2eclipse-webby to see how hard it would be to incorportate those changes.


Miguel

On Tue, Jan 15, 2013 at 2:28 PM, Fred Bricon <fbricon@xxxxxxxxx> wrote:
the jetty plugin doesn't seem overly multi-module friendly (http://jira.codehaus.org/browse/JETTY-1517)
It seems that, without hacking some extraClasspath attribute AND having to install the dependencies in the local repo first, maven-jetty-plugin is unable to support projects from the maven reactor. Given that workspace projects behave more or less like project reactors, it won't work in eclipse.

For jetty:run to work in eclipse, *some* process would have to execute the project installation / assembly first, replace m2e's file reference (currently the target/classes folder) in the Artifact instance used by the jetty plugin, then the jetty plugin would unzip the binary to do its thing. Seems preposterous right? A more elegant approach would probably be to inject some extraclasspath magic dust into jetty  when invoking jetty:run

If Jesse doesn't want to make his plugin support workspace projects, somebody will have to step up and do the work. The best place to strenghten the bridge between m2e and jetty would probably be webby at the moment. Or a new m2e-jetty integration plugin. Not m2e core, not m2e-wtp.

Currently, your best chance is probably to forget jetty:run in eclipse and either use webby or m2e-wtp, whichever works best for your use case.


On Tue, Jan 15, 2013 at 2:18 PM, Miguel Almeida <migueldealmeida@xxxxxxxxx> wrote:
Fred,



On Tue, Jan 15, 2013 at 12:23 PM, Miguel Almeida <migueldealmeida@xxxxxxxxx> wrote:


Your problem *may* be caused by the jetty plugin not supporting the workspace projects exposed by m2e. Finding out would require debugging jetty:run. have you asked the jetty plugin maintainers?
Trying on IRC (I'm asking Jesse), I might also try the mailing list. But I take it it's a long shot. How or in what path are the workspace projects exposed by m2e in? I take it that the plugin doesn't like workspace projects very much, as when I run jetty:run-war it'll be expecting a jar/war dependency and complain about the workspace project dependency [1]

As Jesse McConnell points out, "that is something the jetty plugin will never do, it is intended to run on the command line and not care about editors or workspaces".
What I don't understand is why m2e (or m2e-wtp) is failing to expose the overlay's resources to the warTest classpath.



_______________________________________________
m2e-users mailing list
m2e-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-users




--
"Have you tried turning it off and on again" - The IT Crowd

_______________________________________________
m2e-users mailing list
m2e-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-users



Back to the top