[mojo-dev] [jira] (MHIBERNATE-130) Instrument goal: default configuration overrides custom one
Artur Polit
created MHIBERNATE-130
Instrument goal: default configuration overrides custom one
Issue Type:
Bug
Affects Versions:
3.0
Assignee:
Johann Reyes
Components:
instrument
Created:
14/Jan/14 2:40 AM
Description:
org.codehaus.mojo
hibernate3-maven-plugin
hibernate
hibernate-entitymanager
3.4.0.GA
org.slf4j
slf4j-api
1.6.6
Instrument statements
"true">
"${project.build.outputDirectory}">
"**/*Archive.class" />
process-classes
instrument
The configuration tag is ommited and there is always single tag include with value */.class , from default configuration.
Project:
Mojo's Hibernate3 Maven Plugin
Priority:
Major
Reporter:
Artur Polit
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MNBMODULE-232) nbm-maven-plugin:3.12 requires JDK 1.7 to run
Sergei Ivanov commented on MNBMODULE-232 nbm-maven-plugin:3.12 requires JDK 1.7 to run Not really wanted to kick a dead horse, but accidentally came across this today: http://maven.apache.org/plugin-tools/maven-plugin-plugin/report-mojo.html#requirements You can specify the requirements to appear on the Plugin Documentation page (System Requirements section): http://mojo.codehaus.org/nbm-maven/nbm-maven-plugin/plugin-info.html I am not sure how does maven-plugin-plugin derive the defaults (they look wrong for the latest version of NBM plugin), and it is certainly a documentation-only feature (i.e. not enforceable in builds). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MNBMODULE-232) nbm-maven-plugin:3.12 requires JDK 1.7 to run
Milos Kleint commented on MNBMODULE-232 nbm-maven-plugin:3.12 requires JDK 1.7 to run yup, I think we've got it configured in the pom, in current dev build I've increased the value to 1.7 so eventually when we do a release, we should be having it shown on the website. 3.12 site is not up as for some reason codehaus site failed to allow the upload of the site when doing the release. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MGWT-373) Netbeans' custom action's property did not pass to gwt:debug session.
Kevin Tarn created MGWT-373 Netbeans' custom action's property did not pass to gwt:debug session. Issue Type: Bug Affects Versions: 2.5.1 Assignee: Unassigned Created: 14/Jan/14 7:30 AM Description: Create a custom action from Netbeans' Maven project property dialog. Set system property to this custom action. Execute this custom action, the saved property is not passed to gwt:run or gwt:debug session. Environment: Netbeans + MacBook Pro OSX 10.9 + JDK 1.7 Project: Mojo's GWT Maven Plugin Priority: Major Reporter: Kevin Tarn This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MWEBSTART-176) Signing of the JNLP file
James Olsen updated MWEBSTART-176 Signing of the JNLP file I've hacked up a solution for generating a APPLICATION_TEMPLATE.JNLP or APPLICATION.JNLP. It includes a new JnlpInfMojo (derived from the JnlpSingleMojo) which simply chops out undesirable processing from the AbstractJnlpMojo allowing the execution to occur at the prepare-package stage (i.e. before the jar is built). A patch is attached and an example usage is below. You do this execution in addition to the (in my case) jnlp-single during package. Your mileage may vary if you use something other than jnlp-single. The patch also includes a LegacyDependencyFilenameStrategy because the ordering of the classifier has changed recently and I wasn't ready to deal with that now. generate-jnlp-template-for-signing prepare-package jnlp-inf application_template.vm ../classes/JNLP-INF/APPLICATION_TEMPLATE.JNLP com.something.Application legacy false true So hopefully this demonstrates that a proper solution might not be too hard. This is definitely a HACK for my own needs, but I present here in case it's any use to anyone. Change By: James Olsen (14/Jan/14 10:42 AM) Attachment: webstart-maven-plugin.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MWEBSTART-249) Dependencies not found in multi-module build
Thomas Weil created MWEBSTART-249 Dependencies not found in multi-module build Issue Type: Bug Affects Versions: 1.0-beta-5, 1.0-beta-4 Assignee: Unassigned Created: 14/Jan/14 10:42 AM Description: In a multi-module project, the plugin fails when using a jarResource that is built within the same execution. Building the jnlp-project only succeeds. Stacktrace is org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-5:jnlp-download-servlet (default) on project planit-client-war: Execution default of goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-5:jnlp-download-servlet failed: sourceFile is null at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:webstart-maven-plugin:1.0-beta-5:jnlp-download-servlet failed: sourceFile is null at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.lang.IllegalArgumentException: sourceFile is null at org.codehaus.mojo.webstart.AbstractBaseJnlpMojo.copyJarAsUnprocessedToDirectoryIfNecessary(AbstractBaseJnlpMojo.java:626) at org.codehaus.mojo.webstart.JnlpDownloadServletMojo.resolveJarResources(JnlpDownloadServletMojo.java:540) at org.codehaus.mojo.webstart.JnlpDownloadServletMojo.execute(JnlpDownloadServletMojo.java:161) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 14 more Excerpt of pom.xml: org.codehaus.mojo webstart-maven-plugin 1.0-beta-5 prepare-package jnlp-download-servlet default.jnlp.vm default.jnlp abc main 1.0 abc.main.Application support.jnlp.vm support.jnlp abc main 1.0 abc.main.Application abc common 1.0 abc loggin 1.0 libs true false Project: Mojo's Webstart Maven Plugin Priority: Blocker Reporter: Thomas Weil This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --
[mojo-dev] issue with version set command
Hi, I tried to change version of all modules in a multi-module project using versions:set command and got empty stack trace exception. On troubleshooting the issue, I found that it throws this error when property name contains ":". Is this expected behavior? Regards, Rupali
[mojo-dev] [ANN] WAS6 Maven Plugin version 1.2.1 Released
Hi, The Mojo team is pleased to announce the release of the WAS6 Maven Plugin version 1.2.1 This plugin works along with an installation of WebSphere Application Server (standalone or ND), to provide automated tasks for: generating RMIC stubs, starting/stopping servers, installing/updating/uninstalling EARs to application servers, starting/stopping application and run arbitrary scripts through wsadmin http://mojo.codehaus.org/was6-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo was6-maven-plugin 1.2.1 Some links : Documentation: http://mojo.codehaus.org/was6-maven-plugin/ JIRA: http://jira.codehaus.org/browse/MWAS svn: https://svn.codehaus.org/mojo/tags/was6-maven-plugin-1.2.1/ Release Notes are available at https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11730&version=19594 **Bug *[MWAS-70] - Skip does not work for wsAdmin, wsStartServer and wsStopServer *[MWAS-72] - WSEJBDeploy fails when pom uses system or provided dependencies. *[MWAS-73] - WSDL2Java fails when pom uses system or provided dependencies. **New Feature *[MWAS-59] - Support install/uninstall and start/stop for WARs Enjoy, The Mojo team. Javier Murciego
[mojo-dev] [jira] (MLICENSE-95) Include copyright year range, not just inception year
Curtis Rueden commented on MLICENSE-95 Include copyright year range, not just inception year Works like a charm. Thank you very much! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MLICENSE-96) Some licenses contain whitespace errors
Curtis Rueden commented on MLICENSE-96 Some licenses contain whitespace errors Looks great, thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [mojo-dev] [VOTE] Release mojo-parent version 33 and mojo-sandbox-parent version 14
I prefer a good latest mojo-parent over a restricted parent which could
mean override these restrictions or fall back to an older version, just
like Anders describes.
So for now I think we should disable (=comment out) the
RequirePrerequisite Rule until the packaging type can be controlled (we
only want this for maven-plugin packaging) and let's see if exclusion of
2.1.x and 2.2.0 works. Also change the maven prerequisite to 2.0 (default)
and keep the comments, they should explain quite clear how it is used (for
future discussions)
In general we'd like to keep the the prerequisite as low as possible for
Maven plugins. However, I think we should gently start forcing users to
move forward. The jump to 2.2.1 might be a bit too much. We could start a
new thread on the users mailing-list about a suggestion for a proper
version, let's say 2.0.6 or 2.0.9
thanks,
Robert
Op Sat, 11 Jan 2014 21:39:15 +0100 schreef Anders Hammar
:
Who says you need to use the latest parent anyways?
I think the latest parent should be useable by all mojos (unless they are
VERY special). So introducing something we know prevents that isn't good
IMHO.
And AFAIR you can override the enforcer rule if you want to use the
latest
parent anyway
That would be a bad think I think, as it would require overriding the
execution by the id ('mojo-enforcer-rules'). Which would override all the
rules (not only the Maven version one), which would open up for future
issues if we later on add more rules in this execution that those mojos
wouldn't be using.
Remember, we add these rules for a reason.
Sorry to turning this vote thread into a discussion, but I think that
fairly major thing sneaked in here. If we add this rule we should agree
on
that all future mojo version would required Maven 2.2.1+ (at least when
bumping minor/major, not bugfix). And we should probably also state this
clearly on the Mojo homepage.
/Anders
On Friday, 10 January 2014, Anders Hammar wrote:
-1 (for now)
Is this really what we want? No more mojo releases that supports Maven
pre-2.2.1 versions? I don't think so.
From build:
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (mojo-enforcer-rules) @
sqlj-maven-plugin ---
[WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequirePrerequisite
failed with message:
The specified Maven prerequisite( 2.0 ) doesn't match the required
version: [2.2.1,)
/Anders
On Fri, Jan 10, 2014 at 10:08 PM, Tony Chemit
wrote:
On Fri, 10 Jan 2014 13:00:12 -0800
Dan Tran wrote:
> I try to pickup the new parent with maven-native, and it seems i
have
to add
>
>
> 2.2.1
>
>
>
> to every single project. Is it correct?
Yes this is it.
>
> -Dan
>
>
>
> On Fri, Jan 10, 2014 at 11:54 AM, Karl Heinz Marbaise <
khmarba...@gmx.de>wrote:
>
> > Hi,
> >
> > +1 mojo-parent version 33
> > +1 mojo-sandbox-parent version 14
> >
> > Kind Regards
> > Karl Heinz Marbaise
> >
> >
> >
> >
-
> > To unsubscribe from this list, please visit:
> >
> >http://xircles.codehaus.org/manage_email
> >
> >
> >
--
Tony Chemit
tél: +33 (0) 2 40 50 29 28
http://www.codelutin.com
email: che...@codelutin.com
twitter: https://twitter.com/tchemit
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Sent from my phone
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [mojo-dev] [VOTE] Release mojo-parent version 33 and mojo-sandbox-parent version 14
On Tue, 14 Jan 2014 22:41:22 +0100
"Robert Scholte" wrote:
> I prefer a good latest mojo-parent over a restricted parent which could
> mean override these restrictions or fall back to an older version, just
> like Anders describes.
>
> So for now I think we should disable (=comment out) the
> RequirePrerequisite Rule until the packaging type can be controlled (we
> only want this for maven-plugin packaging) and let's see if exclusion of
> 2.1.x and 2.2.0 works. Also change the maven prerequisite to 2.0 (default)
> and keep the comments, they should explain quite clear how it is used (for
> future discussions)
>
> In general we'd like to keep the the prerequisite as low as possible for
> Maven plugins. However, I think we should gently start forcing users to
> move forward. The jump to 2.2.1 might be a bit too much. We could start a
> new thread on the users mailing-list about a suggestion for a proper
> version, let's say 2.0.6 or 2.0.9
I was about to send mylself a same email.
Welcome to jurassic park!
Hopefuly we don't maintain anymore maven 1.0 :)
I will drop the release, revert some stuff and reroll another release, since
there is the problem of site generation.
>
> thanks,
>
> Robert
>
>
> Op Sat, 11 Jan 2014 21:39:15 +0100 schreef Anders Hammar
> :
>
> >> Who says you need to use the latest parent anyways?
> >>
> >
> > I think the latest parent should be useable by all mojos (unless they are
> > VERY special). So introducing something we know prevents that isn't good
> > IMHO.
> >
> >
> >> And AFAIR you can override the enforcer rule if you want to use the
> >> latest
> >> parent anyway
> >>
> >
> > That would be a bad think I think, as it would require overriding the
> > execution by the id ('mojo-enforcer-rules'). Which would override all the
> > rules (not only the Maven version one), which would open up for future
> > issues if we later on add more rules in this execution that those mojos
> > wouldn't be using.
> > Remember, we add these rules for a reason.
> >
> > Sorry to turning this vote thread into a discussion, but I think that
> > fairly major thing sneaked in here. If we add this rule we should agree
> > on
> > that all future mojo version would required Maven 2.2.1+ (at least when
> > bumping minor/major, not bugfix). And we should probably also state this
> > clearly on the Mojo homepage.
> >
> > /Anders
> >
> >>
> >>
> >> On Friday, 10 January 2014, Anders Hammar wrote:
> >>
> >>> -1 (for now)
> >>>
> >>> Is this really what we want? No more mojo releases that supports Maven
> >>> pre-2.2.1 versions? I don't think so.
> >>>
> >>> From build:
> >>> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (mojo-enforcer-rules) @
> >>> sqlj-maven-plugin ---
> >>> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequirePrerequisite
> >>> failed with message:
> >>> The specified Maven prerequisite( 2.0 ) doesn't match the required
> >>> version: [2.2.1,)
> >>>
> >>>
> >>> /Anders
> >>>
> >>>
> >>> On Fri, Jan 10, 2014 at 10:08 PM, Tony Chemit
> >>> wrote:
> >>>
> On Fri, 10 Jan 2014 13:00:12 -0800
> Dan Tran wrote:
>
> > I try to pickup the new parent with maven-native, and it seems i
> have
> to add
> >
> >
> > 2.2.1
> >
> >
> >
> > to every single project. Is it correct?
>
> Yes this is it.
>
> >
> > -Dan
> >
> >
> >
> > On Fri, Jan 10, 2014 at 11:54 AM, Karl Heinz Marbaise <
> khmarba...@gmx.de>wrote:
> >
> > > Hi,
> > >
> > > +1 mojo-parent version 33
> > > +1 mojo-sandbox-parent version 14
> > >
> > > Kind Regards
> > > Karl Heinz Marbaise
> > >
> > >
> > >
> > >
> -
> > > To unsubscribe from this list, please visit:
> > >
> > >http://xircles.codehaus.org/manage_email
> > >
> > >
> > >
>
>
>
> --
> Tony Chemit
>
> tél: +33 (0) 2 40 50 29 28
> http://www.codelutin.com
> email: che...@codelutin.com
> twitter: https://twitter.com/tchemit
>
> -
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
> >>>
> >>
> >> --
> >> Sent from my phone
>
> -
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Tony Chemit
tél: +33 (0) 2 40 50 29 28
http://www.codelutin.com
email: che...@codelutin.com
twitter: https://twitter.com/tchemit
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[mojo-dev] [CANCEL] [VOTE] Release mojo-parent version 33 and mojo-sandbox-parent version 14
The vote is cancel :( I will redo another one with no prerequiste. tony. -- Tony Chemit tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: che...@codelutin.com twitter: https://twitter.com/tchemit - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MLICENSE-95) Include copyright year range, not just inception year
Curtis Rueden commented on MLICENSE-95 Include copyright year range, not just inception year Will 1.6 be released soon? I see that it is staged in Codehaus Staging but not promoted yet... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] New plugin proposal: protobuf-maven-plugin
Hello, I have been maintaining a fork of a maven plugin for Google protobuf compiler on GitHub for the last couple of years. Now that it has gained some popularity, there is some popular demand to deploy it into Maven Central. Having thought about it, I would like to do it properly and I would like to host it at CodeHaus (although with GitHub remaining as SCM). I would like to make a clean start, repackage everything into org.codehaus.mojo and so on. At the moment the plugin offers the following functionality: - generation of Java code (production and test) from proto definitions, with support of cross-project and cross-module dependencies - generation of compiled protobuf descriptors - support for a custom protoc toolchain - support for 2nd level plugins (plugins for protobuf compiler) written in Java and packaged as Maven artifacts We (my team) have already been using the the plugin in production environment (mission-critical finance applications) for the last two years or so. The current home for the plugin is: http://sergei-ivanov.github.io/maven-protoc-plugin/ (Plugin Documentation) https://github.com/sergei-ivanov/maven-protoc-plugin (Git repo) The proposed coordinates are org.codehaus.mojo:protobuf-maven-plugin I hope that you will favour my application. With kind regards, your hausmate hopeful, -- Sergei Ivanov
[mojo-dev] [jira] (MLICENSE-95) Include copyright year range, not just inception year
Tony Chemit commented on MLICENSE-95 Include copyright year range, not just inception year Yes tomorrow will be the day (after 72h...). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
