To solve your problem, it may be that code is truly only useful to m2e and if
so we should probably find a way to allow m2e to do what's necessary but not
interfere with the CLI use case. Maybe a simple protected method where m2e can
have an implementation that overrides the realm creation bits
I think you're right about the 95% overlap. If we download the whole
plugin with all their deps to calculate the execution plan we could
surely construct the class realm too; that's just a few pojos per
plugin. I'll investigate.
Still this whole discussion is probably tangential to the problem I
s
I wouldn't speculate without measuring but from anecdotal experience I would
venture to say that of those 200 modules there's 95% overlap in the plugins
executed. I'm not sure it would be that inefficient given what we do today
which is to download the plugin itself to get at its metadata to bui
On 27/07/2012, at 12:45 AM, Stephen Connolly wrote:
> poms have an implicit basedir, so copying the pom to target would change
> the implicit basedir.
>
> pom packaging can be hijacked when you want to attach a primary artifact
> without defining a custom packaging.
>
> Not saying these are goo
I'm not sure this makes sense. Given a reactor with 200 modules, it
would mean you would be downloading all the plugins and constructing
all the realms before even starting on the first module ?
Re-using realms across modules is great, but pre-constructing
everything would give an uneccessary perf
I have some very specific logs in an issue
(http://code.google.com/p/maven-svn-revision-number-plugin/issues/detail?id=16#c85)
indicating that to class realms are being created for the same plugin
when there is only one execution.
The behaviour seems totally consistent with hitting the catch block
No, unfortunately I did not test anything. I'm just a happy/grateful maven
user recognizing somebody has been spending his spare time to fix an issue.
:-)
Am 25.07.2012 22:36 schrieb "Hervé BOUTEMY" :
> that's nice to see some interest
> did you try and check it works as you expect?
>
> Regards,
>
Kristian, you have the project handy that was causing the problem?
On Jul 26, 2012, at 12:54 PM, Igor Fedorenko wrote:
> I have not looked at parallel execution closely and don't fully
> understand the usecase, but I am not sure race condition is the code in
> DefaultClassRealmManager.
>
> As fa
I have not looked at parallel execution closely and don't fully
understand the usecase, but I am not sure race condition is the code in
DefaultClassRealmManager.
As far as I can tell, DefaultClassRealmManager only provides create*
methods, which create new realms and the current implementation lo
In that case we may just want to differentiate because the parallel execution
use case is not one that happens inside the IDE. In the case of CLI execution
it can all be handled up front as additional realm construction beyond the CLI
execution isn't going to happen. In an IDE or shell wouldn't
This is required in m2e where multiple versions of the same plugin can
coexist for long time in the same container.
--
Regards,
Igor
On 12-07-26 8:44 AM, Kristian Rosenvold wrote:
There is a race condition in parallel builds that occurs related to
this piece of code:
http://maven.apache.org/re
I'm just surfing around some code now, but I think it may be for a long-lived
process like an IDE some of that weirdness exists.
On Jul 26, 2012, at 8:44 AM, Kristian Rosenvold wrote:
> There is a race condition in parallel builds that occurs related to
> this piece of code:
>
> http://maven.ap
poms have an implicit basedir, so copying the pom to target would change
the implicit basedir.
pom packaging can be hijacked when you want to attach a primary artifact
without defining a custom packaging.
Not saying these are good reasons, but they are a sort of reason!
There may be others
On 2
Could we not adjust such that after the execution plan is created, prepare all
the class realms required by the plan and once constructed left immutable
during the actual execution of the plan. I can't quite remember but I'm not
sure why we need multiple threads constructing realms with the exec
There is a race condition in parallel builds that occurs related to
this piece of code:
http://maven.apache.org/ref/3.0.4/maven-core/xref/org/apache/maven/classrealm/DefaultClassRealmManager.html#75
The thing is, for some reason, there's a loop that retries the class
realm generation with a rando
15 matches
Mail list logo
