[jira] Commented: (MCHECKSTYLE-31) Multi-module reports do not support custom classpath configurations
[
http://jira.codehaus.org/browse/MCHECKSTYLE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89430
]
Christian Goetze commented on MCHECKSTYLE-31:
-
I've been trying to get this to work for some time, and I can't seem to get
there...
So I did move the plugin configuration into the build / section, which at
least caused the cyclic dependency error I saw before (when I used extensions
/ to go away, but now it seems that it won't go more than one level deep,
skipping over module directories that do not contain a src subtree.
INFO]
[INFO] Building SenSage shared artifacts
[INFO]task-segment: [checkstyle:check]
[INFO]
[INFO] Preparing checkstyle:check
[INFO] [checkstyle:checkstyle]
[INFO] Source directory does not exist - skipping report.
[INFO] [checkstyle:check]
[INFO] Unable to perform checkstyle:check, unable to find checkstyle:checkstyle
outputFile.
This is using maven 2.0.5
Multi-module reports do not support custom classpath configurations
---
Key: MCHECKSTYLE-31
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-31
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-1
Reporter: Mike Perham
Assigned To: fabrizio giustina
Priority: Critical
The latest multi-module tip shows the following:
{noformat}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
configLocationwhizbang/checkstyle.xml/configLocation
headerLocationwhizbang/LICENSE.txt/headerLocation
/configuration
dependencies
dependency
groupIdcom.example.whizbang/groupId
artifactIdbuild-tools/artifactId
version1.0/version
/dependency
/dependencies
/plugin
/plugins
/reporting
{noformat}
This is invalid according to the latest 2.0.2 POM schema. dependencies is
not supported in reporting plugins.
So it seems impossible to provide a custom config in a multi-module build
without using a network URL as we cannot use File or classpath.
--
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
[jira] Commented: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=comments#action_84865 ]
Christian Goetze commented on MNG-2456:
---
I would like to see a fix that does not involve adding extra configuration
items to the assembly... whatever happened to convention instead of
configuration - and yes, the onus is on -you- to determine which behaviour
should be standard...
Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
snapshots
Key: MNG-2456
URL: http://jira.codehaus.org/browse/MNG-2456
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.4
Reporter: Baerrach bonDierne
Assigned To: Kenney Westerhof
Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
MNG-2456-step1-refactoring-patch.txt,
MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
See related problems MJAR-28 and MASSEMBLY-67.
Summary:
The Maven-Archiver uses the file part of the artifact's filename to create
the Class-Path entries in the Manifest.
This works fine for released artifacts and non-deployed snapshot.
The problem occurs when using a deployed snapshot as the assembly plugin will
copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
thus use of java -jar jarfile will fail because of the differing names.
--
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
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_84785 ]
Christian Goetze commented on MNG-624:
--
I would like to add my support for allowing the use of ${...} in the
parent.../parent sections. I just fail to see any downside to it, and it
would certainly make my life easier, as I cannot use the release plugin as it
is...
automatic parent versioning
---
Key: MNG-624
URL: http://jira.codehaus.org/browse/MNG-624
Project: Maven 2
Issue Type: Improvement
Components: Inheritance and Interpolation
Reporter: Brett Porter
Assigned To: Brett Porter
Priority: Blocker
Fix For: 2.1.x
Original Estimate: 4 hours
Remaining Estimate: 4 hours
(this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
MNG-521)
currently, you have to specify the parent version when extending which makes
a project stand alone very easily, but has the drawback of being a
maintainance problem when you start development on a new version. Tools can
help, but it would be nice not to have to rely on them.
One alternative is to allow the parent version to be omitted, and when it is
it is assumed you want the latest. The parent is used from the reactor or the
universal source directory. IT may also be read from a LATEST in the
repository though this is contentious - it may be better to simply fail in
that environment and require builds be in a known checkout structure for
building individual projects.
This also introduces the need for tool support to populate the version on
release and deployment for reproducibility.
--
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
[jira] Commented: (MCOMPILER-21) compiler smarts
[ http://jira.codehaus.org/browse/MCOMPILER-21?page=comments#action_84589 ] Christian Goetze commented on MCOMPILER-21: --- 3) Track inventory. If files are removed, remove associated class files and force jar repacking/ 4) Track timestamps. If file timestamp changes (e.g. to an -older- version), rebuild. 5) Track hash signatures for source files. Recompute signature if file timestamp changes, rebuild only if signature changes. 6) Track hash signatures for class files. Repack jars only if hash signatures change. compiler smarts --- Key: MCOMPILER-21 URL: http://jira.codehaus.org/browse/MCOMPILER-21 Project: Maven 2.x Compiler Plugin Issue Type: Bug Reporter: Brett Porter Priority: Minor Fix For: 2.1 there are probably other ways we can make the compiler stale check smarter. List them out here if you think of them. 1) if a snapshot was resolved to a newer version, rebuild everything. -- 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
