Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] Reducing build times of web application

Thanks, Rafał and Mykola. Webby is exactly what I was looking for!

I got it working (with some minor glitches and NPEs along the way), and now it instantly detects changes, even in those projects listed as dependencies. This is what I'm used to from working on Eclipse plug-in development - great.

Do you know if there is any "principles of operation" documentation for Webby available? I checked out the source code... it looks like it would take a good while to understand. I am somewhat concerned that with the "magic" of Webby I could run into a situation where something works in development, but fails to work in production or vice versa, or some hard to resolve classpath problems (IOW, that it could make me waste time rather than save it!). In fact I already saw one such issue, although I attribute it to a bug in one of my project's libraries (which tries to access a resource via classloader using an initial slash in the resource path - works in standalone Tomcat, but not in Webby).

Also, could you please briefly explain what advantages JRebel has over Webby (or what additional features it provides)?

Regards,
Jan Ploski

Rafał Krzewski wrote:
Definetely, you don't need to do a Maven build to have the changes
reflected in /WEB-INF when using Webby or M2E-WTP. That happens
automagically.
 From my experience Webby is 5 to 10x faster than M2E-WTP for a project
with a dozen modules, several thousand classes and ~0.5 million lines of
code.
When I paired up Webby with JRebel, I'm getting turnaround times < 2s
between Java code change and seeing result in the browser, on my 3 year
old 2GHz Centrino laptop.

cheers,
R.

On 08/05/2011 07:58 AM, Mykola Nikishov wrote:
On 08/05/2011 01:58 AM, Jan Ploski wrote:

AFAICS M2Eclipse doesn't automatically and
incrementally update the contents of target/WEB-INF in that case, so I
have to run the Maven build on the parent project myself (I created a
Run Configuration for that).
WRT to developing web applications: M2E has nothing to do
webapps-specific on its own. You have to look at Sonatype's Webby [1] or
M2E WTP integration [2].

[1]
https://docs.sonatype.org/display/M2ECLIPSE/Integration+with+Maven+WAR+Plugin

[2]
http://community.jboss.org/en/tools/blog/2011/06/23/m2eclipse-wtp-0130-new-noteworthy


Anders Hammar wrote:
So you're doing a Maven build? If so it will take some time (the same
amount of time as from command line). The idea (my take on this at
least) when using the IDE is not to have to do a (full) Maven build all
the time, but rather utilize the fact that Eclipse will compile in
runtime. Eclipse will notify you of compilation errors (as it will when
not using m2eclipse and a Maven project). You want to verify
someting in
the code? Simple, just execute that specific unit test from within
Eclipse (Run as Junit test).

You do a (full) Maven build when you certain things work and you just
want to verify by building the entire project.

This is at least how I try do develop my code,
/Anders

On Thu, Aug 4, 2011 at 22:28, Jan Ploski<jpl@xxxxxxxxxxxxx
<mailto:jpl@xxxxxxxxxxxxx>> wrote:

Sorry, I forgot to mention: I'm using 1.0.0.20110607-2117, so that
shouldn't be an issue.

From the console output I see the time is spread among modules
(module names changed to protect the innocent):

[INFO] Reactor Summary:
[INFO]
[INFO] Parent project ..................... SUCCESS [0.521s]
[INFO] Util ..............................__. SUCCESS [3.082s]
[INFO] Security ........................... SUCCESS [1.156s]
[INFO] Business interfaces ................ SUCCESS [1.272s]
[INFO] Security implementation ............ SUCCESS [0.790s]
[INFO] Business services implementation ... SUCCESS [1.418s]
[INFO] WAR ..............................__.. SUCCESS [7.738s]
[INFO] EAR ..............................__.. SUCCESS [5.742s]

So I suppose my question may be more of a "best practices" / "is
that normal" nature: given such a project structure, and my act of
changing of a single source file, should I "suck it up", or am I
justified in thinking that some optimizations in the development
process are needed. I have been using scripting languages much
recently, so delays of this kind do cause annoyance. But they might
be just a fact of life given the different technology?...

Regards,
Jan Ploski

Anders Hammar wrote:

What version of m2e are you using? v1.0 is a great improvement
compared
to the older 0.x versions (where the behavior you're describing
could
happen).

/Anders

On Thu, Aug 4, 2011 at 18:21, Jan Ploski<jpl@xxxxxxxxxxxxx
<mailto:jpl@xxxxxxxxxxxxx>
<mailto:jpl@xxxxxxxxxxxxx<mailto:jpl@xxxxxxxxxxxxx>>> wrote:

Hi,

As a new user of M2Eclipse, I am wondering about typical and
minimal
build times. What I have here is a multi-module project
structured
according to the usual recommendations (much like the
multi-module
enterprise example in the Maven by Example book). Building
it (from
non-dirty state) using M2Eclipse (or directly with Maven)
takes
about 30 seconds. So after any slightest change in code I
have to
wait for at least 30 seconds before seeing the effect of my
change
in the browser. Given that Eclipse compiles the individual
classes
instantly as I type, the build step seems like a great waste
and an
unnecessary overhead.

What are your impressions? Does working with Maven
necessarily
induce such delays into the edit-compile-run cycle and
should one
treat this overhead as a price for having a portable build
system
("just buy faster hardware")? Or are there any
tried-and-true tricks
for speeding up the process? Right now I'm thinking about
hacking
together something project-specific that detects changes in
.class
files and then updates the corresponding resources in
WEB-INF. But
that's very crude and essentially means working around
Maven (in
development) instead of relying on it equally everywhere.


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



Back to the top