[jira] Created: (ARCHETYPE-128) Unable to create a Cocoon app with Maven archetype: [WARNING] No archetype repository found.
Unable to create a Cocoon app with Maven archetype: [WARNING] No archetype repository found. Key: ARCHETYPE-128 URL: http://jira.codehaus.org/browse/ARCHETYPE-128 Project: Maven Archetype Issue Type: Bug Components: Creator Affects Versions: 2.0-alpha-1 Environment: Linux Fedora 8, JDK 1.5, Maven 2.0.7 Reporter: Luca Morandini When the following command is issued: mvn archetype:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0-RC2 -DgroupId=org.cocoondev -DartifactId=geoid-core Maven 2.0.7 reports this error: [INFO] [archetype:create] [WARNING] No archetype repository found. [WARNING] Specified archetype not found. Choose archetype: 1: internal -> appfuse-basic-jsf (AppFuse archetype for creating a web application with Hibernate, Spring and JSF) ... This was solved by specifying use of the 1.0-alpha-7 archetype version in command line: org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create .. -- 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: (MRM-691) Can't get any of the consumers to work without through a NPE
[ http://jira.codehaus.org/browse/MRM-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123370 ] Jason Chaffee commented on MRM-691: --- The NPE came back when the database update ran. > Can't get any of the consumers to work without through a NPE > > > Key: MRM-691 > URL: http://jira.codehaus.org/browse/MRM-691 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0.1 > Environment: Red Hat Enterprise Linux ES release 4 (Nahant Update 2) >Reporter: Jason Chaffee > Attachments: archiva.log, audit.log, wrapper.20080211.log > > > It appears to be causing NPE for all consumers and some there seems to be > some type of InvalidPath issue as well. > Logs are attached. -- 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] Work stopped: (MSITE-292) Swedish translation for the site
[ http://jira.codehaus.org/browse/MSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MSITE-292 stopped by Dennis Lundberg. > Swedish translation for the site > > > Key: MSITE-292 > URL: http://jira.codehaus.org/browse/MSITE-292 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: internationalization >Reporter: Johan Andrén >Assignee: Dennis Lundberg >Priority: Minor > Attachments: project-info-report_sv_SE.properties, > site-plugin_sv_SE.properties > > > I have attached UTF-8 encoded translations of both the > project-info-report.properties and site-plugin.properties -- 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] Work started: (MSITE-292) Swedish translation for the site
[ http://jira.codehaus.org/browse/MSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MSITE-292 started by Dennis Lundberg. > Swedish translation for the site > > > Key: MSITE-292 > URL: http://jira.codehaus.org/browse/MSITE-292 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: internationalization >Reporter: Johan Andrén >Assignee: Dennis Lundberg >Priority: Minor > Attachments: project-info-report_sv_SE.properties, > site-plugin_sv_SE.properties > > > I have attached UTF-8 encoded translations of both the > project-info-report.properties and site-plugin.properties -- 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-456) Surefire doubly XML-escapes non-visible control characters
[ http://jira.codehaus.org/browse/SUREFIRE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123430 ] Dan Fabulich commented on SUREFIRE-456: --- To repro: run Surefire224WellFormedXmlFailuresTest. > Surefire doubly XML-escapes non-visible control characters > -- > > Key: SUREFIRE-456 > URL: http://jira.codehaus.org/browse/SUREFIRE-456 > Project: Maven Surefire > Issue Type: Bug > Components: xml generation >Affects Versions: 2.4.2 >Reporter: Dan Fabulich >Priority: Minor > Fix For: Future > > > It's illegal to include a non-visible control character in XML, even as a > character entity. e.g. "�" is illegal in XML, even though it's > semantically meaningful. > http://www.w3.org/TR/1998/REC-xml-19980210#charsets > Disturbingly, Java's XML serializer will cheerfully print out � > despite the fact that it will refuse to parse that entity. > As a workaround, for 2.4.2 we're deliberately doublly XML-escaping > non-visible control characters, printing them as "�" instead of > "�" like they're supposed to be. That's better than any alternative > I can think of (e.g. throwing the characters away in test results, replacing > them with a "?" character). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-261) Local Parent POM not found if specifies a directory
[
http://jira.codehaus.org/browse/MSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123437
]
Benjamin Bentmann commented on MSITE-261:
-
bq. [...] just append a slash : "../parent/" which is the correct way of
denoting directories
Don't confuse URIs with filesystem paths, these are two different things that
employ different rules for their representation/parsing (e.g. character
encoding). A filesystem path need not end with a slash just to denote a
directory. For instance, java.io.File does not do so either when wrapping a
directory path string.
> Local Parent POM not found if specifies a directory
> --
>
> Key: MSITE-261
> URL: http://jira.codehaus.org/browse/MSITE-261
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
> Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP SP2
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.0-beta-7
>
> Attachments: site-parent-pom.patch, site-parent-pom.patch
>
>
> The Maven core allows to specify a directory for the element
> in a module POM to locate the parent POM, e.g.{code:xml}
> ...
> ../parent
> {code}will properly find the parent POM in "../parent/pom.xml".
> However, the Site plugin does not follow this lookup strategy:{code}
> [INFO] [site:site]
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file '[SNIP]\..\parent'. for project unknown
> [INFO] Parent project loaded from repository.{code}
> This log output is actually from 2.0-beta-6-SNAPSHOT, 2.0-beta-5 outputs a
> different message but fails, too.
> The attached patch fixes this although I wonder whether this functionality is
> not already included somewhere in the Maven core (where is belongs IMHO).
--
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: (MENFORCER-34) Make code Java 1.4 compatible
[
http://jira.codehaus.org/browse/MENFORCER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MENFORCER-34:
---
Attachment: java-1.4-compat.patch
Simpler.
> Make code Java 1.4 compatible
> -
>
> Key: MENFORCER-34
> URL: http://jira.codehaus.org/browse/MENFORCER-34
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Task
> Components: Standard Rules
>Reporter: Benjamin Bentmann
>Assignee: Brian Fox
>Priority: Trivial
> Attachments: java-1.4-compat.patch, java-1.4-compat.patch
>
>
> The plugin's parent POM states Java 1.4 as the target platform but the code
> does not successfully compile against this.
> The patch simply includes a copy of the JDK code for the offending method
> {{Arrays.hashCode()}}. Alternatively, you could use
> {{[HashCodeBuilder|http://commons.apache.org/lang/api-release/org/apache/commons/lang/builder/HashCodeBuilder.html]}}
> from commons-lang.
--
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: (SUREFIRE-457) TestNG should log on the console before/after every test class
[ http://jira.codehaus.org/browse/SUREFIRE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-457: -- Fix Version/s: Future > TestNG should log on the console before/after every test class > -- > > Key: SUREFIRE-457 > URL: http://jira.codehaus.org/browse/SUREFIRE-457 > Project: Maven Surefire > Issue Type: Wish > Components: TestNG support >Affects Versions: 2.4, 2.4.1, 2.4.2 >Reporter: Dan Fabulich >Priority: Minor > Fix For: Future > > > In Surefire 2.3.x, when running the tests in "directory mode" (i.e. without a > suite.xml file) we used to run each TestNG class as a separate suite. As a > result, we logged to the console before/after every test class. > This behavior totally broke tests that had rich interdependencies (which is a > big part of the point of TestNG), so in Surefire 2.4 we handed more control > over to TestNG. As a result, we let TestNG run the entire directory at once, > and we aren't notified when classes start/end. Since we aren't notified, we > can't log to the console before/after every test class. But this looks like > a regression to those who were used to the 2.3.x behavior. > (This is trickier than it looks, because TestNG can/will run test methods > entirely out of order, running part of class X, and then part of class Y, > then back to class X, then a bit of class Z, etc. And that's not even > considering parallelized testing.) > I argue that to fix this "right" we'd need TestNG to notify us when classes > start/end; we should pressure the TestNG team to provide this functionality. > Benjamin has argued that there should be an option to run each test in its > own suite; I think that option is confusing and error-prone. > http://www.nabble.com/Re%3A-Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport-p15094586.html > If you think you want a one-class-per-suite option, I offer this remark: Many > TestNG tests aren't safe to run in one-class-per-suite mode. If your tests > are safe to run in that mode, then they're also safe to run in JUnit 4. (In > fact, if your tests are that simple, you probably aren't using any of > TestNG's unique features, and you should prefer to use JUnit 4.) So, as a > workaround, don't use TestNG; use JUnit 4 instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-294) Can't escape ${project.version} as plain text inside apt +---- section, on *.apt.vm files
[
http://jira.codehaus.org/browse/MSITE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123459
]
Andrew Hughes commented on MSITE-294:
-
Hi Dennis,
Thanks for the response, what you are saying is correct... if I put this text
in I would expect the value to be replaced
INPUT: index.apt.vm
{noformat}
This project version is ${project.version}
{noformat}
OUTPUT: index.html [which is correct and I am happy with :)
{noformat}
This project version is 1.0.0-SNAPSHOT
{noformat}
But let's say I really wanted the output to say
INPUT: index.apt.vm
{noformat}
This project version is ${project.version} and comes from the
$\{project.version\} property.
{noformat}
OUTPUT: index.html - which is correct and I am happy with :)]
{noformat}
This project version is 1.0.0-SNAPSHOT and comes from the ${project.version}
property.
{noformat}
However if I want to do the above inside an apt escape box it becomes a
bit weird... this is the bug...
INPUT: index.apt.vm
{noformat}
+
This project version is ${project.version} and comes from the
$\{project.version\} property.
+
{noformat}
OUTPUT: index.html - which is not what I want :(
{noformat}
This project version is 1.0.0-SNAPSHOT and comes from the $\{project.version\}
property.
{noformat}
My real use case, is that I have a plugin I am trying to document. My
documentation is an XML HowTo snippet (hence the +-- apt escape section).
The XML HowTo is driven by a mixture of properties to be replaced from values
in the project, and "you must define a property called xxx.xxx within your
profile to complete the plugin usage configuration HowTo. My description
problably sucks so here's my actual input and output I want, and what I get
INPUT: index.apt.vm
{noformat}
How To Use The ${project.groupId}:${project.artifactId}-${project.version}
Plugin
Add the following to your pom.xml's plugin section
+-+
.
${project.groupId}
${project.artifactId}
${project.version}
localhost
4848
admin
adm1nadm1n
$\{basedir\}/target/$\{project.artifactId\}-$\{project.version\}.$\{project.packaging\}
$\{project.artifactId\}-$\{project.version\}
.
+-+
{noformat}
OUTPUT: index.html (this is what I want)
{noformat}
How To Use The mycompany-maven:glassfish-deployer-1.0.0-SNAPSHOT Plugin
Add the following to your pom.xml's plugin section
.
mycompany-maven
glassfish-deployer
1.0.0-SNAPSHOT
localhost
4848
admin
adm1nadm1n
${basedir}/target/${project.artifactId}-${project.version}.${project.packaging}
${project.artifactId}-${project.version}
.
{noformat}
OUTPUT: index.html (this is what I get) NOTE the backslashes are still there
{noformat}
How To Use The mycompany-maven:glassfish-deployer-1.0.0-SNAPSHOT Plugin
Add the following to your pom.xml's plugin section
.
mycompany-maven
glassfish-deployer
1.0.0-SNAPSHOT
localhost
4848
admin
adm1nadm1n
$\{basedir\}/target/$\{project.artifactId\}-$\{project.version\}.$\{project.packaging\}
$\{project.artifactId\}-$\{project.version\}
.
{noformat}
> Can't escape ${project.version} as plain text inside apt + section, on
> *.apt.vm files
> -
>
> Key: MSITE-294
> URL: http://jira.codehaus.org/browse/MSITE-294
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
> Environment: *.apt.vm files, and +- escaped section.
>Reporter: Andrew Hughes
>Priority: Critical
>
> You can reproduce this the following way.
> ./src/site/index.apt.vm (start)
> --
> This will appear without the backslashes
> {noformat}$\{project.version\}{noformat} and that's excellent. But you can't
> get this output in the escaped apt text section below.
> {noformat}
> +---
> However this apt escaped section still shows the backslashes inside this
> section $\{project.version\} and there is no known way the text can be shown
> as above.
> To make matters worse, when you put this in without the backslashes, you get
> the prope
[jira] Updated: (MENFORCER-35) Add new rule RequireSkinVersion
[ http://jira.codehaus.org/browse/MENFORCER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MENFORCER-35: --- Attachment: MENFORCER-35.zip I lacked the time to write a proper test but the attached demo project makes me hope it works... > Add new rule RequireSkinVersion > --- > > Key: MENFORCER-35 > URL: http://jira.codehaus.org/browse/MENFORCER-35 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Attachments: MENFORCER-35.zip, require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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: (MENFORCER-35) Add new rule RequireSkinVersion
Add new rule RequireSkinVersion --- Key: MENFORCER-35 URL: http://jira.codehaus.org/browse/MENFORCER-35 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.0-alpha-3 Reporter: Benjamin Bentmann Assignee: Brian Fox Priority: Minor Attachments: require-skin-version.patch Locking down versions should be possible for every artifacts that Maven might want to download, so the site skin should be considered as well by the Enforcer Plugin. The patch uses the new maven-doxia-tools and hence might need to be deferred until that gets a first release such that the Maven Enforcer Plugin's release cycle is not blocked. -- 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: (SUREFIRE-457) TestNG should log on the console before/after every test class
TestNG should log on the console before/after every test class -- Key: SUREFIRE-457 URL: http://jira.codehaus.org/browse/SUREFIRE-457 Project: Maven Surefire Issue Type: Wish Components: TestNG support Affects Versions: 2.4.1, 2.4, 2.4.2 Reporter: Dan Fabulich Priority: Minor Fix For: Future In Surefire 2.3.x, when running the tests in "directory mode" (i.e. without a suite.xml file) we used to run each TestNG class as a separate suite. As a result, we logged to the console before/after every test class. This behavior totally broke tests that had rich interdependencies (which is a big part of the point of TestNG), so in Surefire 2.4 we handed more control over to TestNG. As a result, we let TestNG run the entire directory at once, and we aren't notified when classes start/end. Since we aren't notified, we can't log to the console before/after every test class. But this looks like a regression to those who were used to the 2.3.x behavior. (This is trickier than it looks, because TestNG can/will run test methods entirely out of order, running part of class X, and then part of class Y, then back to class X, then a bit of class Z, etc. And that's not even considering parallelized testing.) I argue that to fix this "right" we'd need TestNG to notify us when classes start/end; we should pressure the TestNG team to provide this functionality. Benjamin has argued that there should be an option to run each test in its own suite; I think that option is confusing and error-prone. http://www.nabble.com/Re%3A-Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport-p15094586.html If you think you want a one-class-per-suite option, I offer this remark: Many TestNG tests aren't safe to run in one-class-per-suite mode. If your tests are safe to run in that mode, then they're also safe to run in JUnit 4. (In fact, if your tests are that simple, you probably aren't using any of TestNG's unique features, and you should prefer to use JUnit 4.) So, as a workaround, don't use TestNG; use JUnit 4 instead. -- 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: (MSITE-294) Can't escape ${project.version} as plain text inside apt +---- section, on *.apt.vm files
[
http://jira.codehaus.org/browse/MSITE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123459
]
ahughes edited comment on MSITE-294 at 2/12/08 6:01 PM:
--
Hi Dennis,
Thanks for the response, what you are saying is correct... if I put this text
in I would expect the value to be replaced
INPUT: index.apt.vm
{noformat}
This project version is ${project.version}
{noformat}
OUTPUT: index.html which is correct and I am happy with :) :) :)
{noformat}
This project version is 1.0.0-SNAPSHOT
{noformat}
Now let's say I really wanted the output to say
INPUT: index.apt.vm
{noformat}
This project version is ${project.version} and comes from the
$\{project.version\} property.
{noformat}
OUTPUT: index.html - which is correct and I am happy with :) :) :)
{noformat}
This project version is 1.0.0-SNAPSHOT and comes from the ${project.version}
property.
{noformat}
However if I want to do the above inside an apt escape box it becomes a
bit weird... this is the bug...
INPUT: index.apt.vm
{noformat}
+
This project version is ${project.version} and comes from the
$\{project.version\} property.
+
{noformat}
OUTPUT: index.html - which is not what I want :( :( :(
{noformat}
This project version is 1.0.0-SNAPSHOT and comes from the $\{project.version\}
property.
{noformat}
My real use case, is that I have a plugin I am trying to document. My
documentation is an XML HowTo snippet (hence the +-- apt escape section).
The XML HowTo is driven by a mixture of properties to be replaced from values
in the project, and "you must define a property called xxx.xxx within your
profile to complete the plugin usage configuration HowTo. My description
problably sucks so here's my actual input and output I want, and what I get
INPUT: index.apt.vm
{noformat}
How To Use The ${project.groupId}:${project.artifactId}-${project.version}
Plugin
Add the following to your pom.xml's plugin section
+-+
.
${project.groupId}
${project.artifactId}
${project.version}
localhost
4848
admin
adm1nadm1n
$\{basedir\}/target/$\{project.artifactId\}-$\{project.version\}.$\{project.packaging\}
$\{project.artifactId\}-$\{project.version\}
.
+-+
{noformat}
OUTPUT: index.html (this is what I want)
{noformat}
How To Use The mycompany-maven:glassfish-deployer-1.0.0-SNAPSHOT Plugin
Add the following to your pom.xml's plugin section
.
mycompany-maven
glassfish-deployer
1.0.0-SNAPSHOT
localhost
4848
admin
adm1nadm1n
${basedir}/target/${project.artifactId}-${project.version}.${project.packaging}
${project.artifactId}-${project.version}
.
{noformat}
OUTPUT: index.html (this is what I get) NOTE the backslashes are still
there :( :( :(
{noformat}
How To Use The mycompany-maven:glassfish-deployer-1.0.0-SNAPSHOT Plugin
Add the following to your pom.xml's plugin section
.
mycompany-maven
glassfish-deployer
1.0.0-SNAPSHOT
localhost
4848
admin
adm1nadm1n
$\{basedir\}/target/$\{project.artifactId\}-$\{project.version\}.$\{project.packaging\}
$\{project.artifactId\}-$\{project.version\}
.
{noformat}
was (Author: ahughes):
Hi Dennis,
Thanks for the response, what you are saying is correct... if I put this text
in I would expect the value to be replaced
INPUT: index.apt.vm
{noformat}
This project version is ${project.version}
{noformat}
OUTPUT: index.html [which is correct and I am happy with :)
{noformat}
This project version is 1.0.0-SNAPSHOT
{noformat}
But let's say I really wanted the output to say
INPUT: index.apt.vm
{noformat}
This project version is ${project.version} and comes from the
$\{project.version\} property.
{noformat}
OUTPUT: index.html - which is correct and I am happy with :)]
{noformat}
This project version is 1.0.0-SNAPSHOT and comes from the ${project.version}
property.
{noformat}
However if I want to do the above inside an apt escape box it becomes a
bit weird... this is the bug...
INPUT: index.apt.vm
{noformat}
+
This project version is ${project.version} and comes from the
$\{project.version\} property.
+
{noformat}
OUTPUT: index.html - which is not what I wa
[jira] Created: (MAVENUPLOAD-1932) Update j2ssh-common and j2ssh-core
Update j2ssh-common and j2ssh-core -- Key: MAVENUPLOAD-1932 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1932 Project: maven-upload-requests Issue Type: Wish Reporter: Henri Dupre Attachments: sshtools-0.2.9.zip -- 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-3399) Maven shows fake network error until the next updatePolicy period
Maven shows fake network error until the next updatePolicy period - Key: MNG-3399 URL: http://jira.codehaus.org/browse/MNG-3399 Project: Maven 2 Issue Type: Bug Components: General Affects Versions: 2.0.8 Reporter: Jonas Fagundes Hi, The default updatePolicy is daily. If it has any problems in updating it marks that plugin as checked and keeping showing the same error message without trying to hit the server again. At my work they changed the proxy configuration making the build fail, we started to have the following message: The plugin 'org.apache.maven.plugins:maven-clean-plugin' does not exist or no valid version could be found. Even after they rollback the network configuration, maven still showing the same error. To solve the problem I had to put this lines always false central Maven Plugin Repository http://repo1.maven.org/maven2 as the first pluginRepository and run for every developer just to force the update. This workaround works fine but until I realized that this is the behavior of maven it generated a lot problems trying setup the network configuration (it was not trying to hit the network, but it still showing the same error, so all configuration attempts were worthless). Show a network error that was not checked against the current configuration is a bug. My suggestion for an easy solution is to update timestamp of the latest hit in the repository *after* it has a success, if it fails does not update the timestamp and updatePolicy will make it keep trying for every execution until it finally hit with success. This way you don't need to verify any extra condition to see if the previous try resulted in an error. This way will make the debug of network problems much easier for the users that have the same problem. I didn't look your sources, so maybe this solution is not practical in your architecture. Feel free to use another route to solve this bug. Thanks for your excellent work in maven (it is first bug in years), Jonas Fagundes -- 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: (MIDEA-110) multi-module master ipr generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123465 ] Haus Code commented on MIDEA-110: - We ran into the same issue. Using Maven 2.0.6 works fine, 2.0.7 and 2.0.8 are broken > multi-module master ipr generated incorrectly > - > > Key: MIDEA-110 > URL: http://jira.codehaus.org/browse/MIDEA-110 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug > Environment: Windows XP / opened with IntelliJ 7.0.3 (EAP) >Reporter: Darren Davis > > I have a multi-module web-application which works fine with maven2. In order > to make it more friendly with our source control system, the master project > pom file was moved into it's own directory, parallel to the child modules. > C:\\Development\mavenflattened\GetSmartMaster > The modules section of the pom.xml references each child module using a > relative filepath: > > ../GetSmartLogging > ../GetSmart > > Each child pom.xml was modified to reference the parent, also using a > relative filepath: > > com.foo.max > app > ../GetSmartMaster/pom.xml > > With this configuration I can successfully compile,build, deploy the entire > application the mvn commands. > When I create an IntelliJ ipr/iml files using the idea:idea goal, the modules > filepath are incorrect in the ipr file. These appear as: > > >filepath="$PROJECT_DIR$/C:/development/mavenflattened/GetSmartLogging/GetSmartLogging.iml"/> >filepath="$PROJECT_DIR$/C:/development/mavenflattened/GetSmart/GetSmart.iml"/> > > When i try to open up the master ipr with IntelliJ, I get the following > error message for each module: > Cannot load module file > 'C:\development\mavenflattened\GetSmartMaster\C:\development\mavenflattened\GetSmartLogging\GetSmartLogging.iml': > File > C:\development\mavenflattened\GetSmartMaster\C:\development\mavenflattened\GetSmartLogging\GetSmartLogging.iml > does not exist > Would you like to remove the module from the project? > I have to manually edit the generated ipr file to get the project to open > with the correct module references. -- 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: (MRM-693) need a specific guide for creating a new repository
need a specific guide for creating a new repository --- Key: MRM-693 URL: http://jira.codehaus.org/browse/MRM-693 Project: Archiva Issue Type: Bug Components: documentation Affects Versions: 1.0.1 Reporter: Brett Porter the current admin guide talks about what the types of repositories are, but it doesn't walk through creating one - which misses the opportunity to explain that new repositories are secured by default to the administrator. -- 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: (MCOMPILER-59) Compilation fails on warning messages from javac (Java 6)
[ http://jira.codehaus.org/browse/MCOMPILER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MCOMPILER-59. --- Assignee: John Casey Resolution: Fixed Fix Version/s: 2.1 Applied patch for PLXCOMP-87 from Christian Bach, and all is well. Tested against the attached warning.tar.gz... > Compilation fails on warning messages from javac (Java 6) > - > > Key: MCOMPILER-59 > URL: http://jira.codehaus.org/browse/MCOMPILER-59 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Mac OSX 10.4.10 > Maven version: 2.0.7 > Java version: 1.6.0-dp > OS name: "mac os x" version: "10.4.10" arch: "i386" > java version "1.6.0-dp" > Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34) > Java HotSpot(TM) Client VM (build 1.6.0-b88-17-release, mixed mode, sharing) >Reporter: Tim Meighen >Assignee: John Casey > Fix For: 2.1 > > Attachments: compiler-warning.tar.gz, warning.tar.gz > > > The attached project fails due to an inability to parse the following warning > messages from the Java compiler (Java 6) > [INFO] Compilation failure > could not parse error message: > /Users/tmeighen/compiler-warning/entity/target/classes/test/MyEntity.class: > warning: Cannot find annotation method 'name()' in type > 'javax.persistence.Table': class file for javax.persistence.Table not found > /Users/tmeighen/compiler-warning/logic/src/main/java/test/Logic.java:7: > warning: [deprecation] deprecateMe() in test.MyEntity has been deprecated > entity.deprecateMe(); > ^ > could not parse error message: > /Users/tmeighen/compiler-warning/entity/target/classes/test/MyEntity.class: > warning: Cannot find annotation method 'name()' in type > 'javax.persistence.Table': class file for javax.persistence.Table not found > /Users/tmeighen/compiler-warning/logic/src/main/java/test/Logic.java:7: > warning: [deprecation] deprecateMe() in test.MyEntity has been deprecated > entity.deprecateMe(); > ^ -- 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-3273) Point out known pitfalls when developing plugins
[
http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MNG-3273:
I noticed Dennis pointing out the requirement to use Maven 2.0.6 as
prerequisite if plexus-utils != 1.1 should be used
[0|http://www.nabble.com/Re%3A-svn-commit%3A-r616959---in--maven-plugins-trunk-maven-help-plugin%3A-pom.xml-src-main-java-org-apache-maven-plugins-help-SystemMojo.java-src-site-apt-index.apt-src-site-apt-usage.apt-td15216930s177.html],
[1|http://www.nabble.com/Re%3A-svn-commit%3A-r627125maven-plugins-trunk-maven-compiler-plugin-pom.xml-to15443813s177.html].
It seems this subtle point is not properly documented.
> Point out known pitfalls when developing plugins
>
>
> Key: MNG-3273
> URL: http://jira.codehaus.org/browse/MNG-3273
> Project: Maven 2
> Issue Type: Improvement
> Components: Documentation: Guides
>Reporter: Benjamin Bentmann
>Assignee: Vincent Siveton
>Priority: Minor
> Attachments: pitfall-report-output-directory.patch,
> pitfalls-resource-bundles.patch, pitfalls-resource-bundles.patch,
> pitfalls.patch, plexus-utils.patch, plugin-api-logger.patch
>
>
> Writing a simple Maven plugin is quite easy but getting it wrong is also
> quite easy. I am just a novice but have so far noticed two subtle
> anti-patterns that plugin developers should avoid. I would expect that the
> Maven core team knows some more aspects about mojo programming that plugin
> developers should be aware of to fight bugs right from the beginning. All
> those pitfalls would fit nicely into [Plugin
> Development|http://maven.apache.org/guides/plugin/guide-java-plugin-development.html].
> Some examples: It is a bad idea to code something like
> {code:java}
> public MyMojo {
> private Log log = getLog();
> public void execute() throws MojoExecutionException {
> log.debug("...");
> }
> }
> {code}
> Getting the logger this way will retrieve some default logger instead of the
> logger that is injected into the mojo (by the plexus container?). This is
> easily noticed by the different output styles of the log messages and the
> fact that one gets [debug] message without having "-X" enabled.
> Not bad but rather dangerous is something like
> {code:java}
> public MyMojo {
> /**
> * This parameter will take a file path (file paths are
> platform-dependent...)
> * @parameter
> */
> private String outputDirectory;
> public void execute() throws MojoExecutionException {
> File outputDir = new File(outputDirectory).getAbsoluteFile();
> outputDir.mkdirs();
> }
> }
> {code}
> java.io.File resolves relative paths like "target/something" that users might
> provide in the plugin configuration against the current directory which needs
> not be the project base directory. Therefore, path parameters should be
> declared of type java.io.File rather than simple strings as Maven seems to
> automatically push in properly resolved paths into the mojo. If one really
> needs the parameter to be of type String (i.e. to try resource lookup from
> class path), the best practice to properly get an absolute path should be
> documented.
> How to get a plugin ready for reactor builds might also be worth some warning
> words. What does one need to know about aggregator-style execution, execution
> project, forking ... ?
> A further improvement might be links to recommended libraries like
> plexus-utils or plexus-components. This would point peoply to existing code
> and prevent to error-prone reinvention of the wheel (only a few things on
> earth are that simple that people get them reliably right...)
--
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-3273) Point out known pitfalls when developing plugins
[
http://jira.codehaus.org/browse/MNG-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3273:
---
Attachment: plexus-utils.patch
> Point out known pitfalls when developing plugins
>
>
> Key: MNG-3273
> URL: http://jira.codehaus.org/browse/MNG-3273
> Project: Maven 2
> Issue Type: Improvement
> Components: Documentation: Guides
>Reporter: Benjamin Bentmann
>Assignee: Vincent Siveton
>Priority: Minor
> Attachments: pitfall-report-output-directory.patch,
> pitfalls-resource-bundles.patch, pitfalls-resource-bundles.patch,
> pitfalls.patch, plexus-utils.patch, plugin-api-logger.patch
>
>
> Writing a simple Maven plugin is quite easy but getting it wrong is also
> quite easy. I am just a novice but have so far noticed two subtle
> anti-patterns that plugin developers should avoid. I would expect that the
> Maven core team knows some more aspects about mojo programming that plugin
> developers should be aware of to fight bugs right from the beginning. All
> those pitfalls would fit nicely into [Plugin
> Development|http://maven.apache.org/guides/plugin/guide-java-plugin-development.html].
> Some examples: It is a bad idea to code something like
> {code:java}
> public MyMojo {
> private Log log = getLog();
> public void execute() throws MojoExecutionException {
> log.debug("...");
> }
> }
> {code}
> Getting the logger this way will retrieve some default logger instead of the
> logger that is injected into the mojo (by the plexus container?). This is
> easily noticed by the different output styles of the log messages and the
> fact that one gets [debug] message without having "-X" enabled.
> Not bad but rather dangerous is something like
> {code:java}
> public MyMojo {
> /**
> * This parameter will take a file path (file paths are
> platform-dependent...)
> * @parameter
> */
> private String outputDirectory;
> public void execute() throws MojoExecutionException {
> File outputDir = new File(outputDirectory).getAbsoluteFile();
> outputDir.mkdirs();
> }
> }
> {code}
> java.io.File resolves relative paths like "target/something" that users might
> provide in the plugin configuration against the current directory which needs
> not be the project base directory. Therefore, path parameters should be
> declared of type java.io.File rather than simple strings as Maven seems to
> automatically push in properly resolved paths into the mojo. If one really
> needs the parameter to be of type String (i.e. to try resource lookup from
> class path), the best practice to properly get an absolute path should be
> documented.
> How to get a plugin ready for reactor builds might also be worth some warning
> words. What does one need to know about aggregator-style execution, execution
> project, forking ... ?
> A further improvement might be links to recommended libraries like
> plexus-utils or plexus-components. This would point peoply to existing code
> and prevent to error-prone reinvention of the wheel (only a few things on
> earth are that simple that people get them reliably right...)
--
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: (MENFORCER-34) Make code Java 1.4 compatible
Make code Java 1.4 compatible
-
Key: MENFORCER-34
URL: http://jira.codehaus.org/browse/MENFORCER-34
Project: Maven 2.x Enforcer Plugin
Issue Type: Task
Components: Standard Rules
Reporter: Benjamin Bentmann
Assignee: Brian Fox
Priority: Trivial
Attachments: java-1.4-compat.patch
The plugin's parent POM states Java 1.4 as the target platform but the code
does not successfully compile against this.
The patch simply includes a copy of the JDK code for the offending method
{{Arrays.hashCode()}}. Alternatively, you could use
{{[HashCodeBuilder|http://commons.apache.org/lang/api-release/org/apache/commons/lang/builder/HashCodeBuilder.html]}}
from commons-lang.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-188) Execution order of report plugins is arbitrary if inheritance is involved
[
http://jira.codehaus.org/browse/MSITE-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123441
]
Danilo Eiji Seki commented on MSITE-188:
I noticed something strange and made a test. I suspected plugins/reports were
being executed in *alphabetic order* (first by groupId, then by artifactId) and
so they are!
For example, I have a problem generating QALab reports in child projects,
because QALab plugin was always executed before the reports that generate data.
Then I noticed the reports were generated *almost* in the order I specify them
(I use the above alphabetic order, expept for the QALab plugin, that is the
last one). Then I imagined that maybe that happens because all my reports are
from {{org.*}} groups while QALab belongs to {{net.*}}.
I tested it by creating a dummy plugin by renaming the groupId of a QALab
report plugin to {{zzz.net.objectlab}} and deploying it to my local repository.
Then I changed my root dependency to this new one and magic, *IT WORKS*.
I suspect someone is using a sorted collection (tree set, etc). Some
display-beautifuly-list is messing things up.
> Execution order of report plugins is arbitrary if inheritance is involved
> -
>
> Key: MSITE-188
> URL: http://jira.codehaus.org/browse/MSITE-188
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: maven 2.0.4, windows 2000
>Reporter: David Vicente
>Priority: Critical
>
> I have created a maven 2 report : Dashboard report which aggregate all
> reports results in one report.
> My plugin must be executed as the last one even if i can't bind the
> "post-site" phase or use the "aggregator" annotation.
> I declare my report plugin as the last one in the reporting section of my POM.
> When i run mvn site on a single project, it's ok, my plugin has been
> executed as the last one.
> The reports list has been ordered as declared in my POM.
> But if i run "mvn site" on a multi-project POM, the reports list isn't
> ordered as before.
> I think, it's the same problem as
> http://jira.codehaus.org/browse/MNG-1994?page=all
--
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-1994) Execution order of child plugins is arbitrary if inheritance is involved
[
http://jira.codehaus.org/browse/MNG-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123442
]
Danilo Eiji Seki commented on MNG-1994:
---
I noticed something strange and made a test. I suspected plugins/reports were
being executed in *alphabetic order* (first by groupId, then by artifactId) and
so they are!
For example, I have a problem generating QALab reports in child projects,
because QALab plugin was always executed before the reports that generate data.
Then I noticed the reports were generated *almost* in the order I specify them
(I use the above alphabetic order, expept for the QALab plugin, that is the
last one). Then I imagined that maybe that happens because all my reports are
from {{org.*}} groups while QALab belongs to {{net.*}}.
I tested it by creating a dummy plugin by renaming the groupId of a QALab
report plugin to {{zzz.net.objectlab}} and deploying it to my local repository.
Then I changed my root dependency to this new one and magic, *IT WORKS*.
I suspect someone is using a sorted collection (tree set, etc). Some
display-beautifuly-list is messing things up.
> Execution order of child plugins is arbitrary if inheritance is involved
>
>
> Key: MNG-1994
> URL: http://jira.codehaus.org/browse/MNG-1994
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.1
>Reporter: John Didion
>Priority: Critical
> Fix For: 2.1
>
> Attachments: mergePluginLists.txt
>
>
> This is related to MNG-1499, but different, and, in my opinion, equally
> important. It makes sense that the order of plugin execution should be the
> same as it appears in the POM. For example, I have two plugins: one that
> generates a batch file and one that executes it. These plugins must run in
> order or the build will fail. However, the current implementation of
> ModelUtils.mergePluginLists does not respect the order of child plugins.
> There is also a seperate bug in that the assembledPlugins map is being
> checked for the presence of child plugins before adding them to the
> mergedPlugins list, but nothing is ever added to assembledPlugins. So if a
> plugin exists in a parent and a child, it will end up appearing twice in the
> child's plugin list.
> I have re-written this method to fix both these problems. See attached.
--
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: (MSITE-236) multi module reporting - main page doesn't show links to contained modules
[ http://jira.codehaus.org/browse/MSITE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-236. --- Assignee: Lukas Theussl Resolution: Duplicate > multi module reporting - main page doesn't show links to contained modules > -- > > Key: MSITE-236 > URL: http://jira.codehaus.org/browse/MSITE-236 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Reporter: Jan Vissers >Assignee: Lukas Theussl > > In a multi module project, the "site" generates a main page index.html, which > has the contained modules on the upper left hand corner in bold face. These > should be hyperlinks to the actual module's index.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: (MSITE-276) Links on Modules are completely broken on site:stage
[ http://jira.codehaus.org/browse/MSITE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-276. --- Assignee: Lukas Theussl Resolution: Duplicate > Links on Modules are completely broken on site:stage > > > Key: MSITE-276 > URL: http://jira.codehaus.org/browse/MSITE-276 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Jörg Hohwiller >Assignee: Lukas Theussl > > The latest maven-site-plugin 2.0-beta-6 seems to to introduce a new bug that > was NOT present in 2.0-beta-5: > Now all my modules point to the same url which is > "../../opt/project/build/development/projects/../dummyhost.de" > Something goes very wrong here: > 1. The link should not contain pathnames specific for the environment where > it was build (/opt/project/build/development/projects) nor the hostname and > path of the distributionManagement. > 2. The modulename itself is totally lost and all module-links in the menu > have the same href > Whatever has happend here, made it a lot worse. The site is now totally > unuseable. > It seems that only mvn site was tested before the 2.0-beta-6 was released. > Multimodule-Builds need to be tested with site:stage or site:deploy. -- 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-281) Assembly Descriptor from external or parent source
Assembly Descriptor from external or parent source -- Key: MASSEMBLY-281 URL: http://jira.codehaus.org/browse/MASSEMBLY-281 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Ben Tatham It would be really convenient if you could easily share assembly descriptors from the parent pom. If the parent pom defines an assembly (likely in pluginManagement), and the descriptor lives in that parent project, then the child should be able to run the same assembly, without having to explicitly download and unpack the parent project dependency. The same fix/feature could be used for other config-file based plugins, like maven-verifier-plugin, as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3398) Multiple Plugin Declarations Ignored with no warning
Multiple Plugin Declarations Ignored with no warning Key: MNG-3398 URL: http://jira.codehaus.org/browse/MNG-3398 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.8, 2.0.7 Reporter: Ben Tatham If I (accidentally) declare the same plugin in the pom twice, with different executions,only the executions from the first declaration are run. And no warning is given saying that it is ignoring the others. I figure there are two options to solve this: either use both declarations, or fail the build (fail -- not warning) to tell the user to fix their pom. -- 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: (MSITE-215) creates broken links for parents parent
[ http://jira.codehaus.org/browse/MSITE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-215. --- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0-beta-6 > creates broken links for parents parent > --- > > Key: MSITE-215 > URL: http://jira.codehaus.org/browse/MSITE-215 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Reporter: Jörg Hohwiller >Assignee: Dennis Lundberg > Fix For: 2.0-beta-6 > > Attachments: banana-world.zip > > > In a multi-project environment with modules that again have modules > (project/module1/module1A) the not only creates the > direct parent but all parents (see issue MSITE-136) what seems perfect to me. > Anyways only the link of the direct parent works for me. All other links are > broken. I use "mvn site:stage -DstagingDirectory=". > If I use -DstagingDirectory=/foo/bar then the link for "module1" is > "/foo/bar//module1/index.html" what is correct. But the link > for "project" is "/foo//index.html" but it should be > "/foo/bar//index.html". > Besides I do NOT want to have the "" what is automatically > produced from the "" of the POM, but is required for > site:stage to work. -- 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: (MSITE-261) Local Parent POM not found if specifies a directory
[
http://jira.codehaus.org/browse/MSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated MSITE-261:
Fix Version/s: 2.0-beta-7
> Local Parent POM not found if specifies a directory
> --
>
> Key: MSITE-261
> URL: http://jira.codehaus.org/browse/MSITE-261
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
> Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP SP2
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 2.0-beta-7
>
> Attachments: site-parent-pom.patch, site-parent-pom.patch
>
>
> The Maven core allows to specify a directory for the element
> in a module POM to locate the parent POM, e.g.{code:xml}
> ...
> ../parent
> {code}will properly find the parent POM in "../parent/pom.xml".
> However, the Site plugin does not follow this lookup strategy:{code}
> [INFO] [site:site]
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file '[SNIP]\..\parent'. for project unknown
> [INFO] Parent project loaded from repository.{code}
> This log output is actually from 2.0-beta-6-SNAPSHOT, 2.0-beta-5 outputs a
> different message but fails, too.
> The attached patch fixes this although I wonder whether this functionality is
> not already included somewhere in the Maven core (where is belongs IMHO).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-261) Local Parent POM not found if specifies a directory
[
http://jira.codehaus.org/browse/MSITE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123427
]
Lukas Theussl commented on MSITE-261:
-
It should also work if you just append a slash : "../parent/" which is the
correct way of denoting directories, see DOXIASITETOOLS-9. However, since maven
core supports it and the need for a slash is nowhere documented, I guess we
have to work around it.
> Local Parent POM not found if specifies a directory
> --
>
> Key: MSITE-261
> URL: http://jira.codehaus.org/browse/MSITE-261
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
> Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP SP2
>Reporter: Benjamin Bentmann
>Priority: Minor
> Attachments: site-parent-pom.patch, site-parent-pom.patch
>
>
> The Maven core allows to specify a directory for the element
> in a module POM to locate the parent POM, e.g.{code:xml}
> ...
> ../parent
> {code}will properly find the parent POM in "../parent/pom.xml".
> However, the Site plugin does not follow this lookup strategy:{code}
> [INFO] [site:site]
> [INFO] Unable to load parent project from a relative path: Could not find the
> model file '[SNIP]\..\parent'. for project unknown
> [INFO] Parent project loaded from repository.{code}
> This log output is actually from 2.0-beta-6-SNAPSHOT, 2.0-beta-5 outputs a
> different message but fails, too.
> The attached patch fixes this although I wonder whether this functionality is
> not already included somewhere in the Maven core (where is belongs IMHO).
--
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: (MSITE-174) Default bundle used not correct
[
http://jira.codehaus.org/browse/MSITE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-174.
---
Assignee: Lukas Theussl
Resolution: Fixed
Fix Version/s: 2.0-beta-7
Applied, thanks!
> Default bundle used not correct
> ---
>
> Key: MSITE-174
> URL: http://jira.codehaus.org/browse/MSITE-174
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: internationalization
> Environment: trunk, french os
>Reporter: Vincent Siveton
>Assignee: Lukas Theussl
> Fix For: 2.0-beta-7
>
> Attachments: i18n-en.patch
>
>
> Using this configuration, MSITE produces only french reports:
> {code:xml}
>
> fr,en
>
> {code}
--
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: (DOXIA-215) Trailing spaces after table definition causes exception
Trailing spaces after table definition causes exception
---
Key: DOXIA-215
URL: http://jira.codehaus.org/browse/DOXIA-215
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.0-alpha-10
Environment: Linux Fedore Core 6, Maven 2.0.7
Reporter: Felipe Kamakura
Any extra white spaces after a table definition (e.g. after a {{|cell1|cell2|}}
) causes a {{java.lang.ArrayIndexOutOfBoundsException}} to be thrown.
The stack trace is the following:
{code}
java.lang.ArrayIndexOutOfBoundsException: 2
at
org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791)
at
org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:771)
at
org.apache.maven.doxia.module.confluence.parser.table.TableCellBlock.before(TableCellBlock.java:38)
at
org.apache.maven.doxia.module.confluence.parser.AbstractFatherBlock.traverse(AbstractFatherBlock.java:49)
at
org.apache.maven.doxia.module.confluence.parser.AbstractFatherBlock.traverse(AbstractFatherBlock.java:55)
at
org.apache.maven.doxia.module.confluence.parser.AbstractFatherBlock.traverse(AbstractFatherBlock.java:55)
at
org.apache.maven.doxia.module.confluence.ConfluenceParser.parse(ConfluenceParser.java:152)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:59)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:342)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:46)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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)
{code}
--
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: (MSITE-180) Missing url tag in (parent) pom make it ignore the site inheritence system
[ http://jira.codehaus.org/browse/MSITE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Falkenberg updated MSITE-180: - Attachment: multi-module-project.zip I've attached a sample, minimal, multi-module project which demonstrates the behavior described here even though the url-tag is set. The parent's site.xml overrides everything in the child module's site.xml except the links in the links-tag which are combined (like they should). You have to alter the project.url and project.distributionManagement.site.url to test it on your local machine. I've tested this with both maven-site-plugin version 2.0-beta-6 and 2.0-beta-7-SNAPSHOT with the same result using Maven 2.0.8 on OS X. Furthermore the site:stage-target doesn't generate working links between modules. I hope I have just messed up the configuration because I would really like to get this working :) > Missing url tag in (parent) pom make it ignore the site inheritence system > -- > > Key: MSITE-180 > URL: http://jira.codehaus.org/browse/MSITE-180 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-5 >Reporter: Geoffrey De Smet > Attachments: multi-module-project.zip > > > IF none of the poms (module or parent) don't have an url tag, like this: > > ... > ... > ... > > (It doesn't matter if they have url tags in scm, distribution etc) > THEN site inheritence quitely isn't applied, for example in the parent's > site.xml > > http://www.mavenblogs.org/"/> > > isn't inherited in the childe module's site. > proposed solutions: > - or fix it :) > - or document this wanted behaviour in the site plugin's documentation at > http://maven.apache.org/plugins/maven-site-plugin/howto.html > with something like > "Site inheritence only works if you have a url tag in your parent pom." > because this can cost people many hours - it did for me > But once site inheritence works, it's very nice though :) -- 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: (DOXIA-214) macro for module overview list
[ http://jira.codehaus.org/browse/DOXIA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123420 ] Lukas Theussl commented on DOXIA-214: - This should be done by the site plugin, doxia doesn't know anything about (project) modules. > macro for module overview list > -- > > Key: DOXIA-214 > URL: http://jira.codehaus.org/browse/DOXIA-214 > Project: Maven Doxia > Issue Type: New Feature >Reporter: Jörg Hohwiller > > In maven 1 the multiproject site generated a quite useful html table listing > all sub-projects (modules) of a project. > With maven 2 I can only find the module links in generated in the menu. > However the name has to fit in the tiny menu and therefore sometimes does not > give an idea > of what to expect. > I would like to see a doxia macro that could generate a module overview list > showing the modules > with their description. The module names should be a link to the module just > as the navigation does. > This would allow to place such a handy overview on the front-page via > index.xml / index.apt > The perfect solution would be to have a configuration option to specify the > columns of the overview table: > -- 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: (DOXIA-40) Request for a TOC-like feature
[ http://jira.codehaus.org/browse/DOXIA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123417 ] Lukas Theussl commented on DOXIA-40: This was done in alpha-9, so it's included in site plugin 2.0-beta-6. See http://maven.apache.org/doxia/macros/index.html. > Request for a TOC-like feature > -- > > Key: DOXIA-40 > URL: http://jira.codehaus.org/browse/DOXIA-40 > Project: Maven Doxia > Issue Type: New Feature >Reporter: Anuerin Diaz >Assignee: Vincent Siveton >Priority: Minor > > If it is possible, I would like to request for a TOC like functionality that > will generate links to certain headers (section, subsection, etc) on the > document. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-160) Generate a web site for multiple projects
[ http://jira.codehaus.org/browse/MSITE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123416 ] Gabriel Falkenberg commented on MSITE-160: -- Is links between modules supposed to work for site-plugin-multiproject cause it doesn't for me... > Generate a web site for multiple projects > - > > Key: MSITE-160 > URL: http://jira.codehaus.org/browse/MSITE-160 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-6 > Environment: Debian + Tomcat >Reporter: Franck HUGOT >Assignee: Vincent Siveton >Priority: Minor > > Hello, > Is there a way to generate only one web site for multiple projects? > I can't find a way to do this, except generate a web site for each project > and develop a specific home page that refer to each project home page. > Thanks in advance. -- 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: (DOXIA-145) Adding logger feature
[ http://jira.codehaus.org/browse/DOXIA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-145: Attachment: DOXIA-145.patch After some more discussion, here is my proposition: only DefaultDoxia extends AbstractLogEnabled. Sink, parser and macro have independent instances of a logger that they inherit from a super interface (note: api changes!) so in principle they can be set independently. In practice it's the parser that should propagate its logger to the sink and macros that it's using. I have put the logging package into a separate module to avoid a circular dependency, since both sink and parser should be LogEnabled. I have tested by adding a simple xdoc to the site-renderer test that contains an invalid element, one can see that the plexus logger injected in DefaultDoxia is used indeed. > Adding logger feature > - > > Key: DOXIA-145 > URL: http://jira.codehaus.org/browse/DOXIA-145 > Project: Maven Doxia > Issue Type: New Feature > Components: Core, Modules, Sink API >Reporter: Vincent Siveton > Fix For: 1.0-beta-1 > > Attachments: DOXIA-145.patch > > > Doxia needs to have logger capability insides -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-294) Can't escape ${project.version} as plain text inside apt +---- section, on *.apt.vm files
[
http://jira.codehaus.org/browse/MSITE-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123403
]
Dennis Lundberg commented on MSITE-294:
---
Putting
{code}
${project.version}
{code}
into a *.apt.vm file *will* replace it with the actual value of that property
from the pom. This is the intended behavior.
See "Filtering" at the bottom of
http://maven.apache.org/plugins/maven-site-plugin/usage.html
> Can't escape ${project.version} as plain text inside apt + section, on
> *.apt.vm files
> -
>
> Key: MSITE-294
> URL: http://jira.codehaus.org/browse/MSITE-294
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
> Environment: *.apt.vm files, and +- escaped section.
>Reporter: Andrew Hughes
>Priority: Critical
>
> You can reproduce this the following way.
> ./src/site/index.apt.vm (start)
> --
> This will appear without the backslashes
> {noformat}$\{project.version\}{noformat} and that's excellent. But you can't
> get this output in the escaped apt text section below.
> {noformat}
> +---
> However this apt escaped section still shows the backslashes inside this
> section $\{project.version\} and there is no known way the text can be shown
> as above.
> To make matters worse, when you put this in without the backslashes, you get
> the properties value (like a filter). See: ${project.version} not the desired
> string as above
> +---
> {noformat}
> -
> ./src/site/index.apt.vm (start)
--
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: (MEV-574) Incorrect metadata from java.xml
Incorrect metadata from java.xml Key: MEV-574 URL: http://jira.codehaus.org/browse/MEV-574 Project: Maven Evangelism Issue Type: Bug Components: Invalid Metadata Reporter: Adrian Skehill The maven-metadata for the javax.mail component is incorrect. When I open the metadata xml file it says: (http://repo1.maven.org/maven2/javax/mail/mail/maven-metadata.xml) javax.activation mail But this should be javax.mail mail -- 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: (SCM-357) UCM config_spec are not managed correctly
[ http://jira.codehaus.org/browse/SCM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Delesio updated SCM-357: Attachment: maven-scm-provider-clearcase-ClearCaseScmProviderRepositoryTest.patch maven-scm-provider-clearcase-ClearCaseScmProviderRepository.patch maven-scm-provider-clearcase-ClearCaseCheckOutCommand.patch I add the ability to make the autogenerated conf-spec more dynamic. By default the config spec will generate a line that looks like this: element -directory * /main/LATEST\n I altered the plugin to make the "/man/LATEST" dynamic. This can now be specified from the scm connection url as a 5th parm. So for instance if you wanted the config-spec to generate a line like the below: element * /main/fooBar/LATEST\n You could specify in the connection url to look like the below: scm:clearcase/main/fooBar/LATEST OR scm:clearcase|/main/fooBar/LATEST The 5th element must start with /main. > UCM config_spec are not managed correctly > - > > Key: SCM-357 > URL: http://jira.codehaus.org/browse/SCM-357 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.0 >Reporter: Jean-Philippe Hautin > Attachments: > maven-scm-provider-clearcase-ClearCaseCheckOutCommand.patch, > maven-scm-provider-clearcase-ClearCaseScmProviderRepository.patch, > maven-scm-provider-clearcase-ClearCaseScmProviderRepositoryTest.patch, > maven-scm-provider-clearcase-SCM-XXX.patch > > > I am using the UCM clearcase configuration. > Currently, the config_spec of the view does not contain the ucm section even > if we ask for UCM Clearcase. > This is due to the fact that the current behavior erase the existing > config_spec file with one with load rules. > I have added a tiny method in the ClearCaseCheckOutCommand to read the > existing config spec and merge it with load rules. -- 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-455) XML delimiter characters in attribute and text content are escaped twice.
[
http://jira.codehaus.org/browse/SUREFIRE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123399
]
Todor Todorov commented on SUREFIRE-455:
Thanks for your fast reaction. I agree, throwing information away is a bad
idea. In my test case I need a string delimiter and I use _null_ character. It
is unusual, but if the string contains XML fragments, it is a good choice I
think. I filtered only the _null_ character, because I read by mistake [XML 1.1
Specification|http://www.w3.org/TR/xml11/#charsets]. It extends the character
range with {{RestrictedChar}} set, so _null_ is probably the only bad character
left there.
> XML delimiter characters in attribute and text content are escaped twice.
> --
>
> Key: SUREFIRE-455
> URL: http://jira.codehaus.org/browse/SUREFIRE-455
> Project: Maven Surefire
> Issue Type: Bug
> Components: xml generation
>Affects Versions: 2.4, 2.4.1
>Reporter: Todor Todorov
> Fix For: 2.4.2
>
> Attachments: surefire-api.patch
>
>
> XML delimiter characters (left angle bracket, ampersand, etc.) are escaped
> twice in _TEST-*.xml_ files in _surefire-reports_ directory. For example the
> left angle bracket is replaced with < instead of < and the right
> angle bracket with > instead of >
> {code:xml}
>
> type="junit.framework.AssertionFailedError">
> junit.framework.AssertionFailedError: expected:<10> but
> was:<7>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotSame(Assert.java:278)
> at junit.framework.Assert.assertSame(Assert.java:242)
> at MyTest.testItem(MyTest.java:38)
>
>
> {code}
> The problem is that both *org.apache.maven.surefire.report.XMLReporter* and
> *org.apache.maven.surefire.util.PrettyPrintXMLWriter* are escaping the XML
> content. As a result the ampersand character is escaped once more time. In
> addition *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* has
> implementation error: three characters (ampersand, left angle bracket and
> right angle bracket) are replaced with *&*
> In the attached patch (for surefire-2.4.1) I removed
> *org.apache.maven.surefire.report.XMLReporter#escapeAttribute* method and
> fixed *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml*
> implementation. Afterwards the XML report was generated as expected:
> {code:xml}
>
> type="junit.framework.AssertionFailedError">
> junit.framework.AssertionFailedError: expected:<10> but was:<7>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotSame(Assert.java:278)
> at junit.framework.Assert.assertSame(Assert.java:242)
> at MyTest.testItem(MyTest.java:38)
>
>
> {code}
--
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-452) suitename always = "TestSuite" even if defined as property
[
http://jira.codehaus.org/browse/SUREFIRE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123473
]
Erez Nahir commented on SUREFIRE-452:
-
Any chance to deploy current fix soon? perhaps as 2.4.1.1 or 2.4.2?
We are blocked in this issue.
> suitename always = "TestSuite" even if defined as property
> --
>
> Key: SUREFIRE-452
> URL: http://jira.codehaus.org/browse/SUREFIRE-452
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.4, 2.4.1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_14
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> and also on Linux
>Reporter: Erez Nahir
> Fix For: 2.x
>
> Attachments: TestNGDirectoryTestSuite.java,
> TestNGDirectoryTestSuite.java
>
>
> Using surefire and testng with no testng.xml but with , the
> generated standard output xml always have suite name="TestSuite".
> This is an issue while using CruiseControl and JUnitReport to generate a
> JUnit report.
> Here is the configuration in my pom file:
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.4.1
>
> true
> fast
> broken
>
>
> suitename
> ${artifactId}
>
>
> testname
> ${artifactId}
>
>
>
>
> There is an attached patch too.
--
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: (MCHANGES-78) Build a changes report by parsing svn comments
[ http://jira.codehaus.org/browse/MCHANGES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123377 ] Emmanuel Hugonnet commented on MCHANGES-78: --- Just to to be up to date : the support of Mercurial is done. I have tried to be as close as possible to the maven-scm-api but there is a limitation due to the fact that the ChangeSet doesn't provide a revision number (which is accessible in mercurial and svn), so i have to modify the code of the providers (an give my own implementation). With this simple correction I would be able to be scm agnostic. Dennis, I have confirmed that setting the # does eliminate the need of a tracker. I hope to release this new version on codehaus soon. Emmanuel > Build a changes report by parsing svn comments > -- > > Key: MCHANGES-78 > URL: http://jira.codehaus.org/browse/MCHANGES-78 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement >Reporter: Emmanuel Hugonnet >Priority: Minor > Attachments: site.tar.gz, svn-changelog-plugin-jdk1.4.tar.gz, > svn-changelog-plugin.tar.gz, svnchangelog-plugin-jdk1.4.tar.gz > > > Builds a changes report by parsing svn comments. > You can configure this plugin as any reporting plugin. But it has specific > configuration parameters : > * grammar : this allows you to specify the grammar used to parse the svn > logs. > Currently it supports two grammars : > o "MANU" which uses @operation:issue; > o "REMY" with [operation:issue] > * trackerType : this allows you to specify the issue tracker used. > Currently it supports two trackers : > o codex > o jira > * trackerUrlPattern : this allows you to specify a pattern to link an > issue to any tracker. -- 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: (MRM-588) proxy logging is not always effective for diagnosing issues
[ http://jira.codehaus.org/browse/MRM-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123474 ] Maria Odea Ching commented on MRM-588: -- We should also log connection errors and timeouts. There were some reports in the users list that a dead remote repo caused Archiva to hang. Logging these would be helpful in diagnosing/identifying problems in Archiva. http://www.nabble.com/Bad-remote-repo-can-cause-Archiva-to-hang--td14873052.html > proxy logging is not always effective for diagnosing issues > --- > > Key: MRM-588 > URL: http://jira.codehaus.org/browse/MRM-588 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-beta-4 >Reporter: Brett Porter > Fix For: 1.1 > > > I would like to open discussion for what exactly needs to be logged, and at > what level, for proxy issues to be effectively diagnosed. With the current > configuration, I was unable to pinpoint some problems easily. > Some thoughts: > - don't talk about policies, but state what is happening > - always include the artifact and repository requested > - log more if it results in a NotFoundException > - condense information onto fewer lines where possible (if there are > concurrent requests, without an NDC these will start getting mixed up in the > logs) > Here are my thoughts: > DEBUG Artifact [x/y/z.jar] will not be requested from remote repository [foo] > as it didn't match whitelist items > DEBUG Artifact [x/y/z.jar] will not be requested from remote repository [foo] > as it matched blacklist item x/** > INFO Artifact [x/y/z.jar] requested from managed repository [internal], > checking remote repositories [central,java.net], excluding remote > repositories [foo] > Then: > INFO Artifact [x/y/z.jar] retrieved from remote repository [central], > skipping others > or > INFO Artifact [x/y/z.jar] not retrieved as it failed post-download policy > [bar-policy] (include reason) > And so on... > Thoughts? > An open question is what level to log this at: I feel that it should be at > INFO, but that might be too noisy by default. Perhaps the right thing to do > here is to add a connector configuration property that says whether to log > all requests (and if not, only log at debug level). -- 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: (MRM-651) Updated consumer plugin to build against the 1.1 apis
[ http://jira.codehaus.org/browse/MRM-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-651. Resolution: Fixed Patch applied -r627299. Thanks Stephen! :) > Updated consumer plugin to build against the 1.1 apis > - > > Key: MRM-651 > URL: http://jira.codehaus.org/browse/MRM-651 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Stephen Gargan >Priority: Trivial > Fix For: 1.1 > > Attachments: 1.1-plugin.patch > > > - Updated the DiscoverNewAritfactConsumer to use the 1.1 APIs. > - Added a simple unit test. -- 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: (MRM-598) Validation error on new repository creation
[ http://jira.codehaus.org/browse/MRM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-598: - Fix Version/s: 1.0.2 > Validation error on new repository creation > --- > > Key: MRM-598 > URL: http://jira.codehaus.org/browse/MRM-598 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-4 > Environment: Win Server 2003 >Reporter: Federico Dal Maso >Assignee: Maria Odea Ching > Fix For: 1.0, 1.0.2 > > Attachments: Bildschirmfoto.png > > > When I try to create a new snapshot repository by web interface I obtain this > validation error: > Repository Purge By Days Older Than needs to be between 0 and 1000. > even if field is correctly set to 30 > It is impossible to create a new repository! -- 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: (MRM-598) Validation error on new repository creation
[ http://jira.codehaus.org/browse/MRM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reopened MRM-598: -- Reopened issue as per last comment. > Validation error on new repository creation > --- > > Key: MRM-598 > URL: http://jira.codehaus.org/browse/MRM-598 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-4 > Environment: Win Server 2003 >Reporter: Federico Dal Maso >Assignee: Maria Odea Ching > Fix For: 1.0, 1.0.2 > > Attachments: Bildschirmfoto.png > > > When I try to create a new snapshot repository by web interface I obtain this > validation error: > Repository Purge By Days Older Than needs to be between 0 and 1000. > even if field is correctly set to 30 > It is impossible to create a new repository! -- 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: (CONTINUUM-1656) Spam
Spam Key: CONTINUUM-1656 URL: http://jira.codehaus.org/browse/CONTINUUM-1656 Project: Continuum Issue Type: Bug Components: Notification Subsystem Affects Versions: 1.1 Environment: Windows 2003 server, JRE 1.6.0_04-b12 Reporter: Dan Peder Eriksen If subversion is not available continuum will continue to send an ERROR message until it is available, even though continuum is set to only send notifcations on status change. This resulted in 2400 emails during a night when the subversion repository did not come online during a reboot. Build result: Provider message: The svn command failed. Command output: --- svn: PROPFIND request failed on '/svn/x/trunk/sub-projects/email-service' svn: PROPFIND of '/svn/x/trunk/sub-projects/email-service': could not connect to server (http://x..no:8082) --- -- 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
