[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 section, which at
least caused the cyclic dependency error I saw before (when I used 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}
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
> whizbang/checkstyle.xml
> whizbang/LICENSE.txt
>
>
>
> com.example.whizbang
> build-tools
> 1.0
>
>
>
>
>
> {noformat}
> This is invalid according to the latest 2.0.2 POM schema. 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 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
... 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
