[jira] Commented: (MENFORCER-42) Maven-Enforcer-Plugin fails in multimodule project when artifacts not in repository
[
http://jira.codehaus.org/browse/MENFORCER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263549#action_263549
]
Stefan Rönisch commented on MENFORCER-42:
-
mvn release:perform fails if one multiproject submoduls depends from a
another within the same multiproject.
Maven-Enforcer-Plugin fails in multimodule project when artifacts not in
repository
---
Key: MENFORCER-42
URL: http://jira.codehaus.org/browse/MENFORCER-42
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Plugin
Affects Versions: 1.0-alpha-3, 1.0
Environment: Tested with Maven 2.0.7 and 2.0.8 on Linux with Java 1.5
Reporter: Martin Höller
Assignee: Brian Fox
Attachments: enforcer-test.tar.gz
Create a new simple multimodule-project and call {{mvn validate}} at the
toplevel. This leads to a build failure if none of the multimodule-artifacts
are in your local repository.
Attached is a simple test project for reproducing this bug.
--
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-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263551#action_263551 ] Bram commented on MNG-3139: --- Another workaround for now (as the others don't work for me / anymore): Install the downloaded skin as version DEFAULT, so you get: M2_repo/org/apache/maven/skins/maven-default-skin/DEFAULT/maven-default-skin-DEFAULT.jar The skin does not exist: Unable to determine the release version Key: MNG-3139 URL: http://jira.codehaus.org/browse/MNG-3139 Project: Maven 2 3 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.0.7 Reporter: eyal david Assignee: John Casey Fix For: 2.0.11, 2.1.0, 3.0-alpha-3 Attachments: cached-metadata.patch, mvn_site_debug.zip hi I have problem generating site when im using the command mvn site it performs all stagegs and when it came to site generation the message is shown : The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven -default-skin \ -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file org.apache.maven.skins:maven-default-skin:jar:RELEASE do u have an idea what is the problem ? p.s the jar is registered in my local repository and in the remote repository thank u -- 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
Setting the ' @requiresProject false' in the related Mojos
weblogic-maven-plugin:10.3.4:plugin has a few warts both in convention handling and in usability. - None of the goals appear to have a need for a project associated with them, but all are flagged as 'requiresProject'. setting ' @requiresProject false' in the related Mojos would allow use of the plugin as a standalone. -- View this message in context: http://maven.40175.n5.nabble.com/Setting-the-requiresProject-false-in-the-related-Mojos-tp4302695p4302695.html Sent from the Maven - Issues mailing list archive at Nabble.com.
[jira] Commented: (MINSTALL-83) The install should also conatin a goal to install directory of external jar files into the repository.
[ http://jira.codehaus.org/browse/MINSTALL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263573#action_263573 ] John Casey commented on MINSTALL-83: You can attach a patch to the plugin here, and we'll review it. If everything looks ok, we'll commit the code and it'll get picked up in the next release. The install should also conatin a goal to install directory of external jar files into the repository. -- Key: MINSTALL-83 URL: http://jira.codehaus.org/browse/MINSTALL-83 Project: Maven 2.x Install Plugin Issue Type: Improvement Reporter: Gaurav Mutreja The install should conatin a goal to install directory of jar files into the repository. It is quite painful to install each jar file one by one(say if we have 100 jar files).It would be great if we provide the directory in which jar files are kept to a single command to install all of the files. I have worked on it and created a new plug-in which which installs in repository the whole directory at once.The code basically modifies the existing installFile mojo source to support the installation of full directory. How can I get it reviewed?So,that I can go ahead and commit the code. Thanks Gaurav -- 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: (MINSTALL-83) The install should also conatin a goal to install directory of external jar files into the repository.
[ http://jira.codehaus.org/browse/MINSTALL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263575#action_263575 ] John Casey commented on MINSTALL-83: ...But please be sure your patch includes tests, and conforms to the source formatting guidelines at: http://maven.apache.org/developers/conventions/code.html The install should also conatin a goal to install directory of external jar files into the repository. -- Key: MINSTALL-83 URL: http://jira.codehaus.org/browse/MINSTALL-83 Project: Maven 2.x Install Plugin Issue Type: Improvement Reporter: Gaurav Mutreja The install should conatin a goal to install directory of jar files into the repository. It is quite painful to install each jar file one by one(say if we have 100 jar files).It would be great if we provide the directory in which jar files are kept to a single command to install all of the files. I have worked on it and created a new plug-in which which installs in repository the whole directory at once.The code basically modifies the existing installFile mojo source to support the installation of full directory. How can I get it reviewed?So,that I can go ahead and commit the code. Thanks Gaurav -- 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: (MSITE-546) container field of SiteDeployMojo not populated correctly - NPE with servers containing configuration
[
http://jira.codehaus.org/browse/MSITE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263579#action_263579
]
Marcin Kuthan commented on MSITE-546:
-
Thanks Lukas for quick reply. You are right, the older snapshot was used (my
Artifactory installation does not support M3 metadata files and served the
outdated plugin).
Now I get another exception, but the exception is not related to the site
plugin.
{code}
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
ClassNotFoundException: Class name which was explicitly given in configuration
using 'implementation' attribute:
'org.apache.maven.wagon.providers.ssh.knownhost.NullKnownHostProvider' cannot
be loaded
{code}
Thanks again.
container field of SiteDeployMojo not populated correctly - NPE with
servers containing configuration
Key: MSITE-546
URL: http://jira.codehaus.org/browse/MSITE-546
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: Maven 3, site:deploy
Affects Versions: 3.0-beta-3
Reporter: Carl Wilund
Assignee: Olivier Lamy
Fix For: 3.0-beta-4
In SiteDeployMojo, the field container is not populated correctly (version
skew with @Requirement?). When configureWagon is subsequently called, IFF the
site deploy server has an entry in settings.xml AND contains a
configuration subelement, there will be a NullPointerException thrown (line
474) when container.lookup is called.
Simple repro:
settings.xml:
...
server
idbogus/id
usernamebogus/username
passwordbogus/password
configuration
/configuration
/server
...
pom.xml:
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.0-beta-3/version
/plugin
/plugins
/build
distributionManagement
site
idbogus/id
nameBogus/name
urlsftp://bogus.bogus.org/bogus/url
/site
/distributionManagement
...
While this should obviously not work, it should not NPE at line 474.
--
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: (MINSTALL-83) The install should also conatin a goal to install directory of external jar files into the repository.
[ http://jira.codehaus.org/browse/MINSTALL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263583#action_263583 ] Gaurav Mutreja commented on MINSTALL-83: Hi John, Thanks a lot for the reply. Let me complete the tests and then I will submit the patch, Thanks Gaurav The install should also conatin a goal to install directory of external jar files into the repository. -- Key: MINSTALL-83 URL: http://jira.codehaus.org/browse/MINSTALL-83 Project: Maven 2.x Install Plugin Issue Type: Improvement Reporter: Gaurav Mutreja The install should conatin a goal to install directory of jar files into the repository. It is quite painful to install each jar file one by one(say if we have 100 jar files).It would be great if we provide the directory in which jar files are kept to a single command to install all of the files. I have worked on it and created a new plug-in which which installs in repository the whole directory at once.The code basically modifies the existing installFile mojo source to support the installation of full directory. How can I get it reviewed?So,that I can go ahead and commit the code. Thanks Gaurav -- 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
error while deploying a project
i m using maven 2.0.9 and recently i have shifted my repository to sonatype
nexus 1.9.0.2 from archiva.
I have migrated all the necessary artifcats to sonatype nexus as explained
in their docs and found no errors while rebuilding any indexes whatsoever in
the logs. The migration was successful. However, while deploying one of the
project, i get following error..
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - pw:pw-base-dependencies:pom:1.0-SNAPSHOT
[INFO]task-segment: [deploy]
[INFO]
[INFO] [jar:test-jar {execution: default}]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: default}]
[INFO] [install:install]
[INFO] Installing /somepath/base/base-dependencies/pom.xml to
/home/nilesh/MiKuStuff/Workspace/_app_base/Maven2Repo/pw/pw-base-dependencies/1.0-SNAPSHOT/pw-base-dependencies-1.0-SNAPSHOT.pom
[INFO] Installing
/somepath/base/base-dependencies/target/WEB-INF/lib/pw-base-dependencies-1.0-SNAPSHOT-tests.jar
to
/home/nilesh/MiKuStuff/Workspace/_app_base/Maven2Repo/pw/pw-base-dependencies/1.0-SNAPSHOT/pw-base-dependencies-1.0-SNAPSHOT-tests.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO] Retrieving previous build number from snapshots
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error retrieving previous build number for artifact
'pw:pw-base-dependencies:pom': Cannot read metadata from
'/somepath/_app_base/Maven2Repo/pw/pw-base-dependencies/1.0-SNAPSHOT/maven-metadata-snapshots.xml':
expected START_TAG or END_TAG not TEXT (position: TEXT seen
...classifiertests/... @14:28)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Thu Apr 14 21:10:06 IST 2011
[INFO] Final Memory: 18M/122M
[INFO]
The contents of the file being complained
(i.e. maven-metadata-snapshots.xml) has following contents..
?xml version=1.0 encoding=UTF-8?
metadata modelVersion=1.1.0
groupIdpw/groupId
artifactIdpw-base-dependencies/artifactId
version1.0-SNAPSHOT/version
versioning
snapshot
timestamp20100617.105422/timestamp
buildNumber11/buildNumber
/snapshot
lastUpdated20110411220259/lastUpdated
snapshotVersions
snapshotVersion
classifiertests/classifier
extensionjar/extension
value1.0-20100617.105422-11/value
updated20100617105422/updated
/snapshotVersion
snapshotVersion
extensionpom/extension
value1.0-20100617.105422-11/value
updated20100617105422/updated
/snapshotVersion
/snapshotVersions
/versioning
/metadata
Googling did not give any hint on what is to be done. And i dont understand
what is wrong with this situation. Please help. Please revert if some more
information is needed.
--
Best Regards,
Nilesh Mevada
[jira] Updated: (MASSEMBLY-555) Need a better solution than packaging == pom for distribution modules whose output is an assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-555: - Fix Version/s: 2.3 Need a better solution than packaging == pom for distribution modules whose output is an assembly - Key: MASSEMBLY-555 URL: http://jira.codehaus.org/browse/MASSEMBLY-555 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2.1 Reporter: John Casey Assignee: John Casey Fix For: 2.3 It's common practice to use a purpose-built module to create a distribution assembly for a project. However, there is no packaging that accommodates this. We need one or more packagings added to the assembly plugin that will allow a proper non-pom packaging. Currently, this is an issue if someone tries to create one assembly from a purpose-built module - say, for an examples aggregation - and then use it in another assembly via moduleSet/binaries. Since the packaging is 'pom', the project is NOT included in the moduleSet, because POMs are assumed not to have binaries. Or, if they do, they're assumed to have binaries that are addressable via some classifier...which I'm still not sure would even work with the assembly plugin. Bottom line is, we need a better solution than abusing the pom packaging for assembly modules. -- 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] Created: (MASSEMBLY-555) Need a better solution than packaging == pom for distribution modules whose output is an assembly
Need a better solution than packaging == pom for distribution modules whose output is an assembly - Key: MASSEMBLY-555 URL: http://jira.codehaus.org/browse/MASSEMBLY-555 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2.1 Reporter: John Casey It's common practice to use a purpose-built module to create a distribution assembly for a project. However, there is no packaging that accommodates this. We need one or more packagings added to the assembly plugin that will allow a proper non-pom packaging. Currently, this is an issue if someone tries to create one assembly from a purpose-built module - say, for an examples aggregation - and then use it in another assembly via moduleSet/binaries. Since the packaging is 'pom', the project is NOT included in the moduleSet, because POMs are assumed not to have binaries. Or, if they do, they're assumed to have binaries that are addressable via some classifier...which I'm still not sure would even work with the assembly plugin. Bottom line is, we need a better solution than abusing the pom packaging for assembly modules. -- 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: (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
http://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263595#action_263595
]
John Casey commented on MASSEMBLY-553:
--
Please add some test project, or at least a URL, where this is occurring.
Without this, it's just a vague description of the problem, and it leaves us
without a definitive confirmation that we've replicated the problem in a test
case.
Assembly plugin ignores attached assemblies
---
Key: MASSEMBLY-553
URL: http://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
Fix For: 2.3
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
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] Updated: (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
http://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-553:
-
Fix Version/s: 2.3
Assembly plugin ignores attached assemblies
---
Key: MASSEMBLY-553
URL: http://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
Fix For: 2.3
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
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
Re: error while deploying a project
On Thu, Apr 14, 2011 at 11:49 AM, Nilesh Mevada niles...@directi.com wrote: I have migrated all the necessary artifcats to sonatype nexus as explained in their docs and found no errors while rebuilding any indexes whatsoever in the logs. The migration was successful. However, while deploying one of the project, i get following error.. Please re-post your question to either the Maven or Nexus users list. (You've written to an address that is only used for automated notifications from the issue tracking system.) http://maven.apache.org/mail-lists.html -- Wendy
[jira] Created: (MCHECKSTYLE-157) Update to post-5.0 checkstyle when the plugin is available
Update to post-5.0 checkstyle when the plugin is available -- Key: MCHECKSTYLE-157 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-157 Project: Maven 2.x Checkstyle Plugin Issue Type: Task Affects Versions: 2.5, 2.4 Reporter: Benson Margulies Once the maven-checkstyle-plugin releases a version with a newer checkstyle that 5.0, use it and fix the rules to stop exploding on @goal. -- 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: (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
http://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263600#action_263600
]
SebbASF commented on MASSEMBLY-553:
---
There is already a test case attached to this JIRA - can you not see it?
Assembly plugin ignores attached assemblies
---
Key: MASSEMBLY-553
URL: http://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
Fix For: 2.3
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
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] Created: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
mvn assembly:assembly NPEs with install:install-file'd artifacts
Key: MASSEMBLY-556
URL: http://jira.codehaus.org/browse/MASSEMBLY-556
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win 7
x64, Sun Java 6u24 x64.
Reporter: Chris West
Attachments: build.log, pom.xml, repository.xml
I have 3rd-party jars installed via. {{mvn install:install-file}}. This causes
{{mvn assembly:assembly}} to NPE around:
{code}
Caused by: java.lang.NullPointerException
at
org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
at
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
...
{code}
To reproduce, first, install:install-file a random file:
{code}
mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
-DartifactId=a -Dversion=0 -Dpackaging=jar
{code}
Then, create pom.xml (attached):
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.goeswhere.test/groupId
artifactIdb/artifactId
version1.0-SNAPSHOT/version
packagingjar/packaging
dependencies
dependency
groupIdcom.goeswhere.test/groupId
artifactIda/artifactId
version0/version
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptor./repository.xml/descriptor
/descriptors
/configuration
/plugin
/plugins
/build
/project
{code}
and repository.xml (attached):
{code:xml}
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idrepository/id
formats
formatjar/format
/formats
repositories
repository
includeMetadatatrue/includeMetadata
outputDirectorymaven2/outputDirectory
/repository
/repositories
/assembly
{code}
And run {{mvn assembly:assembly}}. See attached build.log.
--
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] Closed: (MCHECKSTYLE-153) Checkstyle doesn't run on projects containing only test classes
[
http://jira.codehaus.org/browse/MCHECKSTYLE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHECKSTYLE-153.
---
Resolution: Fixed
Fix Version/s: 2.7
Assignee: Dennis Lundberg
Patch applied in
[r1092498|http://svn.apache.org/viewvc?view=revisionrevision=1092498].
Thanks!
New 2.7-SNAPSHOT deployed. Please test it.
Checkstyle doesn't run on projects containing only test classes
---
Key: MCHECKSTYLE-153
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-153
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Bruce Mackenzie Nielsen
Assignee: Dennis Lundberg
Fix For: 2.7
We discovered that if a project only contains test classes and no normal
classes, the canGenerateReport() function returns false, as it only checks
for the existence of the sourceDirectory path. If includeTestSourceDirectory
is set to true, the function should also check for the existence of the
testSourceDirectory path.
Here's an example patch to the method:
public boolean canGenerateReport()
{
// TODO: would be good to scan the files here
return sourceDirectory.exists() || (includeTestSourceDirectory
testSourceDirectory.exists());
}
--
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] Closed: (MCHECKSTYLE-149) supressionsFileExpression does not work.
[
http://jira.codehaus.org/browse/MCHECKSTYLE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHECKSTYLE-149.
---
Resolution: Fixed
Fix Version/s: 2.7
Assignee: Dennis Lundberg
Patch applied in
[r1092500|http://svn.apache.org/viewvc?view=revisionrevision=1092500].
Thanks!
New 2.7-SNAPSHOT deployed. Please test it.
supressionsFileExpression does not work.
Key: MCHECKSTYLE-149
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-149
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Idcmp
Assignee: Dennis Lundberg
Fix For: 2.7
In DefaultCheckstyleExecutor.getOverridingProperties() there is the following:
{code:java}
if ( request.getSuppressionsFileExpression() != null )
{
String suppresionFile = request.getSuppressionsFileExpression();
if ( suppresionFile != null )
{
p.setProperty( request.getSuppressionsFileExpression(),
suppresionFile );
}
}
{code}
Note how supressionFile is being set to the *expression*, not the *file*.
This one line should read:
{code:java}
String suppresionFile = request.getSuppressionsLocation();
{code}
This bug is blocking the m2e-checkstyle plugin from supporting Maven-driven
suppression files.
--
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] Closed: (MCHECKSTYLE-141) Exception thrown when src/main/java directory does not exist
[ http://jira.codehaus.org/browse/MCHECKSTYLE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-141. --- Resolution: Duplicate Exception thrown when src/main/java directory does not exist Key: MCHECKSTYLE-141 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-141 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.5 Environment: maven 2.2.1 Reporter: Joachim Van der Auwera Attachments: checkstyle-src.patch An exception is thrown when the src directory does not exist. -- 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] Closed: (MCHECKSTYLE-143) /src directory is absent in multiproject, but plugin fails
[ http://jira.codehaus.org/browse/MCHECKSTYLE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-143. --- Resolution: Duplicate /src directory is absent in multiproject, but plugin fails -- Key: MCHECKSTYLE-143 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-143 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 2 Reporter: Yegor Bugayenko I have a multi-module project, which DOES'T have /src directory in a root project (and it's correct I suppose). When I'm running checkstyle plugin it fails because the directory is absent. I don't think it's correct to create an empty directory just for checkstyle. Would be nice to have a special configuration parameter to work around this problem. -- 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: (MCHECKSTYLE-144) If 'src/main/java' does not exist in a project then checkstyle skips the other source folders of the project
[ http://jira.codehaus.org/browse/MCHECKSTYLE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263611#action_263611 ] Dennis Lundberg commented on MCHECKSTYLE-144: - I have just applied 2 patches that could help solve this issue. Can you please try 2.7-SNAPSHOT and see if i works for you? If 'src/main/java' does not exist in a project then checkstyle skips the other source folders of the project Key: MCHECKSTYLE-144 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-144 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Reporter: Ulli Hafner I'm not sure whether this is related to MCHECKSTYLE-141. If I check a test-project that contains only a folder src/test/java but not a folder src/main/java (even thoud the includeTestDir option is set) then checkstyle ignores the whole project: [INFO] --- maven-checkstyle-plugin:2.5:checkstyle (default-cli) @ de.faktorlogik.core.tests --- [INFO] Source directory does not exist - skipping report. [INFO] -- 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: (MCHECKSTYLE-147) Upgrading from 2.4 to 2.6 causes failure during checkstyle configuration
[ http://jira.codehaus.org/browse/MCHECKSTYLE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263612#action_263612 ] Dennis Lundberg commented on MCHECKSTYLE-147: - Can you please try 2.7-SNAPSHOT. This might be related to MCHECKSTYLE-149. Upgrading from 2.4 to 2.6 causes failure during checkstyle configuration Key: MCHECKSTYLE-147 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-147 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.6 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_21 Java home: C:\jdk1.6.0_21-x64\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7 version: 6.1 arch: amd64 Family: windows Reporter: Steve Gorczyca Upgrading from plugin version 2.4 to 2.6 then trying to run mvn site, the build fails because it can't find our suppressions file, even though the debug information indicates that it is correctly found and the file is correctly extracted to target/checkstyle-suppressions.xml Relevant part of the build output: [INFO] Generating Project Plugins report. [DEBUG] maven-jxr-plugin: resolved to version 2.1 from repository central [DEBUG] maven-surefire-report-plugin: resolved to version 2.4.3 from repository central [DEBUG] Adding managed dependencies for org.apache.maven.plugins:maven-surefire- report-plugin [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.4.3 [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.4.3 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1 [DEBUG] Multipage report: 0 subreports [DEBUG] Velocimacro : added #link( href name ) : source = org/apache/maven/doxi a/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #banner( banner id ) : source = org/apache/maven/do xia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #links( links ) : source = org/apache/maven/doxia/s iterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #breadcrumbs( breadcrumbs ) : source = org/apache/m aven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #displayTree( display item ) : source = org/apache/ maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #menuItem( item ) : source = org/apache/maven/doxia /siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #mainMenu( menus ) : source = org/apache/maven/doxi a/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #copyright( ) : source = org/apache/maven/doxia/sit erenderer/resources/default-site.vm [DEBUG] Velocimacro : added #publishDate( position publishDate version ) : sour ce = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #poweredByLogo( poweredBy ) : source = org/apache/m aven/doxia/siterenderer/resources/default-site.vm [DEBUG] Generating C:\work\trunk\wordnet-dictionary\target\site\checkstyle.html [INFO] Generating Checkstyle report. [WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin. [DEBUG] executeCheckstyle start headerLocation : LICENSE.txt [DEBUG] The resource 'build-tools/checkstyle_suppressions.xml' was not found wit h resourceLoader org.codehaus.plexus.resource.loader.FileResourceLoader. [DEBUG] The resource 'build-tools/checkstyle_suppressions.xml' was not found wit h resourceLoader org.codehaus.plexus.resource.loader.JarResourceLoader. [DEBUG] The resource 'build-tools/checkstyle_suppressions.xml' was found as jar:
[jira] Commented: (MCHECKSTYLE-154) With option includeTestSourceDirectory supressions will be ignored for testsources.
[ http://jira.codehaus.org/browse/MCHECKSTYLE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263613#action_263613 ] Dennis Lundberg commented on MCHECKSTYLE-154: - Can you please try with the latest version 2.6. With option includeTestSourceDirectory supressions will be ignored for testsources. - Key: MCHECKSTYLE-154 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-154 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Michael Nitschke We have set up a mulit pom maven project with checkstyle and suppressions. For the source run all supressions (some whitespace) will be followed. For the testsources the supressions will be ignored, resulting in ~6000 wrong false in a single subproject. -- 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-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263615#action_263615 ] Dennis Lundberg commented on MNG-3139: -- Please try using Maven Site Plugin 2.2. Might be related to DOXIASITETOOLS-38. The skin does not exist: Unable to determine the release version Key: MNG-3139 URL: http://jira.codehaus.org/browse/MNG-3139 Project: Maven 2 3 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.0.7 Reporter: eyal david Assignee: John Casey Fix For: 2.0.11, 2.1.0, 3.0-alpha-3 Attachments: cached-metadata.patch, mvn_site_debug.zip hi I have problem generating site when im using the command mvn site it performs all stagegs and when it came to site generation the message is shown : The skin does not exist: Unable to determine the release version Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven -default-skin \ -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file org.apache.maven.skins:maven-default-skin:jar:RELEASE do u have an idea what is the problem ? p.s the jar is registered in my local repository and in the remote repository thank u -- 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: (MCHECKSTYLE-157) Update to post-5.0 checkstyle when the plugin is available
[ http://jira.codehaus.org/browse/MCHECKSTYLE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263618#action_263618 ] Dennis Lundberg commented on MCHECKSTYLE-157: - Benson, did you mean to file this issue for the Maven Checkstyle Plugin, or was in intended for the Cobertura Maven Plugin? Update to post-5.0 checkstyle when the plugin is available -- Key: MCHECKSTYLE-157 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-157 Project: Maven 2.x Checkstyle Plugin Issue Type: Task Affects Versions: 2.4, 2.5 Reporter: Benson Margulies Once the maven-checkstyle-plugin releases a version with a newer checkstyle that 5.0, use it and fix the rules to stop exploding on @goal. -- 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: (MCHECKSTYLE-157) Update to post-5.0 checkstyle when the plugin is available
[ http://jira.codehaus.org/browse/MCHECKSTYLE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263626#action_263626 ] Benson Margulies commented on MCHECKSTYLE-157: -- Oh, dear. Indeed, I put it in the wrong place. Do you have access to move it? Update to post-5.0 checkstyle when the plugin is available -- Key: MCHECKSTYLE-157 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-157 Project: Maven 2.x Checkstyle Plugin Issue Type: Task Affects Versions: 2.4, 2.5 Reporter: Benson Margulies Once the maven-checkstyle-plugin releases a version with a newer checkstyle that 5.0, use it and fix the rules to stop exploding on @goal. -- 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
