Re: maven-plugin-plugin thinks there's no mojos when I use annotations

THanks. On Fri, Jun 29, 2012 at 8:04 PM, Tony Chemit wrote: > On Fri, 29 Jun 2012 19:58:53 -0400 > Benson Margulies wrote: > >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-plugin-plugin:3.0:helpmojo >> (generated-helpmojo) on project maven-shade-plugin: Error extracting >>

Re: maven-plugin-plugin thinks there's no mojos when I use annotations

On Fri, 29 Jun 2012 19:58:53 -0400 Benson Margulies wrote: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-plugin-plugin:3.0:helpmojo > (generated-helpmojo) on project maven-shade-plugin: Error extracting > plugin descriptor: 'No mojo definitions were found for plugin: > org.apa

Re: Order of execution of plugins

I like this. On Fri, Jun 29, 2012 at 9:48 AM, Stephen Connolly wrote: > 3) add a shade:clean goal which removes the jar and let people bind > that to prepare-package > > On 29 June 2012 14:28, Benson Margulies wrote: >> OK, now I understand this. >> >> The jar plugin will optimize out writing a

Re: Order of execution of plugins

3) add a shade:clean goal which removes the jar and let people bind that to prepare-package On 29 June 2012 14:28, Benson Margulies wrote: > OK, now I understand this. > > The jar plugin will optimize out writing a jar in some cases. > > This is never a good idea is shade has produced the jar. Bu

maven-skins pull request: Add reponsive patch to fluido #MSKINS-48

GitHub user hoxca opened a pull request: https://github.com/apache/maven-skins/pull/1 Add reponsive patch to fluido #MSKINS-48 Here is updated patch for a responsive fluido skin * Tested on iphone / osx + mainstream Chrome * Need more test on other platform. You can me

Re: Order of execution of plugins

OK, now I understand this. The jar plugin will optimize out writing a jar in some cases. This is never a good idea is shade has produced the jar. But the jar plugin has no way, I can see, to notice this. So the jar plugin leaves the shaded jar and then shade explodes. I can see two possible appr

Re: Order of execution of plugins

Cancel this thought. The jar plugin purports to run first. On Fri, Jun 29, 2012 at 9:12 AM, Benson Margulies wrote: > https://jira.codehaus.org/browse/MSHADE-126 seems, I think, to result > from a Pretty Dumb Thing. I suspect that the problem is that the jar > plugin has ended up in the packaging

Order of execution of plugins

https://jira.codehaus.org/browse/MSHADE-126 seems, I think, to result from a Pretty Dumb Thing. I suspect that the problem is that the jar plugin has ended up in the packaging phase AFTER the shade plugin, due to the way that plugin management and plugin elements merge. Does this make any sense to

Re: patch for review

I forgot to mention in previous reply that one important constraint is that Every single addition needs to fill out the Version value. The default maven processing makes no use of it and proceeds as before. Only in the IDE's subclass we will use it to throw exception or not. If a request or paramet

Re: patch for review

Agree it's hard to inject that. So that reduce possible backward comp issues. BTW what about using this bean/data structure rather than adding new parameters ? 2012/6/29 Milos Kleint : > Is ModelProblemCollector intended for use outside of maven codebase? > MavenModelBuilder is hardcoding referen

Re: patch for review

Is ModelProblemCollector intended for use outside of maven codebase? MavenModelBuilder is hardcoding reference on DefaultMPC and there's a few other implementations in tests or compat module only.. Milos On Fri, Jun 29, 2012 at 11:49 AM, Olivier Lamy wrote: > Hi, > The main issue I see is non ba

Release of apache-source-release-assembly-descriptor 1.4

Hi, I'd like to release apache-source-release-assembly-descriptor 1.4 The only change is the exclusion of .idea directory content (which was included in source release for idea users). No objections ? I cannot find any jira for those resources part. (Maybe I miss something ? ) Thanks, -- Olivie

Re: patch for review

Hi, The main issue I see is non backward comp for tools implementing their own ModelProblemCollector. I don't have issue to change signature but for future enhancement if needed here, I would prefer to see something more easy to change and don't break again backward comp in the future. So instead m

patch for review

hello, I've prepared a patch for MavenModelBuilder and related code that hopefully will improve the performance of NetBeans integration/embedding. The basic idea is to have all validation problems collected but only fail to build the Mavenproject instance when serious base problems are found (vali