Hi Mirko,
Mirko Friedenhagen wrote:
Hello,
while developing a plugin, I stumbled upon the IMO irregularity, that
projects with packaging POM have no artifact (i.e.
project.getArtifact() will return `null)`. At least my usecase would
have been easier when:
- the POM of a POM project would
Hi All.
I'm starting to do some serious work with Maven 3 and parallel builds.
In doing so, I've discovered that the maven-rar-plugin has not been
recently released.
There have been 15 issues closed, with 12 still outstanding.
So I'd really like to see the current code released, as it
Hi All.
Do we mark an entire plugin as @threadSafe or each goal specifically? I can
easily see that some goals within a single plugin could be threadsafe,
whilst others in the same plugin not threadsafe.
So, what is the level of granularity of this?
-Chris
per goal
On 27 July 2012 11:27, Chris Graham chrisgw...@gmail.com wrote:
Hi All.
Do we mark an entire plugin as @threadSafe or each goal specifically? I can
easily see that some goals within a single plugin could be threadsafe,
whilst others in the same plugin not threadsafe.
So, what is
Excellent!
Thanks!
-Chris
On Fri, Jul 27, 2012 at 8:43 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
per goal
On 27 July 2012 11:27, Chris Graham chrisgw...@gmail.com wrote:
Hi All.
Do we mark an entire plugin as @threadSafe or each goal specifically? I
can
easily
Shouldn't DefaultBuildPluginManager#getPluginRealm be synchronized?
If two threads arrive at DefaultBuildPluginManager line 170 at about the
same time, they both will see null pluginRealm and both will then call
setupPluginRealm, which I believe will likely result in the two threads
using two
notice that a project can inject dependencies to a plugin: this is not so
frequent, so reusing the same realm for each use of a plugin should often be
ok, but not when specific dependencies are injected IMHO
but what about simply synchronizing the getPluginRealm method? It is not used
so often
On 12-07-27 7:35 AM, Hervé BOUTEMY wrote:
notice that a project can inject dependencies to a plugin: this is not so
frequent, so reusing the same realm for each use of a plugin should often be
ok, but not when specific dependencies are injected IMHO
This will be just one problem to solve if
I agree, DefaultClassRealmManager does just what it says; you asked
for a new instance you'll get one; no need to change that. The answer
to my original question seems to be that the funky logic is not there
for maven cli usage, but for IDE integrations. I'm not too happy about
this code being in
On 12-07-27 8:48 AM, Kristian Rosenvold wrote:
I agree, DefaultClassRealmManager does just what it says; you asked
for a new instance you'll get one; no need to change that. The answer
to my original question seems to be that the funky logic is not there
for maven cli usage, but for IDE
Hi
I will take care of that next week.
--
Olivier
Le 27 juil. 2012 12:26, Chris Graham chrisgw...@gmail.com a écrit :
Hi All.
I'm starting to do some serious work with Maven 3 and parallel builds.
In doing so, I've discovered that the maven-rar-plugin has not been
recently released.
Hi folks,
how is it going with this one? Is there anything planned?
I have attached a test project to the issue -
http://jira.codehaus.org/browse/MNG-5127
Hope it helps.
Thanks
Tony
The github ribbon muck in maven-fluido-skin 1.2.2 covers the topBar.
… would actually like a bottom-right or something instead.
Is bottom locations on the roadmap, or at least updated skin to fix the zorder?
--jason
-
To
This would be slightly better if the titter button was floating in the topBar
with some padding around it… instead of sticking to the top.
--jason
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional
14 matches
Mail list logo
