Re: Why does maven 3 still use the M2_HOME variable?
I run m2 and m3 on the same machine at the same time (but from different windows)... no issues at all for me. http://javaadventure.blogspot.com/2011/03/my-magic-maven-and-ant-version.html just don't use M2_HOME at all, use MAVEN_HOME both versions pick it up quite successfully the M2_HOME was only legacy when M1 was around. On 19 July 2011 06:13, Peter Wilkinson proggerp...@gmail.com wrote: Doing this stops maven 2 and maven 3 being able to run on the same machine. It also makes no sense. Cheers, Peter
Re: Why does maven 3 still use the M2_HOME variable?
The maven installation instructions [1] explicitly mention the M2_HOME variable (and not MAVEN_HOME), is this obsolete? -Lukas [1] http://maven.apache.org/download.html#Installation On 07/19/2011 08:26 AM, Stephen Connolly wrote: I run m2 and m3 on the same machine at the same time (but from different windows)... no issues at all for me. http://javaadventure.blogspot.com/2011/03/my-magic-maven-and-ant-version.html just don't use M2_HOME at all, use MAVEN_HOME both versions pick it up quite successfully the M2_HOME was only legacy when M1 was around. On 19 July 2011 06:13, Peter Wilkinsonproggerp...@gmail.com wrote: Doing this stops maven 2 and maven 3 being able to run on the same machine. It also makes no sense. Cheers, Peter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Repository routing for Maven 3
Hi John!
I'll try to get through it while on the train to $dayjob. Maybe we can dump
this into a Wiki page as 'under construction'?
txs and LieGrue,
strub
--- On Tue, 7/19/11, John Casey jdca...@commonjava.org wrote:
From: John Casey jdca...@commonjava.org
Subject: Re: [DISCUSS] Repository routing for Maven 3
To: Maven Developers List dev@maven.apache.org
Date: Tuesday, July 19, 2011, 3:37 AM
heh, hit send to fast...
On 7/18/11 11:11 PM, John Casey wrote:
This has been a long time coming, and I apologize for
the delay. I've
been trying to clear enough time to work on some last
touches to the
implementation before writing this, to make sure the
description agrees
with the code.
The code for this discussion is in the
mirror-group-routing branch of
maven3:
https://svn.apache.org/repos/asf/maven/maven-3/branches/mirror-group-routing
The goal of this branch is to create a mechanism by
which the Maven
repository can be fragmented, allowing artifact
resolution to be routed
to appropriate repository URLs based on groupId and
canonical repository
URL.
The cornerstone of this mapping is the routes file,
which will have a
default copy hosted on Maven project infrastructure.
The file format
(for now) is JSON. Users will be free to create their
own routes file
and point Maven to that instead if they prefer.
Alternatively, the
routes file can be generated by a repository manager
or really any
application capable of hosting or generating the
required JSON file.
So, what's in this routes file? It has two sections:
groupId -
canonical-URL mappings, and canonical-URL -
mirror-URL mappings. These
sections are separate to allow generators to
pass-through one set of
mappings while augmenting or replacing the other...for
example, a
generator may not want to alter the groupId -
canonical-URL mappings,
but will probably want to generate a custom
canonical-URL - mirror-URL*
map.
To begin with, each groupId can have a canonical
repository URL attached
to it in the routing table. This is meant to be the
main Maven
repository that hosts artifacts for that groupId. Many
open-source
projects will probably list something like:
http://oss.sonatype.org/content/groups/public
as the canonical URL for their groupId, since many
open-source projects
use Sonatype OSS to deploy their artifacts.
Given a canonical repository URL for an artifact
groupId, the routing
table then matches this canonical URL up to one or
more mirror URLs. In
the example above, the default routing table JSON
would probably specify
something like (using very rough pseudo-JSON):
http://oss.sonatype.org/content/groups/public: [
{ id: central, url: http://repo1.maven.org/maven2/},
{ id: ibiblio, url:
http://mirrors.ibiblio.org/pub/mirrors/maven2/; }
]
Ideally, I'd like to see the ASF Maven infrastructure
host an
application that allowed any OSS project to register
their groupId and
canonical URL, and allow mirror operators to register
which canonical
URLs they mirror. This would allow us to delegate
administration to
those who have a vested interest in ensuring the
correctness of that
metadata. This application could be something very
lightweight, like a
CouchDB instance that hosts an HTML- and JS-based
application...or, it
could be something more in line with the interests of
our developers, if
needed. The point is it's just the routes file we need
to host, and it
doesn't really matter how.
To support the demands of groupId and mirror routing,
I've had to hack
into the aether-connector-wagon and wrap the
WagonRepositoryConnector in
a class that can query the router for the correct URL
before delegating
to the main WagonRepositoryConnector. Additionally,
I've introduced
modifications and new logic to the MirrorSelector
classes used by Maven
(yes, there are two: one in the old legacy code, and
another in Aether)
in order to make them routing-aware.
I'm also including a DNS TXT-record-based discovery
strategy as well, to
demonstrate the auto-discovery logic. DNS TXT is
something I've been
playing around with for my home network, to
automatically select my
local Archiva instance when I'm at home, and use the
unmirrored
locations outside the house.
I think the implementation is getting pretty close.
I'm currently having
trouble with some sort of race condition that's
showing up in the ITs.
I'm still going through it, but it's likely to be slow
going for awhile
to pin it down, especially since concurrency
programming isn't something
I'm expert at (yet). If anyone has an inclination to
take a look and see
if they can figure out why ITs are failing
intermittently, I'd welcome
the help.
If there's anything in here that doesn't make sense
...just let me know and I can fill in details.
--
John Casey
Developer, PMC Member - Apache Maven
Re: Why does maven 3 still use the M2_HOME variable?
Hi Peter, Peter Wilkinson wrote: Doing this stops maven 2 and maven 3 being able to run on the same machine. It also makes no sense. Don't set it. The Maven start scripts will set it locally themselves. I can run any Maven version side-by-side just by some symbolic links without any environment setting: /usr/bin $ ls -og mvn* lrwxrwxrwx 1 7 Jan 25 08:42 mvn - mvn-3.0 lrwxrwxrwx 1 32 Mar 23 2010 mvn-2.0 - /usr/share/maven-bin-2.0/bin/mvn lrwxrwxrwx 1 32 Sep 17 2009 mvn-2.2 - /usr/share/maven-bin-2.2/bin/mvn lrwxrwxrwx 1 32 Mar 11 08:28 mvn-3.0 - /usr/share/maven-bin-3.0/bin/mvn - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How share a resource across modules builds
Any ideas? Is this more a question for a Plexus user group? ==John On Mon, Jul 18, 2011 at 8:52 AM, John Swingle johnswingl...@gmail.comwrote: I'm writing a plugin that is executed for each module in a multi-module build. I want to inject the same instance of a custom class into each mojo invocation so that I can share the resource. How is this done? I create the custom class and tried injecting it into my mojo class with the following annotation: * @component role=com.example.ResourceToBeSharedAcrossModuleMojos * @required However, I get the following exception: Component descriptor cannot be found in the component repository: com.example.ResourceToBeSharedAcrossModuleMojos. I'm familiar with Spring and IoC in general, but I'm unfamiliar with Plexus and the maven lifecycle. What is the proper way of achieving this? I basically want the class in question to be a singleton and have the same instance injected into each mojo; otherwise, I'll have to create property in the mojo, but I don't like that approach. Thanks for any help! ==John
Re: [DISCUSS] incorporate EPL Aether
I'm not entirely sure, but I think that there may be a false dilemma here on the subject of forks. In general, the Foundation does not permit us to absorb large amounts of code without a formal grant, even if the code carries AL markings. This has come up in the incubator over and over. So, even if Aether is dual-licensed, we cannot simply fork it back into the ASF without the cooperation of the copyright holder. If the copyright holder is cooperative, they can grant even if it's EPL, and if they are not interested in granting, then, a dual license isn't a 'license to fork' into ASF svn. On the other hand, a group of people can certainly make a fork at Codehaus or github, regardless of EPL or AL. So, if I've got this right, there is no particular advantage to us of sticking to the dual-licensed version. If there was an irreconcilable disagreement with Sonatype, we can fork outside the ASF either way, and if there's no such meltdown, we don't need to fork either way. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JXR release vote
We need some more votes on there, please. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven JXR version 2.3
+1 On 7/15/11 1:05 PM, Benson Margulies wrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleName=TextprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven JXR version 2.3
+1 LieGrue, strub --- On Tue, 7/19/11, John Casey jdca...@commonjava.org wrote: From: John Casey jdca...@commonjava.org Subject: Re: [VOTE] Release Maven JXR version 2.3 To: Maven Developers List dev@maven.apache.org Date: Tuesday, July 19, 2011, 3:05 PM +1 On 7/15/11 1:05 PM, Benson Margulies wrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleName=TextprojectId=11085Create=Create There are still a gaggle of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-028/ Staging sites: maven.apache.org/plugins/maven-jxr-plugin/staging maven.apache.org/jxr/staging Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at leasr 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 3 builds take much longer to run in 3.0.3 than in 3.0b1
I'm trying to track down the reason that our builds take much longer to
build under 3.0.3 rather than 3.0b1. Under 3.0.3, our build takes around 9
minutes, whereas under 3.0b1, it's 3 minutes and 30 seconds. While using
jconsole, I saw that most of the time (in 3.0.3) is spent inside
DefaultProjectDependenciesResolver.java. So I downloaded the source to both
3.0b1 and 3.0.3 to see what's happening. I noticed that in 3.0.3 there are
two versions of the class. One is in org.apache.maven.project, while the
other is in org.apache.maven. It also appears that in 3.0.3, the former is
being used. While stepping through the code, I saw that bulk of the time is
spent when it reaches this statement:
node = repoSystem.collectDependencies( session, collect ).getRoot();
In 3.0b1, the code does:
ArtifactResolutionResult result = repositorySystem.resolve( request );
I also noticed that respositorySystem is of type RepositorySystem, and the
concrete implementation is LegacyRepositorySystem. I'm assuming that this
was being used while the Maven 3 was in beta until the new implementation
was created? Going back to 3.0.3, the collectDependencies method lives in
DefaultRepositorySystem.java which is part of
org.sonatype.aether.impl.internal. This eventually calls
collectDependenciesinside
DefaultDependencyCollector.java which is also part of
org.sonatype.aether.impl.internal. I'm assuming that this is how the
dependency graph is built. My question is if there is a way to make this
process faster? Could there be something wrong in the way we've set up our
dependencies in our project which could cause this process to be so slow?
Or, is this a performance regression? If this is the case, I can open an
Jira issue.
--
Ruin untold;
And thine own sadness,
Sing in the grass,
When eve has forgot, that no more hear common things that gleam and pass;
But seek alone to lip, sad Rose of love and ruin untold;
And thine own mother
Can know it as I know
More than another
What makes your own sadness,
Set in her eyes.
$s=01:11:02:11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01:11:
04:11:06:12:04:11:01:12:01:13:02:12:01:14:01:13:01:11:03:12:
01:11:04:12:02:11:01:11:01:13:02:11:03:11:06:11:01:11:05:12:
02:11:01:11:01:13:02:11:02:12:01:12:04:11:06:12:01:11:04:12:
04:11:01:12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01:13:
02:11:01:02:11:01:12:02;
@a=split(/:/,$s);$j=;foreach$c(@a) {@n=split(//,$c);$j.=$n[0]x$n[1];}
for($i=0;$i$j=~y///c;$i+=8){print
chr(unpack(N,pack(B32,substr(0x32 .substr($j,$i,8),-32;}
[RESULT] [VOTE] Release Maven JXR version 2.3
The vote has passed with the following results: binding +1: hboutemy jdcasey struberg I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency plugin versus Aether
On 07/17/2011 05:30 PM, Benson Margulies wrote: I can't even figure out which JIRA in MDEP corresponds to [the dependency plugin issue]. Could someone please send me a pointer? Are you referring to http://jira.codehaus.org/browse/MSHARED-167 by any chance? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
On better testing for webapps in maven....
On peripherally maven-dev related, but as thought leaders, I hope you guys
would take interest.
So I've been aggravated that I've had to start a web app up before running a
test in eclipse, given the way we typically run apps with things like the
jetty-maven-plugin (the startup/shutdown pre/post integration test)
Plus it prevents debugging the app server easily and doing the jdk 1.4
method hot swapping performed by eclipse.
So I came up with a solution I believe is cleaner, works in and out of
eclipse definitely open to suggestions for improvement, but I believe
this will make devs a lot more productive, and I'd eventually like to see
the community move away from the pre/post-integration test start/stop I see
us doing so often.
Already using some of this at a couple of companies I've contracted in the
past.
info is here: https://github.com/rexhoffman/test-extensions
So here is the readme file from the project
Pretty straight forward maven projects, build with ehoffman-parent/pom.xml
and a maven 3 install:
End results: you'll be able to easily write tests that start up web
applications in jetty (either by detecting a marking webapp.properties
file in an open webapp project and running it exploded, or by scanning
the target/ dir for .war files.
The webapp is left open for all tests that happen to use it during the
execution, whether driven by a right-click run as testng test in
eclipse, or via maven surefire runner.
There is equivalent support for Webdriver, where browser instances are
pooled and tests are run multithreaded.
So here is an example test:
*package org.ehoffman.testing.module.webapp;
import static org.ehoffman.testing.fest.webdriver.WebElementAssert.assertThat;
import org.ehoffman.testing.module.webdriver.WebDriverModule;
import org.ehoffman.testng.extensions.Fixture;
import org.ehoffman.testng.extensions.modules.FixtureContainer;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.testng.annotations.Listeners;
import org.testng.annotations.Test;
@Listeners(MyEnforcer.class)
public class SimpleTest {
@Test(groups=functional)
@Fixture(factory={EmbeddedWebappModule.class,
WebDriverModule.Firefox.class, WebDriverModule.HtmlUnitIE6.class})
public void simpleTestOfApplication(){
WebDriver driver = FixtureContainer.getService(WebDriverModule.class);
Application application =
FixtureContainer.getService(EmbeddedWebappModule.class);
driver.navigate().to(application.getDefaultRootUrl());
assertThat(driver.findElement(By.id(message))).isDisplayed().textContains(the
time is now : );
}
}*
So this test is actually run twice, once in Firefox, and once in
HtmlUnit (because those modules both have a getModuleType method
that returns the string WebDriver) after starting up the app handled
by EmbeddedWebappModule.class.
Because these tests can be easily run and debugged in eclipse, method
byte code replacement (stuff that's been around since jdk 1.4) can be
used while debugging to work on methods either in the application or
test (after popping it of the execution stack)
Re: dependency plugin versus Aether
That's it. Thanks. On Tue, Jul 19, 2011 at 2:32 PM, Jesse Glick jesse.gl...@oracle.com wrote: On 07/17/2011 05:30 PM, Benson Margulies wrote: I can't even figure out which JIRA in MDEP corresponds to [the dependency plugin issue]. Could someone please send me a pointer? Are you referring to http://jira.codehaus.org/browse/MSHARED-167 by any chance? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: On better testing for webapps in maven....
You might want to look at Sonatype's m2eclipse-webby[1] for a very easy way to
startup web containers. It would probably be relatively straight forward to
integrate your code for runnings tests.
Webby leverages Cargo to start/stop containers and we've added debugging
support, resource filtering and WAR overlay support.
https://docs.sonatype.org/display/M2ECLIPSE/Integration+with+Maven+WAR+Plugin
On Jul 19, 2011, at 3:11 PM, Rex Hoffman wrote:
On peripherally maven-dev related, but as thought leaders, I hope you guys
would take interest.
So I've been aggravated that I've had to start a web app up before running a
test in eclipse, given the way we typically run apps with things like the
jetty-maven-plugin (the startup/shutdown pre/post integration test)
Plus it prevents debugging the app server easily and doing the jdk 1.4
method hot swapping performed by eclipse.
So I came up with a solution I believe is cleaner, works in and out of
eclipse definitely open to suggestions for improvement, but I believe
this will make devs a lot more productive, and I'd eventually like to see
the community move away from the pre/post-integration test start/stop I see
us doing so often.
Already using some of this at a couple of companies I've contracted in the
past.
info is here: https://github.com/rexhoffman/test-extensions
So here is the readme file from the project
Pretty straight forward maven projects, build with ehoffman-parent/pom.xml
and a maven 3 install:
End results: you'll be able to easily write tests that start up web
applications in jetty (either by detecting a marking webapp.properties
file in an open webapp project and running it exploded, or by scanning
the target/ dir for .war files.
The webapp is left open for all tests that happen to use it during the
execution, whether driven by a right-click run as testng test in
eclipse, or via maven surefire runner.
There is equivalent support for Webdriver, where browser instances are
pooled and tests are run multithreaded.
So here is an example test:
*package org.ehoffman.testing.module.webapp;
import static org.ehoffman.testing.fest.webdriver.WebElementAssert.assertThat;
import org.ehoffman.testing.module.webdriver.WebDriverModule;
import org.ehoffman.testng.extensions.Fixture;
import org.ehoffman.testng.extensions.modules.FixtureContainer;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.testng.annotations.Listeners;
import org.testng.annotations.Test;
@Listeners(MyEnforcer.class)
public class SimpleTest {
@Test(groups=functional)
@Fixture(factory={EmbeddedWebappModule.class,
WebDriverModule.Firefox.class, WebDriverModule.HtmlUnitIE6.class})
public void simpleTestOfApplication(){
WebDriver driver = FixtureContainer.getService(WebDriverModule.class);
Application application =
FixtureContainer.getService(EmbeddedWebappModule.class);
driver.navigate().to(application.getDefaultRootUrl());
assertThat(driver.findElement(By.id(message))).isDisplayed().textContains(the
time is now : );
}
}*
So this test is actually run twice, once in Firefox, and once in
HtmlUnit (because those modules both have a getModuleType method
that returns the string WebDriver) after starting up the app handled
by EmbeddedWebappModule.class.
Because these tests can be easily run and debugged in eclipse, method
byte code replacement (stuff that's been around since jdk 1.4) can be
used while debugging to work on methods either in the application or
test (after popping it of the execution stack)
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
-
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
Re: On better testing for webapps in maven....
Doh... just realized I didn't commit the correct relative path of the parent
pom in all the children ughh... I'll do that when I get home tonight,
don't want to commit to the project from work (pulled it down to demo it
today to the point haired folks)
I did look at using cargo underneath, but since it tends to
spawn separate jvms, and want wars instead of exploded dirs for most of the
servers, I went with direct jetty -- perhaps I didn't investigate enough.
And the big benefit of the library is that there are no extra steps, aside
from the initial app setup/pom editing. You can simply right click on a
file and debug as testng test
I'm kinda following a hacky actor pattern for the individual services
...should probably clean that up some... used by the tests (app server
and web driver instances) and am thinking of trying to keep them resident
somewhere in memory in eclipse at all times, rebuilding them when the jdk
1.4 debug reloading wont work due to method signature change, as that'd make
testing very fast, after having already made it very easy.
Though at some point I might look at glassfish or resin if there is interest
(any webcontainer that doesn't mind being started in debug mode by eclipse).
I will dig in webby tonight to look at it's capabilities though.
On Tue, Jul 19, 2011 at 12:21 PM, Jason van Zyl ja...@sonatype.com wrote:
You might want to look at Sonatype's m2eclipse-webby[1] for a very easy way
to startup web containers. It would probably be relatively straight forward
to integrate your code for runnings tests.
Webby leverages Cargo to start/stop containers and we've added debugging
support, resource filtering and WAR overlay support.
https://docs.sonatype.org/display/M2ECLIPSE/Integration+with+Maven+WAR+Plugin
On Jul 19, 2011, at 3:11 PM, Rex Hoffman wrote:
On peripherally maven-dev related, but as thought leaders, I hope you
guys
would take interest.
So I've been aggravated that I've had to start a web app up before
running a
test in eclipse, given the way we typically run apps with things like the
jetty-maven-plugin (the startup/shutdown pre/post integration test)
Plus it prevents debugging the app server easily and doing the jdk 1.4
method hot swapping performed by eclipse.
So I came up with a solution I believe is cleaner, works in and out of
eclipse definitely open to suggestions for improvement, but I believe
this will make devs a lot more productive, and I'd eventually like to see
the community move away from the pre/post-integration test start/stop I
see
us doing so often.
Already using some of this at a couple of companies I've contracted in
the
past.
info is here: https://github.com/rexhoffman/test-extensions
So here is the readme file from the project
Pretty straight forward maven projects, build with
ehoffman-parent/pom.xml
and a maven 3 install:
End results: you'll be able to easily write tests that start up web
applications in jetty (either by detecting a marking webapp.properties
file in an open webapp project and running it exploded, or by scanning
the target/ dir for .war files.
The webapp is left open for all tests that happen to use it during the
execution, whether driven by a right-click run as testng test in
eclipse, or via maven surefire runner.
There is equivalent support for Webdriver, where browser instances are
pooled and tests are run multithreaded.
So here is an example test:
*package org.ehoffman.testing.module.webapp;
import static
org.ehoffman.testing.fest.webdriver.WebElementAssert.assertThat;
import org.ehoffman.testing.module.webdriver.WebDriverModule;
import org.ehoffman.testng.extensions.Fixture;
import org.ehoffman.testng.extensions.modules.FixtureContainer;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.testng.annotations.Listeners;
import org.testng.annotations.Test;
@Listeners(MyEnforcer.class)
public class SimpleTest {
@Test(groups=functional)
@Fixture(factory={EmbeddedWebappModule.class,
WebDriverModule.Firefox.class, WebDriverModule.HtmlUnitIE6.class})
public void simpleTestOfApplication(){
WebDriver driver = FixtureContainer.getService(WebDriverModule.class);
Application application =
FixtureContainer.getService(EmbeddedWebappModule.class);
driver.navigate().to(application.getDefaultRootUrl());
assertThat(driver.findElement(By.id(message))).isDisplayed().textContains(the
time is now : );
}
}*
So this test is actually run twice, once in Firefox, and once in
HtmlUnit (because those modules both have a getModuleType method
that returns the string WebDriver) after starting up the app handled
by EmbeddedWebappModule.class.
Because these tests can be easily run and debugged in eclipse, method
byte code replacement (stuff that's been around since jdk 1.4) can be
used while debugging to work on methods either in
Re: Maven 3 builds take much longer to run in 3.0.3 than in 3.0b1
Are you using version ranges ? There seems to be an issue with a combinatorial explosion of sorts with version ranges, I am not sure if there has been a jira submitted anywhere for that with a reproducible test case, though. The version range jump (3.0b1 to 3.0.3 include aether), so there's some pretty substantial changes to the dependency resolution stuff. Kristian ti., 19.07.2011 kl. 09.27 -0700, skrev Vivin Suresh Paliath: I'm trying to track down the reason that our builds take much longer to build under 3.0.3 rather than 3.0b1. Under 3.0.3, our build takes around 9 minutes, whereas under 3.0b1, it's 3 minutes and 30 seconds. While using jconsole, I saw that most of the time (in 3.0.3) is spent inside DefaultProjectDependenciesResolver.java. So I downloaded the source to both 3.0b1 and 3.0.3 to see what's happening. I noticed that in 3.0.3 there are two versions of the class. One is in org.apache.maven.project, while the other is in org.apache.maven. It also appears that in 3.0.3, the former is being used. While stepping through the code, I saw that bulk of the time is spent when it reaches this statement: node = repoSystem.collectDependencies( session, collect ).getRoot(); In 3.0b1, the code does: ArtifactResolutionResult result = repositorySystem.resolve( request ); I also noticed that respositorySystem is of type RepositorySystem, and the concrete implementation is LegacyRepositorySystem. I'm assuming that this was being used while the Maven 3 was in beta until the new implementation was created? Going back to 3.0.3, the collectDependencies method lives in DefaultRepositorySystem.java which is part of org.sonatype.aether.impl.internal. This eventually calls collectDependenciesinside DefaultDependencyCollector.java which is also part of org.sonatype.aether.impl.internal. I'm assuming that this is how the dependency graph is built. My question is if there is a way to make this process faster? Could there be something wrong in the way we've set up our dependencies in our project which could cause this process to be so slow? Or, is this a performance regression? If this is the case, I can open an Jira issue. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 builds take much longer to run in 3.0.3 than in 3.0b1
As far as I know, we're not using ranges. However, I don't know if we're
pulling anything in that does use ranges. What's a good way to find out?
As far as the aether stuff, I noticed as much from looking at the source.
I'm just trying to figure out if there is a way to make the
dependency-resolution process faster.
Thanks!
Vivin
On Tue, Jul 19, 2011 at 1:06 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
Are you using version ranges ? There seems to be an issue with a
combinatorial explosion of sorts with version ranges, I am not sure if
there has been a jira submitted anywhere for that with a reproducible
test case, though.
The version range jump (3.0b1 to 3.0.3 include aether), so there's some
pretty substantial changes to the dependency resolution stuff.
Kristian
ti., 19.07.2011 kl. 09.27 -0700, skrev Vivin Suresh Paliath:
I'm trying to track down the reason that our builds take much longer to
build under 3.0.3 rather than 3.0b1. Under 3.0.3, our build takes around
9
minutes, whereas under 3.0b1, it's 3 minutes and 30 seconds. While using
jconsole, I saw that most of the time (in 3.0.3) is spent inside
DefaultProjectDependenciesResolver.java. So I downloaded the source to
both
3.0b1 and 3.0.3 to see what's happening. I noticed that in 3.0.3 there
are
two versions of the class. One is in org.apache.maven.project, while the
other is in org.apache.maven. It also appears that in 3.0.3, the former
is
being used. While stepping through the code, I saw that bulk of the time
is
spent when it reaches this statement:
node = repoSystem.collectDependencies( session, collect ).getRoot();
In 3.0b1, the code does:
ArtifactResolutionResult result = repositorySystem.resolve( request );
I also noticed that respositorySystem is of type RepositorySystem, and
the
concrete implementation is LegacyRepositorySystem. I'm assuming that this
was being used while the Maven 3 was in beta until the new implementation
was created? Going back to 3.0.3, the collectDependencies method lives in
DefaultRepositorySystem.java which is part of
org.sonatype.aether.impl.internal. This eventually calls
collectDependenciesinside
DefaultDependencyCollector.java which is also part of
org.sonatype.aether.impl.internal. I'm assuming that this is how the
dependency graph is built. My question is if there is a way to make this
process faster? Could there be something wrong in the way we've set up
our
dependencies in our project which could cause this process to be so slow?
Or, is this a performance regression? If this is the case, I can open an
Jira issue.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Ruin untold;
And thine own sadness,
Sing in the grass,
When eve has forgot, that no more hear common things that gleam and pass;
But seek alone to lip, sad Rose of love and ruin untold;
And thine own mother
Can know it as I know
More than another
What makes your own sadness,
Set in her eyes.
$s=01:11:02:11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01:11:
04:11:06:12:04:11:01:12:01:13:02:12:01:14:01:13:01:11:03:12:
01:11:04:12:02:11:01:11:01:13:02:11:03:11:06:11:01:11:05:12:
02:11:01:11:01:13:02:11:02:12:01:12:04:11:06:12:01:11:04:12:
04:11:01:12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01:13:
02:11:01:02:11:01:12:02;
@a=split(/:/,$s);$j=;foreach$c(@a) {@n=split(//,$c);$j.=$n[0]x$n[1];}
for($i=0;$i$j=~y///c;$i+=8){print
chr(unpack(N,pack(B32,substr(0x32 .substr($j,$i,8),-32;}
Re: Maven 3 builds take much longer to run in 3.0.3 than in 3.0b1
Hi Vivin, Vivin Suresh Paliath wrote: As far as I know, we're not using ranges. However, I don't know if we're pulling anything in that does use ranges. What's a good way to find out? As far as the aether stuff, I noticed as much from looking at the source. I'm just trying to figure out if there is a way to make the dependency-resolution process faster. You're not the first one reporting this: http://jira.codehaus.org/browse/MNG-5125 - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 builds take much longer to run in 3.0.3 than in 3.0b1
Thanks Jörg! JIRA was the first place I searched to see if anyone else had
noticed this, but I couldn't find anything. Thank you for pointing me to the
issue! Is it possible for me to edit or add to the ticket?
Vivin
On Tue, Jul 19, 2011 at 2:50 PM, Jörg Schaible joerg.schai...@gmx.dewrote:
Hi Vivin,
Vivin Suresh Paliath wrote:
As far as I know, we're not using ranges. However, I don't know if we're
pulling anything in that does use ranges. What's a good way to find out?
As far as the aether stuff, I noticed as much from looking at the source.
I'm just trying to figure out if there is a way to make the
dependency-resolution process faster.
You're not the first one reporting this:
http://jira.codehaus.org/browse/MNG-5125
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Ruin untold;
And thine own sadness,
Sing in the grass,
When eve has forgot, that no more hear common things that gleam and pass;
But seek alone to lip, sad Rose of love and ruin untold;
And thine own mother
Can know it as I know
More than another
What makes your own sadness,
Set in her eyes.
$s=01:11:02:11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01:11:
04:11:06:12:04:11:01:12:01:13:02:12:01:14:01:13:01:11:03:12:
01:11:04:12:02:11:01:11:01:13:02:11:03:11:06:11:01:11:05:12:
02:11:01:11:01:13:02:11:02:12:01:12:04:11:06:12:01:11:04:12:
04:11:01:12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01:13:
02:11:01:02:11:01:12:02;
@a=split(/:/,$s);$j=;foreach$c(@a) {@n=split(//,$c);$j.=$n[0]x$n[1];}
for($i=0;$i$j=~y///c;$i+=8){print
chr(unpack(N,pack(B32,substr(0x32 .substr($j,$i,8),-32;}
maven 3 embedded
hi i'm trying to update my application using the maven 2 embedder to maven 3, and i cannot get the plexus component system to resolve/lookup the components outside of my unit tests, ie. when the same code is executed from a shell. i have gone through the source code for the hudson/jenkins plugin, the maven-core (3.0.3) unit tests, the maven-embedder (3.0.3) MavenCli classes, and attempted to configure things in the ways they do and it still does not work, mostly with this error: org.codehaus.plexus.component.repository.exception.ComponentLookupException : java.util.NoSuchElementException role: org.apache.maven.Maven some more info: - the mavenexecutionrequest building etc. all works, it's just when i get to the plexusContainer.lookup(Maven.class) that it fails. - in brief i create my container like: this.classWorld = new ClassWorld( plexus.core, Thread.currentThread().getContextClassLoader() ); ContainerConfiguration containerConfiguration = new DefaultContainerConfiguration() .setClassWorld(this.classWorld) .setRealm( setupContainerRealm( ) ) .setName( maven ); this.container = new DefaultPlexusContainer( containerConfiguration ); - i can successfully lookup a Maven instance in my maven unit tests (within my maven build) - in the standalone app plexus can find *my* components, but not mavens - i have tried copying the contents of the maven-core META-INF/plexus/components.xml to my components.xml, no luck - most of the plexus guides concerning the class loading/resolving pieces are empty: http://plexus.codehaus.org/guides/developer-guide/index.html it all points to a classloading issue, but i know the required maven classes are on the classpath (albeit in separate jars) as when i remove the jar i get a classnotfoundexception as you would expect. anyway, i've been pulling my hair out for a few days now and so any help is greatly appreciated. thanks larry - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 builds take much longer to run in 3.0.3 than in 3.0b1
Vivin Suresh Paliath wrote: Thanks Jörg! JIRA was the first place I searched to see if anyone else had noticed this, but I couldn't find anything. Thank you for pointing me to the issue! Is it possible for me to edit or add to the ticket? Everyone can add comments, but you have to create an account in JIRA if you do not have one yet. Simply follow the login. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven 3 embedded
hi i'm trying to update my application using the maven 2 embedder to maven 3, and i cannot get the plexus component system to resolve/lookup the components outside of my unit tests, ie. when the same code is executed from a shell. i have gone through the source code for the hudson/jenkins plugin, the maven-core (3.0.3) unit tests, the maven-embedder (3.0.3) MavenCli classes, and attempted to configure things in the ways they do and it still does not work, mostly with this error: org.codehaus.plexus.component.repository.exception.ComponentLookupException : java.util.NoSuchElementException role: org.apache.maven.Maven some more info: - the mavenexecutionrequest building etc. all works, it's just when i get to the plexusContainer.lookup(Maven.class) that it fails. - in brief i create my container like: this.classWorld = new ClassWorld( plexus.core, Thread.currentThread().getContextClassLoader() ); ContainerConfiguration containerConfiguration = new DefaultContainerConfiguration() .setClassWorld(this.classWorld) .setRealm( setupContainerRealm( ) ) .setName( maven ); this.container = new DefaultPlexusContainer( containerConfiguration ); - i can successfully lookup a Maven instance in my maven unit tests (within my maven build) - in the standalone app plexus can find *my* components, but not mavens - i have tried copying the contents of the maven-core META-INF/plexus/components.xml to my components.xml, no luck - most of the plexus guides concerning the class loading/resolving pieces are empty: http://plexus.codehaus.org/guides/developer-guide/index.html it all points to a classloading issue, but i know the required maven classes are on the classpath (albeit in separate jars) as when i remove the jar i get a classnotfoundexception as you would expect. anyway, i've been pulling my hair out for a few days now and so any help is greatly appreciated. thanks larry - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven JXR Version 2.3 Released
The Maven team is pleased to announce the release of the Maven JXR, version 2.3 JXR is a tool for creating cross-references of Java source files. http://maven.apache.org/jxr and http://maven.apache.org/plugins/maven-jxr-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jxr-plugin/artifactId version2.3/version /plugin Release Notes - Maven 2.x JXR - Version 2.3 Release Notes - Maven JXR - Version 2.3 ** Bug * [JXR-64] - System ID of XHTML frameset incorrect in HTML source * [JXR-69] - fails to create cross links in multi-module project * [JXR-84] - Spurious error message fixed in Velocity 1.5 still exists in JXR ** Improvement * [JXR-59] - speed up AbstractJxrReport.hasSources() * [JXR-71] - JXR doesn't link classes with non letters in their names * [JXR-86] - add standard skip configuration option ** New Feature * [JXR-88] - create jxr:aggregate and jxr:test-aggregate Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
