[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-users] wtp, "run on server" -> ensure correct deployment?
|
Hi Fred, all;
and first off, thanks for your thoughts on that.
Am 19.10.2012 18:38, schrieb Fred Bricon:
Let's assume you're using m2e-wtp, if you don't then start by installing
it [1]
I guess I have so.
m2e-wtp doesn't flag target/<module-name> for deployment. Look at
<project>/.settings/org.eclipse.wst.common.component to see what's
deployed instead.
I will have a look at this. At least, from my point of view: What's the
rationale for that? It just seems to make things considerably more
complex and less manageable so there must be a reason for this...?
jars or classes missing would definitely be a bug, if you can reproduce
that with a sample project with m2e-wtp, please report a bug at [2]
Will try that. As far as this is concerned, however, it is not really
"deterministic", or at least I haven't so far found a pattern. Setup is
like this:
- Two jar artifacts and a war artifact in the same workspace. The war
depends upon the two jars, and the two jars are maven declared
compile-scope dependencies in the wars pom.xml. If I build this directly
via maven, the two jars end up in the war in WEB-INF/lib where they are
supposed to.
- In Eclipse, in my configuration, "standard" behaviour in the war
project is that "Deployment Assembly" contains "maven classpath" things
to go to WEB-INF/lib and workspace projects explicitely included there.
This way it works, the workspace jar artifacts are deployed as exploded
folders, no matter whether or not I use "workspace dependency resolution".
- If I remove the two workspace jar artifacts explicitely listed in
"Deployment Assembly", I still would expect m2eclipse to deploy the
"maven classpath dependencies" to WEB-INF/lib in the war, so including
the (pre-built versions of the) two jar artifacts in the workspace
(after all, the stability of a build possibly should not depend upon
whether or not a project is opened in a workspace). However, if I use
this setup and not have the two workspace jars explicitely listed in
"Deployment assembly" configuration, they aren't deployed even if they
are in pom.xml and, so, in the maven classpath dependencies. This is not
really what is to be expected IMO.
Maybe, though, I am doing it all wrong. AFAICT, so far, there are way
too many options to mess with in a situation where a simple "take
anything in 'target/<module>' and deploy that" would be incredibly more
straightforward and manageable.
For GWT related resources, it's trickier : additional configuration is
required : you can try using the gwt m2e configurator we have at JBoss [3]
Well actually, yes, that's what made me mess with the war Deployment
Assembly in the first place: Using maven, the jars (containing
GWT/Vaadin widget sets) are just built cleanly, everything's in there.
In the Eclipse setup, I spent half a day trying to ensure the things
deployed to the app server by the IDE do contain the same things maven
puts into the jars when doing "mvn install". I gave up on that
eventually, it never really was reproducible, sometimes it even seemed
to be different just after something as simple as restarting the IDE or
cleaning the whole workspace once or twice.
Don't get me wrong: I consider Eclipse and most of the things in m2e
pretty good, and I appreciate the work and effort people put into this.
But recently it seems to get into my way pretty often in situations in
which it would absolutely not be required. Talking build stability - why
spending two days trying to convince the IDE to just also be capable of
doing what maven does rather well out of the box? Why spending half a
day filling my pom.xml files with Eclipse specific declarations telling
the IDE to please ignore any "unknown" maven plugins and not complain
about missing lifecycle adapters for plugins for which there aren't any?
This seems to add an utter amount of complexity without, at least in the
use case of using maven for web app development, much noticeable benefit
in return... :/
Oh well, never mind, back to work.
--
"Have you tried turning it off and on again" - The IT Crowd
Yes. I definitely did. ;)
Cheers, all the best to you;
Kristian
