You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2009/11/04 03:09:23 UTC
Java versions within surefire ?
I am working on a patch to surefire and find that habitually I'm
consistently grabbing got my <>'s and java 5 for loops. I see the
following seems to apply:
Some surefire-providers have an implicit java 5 requirement because
(like junit 4) they support java 5 projects.
But what language levels are effective in shared modules (like
surefire-api), surefire-plugin and surefire-booter ? At least sine poms
don't seem to be entirely correctly set up to refelect language levels
either (testng provider uses java 5 features but does not seem to be at
java 5 language level in the poms - AFAIK)
Regards,
Kristian Rosenvold
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Java versions within surefire ?
Posted by Stephen Connolly <st...@gmail.com>.
I don;t see much to be gained in making surefire require JDK 1.5.
There are a lot of people on 2.0.x (heck recent traffic on the list
would seem to imply a lot of people starting to use maven 1.1!) and
forcing JDK 1.5 on them just to get some of the fixes in surefire
would seem to be not nice.
Now that we have maven-plugin-enforcer we should be able to test the
core plugins a bit better and that way we can start releasing them
more often... just have to wait for Benjamin to wire it up on the grid
-Stephen
2009/11/4 Brett Porter <br...@apache.org>:
> The plugin is 1.4 and the booter/api is 1.3 so that you can still run tests
> on old JDKs.
>
> The plugin *could* be updated to 1.5 if it is made to require Maven 2.2.
> Probably not worth it at this stage.
>
> - Brett
>
> On 03/11/2009, at 6:09 PM, Kristian Rosenvold wrote:
>
>> I am working on a patch to surefire and find that habitually I'm
>> consistently grabbing got my <>'s and java 5 for loops. I see the
>> following seems to apply:
>>
>> Some surefire-providers have an implicit java 5 requirement because
>> (like junit 4) they support java 5 projects.
>>
>> But what language levels are effective in shared modules (like
>> surefire-api), surefire-plugin and surefire-booter ? At least sine poms
>> don't seem to be entirely correctly set up to refelect language levels
>> either (testng provider uses java 5 features but does not seem to be at
>> java 5 language level in the poms - AFAIK)
>>
>>
>> Regards,
>>
>> Kristian Rosenvold
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Dependency on system property user.dir
Posted by Stephen Connolly <st...@gmail.com>.
Grand so
On 8 February 2010 11:47, Benjamin Bentmann <be...@udo.edu>wrote:
> Stephen Connolly wrote:
>
> How will I write a plugin that works for both 2.x and 3.x and can detect
>> if
>> the build is running in parallel?
>>
>
> /** @parameter default-value="${session.parallel}" */
> private Boolean parallel;
>
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Artifact instances in a reactor build
Posted by Kristian Rosenvold <kr...@gmail.com>.
On Mon, Feb 15, 2010 at 6:14 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> I am not 100% sure, but I think this may break MavenMetadataCache, which
> caches Artifact instances and assumes they do not change. In m2e, for
> example, we do not flash the cache before each build, only when project
> pom.xml changes. So if one of mojos changes cached Artifact instance,
> next build may misbehave.
>
Nice tip; I checked the code and there seem to be no dependencies on the
mutable parts of
DefaultArtifact. If it were up to me I'd just make most of DefaultArtifact
final and immutable...
It seems like Brett is right; the "file/resolved" bit in DefaultArtifact
probably shouldn't have been
there, and when I think about it it's probably just used within a single
module build in linear maven. It seems
to me like the artifacts are re-resolved "properly" when proceeding to the
next module; this works
well with clear module boundaries ;)
ATM I solved this problem by re-resolving reactor artifacts when a module
transitions into
packaging, but I'll see if I can improve that once I find out why surefire
won't fire consistently ;)
Kristian
Re: // builds for beta 1 (MNG-3004), going for commit
Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 6, 2010, at 12:32 PM, Kristian Rosenvold wrote:
>> If you think that in Linear mode you're going to affect the behavior that we have right now that's a bit of a problem. he
> Sorry if I was unclear. Linear mode is not affected and should be pretty
> much in the clear for future changes too. It's the way we want it.
>
>>> * From a maven-core perspective, I see no reason to flag "parallel" as
>>> experimental.
>> Until it runs in the wild for a bit I think we have to.
>
> Yes, it's the correct thing to do no matter what, since the total
> experience is what the user judges by.
>
I'm sure folks will try it with a little pushing and blogging. I think we should still maintain the position that 3.0 should be as behaviorally consistent with 2.x as possible. If we can get everyone moved forward then you'll have lots of guinea pigs :-)
> Kristian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: // builds for beta 1 (MNG-3004), going for commit
Posted by Kristian Rosenvold <kr...@gmail.com>.
> If you think that in Linear mode you're going to affect the behavior that we have right now that's a bit of a problem. he
Sorry if I was unclear. Linear mode is not affected and should be pretty
much in the clear for future changes too. It's the way we want it.
> > * From a maven-core perspective, I see no reason to flag "parallel" as
> > experimental.
> Until it runs in the wild for a bit I think we have to.
Yes, it's the correct thing to do no matter what, since the total
experience is what the user judges by.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: // builds for beta 1 (MNG-3004), going for commit
Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 6, 2010, at 11:40 AM, Kristian Rosenvold wrote:
> I am going to commit my changes for MNG-3004 to M3 for beta 1.
> The change consists of the following:
>
> * A modularization of the DefaultLifecycleExecutor into smaller
> components. This is primarily done with the intention of extracting
> execution strategy somewhat from the rest of the logic.
> // builds for beta 1 (MNG-3004)
> * Three differenent execution strategies:
> A) Linear ("Classic")
> B) Parallel (Based on Dan's original implemementation)
> C) Weave (Still experimental)
>
> The command line -T option activates parallel running, and the argument
> is in the form
> -T <[nThreads, a float][C][W]|auto>
>
> The C flag scales threads according to CPU cores, this is why nThreads
> is a float
> The W flag activates weave mode (undocumented)
> Examples:
> "mvn -T auto install "
> autoconfigures threads based on cpu count (1 thread per core).
> "mvn -T 1.5C install"
> Runs with 6 threads on a 4 core computer.
> Runs with 2 threads on a single core computer.
> "mvn -T 1.87CW install"
> Runs with 7 threads weave mode on a 4 core computer.
>
> Better suggestions welcome ;) Bikeshedding opportunities galore ;)
>
> Risks/Consequences
> =====
> * I'm not particularly worried about functional regressions in Linear
> mode, and Parallel mode is also stable.
> * This does not mean the full set of maven plugins necessarily works in
> parallel mode; I expect there will be issues with plugins that I have
> not uncovered as of yet.
If you think that in Linear mode you're going to affect the behavior that we have right now that's a bit of a problem. I thought the point of this mode was to have almost zero risk while people could experiment with the || and weave options?
> * There is a risk that I have removed some methods from
> DefaultLifecycleExecutor that may have to be re-added (if they were not
> documented as being externally in-use, I have removed them)
I think the ITs will uncover anything pretty quickly. Between you and Benjamin I'm not too worried.
> * From a maven-core perspective, I see no reason to flag "parallel" as
> experimental.
Until it runs in the wild for a bit I think we have to.
> * Weave mode is still experimental (and is not added to any official
> API's - but parallel is). It's clearly pushing close to the limits of
> what the JVM handles. I will be extending my testing onto Windows to
> check behaviour on different platforms. My goal is to get this stable
> before 3.0 final. The modularization of the lifecycle executor ensures
> that most further changes will be contained to the single
> "LifecycleWeaveBuilder" class (which encapsulates most of "weave" mode).
If people don't activate this option it doesn't affect them. I don't think this is a big deal.
> * Weave mode has some minor issues that are intentionally left TODO,
> pending that the overall stability goals can be reached.
> * I will be updating surefire to include the parallel->forkmode>=once
> check.
> * The change includes decent test coverage; no existing its were harmed
> and quite a few new unit-tests have been added. I will elaborate these
> even further in the weeks to come.
>
> I'm not calling a vote on this, but now is the time for objections. I
> will commit this in about 24 hours time unless there's any significant
> objections. The current patch is at
> http://github.com/krosenvold/maven3,
> and if nothing else, I know Benjamin will be at it with his microscope
> afterwards ;)
>
> The only last thing I'll do now is to read/search through the core
> plugins looking for references to methods I have deleted in
> DefaultLifecyleExecutor.
I say go for it. We're not in a dire rush and Stuart is also working on getting the core working on Guice so you and Stuart should coordinate as I think you might have some overlapping bits. Once it's all in, if the ITs all pass I'm pretty confident at this point that they model reality to a high degree.
>
> Kristian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
// builds for beta 1 (MNG-3004), going for commit
Posted by Kristian Rosenvold <kr...@gmail.com>.
I am going to commit my changes for MNG-3004 to M3 for beta 1.
The change consists of the following:
* A modularization of the DefaultLifecycleExecutor into smaller
components. This is primarily done with the intention of extracting
execution strategy somewhat from the rest of the logic.
// builds for beta 1 (MNG-3004)
* Three differenent execution strategies:
A) Linear ("Classic")
B) Parallel (Based on Dan's original implemementation)
C) Weave (Still experimental)
The command line -T option activates parallel running, and the argument
is in the form
-T <[nThreads, a float][C][W]|auto>
The C flag scales threads according to CPU cores, this is why nThreads
is a float
The W flag activates weave mode (undocumented)
Examples:
"mvn -T auto install "
autoconfigures threads based on cpu count (1 thread per core).
"mvn -T 1.5C install"
Runs with 6 threads on a 4 core computer.
Runs with 2 threads on a single core computer.
"mvn -T 1.87CW install"
Runs with 7 threads weave mode on a 4 core computer.
Better suggestions welcome ;) Bikeshedding opportunities galore ;)
Risks/Consequences
=====
* I'm not particularly worried about functional regressions in Linear
mode, and Parallel mode is also stable.
* This does not mean the full set of maven plugins necessarily works in
parallel mode; I expect there will be issues with plugins that I have
not uncovered as of yet.
* There is a risk that I have removed some methods from
DefaultLifecycleExecutor that may have to be re-added (if they were not
documented as being externally in-use, I have removed them)
* From a maven-core perspective, I see no reason to flag "parallel" as
experimental.
* Weave mode is still experimental (and is not added to any official
API's - but parallel is). It's clearly pushing close to the limits of
what the JVM handles. I will be extending my testing onto Windows to
check behaviour on different platforms. My goal is to get this stable
before 3.0 final. The modularization of the lifecycle executor ensures
that most further changes will be contained to the single
"LifecycleWeaveBuilder" class (which encapsulates most of "weave" mode).
* Weave mode has some minor issues that are intentionally left TODO,
pending that the overall stability goals can be reached.
* I will be updating surefire to include the parallel->forkmode>=once
check.
* The change includes decent test coverage; no existing its were harmed
and quite a few new unit-tests have been added. I will elaborate these
even further in the weeks to come.
I'm not calling a vote on this, but now is the time for objections. I
will commit this in about 24 hours time unless there's any significant
objections. The current patch is at
http://github.com/krosenvold/maven3,
and if nothing else, I know Benjamin will be at it with his microscope
afterwards ;)
The only last thing I'll do now is to read/search through the core
plugins looking for references to methods I have deleted in
DefaultLifecyleExecutor.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Dependency on system property user.dir
Posted by Stephen Connolly <st...@gmail.com>.
On 8 February 2010 11:20, Kristian Rosenvold
<kr...@gmail.com>wrote:
> On Mon, Feb 8, 2010 at 10:58 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote
>
> >
> > >I think it would be acceptable to break a build if forkmode=never and
> > >parallel build=true... i.e. have the maven api's expose the fact that we
> > are
> > >running in a parallel build, and then surefire can bomb the build out
> > saying
> > >that forkmode=never is incompatible with parallel builds... then the
> user
> > >can decide to switch back to forkmode=once, or not use parallel
> builds...
> >
> > Good solution, I'll give that a try.
>
>
>
> > I think that there are a number of other plugins which might want to be
> > aware of a parallel build... e.g. maven-invoker-plugin,
> jetty-maven-plugin,
> > etc... so I do think that the maven 3 API's need to have some mechanism
> of
> > exposing to plugins that they are running in a parallel build.... how we
> > add
> > this information in such a way that plugins will still work for 2.x as
> well
> > as 3.x is an interesting question
> >
> >
> There will be some shared resources like tcp-ports that you probably can
> get
> away with
> just configuring per-module (and for jetty-maven-plugin I think this
> works).
>
Yes it can be done, but you have to design your build to be port usage
aware.... (I have all my builds use a different port and push that port to
the integration tests so that they don't conflict... but not everyone else
will have put that effort in)
>
> Anyone have any suggestions on how plugins should find out if
> they're being run in parallel ?
>
> Kristian
>
Re: Artifact instances in a reactor build
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I am not 100% sure, but I think this may break MavenMetadataCache, which
caches Artifact instances and assumes they do not change. In m2e, for
example, we do not flash the cache before each build, only when project
pom.xml changes. So if one of mojos changes cached Artifact instance,
next build may misbehave.
--
Regards,
Igor
Kristian Rosenvold wrote:
> It seems like an artifact with coordinates X has one separate instance
> of DefaultArtifact in each project it appears. So project P0 has
> instance X1 and P1 has instance X2. When the jar plugin in P0 calls
> setFile on X1, X2 does not get updated.
>
> Is there a well-defined business case for this behaviour ? I suppose in
> "linear" maven these instances are not concurrently in service, and it
> may not matter too much. Since I feel they represent underlying
> singletons, I'd like to make them so. Anyone have any good reason not
> to ? (I was /thinking/ along the lines that there may be something
> related to snapshot versions, but that's just a little over my head)
>
> (The reason I'm asking is that I find myself writing some fairly
> questionable code to transfer attributes from X1->X2)
>
> Kristian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Artifact instances in a reactor build
Posted by Jason van Zyl <ja...@sonatype.com>.
Our assumption thus far has been that for a given build, including within a reactor, that the dependencies would boil down to a graph so by definition one instance. I think what you're seeing is the transformation of the tree to a graph and having leftovers. So for right now, for all the use cases that we purport to deal with assumes a graph structure in the end. For typical Java this makes sense because we're dealing a normal classloader structure where there is generally one per runtime, or at best one per application like a webapp.
The one concrete use case that we have in Tycho right now is that because OSGi's classloaders are more sophisticated what we have there is resolution per project in a given reactor because given N bundles each may have a different of of artifact A with no adverse affects. And the transitive closure of A may be different in each case.
So I would do anything now that assumes the graph for a reactor, and eventually we'll figure out how to merge in the concepts from Tycho where we truly will have multiple graphs.
Some other things to note is that you should probably chat with Benjamin as there is a rework of the artifact resolution API on a branch that probably won't make it into 3.0 but I'd like your changes not to impede the absorption of those changes ultimately.
On Feb 13, 2010, at 3:34 PM, Kristian Rosenvold wrote:
> It seems like an artifact with coordinates X has one separate instance
> of DefaultArtifact in each project it appears. So project P0 has
> instance X1 and P1 has instance X2. When the jar plugin in P0 calls
> setFile on X1, X2 does not get updated.
>
> Is there a well-defined business case for this behaviour ? I suppose in
> "linear" maven these instances are not concurrently in service, and it
> may not matter too much. Since I feel they represent underlying
> singletons, I'd like to make them so. Anyone have any good reason not
> to ? (I was /thinking/ along the lines that there may be something
> related to snapshot versions, but that's just a little over my head)
>
> (The reason I'm asking is that I find myself writing some fairly
> questionable code to transfer attributes from X1->X2)
>
> Kristian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Artifact instances in a reactor build
Posted by Brett Porter <br...@apache.org>.
I can't see any reason they'd need to be separate, though my inclination would be to move away from sharing that information via the 'file' property and resolving it from the correct place when needed. I'm not up to date on how trunk is handling these objects though.
On 14/02/2010, at 7:34 AM, Kristian Rosenvold wrote:
> It seems like an artifact with coordinates X has one separate instance
> of DefaultArtifact in each project it appears. So project P0 has
> instance X1 and P1 has instance X2. When the jar plugin in P0 calls
> setFile on X1, X2 does not get updated.
>
> Is there a well-defined business case for this behaviour ? I suppose in
> "linear" maven these instances are not concurrently in service, and it
> may not matter too much. Since I feel they represent underlying
> singletons, I'd like to make them so. Anyone have any good reason not
> to ? (I was /thinking/ along the lines that there may be something
> related to snapshot versions, but that's just a little over my head)
>
> (The reason I'm asking is that I find myself writing some fairly
> questionable code to transfer attributes from X1->X2)
>
> Kristian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Artifact instances in a reactor build
Posted by Kristian Rosenvold <kr...@gmail.com>.
It seems like an artifact with coordinates X has one separate instance
of DefaultArtifact in each project it appears. So project P0 has
instance X1 and P1 has instance X2. When the jar plugin in P0 calls
setFile on X1, X2 does not get updated.
Is there a well-defined business case for this behaviour ? I suppose in
"linear" maven these instances are not concurrently in service, and it
may not matter too much. Since I feel they represent underlying
singletons, I'd like to make them so. Anyone have any good reason not
to ? (I was /thinking/ along the lines that there may be something
related to snapshot versions, but that's just a little over my head)
(The reason I'm asking is that I find myself writing some fairly
questionable code to transfer attributes from X1->X2)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Dependency on system property user.dir
Posted by Benjamin Bentmann <be...@udo.edu>.
Stephen Connolly wrote:
> How will I write a plugin that works for both 2.x and 3.x and can detect if
> the build is running in parallel?
/** @parameter default-value="${session.parallel}" */
private Boolean parallel;
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Dependency on system property user.dir
Posted by Stephen Connolly <st...@gmail.com>.
On 8 February 2010 11:23, Benjamin Bentmann <be...@udo.edu>wrote:
> Kristian Rosenvold wrote:
>
> Anyone have any suggestions on how plugins should find out if
>> they're being run in parallel ?
>>
>
> Add a getter to the MavenSession that allows plugins to query the current
> mode of operation.
>
>
How will I write a plugin that works for both 2.x and 3.x and can detect if
the build is running in parallel?
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Dependency on system property user.dir
Posted by Benjamin Bentmann <be...@udo.edu>.
Kristian Rosenvold wrote:
> Anyone have any suggestions on how plugins should find out if
> they're being run in parallel ?
Add a getter to the MavenSession that allows plugins to query the
current mode of operation.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Dependency on system property user.dir
Posted by Kristian Rosenvold <kr...@gmail.com>.
On Mon, Feb 8, 2010 at 10:58 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote
>
> >I think it would be acceptable to break a build if forkmode=never and
> >parallel build=true... i.e. have the maven api's expose the fact that we
> are
> >running in a parallel build, and then surefire can bomb the build out
> saying
> >that forkmode=never is incompatible with parallel builds... then the user
> >can decide to switch back to forkmode=once, or not use parallel builds...
>
> Good solution, I'll give that a try.
> I think that there are a number of other plugins which might want to be
> aware of a parallel build... e.g. maven-invoker-plugin, jetty-maven-plugin,
> etc... so I do think that the maven 3 API's need to have some mechanism of
> exposing to plugins that they are running in a parallel build.... how we
> add
> this information in such a way that plugins will still work for 2.x as well
> as 3.x is an interesting question
>
>
There will be some shared resources like tcp-ports that you probably can get
away with
just configuring per-module (and for jetty-maven-plugin I think this
works).
Anyone have any suggestions on how plugins should find out if
they're being run in parallel ?
Kristian
Re: Dependency on system property user.dir
Posted by Stephen Connolly <st...@gmail.com>.
On 8 February 2010 09:18, Kristian Rosenvold
<kr...@gmail.com>wrote:
> On Mon, Feb 8, 2010 at 2:32 AM, Brett Porter <br...@apache.org> wrote:
>
> >
> > On 07/02/2010, at 6:16 AM, Kristian Rosenvold wrote:
> >
> > > I just discovered that the source of the hideous concurrency problem
> > > I've been tracking for some time is the system property "user.dir".
> >
> >
> > > Surefire basically sets the following three system properties:
> > >
> > > "basedir" = basedir.getAbsolutePath()
> > > "user.dir" = workingDirectory.getAbsolutePath();
> > > "localRepository" = localRepository.getBasedir();
> >
>
> I may be wrong, it may have been any of the three system properties.
> Commenting
> them out in surefire "solved" my problem, and it does not seem to have any
> immediate
> effect on anything (there is a SUREFIRE-419 attached to one of the
> properties so I'll
> see if that's still relevant).
>
>
>
> > >
> > > These properties are also used inside maven core, and creates
> > > some interesting concurrency problems because by the time surefire sets
> > > these values they may have changed already ;)
> >
> > Where are they used in the core? I thought it had been removed and would
> > only be accessed on the initial set up from the cli.
> >
>
> PluginParameterExpressionEvaluator (line 89) references "user.dir", which
> was
> what had me immediately suspecting that property. But I am unsure if this
> block
> of code is "live"; there are unit tests using it but upon real execution it
> doesn't
> get executed. I just compiled the following code (skipTests=true on m3
> itself, since
> it's being used by a single unit test)
>
> if ( basedir == null )
> {
> throw new RuntimeException("user.dir not in use");
> //basedir = System.getProperty( "user.dir" );
> }
>
> I ran the full set of integration tests and the surefire tests and they all
> passed, so I think this
> code is dead.
>
> It seems like this forks into 2 different problems:
>
> A) Why/what/where is core picking up the system properties
>
> B) Why is surefire setting them.
>
> My immediate interest is really B. I see that the setting of the system
> properties were
> introduced in r382683 and r606809. Grepping for "System.setProperty" within
> surefire
> reveals that surefire is being very eager to manipulate local environment
> to run in-process, there's more cases SureFireBooter.java line
> 330<
> http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?view=markup&pathrev=HEAD
> >
>
> It feels to me like the "correct" thing to do is not to manipulate the
> runtime-environment
> with forkmode=never, in other words stop supporting /any/ kind of
> System.setProperty
> for non-forked operation. This would break backwards compatibility, which
> I
> understand is
> not too popular. An alternate solution would be to disallow forkmode=never
> within concurrent
> running (or just upgrade to forkmode=once with a nice message)
>
I don't think it is acceptable to tweak an explicitly set parameter on a
mojo just to "fix" the user's build (also know as doing a "Hudson m2 project
type"). the default forkmode is once, they must have some good reason for
setting it to never (like they want to run out of permgen space, etc) ;-)
I think it would be acceptable to break a build if forkmode=never and
parallel build=true... i.e. have the maven api's expose the fact that we are
running in a parallel build, and then surefire can bomb the build out saying
that forkmode=never is incompatible with parallel builds... then the user
can decide to switch back to forkmode=once, or not use parallel builds...
I think that there are a number of other plugins which might want to be
aware of a parallel build... e.g. maven-invoker-plugin, jetty-maven-plugin,
etc... so I do think that the maven 3 API's need to have some mechanism of
exposing to plugins that they are running in a parallel build.... how we add
this information in such a way that plugins will still work for 2.x as well
as 3.x is an interesting question
-Stephen
>
>
> > I wouldn't be opposed to Surefire not supporting setting system
> properties
> > in non-forking mode in a future release, it seems like a recipe for
> disaster
> > in an embedded / concurrent environment. I think it was done to encourage
> > some consistency between the forked and non-forked versions.
> >
>
> I'm basically feature-complete with the m3 core for weave mode, and now
> it's
> all down to
> bug-hunting in the actual end-user experience; mvn install.
>
> War-plugin and surefire will be needing patches, and I suppose I'll make
> jira issues
> and fix these once I get a stable version running 24/7. I think there's
> little point in
> committing any code "live" before 24/7 stability can be demonstrated for a
> decent-sized
> group of projects.
>
> Kristian
>
Re: Dependency on system property user.dir
Posted by Kristian Rosenvold <kr...@gmail.com>.
On Mon, Feb 8, 2010 at 2:32 AM, Brett Porter <br...@apache.org> wrote:
>
> On 07/02/2010, at 6:16 AM, Kristian Rosenvold wrote:
>
> > I just discovered that the source of the hideous concurrency problem
> > I've been tracking for some time is the system property "user.dir".
>
>
> > Surefire basically sets the following three system properties:
> >
> > "basedir" = basedir.getAbsolutePath()
> > "user.dir" = workingDirectory.getAbsolutePath();
> > "localRepository" = localRepository.getBasedir();
>
I may be wrong, it may have been any of the three system properties.
Commenting
them out in surefire "solved" my problem, and it does not seem to have any
immediate
effect on anything (there is a SUREFIRE-419 attached to one of the
properties so I'll
see if that's still relevant).
> >
> > These properties are also used inside maven core, and creates
> > some interesting concurrency problems because by the time surefire sets
> > these values they may have changed already ;)
>
> Where are they used in the core? I thought it had been removed and would
> only be accessed on the initial set up from the cli.
>
PluginParameterExpressionEvaluator (line 89) references "user.dir", which
was
what had me immediately suspecting that property. But I am unsure if this
block
of code is "live"; there are unit tests using it but upon real execution it
doesn't
get executed. I just compiled the following code (skipTests=true on m3
itself, since
it's being used by a single unit test)
if ( basedir == null )
{
throw new RuntimeException("user.dir not in use");
//basedir = System.getProperty( "user.dir" );
}
I ran the full set of integration tests and the surefire tests and they all
passed, so I think this
code is dead.
It seems like this forks into 2 different problems:
A) Why/what/where is core picking up the system properties
B) Why is surefire setting them.
My immediate interest is really B. I see that the setting of the system
properties were
introduced in r382683 and r606809. Grepping for "System.setProperty" within
surefire
reveals that surefire is being very eager to manipulate local environment
to run in-process, there's more cases SureFireBooter.java line
330<http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?view=markup&pathrev=HEAD>
It feels to me like the "correct" thing to do is not to manipulate the
runtime-environment
with forkmode=never, in other words stop supporting /any/ kind of
System.setProperty
for non-forked operation. This would break backwards compatibility, which I
understand is
not too popular. An alternate solution would be to disallow forkmode=never
within concurrent
running (or just upgrade to forkmode=once with a nice message)
> I wouldn't be opposed to Surefire not supporting setting system properties
> in non-forking mode in a future release, it seems like a recipe for disaster
> in an embedded / concurrent environment. I think it was done to encourage
> some consistency between the forked and non-forked versions.
>
I'm basically feature-complete with the m3 core for weave mode, and now it's
all down to
bug-hunting in the actual end-user experience; mvn install.
War-plugin and surefire will be needing patches, and I suppose I'll make
jira issues
and fix these once I get a stable version running 24/7. I think there's
little point in
committing any code "live" before 24/7 stability can be demonstrated for a
decent-sized
group of projects.
Kristian
Re: Dependency on system property user.dir
Posted by Brett Porter <br...@apache.org>.
On 07/02/2010, at 6:16 AM, Kristian Rosenvold wrote:
> I just discovered that the source of the hideous concurrency problem
> I've been tracking for some time is the system property "user.dir".
>
> Surefire basically sets the following three system properties:
>
> "basedir" = basedir.getAbsolutePath()
> "user.dir" = workingDirectory.getAbsolutePath();
> "localRepository" = localRepository.getBasedir();
>
> These properties are also used inside maven core, and creates
> some interesting concurrency problems because by the time surefire sets
> these values they may have changed already ;)
Where are they used in the core? I thought it had been removed and would only be accessed on the initial set up from the cli.
>
> The method in question is SurefirePlugin.processSystemProperties, with
> non-forking operation.
I wouldn't be opposed to Surefire not supporting setting system properties in non-forking mode in a future release, it seems like a recipe for disaster in an embedded / concurrent environment. I think it was done to encourage some consistency between the forked and non-forked versions.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Dependency on system property user.dir
Posted by Kristian Rosenvold <kr...@gmail.com>.
I just discovered that the source of the hideous concurrency problem
I've been tracking for some time is the system property "user.dir".
Surefire basically sets the following three system properties:
"basedir" = basedir.getAbsolutePath()
"user.dir" = workingDirectory.getAbsolutePath();
"localRepository" = localRepository.getBasedir();
These properties are also used inside maven core, and creates
some interesting concurrency problems because by the time surefire sets
these values they may have changed already ;)
The method in question is SurefirePlugin.processSystemProperties, with
non-forking operation.
Have these properties been discussed before ? Any issues, pointers,
thoughts ?
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Java versions within surefire ?
Posted by Brett Porter <br...@apache.org>.
The plugin is 1.4 and the booter/api is 1.3 so that you can still run
tests on old JDKs.
The plugin *could* be updated to 1.5 if it is made to require Maven
2.2. Probably not worth it at this stage.
- Brett
On 03/11/2009, at 6:09 PM, Kristian Rosenvold wrote:
> I am working on a patch to surefire and find that habitually I'm
> consistently grabbing got my <>'s and java 5 for loops. I see the
> following seems to apply:
>
> Some surefire-providers have an implicit java 5 requirement because
> (like junit 4) they support java 5 projects.
>
> But what language levels are effective in shared modules (like
> surefire-api), surefire-plugin and surefire-booter ? At least sine
> poms
> don't seem to be entirely correctly set up to refelect language levels
> either (testng provider uses java 5 features but does not seem to be
> at
> java 5 language level in the poms - AFAIK)
>
>
> Regards,
>
> Kristian Rosenvold
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org