fluido skin twitter button could use some padding

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 c

maven-fluido-skin github ribbon covered by topBar

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

MNG-5127 - Maven profile activation does not work when profile is defined in inherited 'parent' pom

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

Re: Release Request: maven-rar-plugin

Hi I will take care of that next week. -- Olivier Le 27 juil. 2012 12:26, "Chris Graham" 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. > > There have been

Re: Use case for funky class realm construction logic

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 integra

Re: Use case for funky class realm construction logic

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 c

Re: Use case for funky class realm construction logic

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

Re: Use case for funky class realm construction logic

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

Re: Use case for funky class realm construction logic

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 dif

Re: @threadSafe

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 wrote: > > > Hi All. > > > > Do we mark an entire plugin as @threadSafe or each goal specifically? I > can > > easily see tha

Re: @threadSafe

per goal On 27 July 2012 11:27, Chris Graham 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 the level of g

@threadSafe

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

Release Request: maven-rar-plugin

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 addresses

Re: Should the POM be the artifact of a POM project?

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