[jira] Commented: (DOXIA-103) Input encoding handling problem
[ http://jira.codehaus.org/browse/DOXIA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103535 ] Lukas Theussl commented on DOXIA-103: - DOXIA-133 and MSITE-239 have related test cases, however I don't know if the patch at DOXIA-133 is the best solution. I'd like to discuss encoding related issues for beta-1... later (vacation time for me now... :) ) > Input encoding handling problem > --- > > Key: DOXIA-103 > URL: http://jira.codehaus.org/browse/DOXIA-103 > Project: Maven Doxia > Issue Type: Bug > Components: Site Renderer > Environment: Linux, Java 5 >Reporter: Sergey N. Zaitsev >Priority: Trivial > Fix For: 1.0-alpha-9 > > Attachments: default-site-renderer.diff > > > Site Renderer ignores parameter and uses ISO-8859-1 encoding > when reading source files . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTTASKS-78) unable to download a dependency when it is a SNAPSHOT and multiple remoteRepositories are used
[
http://jira.codehaus.org/browse/MANTTASKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-78:
---
Attachment: MANTTASKS-78.diff
Found and fixed the problem
When no id is specified on a repository declaration, a default id is used.
It was hardcoded as "remote" (even for local repo).
Then if there was 2 remoteRepository declarations, they had the same id even if
they were for different urls...
With this patch, the default id for local repo is "local", and the url for a
remote repo: we can't have the same id when 2 repos are different
> unable to download a dependency when it is a SNAPSHOT and multiple
> remoteRepositories are used
> --
>
> Key: MANTTASKS-78
> URL: http://jira.codehaus.org/browse/MANTTASKS-78
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task, POM Integration
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Attachments: MANTTASKS-78.diff, MANTTASKS-78.diff
>
>
> the conditions for this problem are very precise:
> {code:xml}
> id="my.maven.project.SNAPSHOT">
>
>
>
>
> {code}
> but if the second remoteRepository is removed, or even the 2 repositories
> switched, there is no problem...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTTASKS-78) unable to download a dependency when it is a SNAPSHOT and multiple remoteRepositories are used
[
http://jira.codehaus.org/browse/MANTTASKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-78:
---
Attachment: (was: MANTTASKS-78.diff)
> unable to download a dependency when it is a SNAPSHOT and multiple
> remoteRepositories are used
> --
>
> Key: MANTTASKS-78
> URL: http://jira.codehaus.org/browse/MANTTASKS-78
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task, POM Integration
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-78.diff
>
>
> the conditions for this problem are very precise:
> {code:xml}
> id="my.maven.project.SNAPSHOT">
>
>
>
>
> {code}
> but if the second remoteRepository is removed, or even the 2 repositories
> switched, there is no problem...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTTASKS-78) unable to download a dependency when it is a SNAPSHOT and multiple remoteRepositories are used
[
http://jira.codehaus.org/browse/MANTTASKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-78:
---
Fix Version/s: 2.0.8
Patch Submitted: [Yes]
> unable to download a dependency when it is a SNAPSHOT and multiple
> remoteRepositories are used
> --
>
> Key: MANTTASKS-78
> URL: http://jira.codehaus.org/browse/MANTTASKS-78
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task, POM Integration
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-78.diff
>
>
> the conditions for this problem are very precise:
> {code:xml}
> id="my.maven.project.SNAPSHOT">
>
>
>
>
> {code}
> but if the second remoteRepository is removed, or even the 2 repositories
> switched, there is no problem...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGELOG-74) Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, MCHANGELOG-72, MCHANGELOG-73
[ http://jira.codehaus.org/browse/MCHANGELOG-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-74: - Attachment: MCHANGELOG-69,70,71,72,73.patch previous patch was missing a call to sinkAuthorNames() in doChangeSetDetails() methods and thus did not print active links for the developer names (was a patch error) > Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, > MCHANGELOG-72, MCHANGELOG-73 > > > Key: MCHANGELOG-74 > URL: http://jira.codehaus.org/browse/MCHANGELOG-74 > Project: Maven 2.x Changelog Plugin > Issue Type: Task >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-69,70,71,72,73.patch, > MCHANGELOG-69,70,71,72,73.patch, MCHANGELOG-69,70,71,72,73.patch > > > This is a combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, > MCHANGELOG-72, MCHANGELOG-73. I have produced individual patches for each > issue so that the code can easily be reviewed by the committers and then this > combined patch to allow all those mini-patches to be easily applied against > the trunk. > I hope this is considered ok as I could not think of a better way to make the > job of the committer easy, plus it was right pain to do > All updates made against trunk revision 560535. > Note there are two change in this combined patch to the individual patches - > due to MCHANGELOG-68 I had switched on ignore test failures - and being an > idiot had not kept track of how many unit tests were failing. To my horror I > noticed that loads of the tests were failing but not due to functional issues > as such but instead due to the NPEs being raised because a lack of injected > values. I have since changed the code to, where appropriate, check for nulls > and thus all the unit tests NPEs have gone away. Sorry I should have had my > eye on this right from the 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] Updated: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCLOVER-80: -- Attachment: MCLOVER-80.diff it has been observed that a module hierarchy is very different to the project inheritance hierarchy. This version of the patch thus fixes aggregate such that: *Aggregate no longer aggregates all clover databases to all other clover databases regardless of their position within the *module* hierarchy. This is the original issue that ticket was raised to address. The previous patch attempted to do the same thing but, critically, used the inheritance hierarchy and not the module hierarchy. > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff, MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103541 ] John Allen edited comment on MCLOVER-80 at 7/29/07 6:46 AM: it has been observed that a module hierarchy is very different to the project inheritance hierarchy. This version of the patch thus fixes aggregate such that: Aggregate no longer aggregates all clover databases to all other clover databases regardless of their position within the *module* hierarchy. This is the original issue that ticket was raised to address. The previous patch attempted to do the same thing but, critically, used the inheritance hierarchy and not the module hierarchy. was: it has been observed that a module hierarchy is very different to the project inheritance hierarchy. This version of the patch thus fixes aggregate such that: *Aggregate no longer aggregates all clover databases to all other clover databases regardless of their position within the *module* hierarchy. This is the original issue that ticket was raised to address. The previous patch attempted to do the same thing but, critically, used the inheritance hierarchy and not the module hierarchy. > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff, MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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-140) Review the Doxia site documentation
[ http://jira.codehaus.org/browse/DOXIA-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103543 ] Vincent Siveton commented on DOXIA-140: --- first done with r558696 > Review the Doxia site documentation > --- > > Key: DOXIA-140 > URL: http://jira.codehaus.org/browse/DOXIA-140 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Siveton > Fix For: 1.0-beta-1 > > -- 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-144) Review signature methods
Review signature methods Key: DOXIA-144 URL: http://jira.codehaus.org/browse/DOXIA-144 Project: Maven Doxia Issue Type: Improvement Components: Core, Modules Affects Versions: 1.0-alpha-9 Reporter: Vincent Siveton Fix For: 1.0-beta-1 Severals methods are public instead of private -- 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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCLOVER-80: -- Attachment: MCLOVER-80.diff > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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-133) default XML encoding (UTF-8) or XML encoding set in XML files is ignored: inputEncoding is used instead
[
http://jira.codehaus.org/browse/DOXIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-133:
Attachment: DOXIA-133_doxia.diff
re-did the patch with latest trunk revision
> default XML encoding (UTF-8) or XML encoding set in XML files is ignored:
> inputEncoding is used instead
> ---
>
> Key: DOXIA-133
> URL: http://jira.codehaus.org/browse/DOXIA-133
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Docbook Simple, Module - Fml, Module -
> Xdoc, Module - Xhtml, Site Renderer
>Affects Versions: 1.0-alpha-8
>Reporter: Herve Boutemy
> Fix For: 1.0-alpha-9
>
> Attachments: DOXIA-133_doxia-siterenderer.diff, DOXIA-133_doxia.diff,
> DOXIA-133_doxia.diff
>
>
> Encoding can be specified per file, in the XML header: encoding="xxx"?>, or defaults to UTF-8
> But DefaultSiteRenderer class always read files with inputEncoding: {{reader
> = new InputStreamReader( new FileInputStream( fullPathDoc ),
> context.getInputEncoding() );}}
> When the source file is XML (xdoc, xhtml), should use XmlReader from
> PLXUTILS-11 to detect the XML stream encoding instead.
> Test case included in MSITE-239, site-plugin-test14
--
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-142) Allow snippet macro contents to be output as-is, instead of verbatim
[
http://jira.codehaus.org/browse/DOXIA-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103548
]
Dennis Lundberg commented on DOXIA-142:
---
The non-verbatim text should be output as-is (rawText), without XML-escaping
the characters. That way you can put an html-snippet in a file and reuse in it
in multiple places, like a kind of include.
> Allow snippet macro contents to be output as-is, instead of verbatim
>
>
> Key: DOXIA-142
> URL: http://jira.codehaus.org/browse/DOXIA-142
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-alpha-8
>Reporter: Dennis Lundberg
> Attachments: snippet-non-verbatim.patch
>
>
> It would be extremely useful to be able to use the snippet macro to "include"
> ready made content. That is not possible because the SnippetMacro class
> outputs the content as verbatim escaped text. This could be allowed by adding
> a new parameter "verbatim" to the snippet macro that defaults to "true" to
> preserve the current behavior.
> Consider this code example
> {code}
> verbatim="false"/>
> {code}
> It would take the snippet "mytable" from the specified file and insert it
> "as-is".
> If you like this idea I will apply the patch and add examples to the
> documentation 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: (MJAVADOC-140) test-javadoc run in aggregate mode does not pass correct classpath to javadoc tool
test-javadoc run in aggregate mode does not pass correct classpath to javadoc
tool
--
Key: MJAVADOC-140
URL: http://jira.codehaus.org/browse/MJAVADOC-140
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: John Allen
Priority: Blocker
compare - local build of test-javadoc for a project:
{code}
-classpath
'D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
D:/PROFILES/allenj4/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar'
-protected
-sourcepath
'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
-author
-charset
'ISO-8859-1'
-d
'D:/APT/projects/apt-examples/calculator/calculator-engine/target/site/testapidocs'
-doctitle
'Calculator Engine 1.1-SNAPSHOT Test API'
-linkoffline
'http://java.sun.com/j2se/1.4.2/docs/api' null
-use
-version
-windowtitle
'Calculator Engine 1.1-SNAPSHOT Test API'
{code}
with the one produced at the root project. It obviously contains many more
classpath details but critically you'll see junit JAR
{code}
-classpath
'D:/APT/projects/apt-examples/calculator/calculator-root/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-root/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-skin/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-skin/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-ejb/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-ejb/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-servlets/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-servlets/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-webapp/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-webapp/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-ear/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-ear/target/test-classes;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT.jar;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-servlets/1.1-SNAPSHOT/calculator-servlets-1.1-SNAPSHOT.jar;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT-client.jar;
D:/PROFILES/allenj4/.m2/repository/javax/j2ee/j2ee/1.4/j2ee-1.4.jar;
D:/PROFILES/allenj4/.m2/repository/tomcat/jasper-runtime/5.5.12/jasper-runtime-5.5.12.jar;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-engine/1.1-SNAPSHOT/calculator-engine-1.1-SNAPSHOT.jar'
-protected
-sourcepath
'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
-author
-charset
'ISO-8859-1'
-d
'D:/APT/projects/apt-examples/calculator/calculator-root/target/site/testapidocs'
-doctitle
'Calculator 1.1-SNAPSHOT Test API'
-linkoffline
'http://java.sun.com/j2se/1.4.2/docs/api' null
-use
-version
-windowtitle
'Calculator 1.1-SNAPSHOT Test API'
{code}
Which of course gives us:
{code}
[INFO] Javadoc Warnings
[WARNING]
D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:6:
package junit.framework does not exist
[WARNING] import junit.framework.TestCase;
[WARNING] ^
[WARNING]
D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:13:
cannot find symbol
[WARNING] symbol: class TestCase
[WARNING] extends TestCase
[WARNING] ^
{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: (MCHANGELOG-66) changelog for perforce fails because of default clientspec
[
http://jira.codehaus.org/browse/MCHANGELOG-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103553
]
Brian Jackson commented on MCHANGELOG-66:
-
Dennis, yup that is exactly what works. I highly recommend everyone NOT use
the same setting for the scm plugin as it will hose your client spec when doing
a release. It's a reported bug in the release plugin but I don't remember the
JIRA key off the top of my head.
> changelog for perforce fails because of default clientspec
> --
>
> Key: MCHANGELOG-66
> URL: http://jira.codehaus.org/browse/MCHANGELOG-66
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Brian Jackson
>Assignee: Dennis Lundberg
> Fix For: 2.1
>
>
> Currently changelog fails for Perforce when the default clientspec is used
> and the plugin provides no way to supply the clientspec name. Currently you
> can do the following for the scm plugin so that the scm:changelog will work:
>
> maven-scm-plugin
>
>
>
> maven.scm.perforce.clientspec.name
>
> ${perforce.clientspec.name.from.settings.xml}
>
>
>
>
> I propose the same for the changelog report plugin.
--
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: (MRELEASE-271) perform goal sometimes fails with multi-module projects
perform goal sometimes fails with multi-module projects --- Key: MRELEASE-271 URL: http://jira.codehaus.org/browse/MRELEASE-271 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6, 2.0-beta-4 Environment: XP Reporter: David Hoffer Attachments: MavenReleaseFailure.zip, SuccessfulReleaseBuild.txt We have a multi-module maven project that has recently started failing in the release:perform goal. We have just added a couple more modules but do not know if that is the cause of the failure. It seems that the release:perform fails to compile the source after the SCM tag and checkout. The failure says that it cannot find a dependent jar but it is that jar that it is supposed to be building and releasing! I updated to use the latest 2.0-beta-6 release plugin version but this did not help. Upon receiving feedback in the maven users group that others have seen this behavior I followed their advise and added clean install to my parent pom which did fix the problem. Why is the release goal failing now? When do I and when do I not need these changes to my pom? I will attach pom and build logs in hopes this can be fixed soon, let me know if you need additional information. -Dave -- 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: (MAVENUPLOAD-1619) Please upload XMLUnit for Java 1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103558 ] Paul King commented on MAVENUPLOAD-1619: Any suggestions on the path forward? Is there a standard maven way to handle the above or is this use case outside what the standard model supports? Or to rephrase, does moving forward while sticking with the current model involve splitting the deliverables into two: one which would have the required compile-time dependency, the other would have to remove the class and remove the dependency? Is there something equivalent to ivy's profiles? I am not 100% sure about the full capabilities of ivy's profiles but I believe they can handle scenarios like this. > Please upload XMLUnit for Java 1.1 > -- > > Key: MAVENUPLOAD-1619 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1619 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Stefan Bodewig >Assignee: Carlos Sanchez > > XMLUnit for Java 1.1 has been released today. > http://xmlunit.sf.net/ > I am listed as a project admin at http://sourceforge.net/projects/xmlunit/ -- 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-435) need to review repository defaults
need to review repository defaults
--
Key: MRM-435
URL: http://jira.codehaus.org/browse/MRM-435
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-beta-1
Reporter: Brett Porter
when running the appserver, the default is file:/${appserver.home}/... which is
incorrect (it should be pre-filled with the value of appserver.home). Moreover,
it should really be appserver.base, not appserver.home anyway.
--
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-436) incorrect default cron expression for snapshots repository
incorrect default cron expression for snapshots repository -- Key: MRM-436 URL: http://jira.codehaus.org/browse/MRM-436 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: Brett Porter it is '0 0' which is not a valid value - it should probably be the same as for releases -- 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-374) Changes aren't saved when updating Archiva Managed Snapshot Repository
[ http://jira.codehaus.org/browse/MRM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103559 ] Brett Porter commented on MRM-374: -- still seeing this in the latest version. > Changes aren't saved when updating Archiva Managed Snapshot Repository > -- > > Key: MRM-374 > URL: http://jira.codehaus.org/browse/MRM-374 > Project: Archiva > Issue Type: Bug > Components: repository interface >Reporter: Dawn Angelito > Fix For: 1.0.x > > > Steps: > 1) Log in as admin. > 2) In the left menu, under Administration, click Repositories. > 3) Edit Archiva Managed Snapshot Repository. > 4) Since this is a snapshot repository, uncheck Releases Included. > 5) Click Update Repository. > Notice that "Releases Included" is still set to "True" for Archiva Managed > Snapshot 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: (MRM-437) admin editing of proxy connectors fails in multiple instances
admin editing of proxy connectors fails in multiple instances - Key: MRM-437 URL: http://jira.codehaus.org/browse/MRM-437 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: Brett Porter I've seen the following: - edit first one and save (order changes) - edit new first one and save (end up with the same connector for both, eg the blacklist is duplicated) - in other circumstances, I'd seen editing the proxy connector produce a second one - removing the corresponding remote repository doesn't remove the associated network proxy. I believe this entire set of actions needs a review. -- 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-438) broken images in the download box on the artifact page
broken images in the download box on the artifact page -- Key: MRM-438 URL: http://jira.codehaus.org/browse/MRM-438 Project: Archiva Issue Type: Bug Affects Versions: 1.0-beta-1 Reporter: Brett Porter these don't appear to work at all in the latest version - it isn't noticeable in firefox but in ie you get the big white square with an X in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
