[jira] Issue Comment Edited: (DOXIA-153) HTML tags in twiki not rendered correctly
[ http://jira.codehaus.org/browse/DOXIA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112200 ] Lukas Theussl edited comment on DOXIA-153 at 10/31/07 3:02 AM: --- Twiki is a text parser while html tags are handled by the xml parser in doxia. We have to find a way to mix the two in order to solve this issue. was: Twiki is a text parser while html tags are handles by the xml parser in doxia. We have to find a way to mix the two in order to solve this issue. > HTML tags in twiki not rendered correctly > - > > Key: DOXIA-153 > URL: http://jira.codehaus.org/browse/DOXIA-153 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Twiki >Affects Versions: 1.0-alpha-9 >Reporter: Alexander Hars > > TWiki formatting rules > (http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules) state that html > tags may be included in a Twiki Page. In some cases, this is required to > achieve certain effects. See the description of Verbatim Mode, where it says > that ... should be used in certain cases. > However, when running the mvn site on .twiki files, all "<" and ">" are > replaced by "<" and "> > Steps to reproduce: > Create a maven site project. > Add a .twiki file with the following content: > ---+ Twiki test > > Hello > Hello > > After the site has been generated, no tags will exist instead the > following will be shown: >Hello Hello-- 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-153) HTML tags in twiki not rendered correctly
[ http://jira.codehaus.org/browse/DOXIA-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-153: Summary: HTML tags in twiki not rendered correctly (was: HTML tags not rendered correctly) Twiki is a text parser while html tags are handles by the xml parser in doxia. We have to find a way to mix the two in order to solve this issue. > HTML tags in twiki not rendered correctly > - > > Key: DOXIA-153 > URL: http://jira.codehaus.org/browse/DOXIA-153 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Twiki >Affects Versions: 1.0-alpha-9 >Reporter: Alexander Hars > > TWiki formatting rules > (http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules) state that html > tags may be included in a Twiki Page. In some cases, this is required to > achieve certain effects. See the description of Verbatim Mode, where it says > that ... should be used in certain cases. > However, when running the mvn site on .twiki files, all "<" and ">" are > replaced by "<" and "> > Steps to reproduce: > Create a maven site project. > Add a .twiki file with the following content: > ---+ Twiki test > > Hello > Hello > > After the site has been generated, no tags will exist instead the > following will be shown: >Hello Hello-- 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-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112202 ] Joerg Schaible commented on MNG-3259: - Guess, I have to apologize now ... ;-) > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module 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: (MRM-544) Cleanup index of artifacts that are no longer in the repository
[ http://jira.codehaus.org/browse/MRM-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-544. Resolution: Fixed Fixed in -r590622 - remove artifact from index if artifact no longer exists in the file system - added tests > Cleanup index of artifacts that are no longer in the repository > --- > > Key: MRM-544 > URL: http://jira.codehaus.org/browse/MRM-544 > Project: Archiva > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-2 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.0-beta-4 > > > This was left out from MRM-37 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-212) Assembly Descriptor Schemas (XSD) have wrong targetNamespace
[ http://jira.codehaus.org/browse/MASSEMBLY-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112215 ] Manfred Geiler commented on MASSEMBLY-212: -- *PING* Just searched, but have no idea, where those XSDs are located in the SVN repo. If someone points me to them I can provide a patch. Regards, Manfred > Assembly Descriptor Schemas (XSD) have wrong targetNamespace > > > Key: MASSEMBLY-212 > URL: http://jira.codehaus.org/browse/MASSEMBLY-212 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2-beta-1, 2.2-beta-2, 2.2 >Reporter: Manfred Geiler >Priority: Minor > Fix For: 2.2 > > > There are two versions of Assembly XSDs on the website: > http://maven.apache.org/plugins/maven-assembly-plugin/ > Both define a targetNamespace "http://maven.apache.org/POM/4.0.0"; which is > wrong because those XSDs define the Schema for the Assembly Descriptor and > not the POM. > Proposed fix for assembly-1.0.0.xsd: > Change targetNamespace and xmlns to something like > "http://maven.apache.org/Assembly/1.0.0"; > Proposed fix for assembly-1.1.0-SNAPSHOT.xsd: > Change targetNamespace and xmlns to something like > "http://maven.apache.org/Assembly/1.1.0"; > Regards, > Manfred -- 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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112219
]
srikanth madarapu commented on MDEP-117:
Thats correct, i am running either mvn clean install or mvn install.
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped 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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112223
]
srikanth madarapu commented on MDEP-117:
The includes attribute also doesn't work. I am not sure if i understood it
correctly, but my understanding is that with includes, i can unzip a set of
files. For example *.properties in that zip file.
I have added **/*_*.properties to the above configuration.
I just wanted to unpack all the properties files that have '_' in their name.
But the zip is being unpacked. Do I need to open this as another defect?
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped 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] Closed: (MASSEMBLY-180) A bug in artifact filtering ( maven-common-artifact-filters )
[ http://jira.codehaus.org/browse/MASSEMBLY-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-180. Resolution: Fixed fixed in revId=590694 > A bug in artifact filtering ( maven-common-artifact-filters ) > - > > Key: MASSEMBLY-180 > URL: http://jira.codehaus.org/browse/MASSEMBLY-180 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Milos Volauf >Assignee: John Casey > Fix For: 2.2-beta-2 > > > I found this bug while using and section in > element. > I had to check the source code to understand the "Advanced Artifact-Matching > in includes and excludes". > I found a bug in the project maven-common-artifact-filters, 1.0-alpha-1. > I checked the class PatternIncludesArtifactFilter, revision 487820. > There is a bug in the method: > private boolean matchAgainst( String value, List patterns, boolean > regionMatch ) > There is an iteration of a list of patterns. When a pattern matches, the > method should return true. > When no pattern matches, it should return false. > However, when there is a pattern using a wildcard and this pattern does not > match, the flow > will reach the line 216 where the method returns false. > Gotcha! the next patterns are not tried > In other words, say we have : > > ... > > :jar: > :test-jar: > > ... > > The effect of the bug is that the seconds pattern (:test-jar:) will not be > used, because if matching of the first (:jar:) fails, > the method returns false, the next patterns is not used. > I hope I clarified this issue. -- 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-364) 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency
[ http://jira.codehaus.org/browse/SUREFIRE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated SUREFIRE-364: Description: Previously stable build now reports this: 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. 27-Oct-2007 12:04:15 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null 27-Oct-2007 12:04:15 27-Oct-2007 12:04:15 from the specified remote repositories: 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases (http://maven.catlin.com/maven2-repo/releases), 27-Oct-2007 12:04:15 Apache Snapshots (http://people.apache.org/repo/m2-snapshot-repository), 27-Oct-2007 12:04:15 stat-scm-sourceforge (http://stat-scm.sourceforge.net/maven2), 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots (http://maven.catlin.com/maven2-repo/snapshots), 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), 27-Oct-2007 12:04:15 codehaus.snapshots (http://snapshots.repository.codehaus.org), 27-Oct-2007 12:04:15 apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), 27-Oct-2007 12:04:15 Codehaus Snapshots (http://snapshots.repository.codehaus.org/ 27-Oct-2007 12:04:15 was: Previously stable build now reports this: 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. 27-Oct-2007 12:04:15 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null 27-Oct-2007 12:04:15 27-Oct-2007 12:04:15 from the specified remote repositories: 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases (http://maven.catlin.com/maven2-repo/releases), 27-Oct-2007 12:04:15 Apache Snapshots (http://people.apache.org/repo/m2-snapshot-repository), 27-Oct-2007 12:04:15 stat-scm-sourceforge (http://stat-scm.sourceforge.net/maven2), 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots (http://maven.catlin.com/maven2-repo/snapshots), 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), 27-Oct-2007 12:04:15 codehaus.snapshots (http://snapshots.repository.codehaus.org), 27-Oct-2007 12:04:15 apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), 27-Oct-2007 12:04:15 Codehaus Snapshots (http://snapshots.repository.codehaus.org/ 27-Oct-2007 12:04:15 Remaining Estimate: 0 minutes Original Estimate: 0 minutes Do these additional problems need to be in this issue, or can we close it? > 2.4-SNAPSHOT of 27th Oct 2007 has invalid Plexus dependency > --- > > Key: SUREFIRE-364 > URL: http://jira.codehaus.org/browse/SUREFIRE-364 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.4 >Reporter: Matt Read >Assignee: John Casey >Priority: Blocker > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Previously stable build now reports this: > 27-Oct-2007 12:04:15 [INFO] Failed to resolve artifact. > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 Couldn't find a version in [1.0-alpha-7, 1.0-alpha-8, > 1.0-alpha-9] to match range [1.0-alpha-10-SNAPSHOT,1.0-alpha-10-SNAPSHOT] > 27-Oct-2007 12:04:15 org.codehaus.plexus:plexus-archiver:jar:null > 27-Oct-2007 12:04:15 > 27-Oct-2007 12:04:15 from the specified remote repositories: > 27-Oct-2007 12:04:15 maven.catlin.com.repo.releases > (http://maven.catlin.com/maven2-repo/releases), > 27-Oct-2007 12:04:15 Apache Snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 stat-scm-sourceforge > (http://stat-scm.sourceforge.net/maven2), > 27-Oct-2007 12:04:15 maven.catlin.com.repo.snapshots > (http://maven.catlin.com/maven2-repo/snapshots), > 27-Oct-2007 12:04:15 central (http://repo1.maven.org/maven2), > 27-Oct-2007 12:04:15 codehaus.snapshots > (http://snapshots.repository.codehaus.org), > 27-Oct-2007 12:04:15 apache.snapshots > (http://people.apache.org/repo/m2-snapshot-repository), > 27-Oct-2007 12:04:15 Codehaus Snapshots > (http://snapshots.repository.codehaus.org/ > 27-Oct-2007 12:04:15 -- 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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112231
]
srikanth madarapu commented on MDEP-117:
Which functionality, is that the includeClassifiers or the includes ? or both ?
I am not sure how to tell which version i am using, as i said i have two
versions of unpack-dependencies in my repository, .0-alpha-1 and 2.0-alpha-4. I
guess it the alpha4. How can i tell? Is there any command likemvn
dependency:resolvefor plug-ins?
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped 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] Updated: (MNG-3068) Build extensions fail to load if not available locally and remote repo is defined in the same POM where the extension is defined
[
http://jira.codehaus.org/browse/MNG-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3068:
Vincent, is this the case addressed in the xar integration-test? If so, I can
close this now, since I've checked and that's working now.
> Build extensions fail to load if not available locally and remote repo is
> defined in the same POM where the extension is defined
>
>
> Key: MNG-3068
> URL: http://jira.codehaus.org/browse/MNG-3068
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1
>Reporter: Vincent Massol
>Assignee: John Casey
> Fix For: 2.1
>
>
> * If you define the remote repo in settings.xml it works
> * If you define it in the pom.xml file it doesn't work
> For example, this fails if xwiki-build-xar-handlers isn't available in the
> local repo:
> {noformat}
>
>
>
> com.xpn.xwiki.platform
> xwiki-build-xar-handlers
> 1.0-SNAPSHOT
>
>
>
>
>
> xwiki
> XWiki Maven2 Remote Repository
> http://maven.xwiki.org
>
> true
>
>
> true
>
>
>
>
> {noformat}
--
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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112230
]
Brian Fox commented on MDEP-117:
That functionality is only in the latest snapshot. Also, please confirm which
version you are using of the plugin.
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped 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] Created: (MANTRUN-76) problem with wsgen ant task from maven-antrun-plugin
problem with wsgen ant task from maven-antrun-plugin
Key: MANTRUN-76
URL: http://jira.codehaus.org/browse/MANTRUN-76
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Reporter: Kevin
I am using maven 2.0.4 and am trying to generate all of the portable artifacts
for a JAX-WS web service from a JAX-WS service endpoint implementation class.
I can generate them and specify the directory where the generated sources or
classes should come.
However, when I use:
sourcedestdir="${project.build.directory}/generated-sources/main/java"
destdir="${project.build.directory}/generated-classes/main/java"
and try to add this source directory as source directory in maven with:
${project.build.directory}/generated-sources/main/java
It still doesn't add it as source directory.
There is a plugin to add source directories: build-helper-maven-plugin
This solves the problem for eclipse, but the generated-classes are not added to
the jar that is created.
How can I add these generated-classes to the jar?
I already used wsimport several times and there I don't have any problems. The
generated-sources directory is added as source directory and the
generated-classes are in the jar that is created.
--
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-366) Out Of Memory exceptions in 2.4 SNAPSHOTs
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated SUREFIRE-366:
Description:
I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
fine.
Then something was changed (surefire or it's dependencies) - and now my simple
CRUD test cause OutOfMemory exception!
For enhancing i use ant call plugin:
Interesting, that now openjpa javaagent doesn't work (but it has worked in
Friday)
org.apache.maven.plugins
maven-surefire-plugin
once
-javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
true
Now it cause -
[INFO] Surefire report directory:
E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
orts
[INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
java.lang.reflect.InvocationTargetException
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
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/lang/exception/NestableRuntimeException
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
FATAL ERROR in native method: processing of -javaagent failed
at
org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
... 5 more
By the way - time of tests execution rises from one to another:
Running
ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
Running ru.lanit.ps.registry.service.address.AddressServiceTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.995 sec
Running ru.lanit.ps.registry.model.jibx.roffdoctype.ROffDocTypeBindingTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.434 sec
Running ru.lanit.ps.registry.service.appealterm.AppealTermServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.558 sec
Running
ru.lanit.ps.registry.service.rplacesrequirements.RPlacesRequirementsServiceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.835 sec
Running
ru.lanit.ps.registry.service.ractivitydirection.RActivityDirectionServiceTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 25.942 sec <<<
FAILURE! - OutOfMem
All tests is very simple CRUD tests
If i configure as following:
org.apache.maven.plugins
maven-surefire-plugin
once
-javaagent:${project.basedir}/../../openjpa_agent/openjpa-
[jira] Updated: (SUREFIRE-366) Out Of Memory exceptions in 2.4 SNAPSHOTs
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated SUREFIRE-366:
I've built maven itself using surefire 2.4-snapshot and both maven
2.0.8-snapshot and 2.1-snapshot, and haven't replicated this issue yet.
> Out Of Memory exceptions in 2.4 SNAPSHOTs
> -
>
> Key: SUREFIRE-366
> URL: http://jira.codehaus.org/browse/SUREFIRE-366
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexander Filipchik
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.4
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
> fine.
> Then something was changed (surefire or it's dependencies) - and now my
> simple CRUD test cause OutOfMemory exception!
> For enhancing i use ant call plugin:
>
>
> classpathref="maven.compile.classpath"
>
> classname="org.apache.openjpa.ant.PCEnhancerTask"/>
> classpath="${project.basedir}/target/classes">
> dir="${project.basedir}/target/classes">
>
>
>
>
> Interesting, that now openjpa javaagent doesn't work (but it has worked in
> Friday)
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
> -javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
> true
>
>
> Now it cause -
> [INFO] Surefire report directory:
> E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
> orts
> [INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
> java.lang.reflect.InvocationTargetException
> 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
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/exception/NestableRuntimeException
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> FATAL ERROR in native method: processing of -javaagent failed
> at
> org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
> ... 5 more
> By the way - time of tests execution rises from one to another:
> Running
> ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
> Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
> Running ru.lanit.ps.registry.service.address.AddressServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
> Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
> Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
> Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
> Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
> Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
> Tests
[jira] Updated: (SUREFIRE-366) Out Of Memory exceptions in 2.4 SNAPSHOTs
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated SUREFIRE-366:
Same thing with the assembly plugin, which has 217 unit tests that use mocks,
etc.
> Out Of Memory exceptions in 2.4 SNAPSHOTs
> -
>
> Key: SUREFIRE-366
> URL: http://jira.codehaus.org/browse/SUREFIRE-366
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexander Filipchik
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.4
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
> fine.
> Then something was changed (surefire or it's dependencies) - and now my
> simple CRUD test cause OutOfMemory exception!
> For enhancing i use ant call plugin:
>
>
> classpathref="maven.compile.classpath"
>
> classname="org.apache.openjpa.ant.PCEnhancerTask"/>
> classpath="${project.basedir}/target/classes">
> dir="${project.basedir}/target/classes">
>
>
>
>
> Interesting, that now openjpa javaagent doesn't work (but it has worked in
> Friday)
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
> -javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
> true
>
>
> Now it cause -
> [INFO] Surefire report directory:
> E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
> orts
> [INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
> java.lang.reflect.InvocationTargetException
> 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
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/exception/NestableRuntimeException
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> FATAL ERROR in native method: processing of -javaagent failed
> at
> org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
> ... 5 more
> By the way - time of tests execution rises from one to another:
> Running
> ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
> Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
> Running ru.lanit.ps.registry.service.address.AddressServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
> Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
> Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
> Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
> Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
> Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed
[jira] Commented: (SUREFIRE-366) Out Of Memory exceptions in 2.4 SNAPSHOTs
[
http://jira.codehaus.org/browse/SUREFIRE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112243
]
Alexander Filipchik commented on SUREFIRE-366:
--
After i had allocated 512Mb for my tests all tests passed successfully.
> Out Of Memory exceptions in 2.4 SNAPSHOTs
> -
>
> Key: SUREFIRE-366
> URL: http://jira.codehaus.org/browse/SUREFIRE-366
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexander Filipchik
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.4
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I use OpenJPA and Maven in my project. Up to 27.10.2007 all tests have worked
> fine.
> Then something was changed (surefire or it's dependencies) - and now my
> simple CRUD test cause OutOfMemory exception!
> For enhancing i use ant call plugin:
>
>
> classpathref="maven.compile.classpath"
>
> classname="org.apache.openjpa.ant.PCEnhancerTask"/>
> classpath="${project.basedir}/target/classes">
> dir="${project.basedir}/target/classes">
>
>
>
>
> Interesting, that now openjpa javaagent doesn't work (but it has worked in
> Friday)
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
> -javaagent:${project.basedir}/../../openjpa_agent/openjpa-1.0.0.jar=jdoEnhance=true
> true
>
>
> Now it cause -
> [INFO] Surefire report directory:
> E:\java\LANIT\PUBSER\checkout\trunk\dev\modules\registry\target\surefire-rep
> orts
> [INFO] Building jar: C:\WINDOWS\TEMP\surefirebooter20526.jar
> java.lang.reflect.InvocationTargetException
> 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
> sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:141)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/exception/NestableRuntimeException
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> FATAL ERROR in native method: processing of -javaagent failed
> at
> org.apache.openjpa.enhance.PCEnhancerAgent.premain(PCEnhancerAgent.java:61)
> ... 5 more
> By the way - time of tests execution rises from one to another:
> Running
> ru.lanit.ps.registry.service.radministrativelevel.RAdministrativeLevelServiceTe
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.671 sec
> Running ru.lanit.ps.registry.service.appeal.AppealServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.749 sec
> Running ru.lanit.ps.registry.service.address.AddressServiceTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.155 sec
> Running ru.lanit.ps.registry.model.jibx.rpaymenttype.RPaymentTypeBindingTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.093 sec
> Running ru.lanit.ps.registry.service.addresstype.RAddressTypeServiceTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.64 sec
> Running ru.lanit.ps.registry.service.pspassport.PsPassportTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.795 sec
> Running ru.lanit.ps.registry.service.functionary.FunctionaryTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.058 sec
> Running ru.lanit.ps.registry.service.paymenttype.PaymentTypeServiceTest
> Tests run: 4, Failures: 0, Er
[jira] Created: (MRM-577) Metadata aren't generated by archiva
Metadata aren't generated by archiva
Key: MRM-577
URL: http://jira.codehaus.org/browse/MRM-577
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-beta-3
Reporter: Arnaud Heritier
To reproduce it you proxy the repo of snapshots at apache :
http://people.apache.org/repo/m2-snapshot-repository
And in your project you add this plugin declaration :
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-2-SNAPSHOT
{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: (CONTINUUM-1539) French langage misspelling
French langage misspelling -- Key: CONTINUUM-1539 URL: http://jira.codehaus.org/browse/CONTINUUM-1539 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1-beta-4 Reporter: Damien Lecan Attachments: CONTINUUM-1534-1.patch Here is french langage patch to correct misspelling -- 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-577) Metadata aren't generated by archiva
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112250
]
Joakim Erdfelt commented on MRM-577:
Archiva responds with a HTTP 404 on the request for that maven-metadata.xml,
researching cause now.
> Metadata aren't generated by archiva
>
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>
> To reproduce it you proxy the repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {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: (MRM-577) Metadata aren't generated by archiva
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112249
]
Joakim Erdfelt commented on MRM-577:
Its not that metadata isn't generated, it simply isn't even being downloaded
from the remote proxies. :-(
I can sniff the traffic and see the request going into archiva for the
maven-metadata.xml, but not out of archiva to the proxy.
> Metadata aren't generated by archiva
>
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>
> To reproduce it you proxy the repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {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] Closed: (MSITE-267) Relative path in inherited sites broken for depth of 2
[ http://jira.codehaus.org/browse/MSITE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-267. - Resolution: Cannot Reproduce > Relative path in inherited sites broken for depth of 2 > -- > > Key: MSITE-267 > URL: http://jira.codehaus.org/browse/MSITE-267 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.0-beta-6 > Environment: SunOS >Reporter: Dave Meibusch > > Parent site.xml has bannerLeft with absolute URL in that is > /images/logo.gif > First child module has (correctly) rendered relative path of: > ../images/logo.gif > Grandchild module (child of first child) has (incorrectly) rendered path of: > ../../../images/logo.gif > An extra depth has been added to the relative URL. > If the bannerLeft URL is a relative URL, the first child module has an > incorrectly rendered path (again, extra '../' depth). -- 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-577) Release policy of disabled fails all metadata requests.
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-577:
---
Priority: Minor (was: Major)
Description:
Unable to successfully download maven-metadata.xml files when the release
policy is set to disabled.
To reproduce it:
1) Setup a proxy connector to repo of snapshots at apache :
http://people.apache.org/repo/m2-snapshot-repository
1a) Set the Release policy to "disabled".
2) And in your project you add this plugin declaration :
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-2-SNAPSHOT
{code}
3) Attempt to compile the project.
was:
To reproduce it you proxy the repo of snapshots at apache :
http://people.apache.org/repo/m2-snapshot-repository
And in your project you add this plugin declaration :
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-2-SNAPSHOT
{code}
Fix Version/s: 1.0-beta-4
Component/s: repository interface
Summary: Release policy of disabled fails all metadata requests.
(was: Metadata aren't generated by archiva)
Correcting reason for failure.
> Release policy of disabled fails all metadata requests.
> ---
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
> Components: repository interface
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>Priority: Minor
> Fix For: 1.0-beta-4
>
>
> Unable to successfully download maven-metadata.xml files when the release
> policy is set to disabled.
> To reproduce it:
> 1) Setup a proxy connector to repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> 1a) Set the Release policy to "disabled".
> 2) And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {code}
> 3) Attempt to compile the 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] Created: (MSITE-269) Urls rewritten when they contain the project urls' hostname
Urls rewritten when they contain the project urls' hostname --- Key: MSITE-269 URL: http://jira.codehaus.org/browse/MSITE-269 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Cameron Jones Attachments: pom.xml, site.xml Urls in the site.xml file are being rewritten if they contain the hostname of the project url. For example: pom.xml: http://208.75.85.243 ... test.site file:///srv/www/test/site ... site.xml: http://208.75.85.243/index.html"; /> Results in the following link for the About page which is incorrect and includes the deployment location instead of the url: http://208.75.85.243/test/site/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] Updated: (CONTINUUM-1539) French langage misspelling
[ http://jira.codehaus.org/browse/CONTINUUM-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1539: Fix Version/s: 1.1 > French langage misspelling > -- > > Key: CONTINUUM-1539 > URL: http://jira.codehaus.org/browse/CONTINUUM-1539 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1-beta-4 >Reporter: Damien Lecan > Fix For: 1.1 > > Attachments: CONTINUUM-1534-1.patch > > > Here is french langage patch to correct misspelling -- 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: (MRELEASE-113) prepare dryRun should also run site:site
[ http://jira.codehaus.org/browse/MRELEASE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112281 ] Barrett Nuzum commented on MRELEASE-113: This is paramount. We have had issues where the only thing preventing a release is a failure in the site plugin. Due to the sticky nature of the tags the release plugin makes, the only solution is rollback, fix, and then rerelease. This is not only extremely time consuming, but entirely preventible. > prepare dryRun should also run site:site > > > Key: MRELEASE-113 > URL: http://jira.codehaus.org/browse/MRELEASE-113 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Mike Perham > > Currently just runs 'clean integration-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: (MSITE-269) Urls rewritten when they contain the project urls' hostname
[ http://jira.codehaus.org/browse/MSITE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-269: -- Affects Version/s: (was: 2.0-beta-7) > Urls rewritten when they contain the project urls' hostname > --- > > Key: MSITE-269 > URL: http://jira.codehaus.org/browse/MSITE-269 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Cameron Jones > Attachments: pom.xml, site.xml > > > Urls in the site.xml file are being rewritten if they contain the hostname of > the project url. For example: > pom.xml: > http://208.75.85.243 > ... > > test.site > file:///srv/www/test/site > > ... > site.xml: > http://208.75.85.243/index.html"; /> > Results in the following link for the About page which is incorrect and > includes the deployment location instead of the url: > http://208.75.85.243/test/site/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] Created: (MCHANGELOG-77) Unable to find repository location for moved then re-created folders
Unable to find repository location for moved then re-created folders Key: MCHANGELOG-77 URL: http://jira.codehaus.org/browse/MCHANGELOG-77 Project: Maven 2.x Changelog Plugin Issue Type: Bug Reporter: Cameron Jones I have a folder in source control which was renamed in order to allow for a new folder to be created in it's place. Since this the changelog plugin can not retrieve the logs giving the error - "Unable to find repository location for"... After a bit of tracking down i found this: http://svnx.lachoseinteractive.net/ticket/22 It appears that the svn command could include the revision number which would fix the issue. -- 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-1540) data-management-cli-1.1-beta-4-app.jar will not import builds data
data-management-cli-1.1-beta-4-app.jar will not import builds data --- Key: CONTINUUM-1540 URL: http://jira.codehaus.org/browse/CONTINUUM-1540 Project: Continuum Issue Type: Bug Components: Data Management Affects Versions: 1.1-beta-4 Environment: Win32 (Windows Server 2003) Reporter: Fred Eckertson data-management-cli-1.1-beta-4-app.jar will not import build data exported from a configured 1.1-bata-3 system. The import attempts to delete BUILDDEFINITION records and fails because of foreign key constraints. The canned records in a pristene 1.1-beta-4 instance are not being deleted in the proper order. Apparently this is because of the new tables PROJECT_BUILDDEFINITION, PROJECTGROUP_BUILDDEFINITION, etc. and the new key constraints that come with them. -- 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: (MAVENUPLOAD-1731) ACEGI-JSF Component Library
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cagatay Civici reopened MAVENUPLOAD-1731: - Updated the fixed bundle > ACEGI-JSF Component Library > --- > > Key: MAVENUPLOAD-1731 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1731 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Cagatay Civici >Assignee: Carlos Sanchez > > ACEGI-JSF Integration library contains the reimplementation of ACEGI's JSP > tags as JSF components. -- 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: (MCHANGELOG-77) Unable to find repository location for moved then re-created folders
[ http://jira.codehaus.org/browse/MCHANGELOG-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112293 ] Cameron Jones commented on MCHANGELOG-77: - As a work around you can explicitly set the report date to start after the time the folder was moved. > Unable to find repository location for moved then re-created folders > > > Key: MCHANGELOG-77 > URL: http://jira.codehaus.org/browse/MCHANGELOG-77 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Reporter: Cameron Jones > > I have a folder in source control which was renamed in order to allow for a > new folder to be created in it's place. Since this the changelog plugin can > not retrieve the logs giving the error - "Unable to find repository location > for"... > After a bit of tracking down i found this: > http://svnx.lachoseinteractive.net/ticket/22 > It appears that the svn command could include the revision number which would > fix the issue. -- 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: (MCHANGELOG-78) Descending date order
Descending date order - Key: MCHANGELOG-78 URL: http://jira.codehaus.org/browse/MCHANGELOG-78 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Reporter: Cameron Jones Priority: Minor The reports generated are ordered in ascending order whereas the entries in each report are descending. It's a bit confusing, i'd like to see it all descending so you always have the most recent changes at the top. -- 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-577) Release policy of disabled fails all metadata requests.
[
http://jira.codehaus.org/browse/MRM-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-577.
--
Resolution: Fixed
Fixing release and snapshot policies to not apply their policy rules to
non-artifacts. (namely maven-metadata.xml files)
Workaround: do not use DISABLED setting for the policies.
Fix committed to archiva/trunk revision 590858.
> Release policy of disabled fails all metadata requests.
> ---
>
> Key: MRM-577
> URL: http://jira.codehaus.org/browse/MRM-577
> Project: Archiva
> Issue Type: Bug
> Components: repository interface
>Affects Versions: 1.0-beta-3
>Reporter: Arnaud Heritier
>Assignee: Joakim Erdfelt
>Priority: Minor
> Fix For: 1.0-beta-4
>
>
> Unable to successfully download maven-metadata.xml files when the release
> policy is set to disabled.
> To reproduce it:
> 1) Setup a proxy connector to repo of snapshots at apache :
> http://people.apache.org/repo/m2-snapshot-repository
> 1a) Set the Release policy to "disabled".
> 2) And in your project you add this plugin declaration :
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.2-beta-2-SNAPSHOT
>
> {code}
> 3) Attempt to compile the 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] Commented: (MCOMPILER-20) add bootclasspath support to forked java compiler
[
http://jira.codehaus.org/browse/MCOMPILER-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112295
]
Benjamin Bentmann commented on MCOMPILER-20:
bq. xerces:xerces
Wouldn't something like
{code:xml}
bla
bla
...
{code}
be more Maven-like? Personally, I don't like the single string approach for
artifact naming in configurations as it requires one to remember the proper
order of its components. This single string introduces another syntactical
element that users must learn to understand and developers must properly parse.
I would argue that XML's parsing facilities are sufficient to avoid such
artifical constructs.
bq. The bootclasspath should be configurable not only for the forked version
but should be a general feature.
+1
bq. [...] that the ability to specifiy the bootclasspath also lacks in the
underlying plexus compiler plugin.
The maven-compiler-plugin already knows how to pass arbitrary arguments using
the element. The hint given at
http://docs.codehaus.org/display/MAVENUSER/Compile+and+Test+with+Different+JDK+Versions
makes use of this. The remaining work would be to avoid hard-coding local repo
paths but to make use of Maven's artifact resolution from remote repos.
> add bootclasspath support to forked java compiler
> -
>
> Key: MCOMPILER-20
> URL: http://jira.codehaus.org/browse/MCOMPILER-20
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Brett Porter
>
> this can be required to override the DOM library used, f.e.
> M1 supports arbitrary paths, and an extdirs for the same thing. Perhaps we
> have add extdirs for the paths, and select dependencies for the
> bootclasspath, ie:
>
>
> xerces:xerces
>
>
> ...
>
>
--
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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112296
]
Brian Fox commented on MDEP-117:
You should always specify the version in your pom. The filtering of unpacked
artifacts is available in alpha-5-SNAPSHOT, the rest in alpha-4
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped 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] Closed: (MRM-571) Create UserRepositories object in archiva-security
[ http://jira.codehaus.org/browse/MRM-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-571. Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-4) was addressed in a separate issue > Create UserRepositories object in archiva-security > -- > > Key: MRM-571 > URL: http://jira.codehaus.org/browse/MRM-571 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Brett Porter >Priority: Critical > > Create a component to aide in filtering of ManagedRepositories based on user > permissions. > The two methods definitely needed (could be more) > * List getAllowedObservingRepositories( > String principal ); > * List getAllowedManagingRepositories( String > principal ); > Care will be needed to ensure that these lookups performs well (possible > caching needed). -- 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-572) Migrate continuum builds of archiva-security to new svn url
[ http://jira.codehaus.org/browse/MRM-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-572. Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-4) > Migrate continuum builds of archiva-security to new svn url > --- > > Key: MRM-572 > URL: http://jira.codehaus.org/browse/MRM-572 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Brett Porter >Priority: Critical > -- 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-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/
[ http://jira.codehaus.org/browse/MRM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-570. Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 1.0-beta-4) Joakim decided this wasn't necessary. > archiva-security/ needs to move from archiva-webapp/ to archiva-base/ > - > > Key: MRM-570 > URL: http://jira.codehaus.org/browse/MRM-570 > Project: Archiva > Issue Type: Task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Assignee: Brett Porter >Priority: Critical > > Since we need to implement backend security around the browse (MRM-569) and > search (MRM-516) facilities, the archiva-security module needs to be > decoupled from archiva-webapp and brought into archiva-base for the general > use of all archiva-base modules. > Leaving archiva-security like it is now will result in pulling in many webapp > specific libraries and concepts that are not needed in the archiva-base > heirarchy. -- 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-548) proxy connectors: default policies for added repositories may not be optimal
[ http://jira.codehaus.org/browse/MRM-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-548: - Priority: Minor (was: Major) Summary: proxy connectors: default policies for added repositories may not be optimal (was: proxy connectors: default policies are not correct on add) confirmed - it currently checks for updates from the repository on every request. This would not be optimal in a large team environment - however daily is probably too infrequent. I would suggest hourly is a reasonable compromise? > proxy connectors: default policies for added repositories may not be optimal > > > Key: MRM-548 > URL: http://jira.codehaus.org/browse/MRM-548 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0-beta-4 > > > the default for snapshots and releases is "ignored" for updates. This is > inconsistent with Maven default behaviour - should it be daily? -- 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-141) clean up design documentation
[ http://jira.codehaus.org/browse/MRM-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-141: - Summary: clean up design documentation (was: update design documentation) I would suggest we only need to do the following for 1.0: - get rid of documents that are no longer relevant (probably mine in the indexing and the proxying modules) - set aside a space for such documents in a structured way so we can gradually grow them back again - incorporate Deng's document. > clean up design documentation > - > > Key: MRM-141 > URL: http://jira.codehaus.org/browse/MRM-141 > Project: Archiva > Issue Type: Task > Components: design >Reporter: Brett Porter > Fix For: 1.0-beta-4 > > > - the indexing design docs don't indicate how to use the indexer from an API > perspective > - there needs to be a more general "this is the architecture" design 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: (MRM-547) proxy connectors: cache failures options are confusing
[
http://jira.codehaus.org/browse/MRM-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112303
]
Joakim Erdfelt commented on MRM-547:
A discussion and decision has been made in the mailing list.
All policy settings are getting a thorough cleanup.
{noformat}
Releases (how often to check for)
(old) IGNORED, ONCE, HOURLY, DAILY, DISABLED
(new) ALWAYS, ONCE, HOURLY, DAILY, NEVER
Snapshots (for often to check for)
(old) IGNORED, ONCE, HOURLY, DAILY, DISABLED
(new) ALWAYS, ONCE, HOURLY, DAILY, NEVER
Cache-Failures
(old) IGNORED, CACHED
(new) NO, YES
Checksum
(old) IGNORED, FIX, FAIL
(new) IGNORE, FIX, FAIL
{noformat}
With new descriptions:
(for releases / snapshots policies)
* ALWAYS : Means that the artifact is always updated from the remote repo.
* ONCE : Means the artifact is updated only ever ONCE from the remote repo. If
it exists on the local repo, the remote repo is never hit for that artifact.
* HOURLY : Means the artifact is updated from the remote repo, only if it is at
least one hour old on the local repo.
* DAILY : Means the artifact is updated from the remote repo, only if it is at
least 1 day old on the local repo.
* NEVER : Means the artifact is never updated from the remote repo.
(for cache-failures)
* NO : Means that the existence of old failures is not checked. All resource
requests are allowed thru to the remote repo.
* YES : Means that the existence of old failures is checked, and will prevent
the request from being performed against the remote repo.
(for checksum)
* IGNORE : Means the contents / validity of the checksum files is ignored.
* FIX : Means that the checksum files are regenerated from the downloaded
resources.
* FAIL : Means that the checksum files are validated against the downloaded
resource, if the resource does not pass the checksum validation, the resource
and the checksum files are deleted from the local repository and a failure is
issued for the transfer.
> proxy connectors: cache failures options are confusing
> --
>
> Key: MRM-547
> URL: http://jira.codehaus.org/browse/MRM-547
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-2
>Reporter: Brett Porter
>Priority: Minor
> Fix For: 1.0-beta-4
>
>
> I think this should be renamed to just "failures" which can be "cached" or
> "ignored", or otherwise be changed to a yes/no value for "cached failures".
--
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: (MRM-556) not possible to configure purge by retention count
[ http://jira.codehaus.org/browse/MRM-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-556 started by Maria Odea Ching. > not possible to configure purge by retention count > -- > > Key: MRM-556 > URL: http://jira.codehaus.org/browse/MRM-556 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Maria Odea Ching >Priority: Critical > Fix For: 1.0-beta-4 > > > currently, this is activated by a 0 value in the # days field, but the > validation prevents that from happening. > I believe the behaviour should be as follows: > - the retention count is the *minimum* number to retain - this many are > guaranteed. Valid values are >= 1 > - the # of days is the actual filter applied. Valid values are >= 0 > So, the retained snapshots is the union of the two sets of results. > However, the retention count still does not apply to something that is > handled by "delete released snapshots", these should always be deleted in > their entirety. -- 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: (CONTINUUM-1472) No navigation on Project Release Summary page
[ http://jira.codehaus.org/browse/CONTINUUM-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112308 ] Wendy Smoak commented on CONTINUUM-1472: This is important for people who use the release functionality. Any chance we can get a navigation button added to the "Project Release Summary" page for 1.1? Example URL for the page in question: http://artemis:9097/continuum/releaseViewResult.action?projectId=1&releaseId=net.wsmoak%3Ahello (There's probably a similar issue for the results page after 'Perform Release'.) > No navigation on Project Release Summary page > - > > Key: CONTINUUM-1472 > URL: http://jira.codehaus.org/browse/CONTINUUM-1472 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Maria Catherine Tan >Priority: Minor > > If you click 'View Output' after Prepare for Release finishes, the only way > to get back from the Project Release Summary page is to use the browser back > button. -- 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-1541) NPE with "Provide Release Parameters"
NPE with "Provide Release Parameters" - Key: CONTINUUM-1541 URL: http://jira.codehaus.org/browse/CONTINUUM-1541 Project: Continuum Issue Type: Bug Components: Release Affects Versions: 1.1-beta-4 Environment: Continuum 1.1.-beta-4 Ubuntu 7 Server Reporter: Wendy Smoak To reproduce: 1. Complete 'Prepare for Release' as usual 2. Choose "Perform project release" 3. Select "Provide Release Parameters" (rather than selecting the version number you just prepared) 4. Fill in the scm credentials and an existing tag, such as 'hello-1.0.3' 5. Click 'Done' It should work, but instead you get a NPE: Error Occurred java.lang.NullPointerException Show/hide Stack Trace java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:336) at org.apache.maven.continuum.web.action.ReleaseInProgressAction.execute(ReleaseInProgressAction.java:63) 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 com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192) at org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:174) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.i
[jira] Closed: (MRM-549) proxy connectors: no "always" option for releases and snapshots policies
[ http://jira.codehaus.org/browse/MRM-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-549. -- Assignee: Joakim Erdfelt Resolution: Fixed Fixed in archiva/trunk revision 590908. > proxy connectors: no "always" option for releases and snapshots policies > > > Key: MRM-549 > URL: http://jira.codehaus.org/browse/MRM-549 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-4 > > -- 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-547) proxy connectors: cache failures options are confusing
[ http://jira.codehaus.org/browse/MRM-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-547. -- Assignee: Joakim Erdfelt Resolution: Fixed Fixed in archiva/trunk revision 590908. > proxy connectors: cache failures options are confusing > -- > > Key: MRM-547 > URL: http://jira.codehaus.org/browse/MRM-547 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-4 > > > I think this should be renamed to just "failures" which can be "cached" or > "ignored", or otherwise be changed to a yes/no value for "cached failures". -- 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-548) proxy connectors: default policies for added repositories may not be optimal
[ http://jira.codehaus.org/browse/MRM-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112312 ] Joakim Erdfelt commented on MRM-548: Current default settings in archiva/trunk (checked on revision 590908). (NOTE: These use the new terms as outlined in MRM-547) Releases: Hourly Snapshots: Hourly Cached-Failures: No Checksum Policy: Fix If this is satisfactory, then this jira can be closed. > proxy connectors: default policies for added repositories may not be optimal > > > Key: MRM-548 > URL: http://jira.codehaus.org/browse/MRM-548 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0-beta-4 > > > the default for snapshots and releases is "ignored" for updates. This is > inconsistent with Maven default behaviour - should it be daily? -- 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-548) proxy connectors: default policies for added repositories may not be optimal
[ http://jira.codehaus.org/browse/MRM-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-548. Assignee: Joakim Erdfelt Resolution: Fixed > proxy connectors: default policies for added repositories may not be optimal > > > Key: MRM-548 > URL: http://jira.codehaus.org/browse/MRM-548 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-4 > > > the default for snapshots and releases is "ignored" for updates. This is > inconsistent with Maven default behaviour - should it be daily? -- 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
