[jira] Commented: (MWAR-215) class file JAR inconsistency (archiveClasses and attachClasses options)
[
http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206569#action_206569
]
Neeme Praks commented on MWAR-215:
--
I can rework the patch, I just need to know, what the behavior should be:
# by default turn on the consistent behavior (as the old behavior seems quite
broken to me) and the user can enable the old behavior with some flag (e.g.
legacyStyleClassesJar=true)
# by default leave the old behavior and the user can enable the new behavior
with some flag (e.g. consistentClassesJar=true)
I personally prefer the first approach, but you know better. Also, what should
be the configuration option name, to switch between the new and old behavior?
class file JAR inconsistency (archiveClasses and attachClasses options)
---
Key: MWAR-215
URL: http://jira.codehaus.org/browse/MWAR-215
Project: Maven 2.x WAR Plugin
Issue Type: Improvement
Affects Versions: 2.1-beta-1
Reporter: Neeme Praks
Attachments: maven-WAR-plugin-classes.patch
Copy-paste from
http://article.gmane.org/gmane.comp.jakarta.turbine.maven.devel/94789
{quote}
I have a couple of issues with the current WAR plugin and the way it
packages class files in JAR files (archiveClasses and attachClasses
configuration options), as these two options work independently of each
other:
* archiveClasses moves all class files (and related resources) from
classes directory to JAR file inside WEB-INF/lib directory
* attachClasses creates a new JAR file in target directory from same
set of files and attaches it to the Maven project with some qualifier
(by default it uses classes qualifier)
When we deploy artifacts to Maven repository, this results in two
different JAR files being deployed: one inside WAR and the other
separate from WAR.
Problems with this approach:
* two different JAR files with different MD5/SHA1 checksums.
* the naming convention for these two JAR files is different
These issues really start to snag you when you need to perform updates
after the initial deploy of the WAR. Consider the following scenario:
* development team hands WAR artifact over to deployment team for deployment
* development team needs to give an update to the webapp code (the
dependencies have not changed). One approach is to give the whole WAR
again, but a more reasonable approach would be to give only JAR file, as
it contains all the changes and dependent JARs have not changed.
Whole-WAR-approach becomes especially problematic, when the update needs
to be uploaded over slow network links and you are in a hurry. However,
giving only JAR file presents us with some problems:
# there is no easy way to check the currently deployed webapp JAR
version, as the checksum of the embedded JAR file does not match any
other JAR file in the Maven repository.
# as the naming convention differs, it is going to confuse the
deployment team
Solution to this mess? Unify the way archiveClasses and
attachClasses functionalities work, so they would operate on the same
JAR file. The way this would work:
* if archiveClasses option is specified, it moves all class files to
JAR file inside WEB-INF/lib directory (same as before). It would use the
same naming convention as regular Maven JAR artifacts, with some qualifier.
* if attachClasses option is specified, it attaches that same JAR
file (as created in previous point) to the Maven project.
* if attachClasses is specified, but no archiveClasses - nothing
happens. Or maybe we should then implicitly turn on also the
archiveClasses option?
This has some implications for backwards compatibility:
* naming convention of the embedded JAR file is changed
* the attached JAR file is no longer created in the target
directory, next to the WAR file (it is now attached directly from
WEB-INF/lib directory)
{quote}
--
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: (SUREFIRE-596) Junit test output is broken with junit4-7+
[ http://jira.codehaus.org/browse/SUREFIRE-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206571#action_206571 ] Kristian Rosenvold commented on SUREFIRE-596: - That's the svn integration in my IDE messing up, thanks for explaining Brett - I was honestly stumped and figured it was about choosing the right options for patch. I'm obviously not any good copy-paste coding; need to put that on my CV ;) Junit test output is broken with junit4-7+ --- Key: SUREFIRE-596 URL: http://jira.codehaus.org/browse/SUREFIRE-596 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.5 Environment: junit 4.7 Reporter: Kristian Rosenvold Assignee: Stephen Connolly Fix For: 2.5 Attachments: junit1.diff, junit2.diff, junit2.zip There is a bug in the log output for the junit4.7+ provider, where it just says Result null instead of outputting the proper surefire output. Additionally, the concurrent junit provider should really only be used when the user has requested some concurrent execution model in the configuration. Workaround at the moment is one of the following: A) Use surefire-2.4.3 until this is fixed B) Downgrade to junit 4.6 until this is fixed C) ignore the problem. This may be possible, but some CI systems also parse the output so it may break the build. The enclosed patch fixes both problems on svn trunk of surefire, and also includes updated integration tests. -- 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: (MWAR-178) war plugin documentation and probably implementation is unaware of javaee 5
[ http://jira.codehaus.org/browse/MWAR-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206573#action_206573 ] Stephane Nicoll commented on MWAR-178: -- isn't it a candidate for the ear plugin instead? How would you resolve this issue? war plugin documentation and probably implementation is unaware of javaee 5 --- Key: MWAR-178 URL: http://jira.codehaus.org/browse/MWAR-178 Project: Maven 2.x WAR Plugin Issue Type: New Feature Reporter: David Jencks The example I'm aware of: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html talks about using the war's manifest.mf classpath to include jars in the ear in the war module's classloader. In ee5, there's a ear lib directory: everything in that is automatically included in the ear level classloader, which is certainly available to every war, most likely by being a parent classloader to the war classloader. One consequence of this is that using the manifest classpath in a 1.4 container will likely result in each war getting separate copies of the lib jar classes whereas the ee5 lib directory will result in shared classes. -- 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: (MWAR-216) Changes in dependencies aren't reflected in target/modulename/WEB-INF/lib
[ http://jira.codehaus.org/browse/MWAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206574#action_206574 ] Stephane Nicoll commented on MWAR-216: -- Agreed. Once the metadata about libraries will be fixed, this is trivial to implement. Changes in dependencies aren't reflected in target/modulename/WEB-INF/lib - Key: MWAR-216 URL: http://jira.codehaus.org/browse/MWAR-216 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Kohsuke Kawaguchi The war plugin copies module dependencies into target/modulename/WEB-INF/lib, but it doesn't remove files that don't belong there. So if I change POM to remove a dependency or change a version, you still see the old jar in WEB-INF/lib until you do a clean rebuild. As this often results in a rather painful bug (where you get two different versions of the same library in WEB-INF/lib, which makes the program break in some systems but not others), it'd be highly desirable if the plugin is smart enough to delete files that shouldn't be there. -- 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: (MNG-4528) [regression] mvn deploy ignores proxy settings
[regression] mvn deploy ignores proxy settings
--
Key: MNG-4528
URL: http://jira.codehaus.org/browse/MNG-4528
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Affects Versions: 3.0-alpha-6
Environment: Vista, maven 3.0-alpha-6
Reporter: Fred Bricon
Running mvn deploy fails when behind a proxy (connection refused) in maven
3.0-alpha6, even though the proxy settings have been configured in settings.xml.
Deploying the same artifact succeeds when using maven 2.0.10 - 2.2.1, using
the same settings.xml.
As a workaround, I had to add pass the proxy parameters in the command line:
{noformat}
mvn deploy -Dhttp.proxyHost=proxy.ip -Dhttp.proxyPort=8080
-Dhttp.proxyUser=username -Dhttp.proxyPassword=password
{noformat}
regards,
Fred Bricon
--
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: (ARCHETYPE-281) Update to Velocity 1.5
Update to Velocity 1.5 -- Key: ARCHETYPE-281 URL: http://jira.codehaus.org/browse/ARCHETYPE-281 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Affects Versions: 2.0-alpha-4 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.5.0_17 Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Khaled LABIDI Priority: Minor Hi, I'm using version 2.0-alpha-4 of archetype-plugin and noticed that some velocity features are not supported (leading to parser erreor) particularily the HashMap declaration within a template (Actually, my POM includes some VTL statements) This is because the archetype-plugin 2.0-apha-4 depends on archetype-common 2.0-alpha-4 wich depends on plexus-velocity 1.1.3 which depends on velocity 1.4 and the later become quite old (current version is 1.6) The plexus-velocity version 1.1.8 has been released since Nov.2009 and it updated to use velocity 1.5. Is upgrading archetype-common dependency on plexus-velocity (from 1.1.3 to 1.1.8) planned for archetype-plugin 2.0-apha-5 ? By the way, when does the archetype-plugin 2.0-apha-5 release planned ? Best regards, K.L -- 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: (MERCURY-133) LocalRepositoryReaderM2 mistakes classifier as part of version
[ http://jira.codehaus.org/browse/MERCURY-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206589#action_206589 ] Hanno Braun commented on MERCURY-133: - Anyone still alive here? Will this issue be addressed and will my fix be committed? LocalRepositoryReaderM2 mistakes classifier as part of version -- Key: MERCURY-133 URL: http://jira.codehaus.org/browse/MERCURY-133 Project: Mercury Issue Type: Bug Components: Repository Affects Versions: 1.0-alpha-6 Reporter: Hanno Braun Assignee: Oleg Gusakov Attachments: LocalRepositoryReaderM2.diff LocalRepositoryReaderM2 mistakes the classifier as a part of the version and thus fails to read artifacts that use a classifier. I've tracked this problem down to the method LocalRepositoryReaderM2.findLatestSnapshot and created a fix (see attachment). The attached patch fixes the problem for me and I didn't notice any other side effects. However, I haven't tested it thoroughly with other use cases. -- 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: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Shipilev updated MEAR-85: - Attachment: MEAR-85-ashipilev-TESTS.patch MEAR-85-ashipilev-TESTS.patch Integration tests for this issue. Breaks without the patch. ejb-client dependencies should be placed in defaultLibBundleDir --- Key: MEAR-85 URL: http://jira.codehaus.org/browse/MEAR-85 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: James Olsen Assignee: Stephane Nicoll Priority: Minor Fix For: 2.5 Attachments: MEAR-85-ashipilev-TESTS.patch ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. A workaround is to add an ejbClientModule entry to override the bundleDir: modules ejbClientModule groupId.../groupId artifactId.../artifactId bundleDirlib/bundleDir /ejbClientModule /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] Updated: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Shipilev updated MEAR-85: - Attachment: MEAR-85-ashipilev-v1.patch MEAR-85-ashipilev-v1.patch Proposed solution, fixes new integration tests. ejb-client dependencies should be placed in defaultLibBundleDir --- Key: MEAR-85 URL: http://jira.codehaus.org/browse/MEAR-85 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: James Olsen Assignee: Stephane Nicoll Priority: Minor Fix For: 2.5 Attachments: MEAR-85-ashipilev-TESTS.patch, MEAR-85-ashipilev-v1.patch ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. A workaround is to add an ejbClientModule entry to override the bundleDir: modules ejbClientModule groupId.../groupId artifactId.../artifactId bundleDirlib/bundleDir /ejbClientModule /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: (MPIR-182) Make order of reports shown in Project Reports configurable
Make order of reports shown in Project Reports configurable
-
Key: MPIR-182
URL: http://jira.codehaus.org/browse/MPIR-182
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: Andreas Sewe
Priority: Minor
As far as I can tell the plugin's reports are presented in alphabetical order
in the Project Reports menu. While having About come first seems natural,
some of the other menu items (in particular, Source Repository) are placed
less than optimally. Why not make this configurable, e.g., by making the order
significant in which the {{report}} elements occur in the plugin's
configuration?
--
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-464) assembly descriptor id should be mandatory
assembly descriptor id should be mandatory
--
Key: MASSEMBLY-464
URL: http://jira.codehaus.org/browse/MASSEMBLY-464
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Reporter: Juven Xu
I can create assembly using descriptor like this:
{code:xml}
assembly
id/id
formats
formatzip/format
/formats
fileSets
fileSet
directorysrc/main/java/directory
/fileSet
/fileSets
/assembly
{code}
the file created does not have a classifier, and it's not the main artifact
either, so it's impossible to locate it using maven coordinates.
the id should be mandatory so there will always a classifier.
--
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-3328) Allow multiple profile activation properties.
[
http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206613#action_206613
]
gary fry commented on MNG-3328:
---
Would be great if you could marry OS and Properties as an AND condition.
For example,
activation
os
familyunix/family
/os
property
namemy-prop-2/name
valueanother-value/value
/property
/activation
Currently, Maven2 looks for the first condition that is true, and the profile
is activated. However, this is not very useful if the build needs to run in
both Windows and Unix environments and you need to do something slightly
different on each OS, where activation is also determined by a property being
set at buld time
Allow multiple profile activation properties.
-
Key: MNG-3328
URL: http://jira.codehaus.org/browse/MNG-3328
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.0.8
Reporter: Paul Gier
Fix For: 3.x
The pom model should be changed to allow multiple properties to activate a
profile. So the profile activation section could look something like this:
{code:xml}
activation
properties
my-prop-1some-value/my-prop-1
my-prop-2another-value/my-prop-2
/properties
/activation
{code}
This would provide more flexibility in profile activation.
--
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: (WAGON-298) unable to use basic auth using wagon-http
unable to use basic auth using wagon-http - Key: WAGON-298 URL: http://jira.codehaus.org/browse/WAGON-298 Project: Maven Wagon Issue Type: Bug Components: wagon-http, wagon-http-lightweight Reporter: Tim Harsch Unfortunately this bug has long been worked around for me. I no longer have the environment up to test this issue any further. The entire problem is described in full at: http://stackoverflow.com/questions/1280747/accessing-an-artifactory-maven-repo-that-requires-basic-auth Hopefully you all will have the environment up that could allow you to reproduce this potential bug easily. -- 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] Moved: (WAGON-299) tgz artifacts ungzipped on download
[ http://jira.codehaus.org/browse/WAGON-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3233 to WAGON-299: - Fix Version/s: (was: 2.2.x) 1.0 Affects Version/s: (was: 2.0.7) (was: 2.0.6) (was: 2.0.5) Key: WAGON-299 (was: MNG-3233) Project: Maven Wagon (was: Maven 2 3) tgz artifacts ungzipped on download --- Key: WAGON-299 URL: http://jira.codehaus.org/browse/WAGON-299 Project: Maven Wagon Issue Type: Bug Reporter: Steinar Bang Fix For: 1.0 If a tgz artifact (in our case DLLs and shared libs for different platforms, that accompany a JNI wrapper Java library), is dowloaded from a maven repository on an HTTP server that sets the HTTP header content-encoding: gzip on the download, the downloaded file will be ungzipped before storing it in the local maven repository, still with the extension .tgz, and dependency:unpack will fail when attempting to unpack the library. This has been an upgrade blocker and have stuck us on version 2.0.4, which is getting increasingly hard, so from our POV it's at least priority Major. We first encountered this problem on 2.0.5, and I unintentionally verified today that it's present in 2.0.7. I'm guessing it is in maven itself rather than in the maven-dependency-plugin, which is where we see it, because the same version of the maven-dependency-plugin works on 2.0.4, and fails on later mavens. -- 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: (MNG-4099) Password encryption CLI switches should prompt for password if missing
[ http://jira.codehaus.org/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4099: -- Fix Version/s: (was: 2.2.x) 3.x Password encryption CLI switches should prompt for password if missing -- Key: MNG-4099 URL: http://jira.codehaus.org/browse/MNG-4099 Project: Maven 2 3 Issue Type: Improvement Components: Command Line Affects Versions: 2.1.0 Reporter: Mark Hobson Priority: Trivial Fix For: 3.x The -emp and -ep CLI switches should prompt for a password if the user omits it. This would help to avoid having to escape shell characters in strong passwords. Note that the docs mention that these switches prompt for a password when they do not: http://maven.apache.org/guides/mini/guide-encryption.html -- 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: (MNG-3078) artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository
[ http://jira.codehaus.org/browse/MNG-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3078. - Resolution: Duplicate Fix Version/s: (was: 2.2.x) artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository - Key: MNG-3078 URL: http://jira.codehaus.org/browse/MNG-3078 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories, Dependencies Affects Versions: 2.0.6, 2.0.7 Reporter: Peter Lynch Priority: Critical Using mvn deploy:deploy-file you can successfully upload a 'tar.gz' artifact to a repository. Example without classifier: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat -Dversion=6.0.13 -Dpackaging=tar.gz -DrepositoryId=repo-central -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ -Dfile=apache-tomcat-6.0.13.tar.gz Example with classifier mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat -Dversion=6.0.13 -Dpackaging=tar.gz -Dclassifier=bin -DrepositoryId=repo-central -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ -Dfile=apache-tomcat-6.0.13.tar.gz Once uploaded define a dependency in your pom to it. Example without classifier project packagingpom/packaging ... dependencies ... dependency groupIdorg.apache.tomcat/groupId artifactIdapache-tomcat/artifactId version6.0.13/version typetar.gz/type optionaltrue/optional /dependency ... /dependencies ... /project Example with classifier project packagingpom/packaging ... dependencies ... dependency groupIdorg.apache.tomcat/groupId artifactIdapache-tomcat/artifactId version6.0.13/version typetar.gz/type classifierbin/classifier optionaltrue/optional /dependency ... /dependencies ... /project Now to reproduce the problem you could either do mvn dependency:resolve or mvn assembly:assembly (if the maven assembly plugin is configured with a dependency set that unpacks this dependency for example) The reason I think this is a core bug and not an maven assembly plugin or maven-dependency-plugin bug is because the problem happens in both of these independent plugins. When you run 'mvn dependency:resolve' you'll see that the dependency appears downloaded but then the build fails with : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat \ -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat \ -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.example:core:pom:1.0.0-A1-SNAPSHOT 2) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 -- 1 required artifact is missing. ... ... and even stranger here is the log which proves the dependency was found in the repo and downloaded, but NOT saved to local repository. ... [DEBUG] Trying repository repo-central Downloading: http://repo.example.com:4000/maven-repos/repo-central/org/apache/tomcat/apache-tomcat/6.0.13/apache-tomcat-6.0.13-bin.tar.gz 5826K downloaded [DEBUG] Unable to get resource 'org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13' from repository repo-central (http://repo.example.com:4000/maven-repos/repo-central) [DEBUG] Unable to download the artifact from any repository ..and YOU MAY GET FOOLED into thinking all is well. mvn deploy:deploy-file also installs the same artifact into your local repo. So if you follow above steps and don't get an error it is because the deploy-file goal installed it in your local repo. However when someone else tries to use your project they will get above error. So, first delete from your local repo. example: rm -rf ~/.m2/repository/org/apache/tomcat/apache-tomcat and then try to execute mvn dependency:resolve and it should fail as described. ...and finally I'll mention that doing the same thing with a 'zip' type/packaging there is NO PROBLEM. Ultimately when using the
[jira] Updated: (MNG-3124) Inherite mailing lists from parent POM
[ http://jira.codehaus.org/browse/MNG-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3124: -- Fix Version/s: (was: 2.2.x) 3.1 Inherite mailing lists from parent POM -- Key: MNG-3124 URL: http://jira.codehaus.org/browse/MNG-3124 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Vincent Siveton Fix For: 3.1 Mailing lists report should have an property to get them from parent POM and concatenate in child. Inheritance should be the default option -- 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: (MNG-3148) Write at the debug output the name of the used settings.xml and the path of the repository
[ http://jira.codehaus.org/browse/MNG-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3148. - Resolution: Duplicate Fix Version/s: (was: 2.2.x) already done in at least 3.0-alpha-5 Write at the debug output the name of the used settings.xml and the path of the repository -- Key: MNG-3148 URL: http://jira.codehaus.org/browse/MNG-3148 Project: Maven 2 3 Issue Type: Improvement Components: Settings Affects Versions: 2.0.7 Reporter: Daniel Clemente Priority: Minor When used with the -X option (debug), Maven should also say at least: - which configuration file (settings.xml) it's trying to use, or if it hasn't found anyone - the path of the repository which will be used That's important since a lot of problems occur when you think that you (and Eclipse) are using a repository but Maven is saving all new things in other place. I experienced these problems after a move of the repository and the settings.xml and it was very hard to discover that Maven wasn't really using my ~/.m2/settings.xml -- 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: (MNG-3563) Content of a property ending with .url gets overwritten with the content of url/url from the pom.xml
[
http://jira.codehaus.org/browse/MNG-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3563.
-
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.2.x)
cannot reproduce as described using Maven 2.0.9. Please attach a test project
if this is still a problem in 2.2.1 or 3.0-alpha-X
Content of a property ending with .url gets overwritten with the content of
url/url from the pom.xml
Key: MNG-3563
URL: http://jira.codehaus.org/browse/MNG-3563
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Linux
Reporter: Stephan Kleine
If one creates a property e.g. named jdbc.url in a parent pom.xml and then
refers to that property via ${jdbc.url} in a resource file of a subproject
whose pom.xml is derived from the one that declares the jdbc.url property the
content is overwritten with the content of the url tag during the filtering
step.
E.g.
com.example.project contains:
jdbc.urljdbc:mysql://localhost:3306/TestDB/jdbc.url
in its pom.xml
com.example.subproject is derived from com.example.project and contains
url=${jdbc.url}
in some db setup file and
urlhttp://maven.apache.org/url
in its pom.xml
The resulting content, after the filtering step, will be
url=http://maven.apache.org; instead of
url=jdbc:mysql://localhost:3306/TestDB.
--
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] Issue Comment Edited: (MNG-3328) Allow multiple profile activation properties.
[
http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206613#action_206613
]
gary fry edited comment on MNG-3328 at 1/12/10 10:34 AM:
-
Would be great if you could marry OS and Properties as an AND condition.
For example,
{code:xml}
activation
os
familyunix/family
/os
property
namemy-prop-2/name
valueanother-value/value
/property
/activation
{code}
Currently, Maven2 looks for the first condition that is true, and the profile
is activated. However, this is not very useful if the build needs to run in
both Windows and Unix environments and you need to do something slightly
different on each OS, where activation is also determined by a property being
set at buld time
was (Author: gary.fry):
Would be great if you could marry OS and Properties as an AND condition.
For example,
activation
os
familyunix/family
/os
property
namemy-prop-2/name
valueanother-value/value
/property
/activation
Currently, Maven2 looks for the first condition that is true, and the profile
is activated. However, this is not very useful if the build needs to run in
both Windows and Unix environments and you need to do something slightly
different on each OS, where activation is also determined by a property being
set at buld time
Allow multiple profile activation properties.
-
Key: MNG-3328
URL: http://jira.codehaus.org/browse/MNG-3328
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.0.8
Reporter: Paul Gier
Fix For: 3.x
The pom model should be changed to allow multiple properties to activate a
profile. So the profile activation section could look something like this:
{code:xml}
activation
properties
my-prop-1some-value/my-prop-1
my-prop-2another-value/my-prop-2
/properties
/activation
{code}
This would provide more flexibility in profile activation.
--
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: (MNG-3542) Filtering test resources replaces the wrong value
[
http://jira.codehaus.org/browse/MNG-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3542.
-
Resolution: Fixed
I was able to reproduce this test case, however it is fixed in 2.2.1
Filtering test resources replaces the wrong value
-
Key: MNG-3542
URL: http://jira.codehaus.org/browse/MNG-3542
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Windows XP and Linux
Tried with Maven 2.0.7 upwards
Java 1.5
Reporter: Robert Bracewell
Fix For: 2.2.x
Noticed an oddity with filtering in that it is replacing the wrong properties
under certain conditions. The key thing to note in below mockup is the url
property in pom.xml
Contents of pom.xml:
?xml version=1.0 encoding=UTF-8?
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/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
urlhttp://THIS_IS_A_URL_TO_HIGHLIGHT_THE_BUG/url
groupIdcom.maven.bugs/groupId
artifactIdbug1/artifactId
version1/version
packagingjar/packaging
nameMaven Bug 1/name
build
testResources
testResource
directorysrc/test/resources/directory
filteringtrue/filtering
/testResource
/testResources
/build
/project
In the src/test/resources directory is a file that contains:
?xml version=1.0 encoding=UTF-8?
filtering
property name=url
value${test.url}/value
/property
/filtering
When running mvn clean process-test-resources the file generated in
target/test-classes now contains:
?xml version=1.0 encoding=UTF-8?
filtering
property name=url
valuehttp://THIS_IS_A_URL_TO_HIGHLIGHT_THE_BUG/value
/property
/filtering
This is not what I expect as I don't have a property for test.url defined
--
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] Reopened: (MNG-3542) Filtering test resources replaces the wrong value
[
http://jira.codehaus.org/browse/MNG-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter reopened MNG-3542:
---
Filtering test resources replaces the wrong value
-
Key: MNG-3542
URL: http://jira.codehaus.org/browse/MNG-3542
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Windows XP and Linux
Tried with Maven 2.0.7 upwards
Java 1.5
Reporter: Robert Bracewell
Noticed an oddity with filtering in that it is replacing the wrong properties
under certain conditions. The key thing to note in below mockup is the url
property in pom.xml
Contents of pom.xml:
?xml version=1.0 encoding=UTF-8?
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/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
urlhttp://THIS_IS_A_URL_TO_HIGHLIGHT_THE_BUG/url
groupIdcom.maven.bugs/groupId
artifactIdbug1/artifactId
version1/version
packagingjar/packaging
nameMaven Bug 1/name
build
testResources
testResource
directorysrc/test/resources/directory
filteringtrue/filtering
/testResource
/testResources
/build
/project
In the src/test/resources directory is a file that contains:
?xml version=1.0 encoding=UTF-8?
filtering
property name=url
value${test.url}/value
/property
/filtering
When running mvn clean process-test-resources the file generated in
target/test-classes now contains:
?xml version=1.0 encoding=UTF-8?
filtering
property name=url
valuehttp://THIS_IS_A_URL_TO_HIGHLIGHT_THE_BUG/value
/property
/filtering
This is not what I expect as I don't have a property for test.url defined
--
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: (MNG-3542) Filtering test resources replaces the wrong value
[
http://jira.codehaus.org/browse/MNG-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3542.
-
Resolution: Duplicate
Fix Version/s: (was: 2.2.x)
Assignee: Brett Porter
Filtering test resources replaces the wrong value
-
Key: MNG-3542
URL: http://jira.codehaus.org/browse/MNG-3542
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Windows XP and Linux
Tried with Maven 2.0.7 upwards
Java 1.5
Reporter: Robert Bracewell
Assignee: Brett Porter
Noticed an oddity with filtering in that it is replacing the wrong properties
under certain conditions. The key thing to note in below mockup is the url
property in pom.xml
Contents of pom.xml:
?xml version=1.0 encoding=UTF-8?
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/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
urlhttp://THIS_IS_A_URL_TO_HIGHLIGHT_THE_BUG/url
groupIdcom.maven.bugs/groupId
artifactIdbug1/artifactId
version1/version
packagingjar/packaging
nameMaven Bug 1/name
build
testResources
testResource
directorysrc/test/resources/directory
filteringtrue/filtering
/testResource
/testResources
/build
/project
In the src/test/resources directory is a file that contains:
?xml version=1.0 encoding=UTF-8?
filtering
property name=url
value${test.url}/value
/property
/filtering
When running mvn clean process-test-resources the file generated in
target/test-classes now contains:
?xml version=1.0 encoding=UTF-8?
filtering
property name=url
valuehttp://THIS_IS_A_URL_TO_HIGHLIGHT_THE_BUG/value
/property
/filtering
This is not what I expect as I don't have a property for test.url defined
--
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: (MNG-3587) Strange warnings while building a project
[ http://jira.codehaus.org/browse/MNG-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3587. - Resolution: Won't Fix Fix Version/s: (was: 2.2.x) was reduced to DEBUG level in later versions, and no longer exists in Maven 3.0 Strange warnings while building a project - Key: MNG-3587 URL: http://jira.codehaus.org/browse/MNG-3587 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Seva Popov Attachments: maven-warning.txt We've switched from Maven 2.0.7 to Maven 2.0.9 and started observing strange warnings happening in different contexts in our builds: Example: [WARNING] Attempting to build MavenProject instance for Artifact (com.tvworks.tva.maven.plugins:maven-license-plugin:3.3-20080508.052638-16) of type: maven-plugin; constructing POM artifact instead. [WARNING] Attempting to build MavenProject instance for Artifact (com.tvworks.tva.common:tva-common-logging:3.3-20080513.211757-62) of type: jar; constructing POM artifact instead. More details in this thread: http://www.mail-archive.com/us...@maven.apache.org/msg85248.html -- 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: (MNG-3356) Multiple -Dkey=value command line options not handled correctly
[ http://jira.codehaus.org/browse/MNG-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3356. - Resolution: Won't Fix Fix Version/s: (was: 2.2.x) this is exactly why we used commons-cli 1.0 instead of upgrading. Multiple -Dkey=value command line options not handled correctly --- Key: MNG-3356 URL: http://jira.codehaus.org/browse/MNG-3356 Project: Maven 2 3 Issue Type: Bug Components: Command Line Affects Versions: 2.0.8 Reporter: Christian Koelle Priority: Critical Attachments: command-line.patch After upgrading to 2.0.8 on Debian the handling of multiple (more than one) -Dkey=value cli options fail, i.e. something like: mvn plugin:goal -Dkey1=value1 -Dkey2=value2 fails with: Invalid task 'key2=value2': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion: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] Closed: (MNG-3768) [regression] Class folder system dependency doesn't work anymore
[
http://jira.codehaus.org/browse/MNG-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3768.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.2.x)
since there's no response and no votes, and the length of time this release has
been out there - I think we should stick with the behaviour of MNG-3288
[regression] Class folder system dependency doesn't work anymore
Key: MNG-3768
URL: http://jira.codehaus.org/browse/MNG-3768
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.1.0-M1
Environment: Any
Reporter: Francois Loison
Attachments: mng-3288.zip, MNG-3768.patch.txt, mng-3768.zip,
patch-MNG-3768-distribution.txt
My project use system dependencies pointing to class folders.
dependency
groupIdclass-folder/groupId
artifactIdclass-folder/artifactId
versionN/version
scopesystem/scope
systemPathC:/appli/classes/systemPath
/dependency
Such class folders dependencies worked fine with maven 2.0.7
They are needed by my project as it relies on a legacy application not
packaged into a jar file.
Root cause is located in file DefaultArtifactResolver.java:
if ( !systemFile.isFile() )
{
throw new ArtifactNotFoundException( System artifact: +
artifact + is not a file: + systemFile,
artifact );
}
--
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: (MGPG-19) Site descriptor does not get signed
Site descriptor does not get signed --- Key: MGPG-19 URL: http://jira.codehaus.org/browse/MGPG-19 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Reporter: Stephen Connolly Priority: Blocker When the site descriptor is an attached artifact, the GPG signature is not generated. Steps to reproduce: svn co https://svn.apache.org/repos/asf/maven/surefire/tags/surefire-...@898285 surefire-2.5 cd surefire-2.5 mvn site:attach-descriptor gpg:sign -Papache-release -N ls target/*.asc if there is a surefire-2.5-site.xml.asc then this bug is fixed. -- 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: (MNG-3612) property in settings.xml not interpolated when resolving parent POM from remote repository
[
http://jira.codehaus.org/browse/MNG-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3612:
--
Fix Version/s: (was: 2.2.x)
2.2.2
will assess if this is fixed by the related issue, fixable with it, or not
fixable for 2.2.2 (Based on the evaluation of the fix for the related issue)
property in settings.xml not interpolated when resolving parent POM from
remote repository
--
Key: MNG-3612
URL: http://jira.codehaus.org/browse/MNG-3612
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.9
Environment: Java 1.5.0_11, Windows XP
Reporter: Pat Podenski
Fix For: 2.2.2
Attachments: parent-and-child.zip, pom.xml, pom.xml, settings.xml
The objective was to use a property in the settings.xml within a profile.
This property represents the remote repository host/port number. This is so
that multiple entries of the host/port in the settings.xml profiles do not
need to be edited when the host/port value changes.
When working in a project whose parent POM is not installed in the local
repository, download of the parent POM from the remote repository fails. If
the host/port literal value is substituted in the repository element
contained in the settings.xml profile, the download succeeds.
If the parent POM is installed in the local repository resolution succeeds
(of course we don't need the remote repository in this case unless trying to
update the SNAPSHOT).
Attached example files.
1 - settings.xml file used in ~/.m2/
2 - pom.xml for base-pom
3 - pom.xml for child
To reproduce this problem:
1) deploy parent POM to remote repository (I use Artifactory which has an
upload utility, so I didn't need to install parent POM in the local
repository)
2) verify that parent POM is not in the local repository
3) try a 'mvn clean' or similar command in the child project - this operation
fails (see below)
4) If the literal host/port value is put into the settings.xml repository
element instead of ${repo-host}, the operation will succeed
[INFO] Scanning for projects...
[INFO] snapshot com.foo:base-pom:1-SNAPSHOT: checking for updates from central
[WARNING] repository metadata for: 'snapshot com.foo:base-pom:1-SNAPSHOT'
could not be retrieved
from repository: central due to an error: Error transferring file
[INFO] Repository 'central' will be blacklisted
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: com.foo
ArtifactId: base-pom
Version: 1-SNAPSHOT
Reason: Unable to download the artifact from any repository
com.foo:base-pom:pom:1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
com.foo:base-pom for project:
com.bar:child:jar:0.0.1-SNAPSHOT for project com.bar:child:jar:0.0.1-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find
parent: com.foo:base-pom f
or project: com.bar:child:jar:0.0.1-SNAPSHOT for project
com.bar:child:jar:0.0.1-SNAPSHOT
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBu
ilder.java:1370)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuil
der.java:821)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMa
venProjectBuilder.java:506)
at
[jira] Updated: (MNG-3168) Correct error message when project descriptor not found
[ http://jira.codehaus.org/browse/MNG-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3168: -- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 still a problem in 3.0-alpha-6 Correct error message when project descriptor not found --- Key: MNG-3168 URL: http://jira.codehaus.org/browse/MNG-3168 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build Reporter: Chris Eldredge Fix For: 3.0-alpha-7 When using the -f switch and passing the name of a file which does not exist, Maven complains about pom.xml, not the alternate file name. For example, the command: mvn -f foo.xml install produces this error message: Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one. This error message is confusing and incorrect. Maven should instead report that the file foo.xml could not be loaded. -- 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: (MNG-3646) project's output directory cannot be set to absolute path
[
http://jira.codehaus.org/browse/MNG-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3646.
-
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.2.x)
this works for me in 2.2.1
project's output directory cannot be set to absolute path
-
Key: MNG-3646
URL: http://jira.codehaus.org/browse/MNG-3646
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.8
Reporter: Ittay Dror
I want to be able to set the output (target) directory to some absolute path
outside of the source tree. What I'm trying to do is set builddirectory
to ${output}/${project.artifactId}/${project.groupId}, where 'output' is
passed from the command line.
Looking at the 2.0.8 code, this is what happens:
* DefaultMavenProjectBuilder.buildInternal calls
pathTranslator.alignToBaseDirectory( project.getModel(),
projectDescriptor.getParentFile() );
* DefaultPathTranslagor.alignToBaseDirectory calles build.setDirectory,
build.setSourceDirectory and build.setTestSourceDirectory all with calling
the method alignToBaseDirectory(String, File) where the string is the current
value of the above and File is the base directory
* alignToBaseDirectory(String, File) calls requiresBaseDirectoryAlignment
with the string
* requiresBaseDirectoryAlignment constructs a File on top of the string and
then calls File.isAbsolute to find if the path is absolute
* since a path in the form of ${something} is not considered by File to be
absolute, alignToBaseDirectory adds basedir to the path.
So the final result is that passing -Doutput=/tmp results in the output
directory being set to something like
/home/ittayd/dev/tmp/com.company/artifact which is not what I intended.
I can go around this in linux by using
'/${output}/${project.artifactId}/${project.groupId}', but this won't work in
windows (for two reasons: 1. '/' is not interpreted as a path separator (in
Win32FileSystem) and 2. even if it did, it will not allow setting output to
'D:\TEMP')
--
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: (MNG-3689) Dependency excludes applies to subsequent dependencies
[ http://jira.codehaus.org/browse/MNG-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3689: -- Fix Version/s: (was: 2.2.x) 3.x Still an issue in trunk Dependency excludes applies to subsequent dependencies -- Key: MNG-3689 URL: http://jira.codehaus.org/browse/MNG-3689 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.7, 2.0.8, 2.0.9 Environment: WinXP - Sun JDK-1.5.0_15 Reporter: Paul Taylor Fix For: 3.x Dependency exclusions seem to be in-correctly scoped and so are applying to subsequent dependencies at the same level. This results in dependencies being 'removed' when new dependencies are 'added'. The issue is apparent in the pom below which use spring-ws-core and spring-core, which both use the commons-logging-1.1. Commons-logging 1.1 erroneously includes servlet-api - a fact which spring-ws-core attempts to resolve with exclusions. a pom which ''only'' has spring-core as a dependency pulls in servlet-api. the addition of spring-ws-core has the effect of 'removing' commons-logging. This behaviour occurs under maven 2.0.8. Under maven 2.0.9 it is 'dependency order dependant' - swapping the pair of spring-core and spring-ws-core highlights or hides the erroneous behaviour. ?xml version=1.0 encoding=UTF-8? 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIda.b.c.d/groupId artifactIdmaven-minimal/artifactId namemaven-minimal/name version1.0-SNAPSHOT/version dependencies dependency groupIdorg.springframework.ws/groupId artifactIdspring-ws-core/artifactId version1.0.3/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-core/artifactId version2.0.7/version /dependency /dependencies /project -- 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: (MNG-3416) Setting testOutDirectory to ${basedir}/target/test-classes causes test classpath to be reversed.
[
http://jira.codehaus.org/browse/MNG-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3416.
-
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.2.x (to be reviewed))
please let us know if it continues to be an issue in recent versions
Setting testOutDirectory to ${basedir}/target/test-classes causes test
classpath to be reversed.
Key: MNG-3416
URL: http://jira.codehaus.org/browse/MNG-3416
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.8
Reporter: Ben Lidgey
Environment: maven 2.0.8, surefire 2.4.1,2.4.2
We are running tests using Surefire 2.4.1 and Maven 2.0.8. The Junit test
classes are expecting to load a properties file from
{{src/test/resources}} with the same name as a properties file in
{{src/main/resources}} to load test data etc. However the src/main/resources
properties file is being loaded.
Looking at the debug output shows:
[DEBUG] Test Classpath :
[DEBUG] C:\Documents and
Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar
[more jars]
[DEBUG] c:\Development\Projects\MyProject\target\classes
[DEBUG] c:\Development\Projects\MyProject\target\test-classes
Which would explain it. Setting childDelegation to true doesn't get the
test-classes before classes in the classpath order.
I generated the effective-pom and used it in a copy of the Surefire
integration test for the classpath order
(http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/classpath-order).
The tests failed. I then trawled through the project POM and then its parent
POM commenting out plugins, reporting, dependencies, and other bits until the
test passed.
The thing that was causing the test to fail was that in the parent POM:
{code:xml}
defaultGoalpackage/defaultGoal
directorytarget/directory
finalName${pom.artifactId}-${pom.version}/finalName
sourceDirectory${basedir}/src/main/java/sourceDirectory
testSourceDirectory${basedir}/src/test/java/testSourceDirectory
testOutputDirectory${basedir}/target/test-classes/testOutputDirectory
outputDirectory${basedir}/target/classes/outputDirectory
{code}
Changing just testOutputDirectory to
{code:xml}
testOutputDirectorytarget/test-classes/testOutputDirectory
{code}
Made the tests pass. I've no idea why.
--
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: (MNG-3707) mvn script cannot compile sources which use java 1.6 classes if JAVA_HOME is set
[
http://jira.codehaus.org/browse/MNG-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3707.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.2.x (to be reviewed))
I think the workaround is good enough here, especially with most Mac devs on
Snow Leopard now only having 1.6!
mvn script cannot compile sources which use java 1.6 classes if JAVA_HOME is
set
Key: MNG-3707
URL: http://jira.codehaus.org/browse/MNG-3707
Project: Maven 2 3
Issue Type: Bug
Components: Command Line
Reporter: Brian McCallister
The section of the mvn script:
Darwin*) darwin=true
if [ -z $JAVA_VERSION ] ; then
JAVA_VERSION=CurrentJDK
else
echo Using Java version: $JAVA_VERSION
fi
if [ -z $JAVA_HOME ] ; then
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
fi
;;
ignores JAVA_VERSION if JAVA_HOME is set. This would be fine if it would
compile against the version of java specified in JAVA_HOME, but it doesn't it
compiles against the value pointed at by the
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK symlink,
which is always 1.5 (even if you change java version so that the
/System/Library/Frameworks/JavaVM.framework/Versions/Current symlink is
updated by the OS).
I would prefer maven respect JAVA_HOME, but will take anything that allows me
to leave JAVA_HOME set and still be able to compile things :-)
--
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: (MNG-3242) It's not possible to get a property with unescaped sign for urls
[ http://jira.codehaus.org/browse/MNG-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3242. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x (to be reviewed)) I can't reproduce this with the sample project. Perhaps the newer releases of the resources plugin have resolved this? It's not possible to get a property with unescaped sign for urls -- Key: MNG-3242 URL: http://jira.codehaus.org/browse/MNG-3242 Project: Maven 2 3 Issue Type: Bug Components: General Affects Versions: 2.0.6 Reporter: Nils Eckert Attachments: mvntest-20080327.zip I found no way to create a property with a not escaped ampersand (-sign). This is needed for a MySQL jdbc-connection String with some connection variabled and should be filtered in a properties file during compile phase. It tried to escape it with amp; This leeds to following error: Project build error Cannot read project model from interpolating filter of serialized version. It is no option to use a double escaping with amp;amp;. Here I get a amp; in my connection url. I also tried to use a [CDATA[ ... ]] with the same problems. It's not possible to use sign. And if I use amp; this escaped tag appears in my properties file after filtering. -- 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: (MNG-3926) Spaces if properties are not preserved if using CDATA
[ http://jira.codehaus.org/browse/MNG-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3926: -- Priority: Trivial (was: Major) Fix Version/s: (was: 2.2.x (to be reviewed)) Backlog a very minor issue, but we should be trimming the xml source by its rules and not the properties in the model Spaces if properties are not preserved if using CDATA - Key: MNG-3926 URL: http://jira.codehaus.org/browse/MNG-3926 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Stefan Franke Priority: Trivial Fix For: Backlog Using a property like this one: properties cdata![CDATA[ ]]/cdata /properties results into an empty property (see effective-pom): properties cdata/ /properties which is wrong. See also the XML spec: Note that a CDATA section containing only white space or a reference to an entity whose replacement text is character references expanding to white space do not match the nonterminal S which also stats that white spaces inside CDATA must not be trimmed away. -- 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: (MNG-3162) Reports configuration not inherited from parent pom
[ http://jira.codehaus.org/browse/MNG-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3162. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x (to be reviewed)) is working in 2.2.1 Reports configuration not inherited from parent pom --- Key: MNG-3162 URL: http://jira.codehaus.org/browse/MNG-3162 Project: Maven 2 3 Issue Type: Bug Affects Versions: 2.0.7 Reporter: Olivier Jacob Attachments: effective-pom.txt, test-findbugs.zip When I redefine the plugin configuration for a report in a module's pom.xml, the configuration elements are not inherited from the parent pom. Attached is an archive containing a sample project that shows the problem, and the effective pom generated by Maven. -- 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: (MNG-3526) Small change to artifact version parsing.
[ http://jira.codehaus.org/browse/MNG-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3526: -- Fix Version/s: (was: 2.2.x (to be reviewed)) 3.1 Small change to artifact version parsing. - Key: MNG-3526 URL: http://jira.codehaus.org/browse/MNG-3526 Project: Maven 2 3 Issue Type: Improvement Components: General Affects Versions: 2.0.9 Reporter: Paul Gier Fix For: 3.1 Attachments: MNG-3526-maven-artifact-r648413.patch We currently many projects that use an OSGi compatible scheme for release version numbers. The OSGi spec does not currently allow a - to determine the location of the qualifier. So instead of the maven standard like this: 1.0.1-beta-1 We have something like this: 1.0.1.beta1 Maven's currently handles this by treating the entire version string as a classifier. It would be helpful this could be parsed as major = 1 minor = 0 incremental = 1 qualifier = beta1 -- 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: (MNG-4253) Fails with cyclic dependency in case of extension
[ http://jira.codehaus.org/browse/MNG-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4253. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x (to be reviewed)) I can't produce the cyclic error using that example - can someone provide a full test case and reopen if still a problem? I suspect this is already fixed in 3.x. Fails with cyclic dependency in case of extension - Key: MNG-4253 URL: http://jira.codehaus.org/browse/MNG-4253 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.1.0 Reporter: Paul Benedict Assignee: John Casey Per the comment of Jörg Hohwiller in MNG-4184, this issue arises with extension as suggested here: http://mojo.codehaus.org/findbugs-maven-plugin/2.0.1/examples/multi-module-config.html -- 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: (MNG-3597) Using ${project.parent.basedir} in systemPath/ causes InvalidProjectModelException
[
http://jira.codehaus.org/browse/MNG-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3597.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.2.x (to be reviewed))
this isn't a documented expression to my knowledge, and relying on the parent
being in the workspace (where it might be in the repository) is unreliable.
I suggest you might need a pattern like the following:
http://brettporter.wordpress.com/2009/06/10/a-maven-friendly-pattern-for-storing-dependencies-in-version-control/
Using ${project.parent.basedir} in systemPath/ causes
InvalidProjectModelException
Key: MNG-3597
URL: http://jira.codehaus.org/browse/MNG-3597
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.8
Reporter: Jan Rudert
Hi
although the Anttask echo message=${project.parent.basedir} / prints out
the proper path of my multiproject's root directory, I get an
InvalidProjectModelException If I try to use it in the systemPath/ element
of a dependency like this:
dependency
groupIdorg.company.my/groupId
artifactIdxyz/artifactId
version1.0/version
scopesystem/scope
systemPath${project.parent.basedir}/path/to/xyz.jar/systemPath
/dependency
Also mvn help:effective-pom resolves that property if not used in
systemPath/
--
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: (MNG-3261) Classified extensions
[ http://jira.codehaus.org/browse/MNG-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3261. - Resolution: Won't Fix Fix Version/s: (was: 2.2.x (to be reviewed)) you can configure the JAR plugin (and others) to attach an artifact with a classifier, but the primary artifact never has one Classified extensions - Key: MNG-3261 URL: http://jira.codehaus.org/browse/MNG-3261 Project: Maven 2 3 Issue Type: Improvement Components: Plugins and Lifecycle, POM Affects Versions: 2.0.7 Reporter: Tuomas Kiviaho Priority: Minor I planned to use checkstyle suppression filters though an extension mimicking the multimodule configuration but instead using classified extensions. During the process I realized that model version 4.0.0 doesn't allow defining a classifier (nor type) along with groupId, artifactId and version. Is there a compelling reason for this or could these elements be allowed to some future model version. -- 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: (MNG-3462) Settings: Proceeding slash should be removed from URLs
[ http://jira.codehaus.org/browse/MNG-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3462. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x (to be reviewed)) no longer an issue in 3.0-SNAPSHOT Settings: Proceeding slash should be removed from URLs -- Key: MNG-3462 URL: http://jira.codehaus.org/browse/MNG-3462 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, Settings Affects Versions: 2.0.8 Reporter: Paul Benedict Priority: Minor When repositories and mirrors have their URL end with a slash, you will see a double-slash in the URL. Example configuration: mirrors mirror idmergere/id mirrorOfcentral/mirrorOf nameMergere/name urlhttp://repo.mergere.com/maven2//url /mirror /mirrors Output: mvn help:effective-pom Downloading: http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.pom 1K downloaded Downloading: http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.jar 19K downloaded -- 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: (MNG-3470) Build does not fail on corrupted POM even with checksumPolicy=fail
[ http://jira.codehaus.org/browse/MNG-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3470: -- Fix Version/s: (was: 2.2.x (to be reviewed)) 3.0-alpha-7 for review on trunk based on earlier comment Build does not fail on corrupted POM even with checksumPolicy=fail -- Key: MNG-3470 URL: http://jira.codehaus.org/browse/MNG-3470 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Benjamin Bentmann Priority: Minor Fix For: 3.0-alpha-7 Attachments: mng-3470-it.patch If a dependency has a corrupted POM and the corresponding remote repo is configured with checksumPolicy=fail, Maven does still not fail the build. This seems to caused by the fix for MNG-2282: The original ChecksumFailedException is wrapped into a TransferFailedException which is errorneously converted into a ResourceDoesNotExistException by DefaultWagonManager.getArtifact(). Next up, DefaultArtifactResolver.resolve() wraps this into an ArtifactNotFoundException. DefaultMavenProjectBuilder.findModelFromRepository() will catch this and simply create a stub POM instead of failing. The code from the trunk looks different, not sure if it suffers from this. Now that I have a JIRA id, I will try to setup an IT. -- 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: (MNG-2738) 1-char profile names cannot be activated with -P
[
http://jira.codehaus.org/browse/MNG-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-2738:
--
Fix Version/s: (was: 2.2.x (to be reviewed))
Backlog
1-char profile names cannot be activated with -P
Key: MNG-2738
URL: http://jira.codehaus.org/browse/MNG-2738
Project: Maven 2 3
Issue Type: Bug
Components: Command Line
Affects Versions: 2.0-alpha-1
Reporter: Kenney Westerhof
Priority: Minor
Fix For: Backlog
'mvn install -Uc' gives;
{noformat}
Unable to parse command line options: no argument for:P
usage: mvn [options] [goal(s)] [phase(s)]
Options:
...etc...
{noformat}
(same for mvn -Pc [whatever])
--
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: (MNG-2382) relative path of webResources in parent pom not anchored correctly when run from parent
[
http://jira.codehaus.org/browse/MNG-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2382.
-
Resolution: Duplicate
Fix Version/s: (was: 2.2.x (to be reviewed))
Assignee: Brett Porter
relative path of webResources in parent pom not anchored correctly when run
from parent
---
Key: MNG-2382
URL: http://jira.codehaus.org/browse/MNG-2382
Project: Maven 2 3
Issue Type: Improvement
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: David Smiley
Assignee: Brett Porter
Priority: Minor
In my parent POM, in pluginManagement, I have:
{quote}
plugin
artifactIdmaven-war-plugin/artifactId
configuration
webResources
resource
directorysrc/webapp/directory
/resource
/webResources
/configuration
/plugin
{quote}
If I run {{mvn package}} when at the child module with war packaging, this
works fine. But when I run that at the parent module, the {{src/webapp}}
path is not interpreted as relative to the child module being built, as it
should (I think). By comparison, when I configure my source directory, test
source directory, or resources in the parent pom using a relative path, they
are correctly interpreted as relative to the module being built, regardless
of wether I run it from the parent or child module.
As a work-around, I am forced to prefix the relative path with ${basedir},
which should not be necessary.
--
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: (MNG-3588) ${maven.repo.local} in settings.xml doesn't work.
[
http://jira.codehaus.org/browse/MNG-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3588.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.2.x (to be reviewed))
that's not how the property is meant to work. IF you are trying to switch local
repositories, you're best to use separate settings.xml files.
${maven.repo.local} in settings.xml doesn't work.
-
Key: MNG-3588
URL: http://jira.codehaus.org/browse/MNG-3588
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Marcin Kuthan
Priority: Minor
I can't use ${maven.repo.local} parameter inside settings.xml file. The
parameter is simply ignored.
settings
localRepositoryc:\base_repo_location/localRepository
profiles
profile
idmy-profile/id
properties
maven.repo.localC:\alternative_repo_location/maven.repo.local
/properties
/profile
/profiles
/settings
When I run
mvn -P my-profile package
all downloaded artifacts are stored under c:\base_repo_location not
C:\alternative_repo_location.
When I run
mvn -Dmaven.repo.local=C:\alternative_repo_location package package
artifacts are stored under C:\alternative_repo_location as I expected.
--
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: (MNG-3480) Extend unit test for DefaultMavenProjectBuilder to check inheritance from super POM
[ http://jira.codehaus.org/browse/MNG-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3480. - Resolution: Won't Fix Fix Version/s: (was: 2.2.x (to be reviewed)) this code is all different in 3.x, I think we can stick with what wee have. Extend unit test for DefaultMavenProjectBuilder to check inheritance from super POM --- Key: MNG-3480 URL: http://jira.codehaus.org/browse/MNG-3480 Project: Maven 2 3 Issue Type: Task Components: POM Reporter: Benjamin Bentmann Assignee: John Casey Priority: Trivial Attachments: project-builder-minimal-pom-test.patch, project-builder-minimal-pom-test.patch.txt I originally wanted to create a unit test to trigger the failures Brian mentioned in MNG-3478. I ended up with a test that doesn't fail as expected but it might be useful nevertheless. -- 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: (MSITE-457) NPE on source XREF
NPE on source XREF -- Key: MSITE-457 URL: http://jira.codehaus.org/browse/MSITE-457 Project: Maven 2.x Site Plugin Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-17-generic arch: amd64 Family: unix Reporter: Johannes Schneider [INFO] Generating Source Xref report. [DEBUG] Scanning /home/johannes/projects/com.cedarsoft.commons/version/src/main/java [DEBUG] parsing... com/cedarsoft/VersionRange.java [DEBUG] parsing... com/cedarsoft/Version.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java [DEBUG] parsing... com/cedarsoft/VersionException.java [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html [DEBUG] ** [DEBUG] Starting Jakarta Velocity v1.4 [DEBUG] RuntimeInstance initializing. [DEBUG] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [DEBUG] Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ClasspathResourceLoader : initialization starting. [DEBUG] ClasspathResourceLoader : initialization complete. [DEBUG] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [DEBUG] Default ResourceManager initialization complete. [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [DEBUG] Created: 20 parsers. [DEBUG] Velocimacro : initialization starting. [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in templates [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [DEBUG] Velocimacro : messages on : VM system will output logging messages [DEBUG] Velocimacro : autoload off : VM system will not automatically reload global library macros [DEBUG] Velocimacro : initialization complete. [DEBUG] Velocity successfully started. [DEBUG] ResourceManager : found templates/index.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/overview-frame.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/allclasses-frame.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/overview-summary.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/package-summary.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG]
[jira] Commented: (MSITE-457) NPE on source XREF
[ http://jira.codehaus.org/browse/MSITE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206672#action_206672 ] Johannes Schneider commented on MSITE-457: -- Hmm, think this issue should be moved to http://jira.codehaus.org/browse/JXR NPE on source XREF -- Key: MSITE-457 URL: http://jira.codehaus.org/browse/MSITE-457 Project: Maven 2.x Site Plugin Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-17-generic arch: amd64 Family: unix Reporter: Johannes Schneider [INFO] Generating Source Xref report. [DEBUG] Scanning /home/johannes/projects/com.cedarsoft.commons/version/src/main/java [DEBUG] parsing... com/cedarsoft/VersionRange.java [DEBUG] parsing... com/cedarsoft/Version.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java [DEBUG] parsing... com/cedarsoft/VersionException.java [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html [DEBUG] ** [DEBUG] Starting Jakarta Velocity v1.4 [DEBUG] RuntimeInstance initializing. [DEBUG] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [DEBUG] Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ClasspathResourceLoader : initialization starting. [DEBUG] ClasspathResourceLoader : initialization complete. [DEBUG] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [DEBUG] Default ResourceManager initialization complete. [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [DEBUG] Created: 20 parsers. [DEBUG] Velocimacro : initialization starting. [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in templates [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [DEBUG] Velocimacro : messages on : VM system will output logging messages [DEBUG] Velocimacro : autoload off : VM system will not automatically reload global library macros [DEBUG] Velocimacro : initialization complete. [DEBUG] Velocity successfully started. [DEBUG] ResourceManager : found templates/index.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/overview-frame.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found
[jira] Commented: (MSITE-457) NPE on source XREF
[ http://jira.codehaus.org/browse/MSITE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206678#action_206678 ] Johannes Schneider commented on MSITE-457: -- It seems it is related to a custom stylesheet. When I remove that line: stylesheetxref/cedarsoft.css/stylesheet from reporting.plugins.plugin.configuration everything works as expected. But this line worked with an older version. I have updated several plugins. One of them broke it. I think it is not the site plugin and not the jxr plugin. I tried to revert both versions NPE on source XREF -- Key: MSITE-457 URL: http://jira.codehaus.org/browse/MSITE-457 Project: Maven 2.x Site Plugin Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-17-generic arch: amd64 Family: unix Reporter: Johannes Schneider [INFO] Generating Source Xref report. [DEBUG] Scanning /home/johannes/projects/com.cedarsoft.commons/version/src/main/java [DEBUG] parsing... com/cedarsoft/VersionRange.java [DEBUG] parsing... com/cedarsoft/Version.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java [DEBUG] parsing... com/cedarsoft/VersionException.java [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html [DEBUG] ** [DEBUG] Starting Jakarta Velocity v1.4 [DEBUG] RuntimeInstance initializing. [DEBUG] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [DEBUG] Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ClasspathResourceLoader : initialization starting. [DEBUG] ClasspathResourceLoader : initialization complete. [DEBUG] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [DEBUG] Default ResourceManager initialization complete. [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [DEBUG] Created: 20 parsers. [DEBUG] Velocimacro : initialization starting. [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in templates [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [DEBUG] Velocimacro : messages on : VM system will output logging messages [DEBUG] Velocimacro : autoload off : VM system will not automatically reload global library macros [DEBUG] Velocimacro : initialization complete. [DEBUG] Velocity successfully started. [DEBUG]
[jira] Commented: (MSITE-457) NPE on source XREF
[ http://jira.codehaus.org/browse/MSITE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206686#action_206686 ] Johannes Schneider commented on MSITE-457: -- Okay, I have found the problem. I have moved the xref-plugin configuration (including the dependency that contains the stylesheet) to the pluginManagement section. While this works for the javadoc plugin (also has an additional dependency declared and references the resource) it does not for xref. So I had to move the dependency back to build.plugins. Now it works as expected again. I don't know enough about maven and plugin configuration to find out whether this is a bug or my fault... I assume the second. At least a better error message will be very helpful... NPE on source XREF -- Key: MSITE-457 URL: http://jira.codehaus.org/browse/MSITE-457 Project: Maven 2.x Site Plugin Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-17-generic arch: amd64 Family: unix Reporter: Johannes Schneider [INFO] Generating Source Xref report. [DEBUG] Scanning /home/johannes/projects/com.cedarsoft.commons/version/src/main/java [DEBUG] parsing... com/cedarsoft/VersionRange.java [DEBUG] parsing... com/cedarsoft/Version.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java [DEBUG] parsing... com/cedarsoft/VersionException.java [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html [DEBUG] ** [DEBUG] Starting Jakarta Velocity v1.4 [DEBUG] RuntimeInstance initializing. [DEBUG] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [DEBUG] Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ClasspathResourceLoader : initialization starting. [DEBUG] ClasspathResourceLoader : initialization complete. [DEBUG] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [DEBUG] Default ResourceManager initialization complete. [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [DEBUG] Created: 20 parsers. [DEBUG] Velocimacro : initialization starting. [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in templates [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [DEBUG] Velocimacro : messages on : VM system will output logging messages
[jira] Moved: (JXR-79) NPE on source XREF
[ http://jira.codehaus.org/browse/JXR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MSITE-457 to JXR-79: -- Key: JXR-79 (was: MSITE-457) Project: Maven JXR (was: Maven 2.x Site Plugin) NPE on source XREF -- Key: JXR-79 URL: http://jira.codehaus.org/browse/JXR-79 Project: Maven JXR Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-17-generic arch: amd64 Family: unix Reporter: Johannes Schneider [INFO] Generating Source Xref report. [DEBUG] Scanning /home/johannes/projects/com.cedarsoft.commons/version/src/main/java [DEBUG] parsing... com/cedarsoft/VersionRange.java [DEBUG] parsing... com/cedarsoft/Version.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java [DEBUG] parsing... com/cedarsoft/VersionException.java [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html [DEBUG] ** [DEBUG] Starting Jakarta Velocity v1.4 [DEBUG] RuntimeInstance initializing. [DEBUG] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [DEBUG] Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ClasspathResourceLoader : initialization starting. [DEBUG] ClasspathResourceLoader : initialization complete. [DEBUG] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [DEBUG] Default ResourceManager initialization complete. [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [DEBUG] Created: 20 parsers. [DEBUG] Velocimacro : initialization starting. [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in templates [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [DEBUG] Velocimacro : messages on : VM system will output logging messages [DEBUG] Velocimacro : autoload off : VM system will not automatically reload global library macros [DEBUG] Velocimacro : initialization complete. [DEBUG] Velocity successfully started. [DEBUG] ResourceManager : found templates/index.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/overview-frame.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/allclasses-frame.vm with loader
[jira] Commented: (MGPG-19) Site descriptor does not get signed
[ http://jira.codehaus.org/browse/MGPG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206712#action_206712 ] Dennis Lundberg commented on MGPG-19: - I had a look at how the Site Plugin attaches the descriptor. It is attached as metadata to the artifact - not as an attached artifact. ArtifactMetadata has no accessors to any File object, but ProjectArtifactMetadata has a private variable that holds a File. That private variable is used to copy the file to the local repository during install, but again it is private. Without a file we can't sign it AFAICT. If we install the site descriptor into the local repository *before* we try to sign it, we should be able to access it from the local repo. But I'm not sure how well that works with the life cycle. I think it's a chicken-and-egg problem. Site descriptor does not get signed --- Key: MGPG-19 URL: http://jira.codehaus.org/browse/MGPG-19 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Reporter: Stephen Connolly Priority: Blocker When the site descriptor is an attached artifact, the GPG signature is not generated. Steps to reproduce: svn co https://svn.apache.org/repos/asf/maven/surefire/tags/surefire-...@898285 surefire-2.5 cd surefire-2.5 mvn site:attach-descriptor gpg:sign -Papache-release -N ls target/*.asc if there is a surefire-2.5-site.xml.asc then this bug is fixed. -- 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: (MGPG-19) Site descriptor does not get signed
[ http://jira.codehaus.org/browse/MGPG-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206718#action_206718 ] Brett Porter commented on MGPG-19: -- it should be getting into the local repository first, as that's how the deploy mechanism works. However, that'd be a one off solution - sounds like a Maven issue that the metadata can't be enumerated. Perhaps it is better to change the site plugin to attach it as an artifact instead (it probably should be anyway?) Site descriptor does not get signed --- Key: MGPG-19 URL: http://jira.codehaus.org/browse/MGPG-19 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-4 Reporter: Stephen Connolly Priority: Blocker When the site descriptor is an attached artifact, the GPG signature is not generated. Steps to reproduce: svn co https://svn.apache.org/repos/asf/maven/surefire/tags/surefire-...@898285 surefire-2.5 cd surefire-2.5 mvn site:attach-descriptor gpg:sign -Papache-release -N ls target/*.asc if there is a surefire-2.5-site.xml.asc then this bug is fixed. -- 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: (JXR-79) NPE on source XREF
[ http://jira.codehaus.org/browse/JXR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=206719#action_206719 ] Wendy Smoak commented on JXR-79: Whatever the problem is, it shouldn't die with a NPE. Can you provide a simple example project that demonstrates the problem? NPE on source XREF -- Key: JXR-79 URL: http://jira.codehaus.org/browse/JXR-79 Project: Maven JXR Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_16 Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.31-17-generic arch: amd64 Family: unix Reporter: Johannes Schneider [INFO] Generating Source Xref report. [DEBUG] Scanning /home/johannes/projects/com.cedarsoft.commons/version/src/main/java [DEBUG] parsing... com/cedarsoft/VersionRange.java [DEBUG] parsing... com/cedarsoft/Version.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionRangeException.java [DEBUG] parsing... com/cedarsoft/VersionMismatchException.java [DEBUG] parsing... com/cedarsoft/UnsupportedVersionException.java [DEBUG] parsing... com/cedarsoft/VersionException.java [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionRange.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionRange.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/Version.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/Version.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionRangeException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionRangeException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionMismatchException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionMismatchException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/UnsupportedVersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/UnsupportedVersionException.html [DEBUG] /home/johannes/projects/com.cedarsoft.commons/version/src/main/java/com/cedarsoft/VersionException.java - /home/johannes/projects/com.cedarsoft.commons/version/target/site/xref/com/cedarsoft/VersionException.html [DEBUG] ** [DEBUG] Starting Jakarta Velocity v1.4 [DEBUG] RuntimeInstance initializing. [DEBUG] Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties [DEBUG] Trying to use logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Using logger class org.apache.maven.jxr.log.VelocityLogger [DEBUG] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [DEBUG] Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ClasspathResourceLoader : initialization starting. [DEBUG] ClasspathResourceLoader : initialization complete. [DEBUG] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [DEBUG] Default ResourceManager initialization complete. [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [DEBUG] Created: 20 parsers. [DEBUG] Velocimacro : initialization starting. [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in templates [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [DEBUG] Velocimacro : messages on : VM system will output logging messages [DEBUG] Velocimacro : autoload off : VM system will not automatically reload global library macros [DEBUG] Velocimacro : initialization complete. [DEBUG] Velocity successfully started. [DEBUG] ResourceManager : found templates/index.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager : found templates/overview-frame.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader [DEBUG] ResourceManager :
