[mojo-dev] [jira] Assigned: (MJBOSSPACK-37) Add support for JBoss AOP packaging (.aop extension)
[ http://jira.codehaus.org/browse/MJBOSSPACK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned MJBOSSPACK-37: --- Assignee: Anders Hammar Add support for JBoss AOP packaging (.aop extension) Key: MJBOSSPACK-37 URL: http://jira.codehaus.org/browse/MJBOSSPACK-37 Project: Maven 2.x JBoss Packaging Plugin Issue Type: New Feature Affects Versions: 2.1 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Attachments: MJBOSSPACK-37.patch JBoss AS recognizes the .aop extension for JBoss AOP packages. More info here: http://docs.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/reference/en/html/running.html#d0e4558 In its simplest scenario, it's very similar to sar for example. A more advanced scenario includes aop compile time weaving, but I think that could be left to a later exercise. The biggest problem with that part is that there is no maven plugin in central that does this. Jboss has one, but it's only in their repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] [Clirr Plugin] patch available
Hi, I provided a patch for the Clirr Plugin ([1]) to allow setting of the severity, when executing the 'check' goal. Would be nice if someone could apply the patch. Thanks! Matthias [1] http://jira.codehaus.org/browse/MCLIRR-35 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] Updated: (MCLIRR-35) Allow setting of minSeverity parameter for the check goal aswell
[ http://jira.codehaus.org/browse/MCLIRR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCLIRR-35: --- Fix Version/s: 2.3 Allow setting of minSeverity parameter for the check goal aswell -- Key: MCLIRR-35 URL: http://jira.codehaus.org/browse/MCLIRR-35 Project: Maven 2.x Clirr Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Matthias Weßendorf Assignee: Olivier Lamy Fix For: 2.3 Attachments: minSeverity.patch Currently the minSeverity can be only applied to the 'clirr' goal. It would be nice if it could be used on 'check' as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] Assigned: (MCLIRR-35) Allow setting of minSeverity parameter for the check goal aswell
[ http://jira.codehaus.org/browse/MCLIRR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MCLIRR-35: -- Assignee: Olivier Lamy Allow setting of minSeverity parameter for the check goal aswell -- Key: MCLIRR-35 URL: http://jira.codehaus.org/browse/MCLIRR-35 Project: Maven 2.x Clirr Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Matthias Weßendorf Assignee: Olivier Lamy Fix For: 2.3 Attachments: minSeverity.patch Currently the minSeverity can be only applied to the 'clirr' goal. It would be nice if it could be used on 'check' as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] [Clirr Plugin] patch available
Hello, I will have a look. 2011/1/3 Matthias Wessendorf mat...@apache.org: Hi, I provided a patch for the Clirr Plugin ([1]) to allow setting of the severity, when executing the 'check' goal. Would be nice if someone could apply the patch. Thanks! Matthias [1] http://jira.codehaus.org/browse/MCLIRR-35 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] Commented: (CBUILDS-52) make:compile ignores derived configuration parameters
[
http://jira.codehaus.org/browse/CBUILDS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250264#action_250264
]
Lee Thompson commented on CBUILDS-52:
-
Code is checked in, having trouble deploying a snapshot on the new nexus repo.
make:compile ignores derived configuration parameters
-
Key: CBUILDS-52
URL: http://jira.codehaus.org/browse/CBUILDS-52
Project: Mojo C Builds
Issue Type: Bug
Components: Automake/Autoconfig Orchestration
Affects Versions: 1.0-beta-1
Reporter: Anton Nikitin
Assignee: Lee Thompson
make:compile should take into account parameters derived from base class.
E.g. environment and skipped parameters are ignored even if
compileEnvironment and skipCompile are not set.
It seems that implementation class (org.codehaus.mojo.make.CompileExecMojo)
should set the values like other mojos only if overriding parameter is set,
i.e.
if ( compileEnvironment != null !compileEnvironment.isEmpty() )
{
setEnvironment( compileEnvironment );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
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] Created: (CBUILDS-56) automvn packaging needs to be rewritten
automvn packaging needs to be rewritten --- Key: CBUILDS-56 URL: http://jira.codehaus.org/browse/CBUILDS-56 Project: Mojo C Builds Issue Type: Improvement Components: POMs, Inheritance, and Configuration Affects Versions: 1.0-beta-1 Reporter: Lee Thompson the automvn lifecycle needs to be rewritten, its pretty useless at the moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] [Clirr Plugin] patch available
Hi, thanks for looking into this. -Matthias On Mon, Jan 3, 2011 at 10:11 AM, Olivier Lamy ol...@apache.org wrote: Hello, I will have a look. 2011/1/3 Matthias Wessendorf mat...@apache.org: Hi, I provided a patch for the Clirr Plugin ([1]) to allow setting of the severity, when executing the 'check' goal. Would be nice if someone could apply the patch. Thanks! Matthias [1] http://jira.codehaus.org/browse/MCLIRR-35 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] Updated: (MTAGLIST-54) Allow HTML tags in comments
[ http://jira.codehaus.org/browse/MTAGLIST-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Pilato updated MTAGLIST-54: - Attachment: tag-mojo-patch.txt Here is a Patch to support html comments in the HTML report. It could have xml report side effects Allow HTML tags in comments --- Key: MTAGLIST-54 URL: http://jira.codehaus.org/browse/MTAGLIST-54 Project: Maven 2.x Taglist Plugin Issue Type: Wish Environment: All Reporter: David Pilato Priority: Trivial Attachments: tag-mojo-patch.txt Hi, It could be usefull to be able in the tagClass property to specify if text after the tag will be treated as plain text (default as now) or as html code. With this property, we can write some comments like : // mytag Hello bMister Bold/b By default, it will generate in the final report Hello bMister Bold/b By setting html code, it will generate Hello Mister Bold with Mister Bold in bold. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] Commented: (MCOBERTURA-86) no coverage reported for integration-test
[
http://jira.codehaus.org/browse/MCOBERTURA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250278#action_250278
]
Harald Brabenetz commented on MCOBERTURA-86:
I use the following workaround:
{noformat}
profile
!-- Build with IntegrationTestcoverage = instrument classes with cobertura
before integrationtests starts. --
idbuildWithIntegrationTestCoverage/id
activation
property
namebuildWithIntegrationTestCoverage/name
valuetrue/value
/property
/activation
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.3/version
executions
execution
idinstrument-classes/id
phasepackage/phase
goals
goalinstrument/goal
/goals
/execution
/executions
/plugin
!-- Add cobertura as dependency to the jetty-plugin (required for
instrumented classes) --
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
dependencies
dependency
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.3/version
typejar/type
/dependency
/dependencies
/plugin
/plugins
/build
/profile
{noformat}
And then i start the site-generation with:
{noformat}
mvn clean install site -DbuildWithIntegrationTestCoverage=true
{noformat}
no coverage reported for integration-test
-
Key: MCOBERTURA-86
URL: http://jira.codehaus.org/browse/MCOBERTURA-86
Project: Maven 2.x Cobertura Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, maven 2.0.8
Reporter: Jean-Francois Poilpret
Attachments:
cobertura-maven-plugin_check-only-and-report-only-mojos_with-IT.patch,
cobertura-maven-plugin_check-only-and-report-only-mojos_with-IT_for-2.5-SNAPSHOT.patch,
cobertura-maven-plugin_check-only-mojo.patch,
CoberturaIntegrationReportMojo.patch, CoberturaReportOnlyMojo.patch
In my project, I have both unit tests (test phase) and integration tests
(integration-test phase).
So far I could manage configuring maven-surefire-plugin and
maven-surefire-report-plugin to execute both tests correctly and also
generate 2 different reports.
Then I have added cobertura-maven-plugin to the reporting in order to get
coverage but unfortunately only unit tests have their coverage reported (I
know it because I have some classes which are only integration tested but are
reported as 0% covered).
After trying to find information on the mailing lists, on the web and other
existing resources, I could not find any hint on how to make this work.
It looks like cobertura-maven-plugin, by its current design, will never run
integration-test to collect coverage, it seems to stop at the test phase.
Thus whenever a POM project has integration tests and uses
cobertura-maven-plugin for coverage report, the generated reports are wrong,
which is very misleading.
Actually, I was surprised not to find this issue already in JIRA.
Is there a chance this gets fixed soon? Or is there a usable workaround for
this problem (besides switching to clover which I am not sure it would work
better ;-)) Did someone succeed in patching cobertura-maven-plugin to get the
correct behavior?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
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] Closed: (MCLIRR-35) Allow setting of minSeverity parameter for the check goal aswell
[ http://jira.codehaus.org/browse/MCLIRR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCLIRR-35. -- Resolution: Fixed fixed rev 13338. Thanks ! Allow setting of minSeverity parameter for the check goal aswell -- Key: MCLIRR-35 URL: http://jira.codehaus.org/browse/MCLIRR-35 Project: Maven 2.x Clirr Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Matthias Weßendorf Assignee: Olivier Lamy Fix For: 2.3 Attachments: minSeverity.patch Currently the minSeverity can be only applied to the 'clirr' goal. It would be nice if it could be used on 'check' as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] [Clirr Plugin] patch available
patch applied and SNAPSHOT deployed. -- Olivier 2011/1/3 Matthias Wessendorf mat...@apache.org: Hi, thanks for looking into this. -Matthias On Mon, Jan 3, 2011 at 10:11 AM, Olivier Lamy ol...@apache.org wrote: Hello, I will have a look. 2011/1/3 Matthias Wessendorf mat...@apache.org: Hi, I provided a patch for the Clirr Plugin ([1]) to allow setting of the severity, when executing the 'check' goal. Would be nice if someone could apply the patch. Thanks! Matthias [1] http://jira.codehaus.org/browse/MCLIRR-35 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] Created: (CBUILDS-57) file name string handling in RPM plugin needs refactoring
file name string handling in RPM plugin needs refactoring - Key: CBUILDS-57 URL: http://jira.codehaus.org/browse/CBUILDS-57 Project: Mojo C Builds Issue Type: Improvement Components: RPM artifact management Affects Versions: 1.0-beta-1, 1.0-alpha-6, 1.0-alpha-5 Reporter: Lee Thompson Priority: Minor BuildRpmMojo.java GenerateSpecFileMojo.java and perhaps a few others have different implementations of the same code to generate the file name, version, classifier, package extenstion. This needs to be consolidated/refactored as its generated a lot of bugs. It could be three lines of code? mvnVersion = rpmVersion + - + rpmRelease classifier = skipPlatformPostfix ? noarch : distroName + . + distroCPU filename = rpmName + . + mvnVersion + . + classifier + .rpm RpmInfoFormatter.java and ProjectRpmFileManager.java and maybe a few others need to be rewritten -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] Updated: (CBUILDS-52) make:compile ignores derived configuration parameters
[
http://jira.codehaus.org/browse/CBUILDS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Thompson updated CBUILDS-52:
Issue Type: Bug (was: Sub-task)
Parent: (was: CBUILDS-57)
make:compile ignores derived configuration parameters
-
Key: CBUILDS-52
URL: http://jira.codehaus.org/browse/CBUILDS-52
Project: Mojo C Builds
Issue Type: Bug
Components: Automake/Autoconfig Orchestration
Affects Versions: 1.0-beta-1
Reporter: Anton Nikitin
Assignee: Lee Thompson
make:compile should take into account parameters derived from base class.
E.g. environment and skipped parameters are ignored even if
compileEnvironment and skipCompile are not set.
It seems that implementation class (org.codehaus.mojo.make.CompileExecMojo)
should set the values like other mojos only if overriding parameter is set,
i.e.
if ( compileEnvironment != null !compileEnvironment.isEmpty() )
{
setEnvironment( compileEnvironment );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
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] Updated: (CBUILDS-52) make:compile ignores derived configuration parameters
[
http://jira.codehaus.org/browse/CBUILDS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Thompson updated CBUILDS-52:
Issue Type: Sub-task (was: Bug)
Parent: CBUILDS-57
make:compile ignores derived configuration parameters
-
Key: CBUILDS-52
URL: http://jira.codehaus.org/browse/CBUILDS-52
Project: Mojo C Builds
Issue Type: Sub-task
Components: Automake/Autoconfig Orchestration
Affects Versions: 1.0-beta-1
Reporter: Anton Nikitin
Assignee: Lee Thompson
make:compile should take into account parameters derived from base class.
E.g. environment and skipped parameters are ignored even if
compileEnvironment and skipCompile are not set.
It seems that implementation class (org.codehaus.mojo.make.CompileExecMojo)
should set the values like other mojos only if overriding parameter is set,
i.e.
if ( compileEnvironment != null !compileEnvironment.isEmpty() )
{
setEnvironment( compileEnvironment );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
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] Updated: (CBUILDS-54) RPM plugin fails on RHEL6
[
http://jira.codehaus.org/browse/CBUILDS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Thompson updated CBUILDS-54:
Issue Type: Sub-task (was: Bug)
Parent: CBUILDS-57
RPM plugin fails on RHEL6
-
Key: CBUILDS-54
URL: http://jira.codehaus.org/browse/CBUILDS-54
Project: Mojo C Builds
Issue Type: Sub-task
Components: RPM artifact management
Affects Versions: 1.0-alpha-5, 1.0-alpha-6, 1.0-beta-1
Environment: Redhat Enterprise Linux 6.0
Reporter: Lee Thompson
Assignee: Lee Thompson
Priority: Blocker
Fix For: 1.0-beta-2
[INFO] --- make-maven-plugin:1.0-beta-2-SNAPSHOT:make-install
(default-make-install) @ baselayout ---
[INFO] make[1]: Entering directory
`/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/baselayout-0.2'
[INFO] make[1]: Nothing to be done for `install-exec-am'.
[INFO] test -z /opt/baselayout || /bin/mkdir -p
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-basedir//opt/baselayout
[INFO] /usr/bin/install -c -m 644 AUTHORS COPYING ChangeLog INSTALL NEWS
README
'/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-basedir//opt/baselayout'
[INFO] make[1]: Leaving directory
`/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/baselayout-0.2'
[INFO]
[INFO] --- rpm-cbuild-maven-plugin:1.0-beta-2-SNAPSHOT:generate-spec
(default-generate-spec) @ baselayout ---
[WARNING] Assuming all dependencies are real RPM dependencies. Provides
statement is not currently being populated.
[INFO] RPM Name: 'pkgs_rpms_dev-sys_baselayout'
[INFO] RPM Name: 'pkgs_rpms_dev-sys_baselayout-0.2-3.rhel6'
[INFO]
[INFO] --- rpm-cbuild-maven-plugin:1.0-beta-2-SNAPSHOT:build (default-build)
@ baselayout ---
[INFO] RPM Name: 'rpms_dev-sys_baselayout-0.2-3.rhel6'
[INFO] RPMS Directory:
'/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-topdir/RPMS/i386'
[INFO] RPM Name: 'pkgs_rpms_dev-sys_baselayout'
[INFO] Processing files: pkgs_rpms_dev-sys_baselayout-0.2-3.rhel6.i686
[INFO] Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-basedir
[INFO] Wrote:
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-topdir/RPMS/i686/pkgs_rpms_dev-sys_baselayout-0.2-3.rhel6.i686.rpm
[INFO] Executing(%clean): /bin/sh -e
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-topdir/tmp/rpm-tmp.vujIrT
[INFO] + umask 022
[INFO] + cd
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-topdir/BUILD
[INFO] + /bin/rm -rf
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-basedir
[INFO] + exit 0
extractProperty:: 'Red Hat Enterprise Linux Workstation release 6.0
(Santiago)' {Red Hat Enterprise Linux .* release ([0-9]+)=rhel$1, CentOS
release ([.0-9]+)=centos$1, Red Hat Linux release ([0-9]+)=rh$1}
[INFO] Attatching artifact classifier :rhel6.i386: name
:/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-topdir/RPMS/i386/pkgs_rpms_dev-sys_baselayout-0.2-3.rhel6.i386.rpm
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.444s
[INFO] Finished at: Sat Jan 01 16:26:14 PST 2011
[INFO] Final Memory: 9M/247M
[INFO]
[ERROR] Failed to execute goal
org.codehaus.mojo:rpm-cbuild-maven-plugin:1.0-beta-2-SNAPSHOT:build
(default-build) on project baselayout: RPM artifact:
/home/lee/workspace/pkgs/rpms/dev-sys/baselayout/target/rpm-topdir/RPMS/i386/pkgs_rpms_dev-sys_baselayout-0.2-3.rhel6.i386.rpm
does not exist. - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[...@localhost baselayout]$ ls target/
baselayout-0.2 baselayout-0.2.tar.gz classes rpm-topdir
[...@localhost baselayout]$ ls target/rpm-topdir/
BUILD BUILDROOT maven-rpm-config RPMS SOURCES SPECS SRPMS tmp
[...@localhost baselayout]$ ls target/rpm-topdir/RPMS/
i386 i686
[...@localhost baselayout]$ ls target/rpm-topdir/RPMS/i686/
pkgs_rpms_dev-sys_baselayout-0.2-3.rhel6.i686.rpm
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[mojo-dev] [jira] Created: (CBUILDS-58) RPM dependencies broke with move to maven 3.0
RPM dependencies broke with move to maven 3.0 - Key: CBUILDS-58 URL: http://jira.codehaus.org/browse/CBUILDS-58 Project: Mojo C Builds Issue Type: Bug Affects Versions: 1.0-beta-2 Reporter: Lee Thompson Priority: Critical Put a dependency into an rpm package POM and you get a java null pointer exception -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - 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] Mojo Developer Cookbook and v3.0
ArtifactFactory out, Aether in? Long live Aether? http://www.sonatype.com/people/2010/08/introducing-aether/ From: Lee Thompson bm...@yahoo.com To: dev@mojo.codehaus.org Sent: Thu, December 30, 2010 8:28:07 PM Subject: [mojo-dev] Mojo Developer Cookbook and v3.0 So, a bunch of the API's used in the Mojo Developers Cookbook have been marked deprecated in maven 3.0. ArtifactFactory and ArtifactMetadataSource for instance. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Another one I use a lot is WagonManager. I poked around the maven source code for about an hour and couldn't figure out what replaces ArtifactFactory. Anyone else going to Maven 3.0 run into this or just ignore the warnings...
Re: [mojo-dev] Mojo Developer Cookbook and v3.0
Using Aether directly will make your plugin require Maven 3.x. /Anders On Mon, Jan 3, 2011 at 19:18, Lee Thompson bm...@yahoo.com wrote: ArtifactFactory out, Aether in? Long live Aether? http://www.sonatype.com/people/2010/08/introducing-aether/ -- *From:* Lee Thompson bm...@yahoo.com *To:* dev@mojo.codehaus.org *Sent:* Thu, December 30, 2010 8:28:07 PM *Subject:* [mojo-dev] Mojo Developer Cookbook and v3.0 So, a bunch of the API's used in the Mojo Developers Cookbook have been marked deprecated in maven 3.0. ArtifactFactory and ArtifactMetadataSource for instance. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Another one I use a lot is WagonManager. I poked around the maven source code for about an hour and couldn't figure out what replaces ArtifactFactory. Anyone else going to Maven 3.0 run into this or just ignore the warnings...
Re: [mojo-dev] Mojo Developer Cookbook and v3.0
Yeah, my environment is all maven 3.0.1. I just converted all my plugins to use as little the maven-compat aspects as possible. Any other mojos doing this yet? If not, it might explain the lack of docs. From: Anders Hammar and...@hammar.net To: dev@mojo.codehaus.org Sent: Mon, January 3, 2011 12:31:04 PM Subject: Re: [mojo-dev] Mojo Developer Cookbook and v3.0 Using Aether directly will make your plugin require Maven 3.x. /Anders On Mon, Jan 3, 2011 at 19:18, Lee Thompson bm...@yahoo.com wrote: ArtifactFactory out, Aether in? Long live Aether? http://www.sonatype.com/people/2010/08/introducing-aether/ From: Lee Thompson bm...@yahoo.com To: dev@mojo.codehaus.org Sent: Thu, December 30, 2010 8:28:07 PM Subject: [mojo-dev] Mojo Developer Cookbook and v3.0 So, a bunch of the API's used in the Mojo Developers Cookbook have been marked deprecated in maven 3.0. ArtifactFactory and ArtifactMetadataSource for instance. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Another one I use a lot is WagonManager. I poked around the maven source code for about an hour and couldn't figure out what replaces ArtifactFactory. Anyone else going to Maven 3.0 run into this or just ignore the warnings...
RE: [mojo-dev] Mojo Developer Cookbook and v3.0
Hi Lee, I did already notice you were moving this project to M3. IMHO I think we should try to support as many Maven versions as possible. It's not just up to us to force developers to move to the most recent version of Maven. For instance: companies might have locked their Maven version for certain projects. Reasons to move to a newer version of Maven would be: - Bugs in Maven which might cause the plugin to fail. - Maven-API changes which are required for certain fixes/improvements of the plugin. btw, this counts for any type of newer versions (major-updates, minor-updates, incremental-updates). I hope you have good reason to switch to M3, but I'd suggest to depend on Maven 3.0 instead of 3.0.1 (unless one of the above reasons forces you to use 3.0.1) -Robert Date: Mon, 3 Jan 2011 10:56:01 -0800 From: bm...@yahoo.com To: dev@mojo.codehaus.org Subject: Re: [mojo-dev] Mojo Developer Cookbook and v3.0 Yeah, my environment is all maven 3.0.1. I just converted all my plugins to use as little the maven-compat aspects as possible. Any other mojos doing this yet? If not, it might explain the lack of docs. From: Anders Hammar and...@hammar.net To: dev@mojo.codehaus.org Sent: Mon, January 3, 2011 12:31:04 PM Subject: Re: [mojo-dev] Mojo Developer Cookbook and v3.0 Using Aether directly will make your plugin require Maven 3.x. /Anders On Mon, Jan 3, 2011 at 19:18, Lee Thompson bm...@yahoo.com wrote: ArtifactFactory out, Aether in? Long live Aether? http://www.sonatype.com/people/2010/08/introducing-aether/ From: Lee Thompson bm...@yahoo.com To: dev@mojo.codehaus.org Sent: Thu, December 30, 2010 8:28:07 PM Subject: [mojo-dev] Mojo Developer Cookbook and v3.0 So, a bunch of the API's used in the Mojo Developers Cookbook have been marked deprecated in maven 3.0. ArtifactFactory and ArtifactMetadataSource for instance. http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook Another one I use a lot is WagonManager. I poked around the maven source code for about an hour and couldn't figure out what replaces ArtifactFactory. Anyone else going to Maven 3.0 run into this or just ignore the warnings...
Re: [mojo-dev] [Clirr Plugin] patch available
Hi Olivier, thanks for applying my patch and deploying the SNAPSHOT. Are there any plans to run a release of this, soon? -Matthias On Mon, Jan 3, 2011 at 6:40 PM, Olivier Lamy ol...@apache.org wrote: patch applied and SNAPSHOT deployed. -- Olivier 2011/1/3 Matthias Wessendorf mat...@apache.org: Hi, thanks for looking into this. -Matthias On Mon, Jan 3, 2011 at 10:11 AM, Olivier Lamy ol...@apache.org wrote: Hello, I will have a look. 2011/1/3 Matthias Wessendorf mat...@apache.org: Hi, I provided a patch for the Clirr Plugin ([1]) to allow setting of the severity, when executing the 'check' goal. Would be nice if someone could apply the patch. Thanks! Matthias [1] http://jira.codehaus.org/browse/MCLIRR-35 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
