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
<[email protected]>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 <[email protected]> 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 <
>> [email protected]> wrote:
>>
>>> Fred,
>>>
>>>
>>>
>>> On Tue, Jan 15, 2013 at 12:23 PM, Miguel Almeida <
>>> [email protected]> 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
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/m2e-users
>>>
>>>
>>
>>
>> --
>> "Have you tried turning it off and on again" - The IT Crowd
>>
>> _______________________________________________
>> m2e-users mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/m2e-users
>>
>>
>
_______________________________________________
m2e-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/m2e-users
