[jira] Commented: (MAVENUPLOAD-1779) please upload JsUnit 2.1.4 test runner
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111372 ] nicolas de loof commented on MAVENUPLOAD-1779: -- This is not a typo : the bundle is archived using the custom javascript archive format (from mojo javascript plugin) > please upload JsUnit 2.1.4 test runner > -- > > Key: MAVENUPLOAD-1779 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1779 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof > > jsunit is a port of junit to javascript. > the test runner is the client part of the jsunit framework. This bundle is a > javascript archive of this runner, packaged as a jar for the (mojo) > javascript 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] Commented: (MAVENUPLOAD-1779) please upload JsUnit 2.1.4 test runner
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111379 ] nicolas de loof commented on MAVENUPLOAD-1779: -- I changed archive format to "classic" JAR. > please upload JsUnit 2.1.4 test runner > -- > > Key: MAVENUPLOAD-1779 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1779 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof > > jsunit is a port of junit to javascript. > the test runner is the client part of the jsunit framework. This bundle is a > javascript archive of this runner, packaged as a jar for the (mojo) > javascript 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] Commented: (MAVENUPLOAD-1777) please upload Log4Javascript
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111380 ] nicolas de loof commented on MAVENUPLOAD-1777: -- Changed archive format to "classic" JAR > please upload Log4Javascript > > > Key: MAVENUPLOAD-1777 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1777 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: nicolas de loof > > Log4Javascript is a js librarie comparable to log4j in javascript development. > This bundle contains a javascript archive, created for the javascript maven > tools currently in mojo sandbox. -- 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-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111384 ] manuel aldana commented on MNG-3252: it is a complete miracle. after downloading and installing a fresh maven-2.0.7.bin.zip it worked. still my not working maven installation with 'mvn -version' showed version 2.0.7. just weird! indeed the contents of my not working maven showed a different checksum, maybe transimission errors or similar, though i assumed that file corruptions are already handled by the unpack programm through checksums... > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: maven-update-policy-test.zip, pomProjectA.xml, > pomProjectB.xml, settings.xml > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3257) Intro to the POM Example 3 - nonsense explanation
Intro to the POM Example 3 - nonsense explanation - Key: MNG-3257 URL: http://jira.codehaus.org/browse/MNG-3257 Project: Maven 2 Issue Type: Bug Components: Documentation: Introductions Affects Versions: Documentation Deficit Reporter: Gary Morgan Priority: Minor The solution explanation for Example 3 contains a number of errors. 1) "we have the element /module/ my-module///module/." should probably read "we have the element my-module." 2) "The value of /module/// is the " should probably read "The value of is the " 3) "relative path from the com.mycompany.app:my-module:1 to com.mycompany.app:my-module:1's POM" should probably read "relative path from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM" 4) "Now, whenever a maven command processes com.mycompany.app:my-module:1" should probably read "Now, whenever a maven command processes com.mycompany.app:my-app: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] Commented: (MNG-3257) Intro to the POM Example 3 - nonsense explanation
[ http://jira.codehaus.org/browse/MNG-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111385 ] Gary Morgan commented on MNG-3257: -- The text in question can be found here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html The paragraphs in full are: "In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For the packaging, it's value was set to "pom", and for the modules section, we have the element /module/ my-module///module/ . The value of /module/// is the relative path from the com.mycompany.app:my-module:1 to com.mycompany.app:my-module:1's POM (by practice, we use the module's artifactId as the module directory's name ). Now, whenever a maven command processes com.mycompany.app:my-module:1, that same maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handles project aggregation differently. " > Intro to the POM Example 3 - nonsense explanation > - > > Key: MNG-3257 > URL: http://jira.codehaus.org/browse/MNG-3257 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: Introductions >Affects Versions: Documentation Deficit >Reporter: Gary Morgan >Priority: Minor > > The solution explanation for Example 3 contains a number of errors. > 1) "we have the element /module/ my-module///module/." > should probably read "we have the element my-module." > 2) "The value of /module/// is the " > should probably read "The value of is the " > 3) "relative path from the com.mycompany.app:my-module:1 to > com.mycompany.app:my-module:1's POM" > should probably read "relative path from the com.mycompany.app:my-app:1 to > com.mycompany.app:my-module:1's POM" > 4) "Now, whenever a maven command processes com.mycompany.app:my-module:1" > should probably read "Now, whenever a maven command processes > com.mycompany.app:my-app: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: (MEV-551) Missing or unnecessary dependency for axis2-fastinfoset
Missing or unnecessary dependency for axis2-fastinfoset --- Key: MEV-551 URL: http://jira.codehaus.org/browse/MEV-551 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Gabriele Contini Axis2 fastinfoset declares a dependency on com.sun.xml.fastinfoset FastInfoset version 1.2.1 that's not included in the repository (there is only version 1.1.1), thus making build fail. On the other hand sun Fastinfoset jar is not inclued in the axis 1.3 distribution either, i guess it is not necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1492) error when trying to run data management tool when behind a proxied firewall
[ http://jira.codehaus.org/browse/CONTINUUM-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111393 ] Damien Lecan commented on CONTINUUM-1492: - Should DMC read settings.xml ? > error when trying to run data management tool when behind a proxied firewall > > > Key: CONTINUUM-1492 > URL: http://jira.codehaus.org/browse/CONTINUUM-1492 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Tomislav Stojcevich > > Using -Dhttp.proxyHost=proxyhost.com, -Dhttp.proxyPort=80 > -Dproxy.User=myuserid -Dhttp.proxyPassword=mypassword doesn't work > Setting -Djava.net.useSystemProxies=true doesn't work > Setting -Dhttp.auth.ntlm.domain=mydomain doesn't work > Nor does it pick up the proxy settings in my settings.xml file. > 0 [main] INFO org.apache.maven.continuum.management.DataManagementCli - > Processing Continuum database... > Exception in thread "main" > org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: > -- > 1) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-3 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.continuum > -DartifactId=data-management-jdo \ > -Dversion=1.1-beta-3 -Dpackaging=jar -Dfile=/path/to/file > Path to dependency: > 1) dummy:dummy:pom:1.0 > 2) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-3 > -- > 1 required artifact is missing. > for artifact: > dummy:dummy:pom:1.0 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243) > at > org.apache.maven.continuum.management.DataManagementCli.downloadArtifact(DataManagementCli.java:292) > at > org.apache.maven.continuum.management.DataManagementCli.processDatabase(DataManagementCli.java:173) > at > org.apache.maven.continuum.management.DataManagementCli.main(DataManagementCli.java:146) -- 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: (MEV-550) Missing castor version or incorrect groovy/openejb dependencies
[ http://jira.codehaus.org/browse/MEV-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111395 ] Paul King commented on MEV-550: --- I will own up to adding the groovy 1.0 pom. I extracted the pom from version control that we used to build the 1.0 jar and placed that in the correct place to be sync'd - no new dependencies were added. I presume we received a warning about the missing dependency when we built the jar at the time. Having a look at the openejb source history, it looks like they added a dependency to a non-existing artifact in Sept 2005 and kept that dependency that way at least for 6 months: http://fisheye.codehaus.org/changelog/openejb/?cs=2173 I couldn't find evidence that the artifact was deleted but it appears some snapshot artifacts related to castor possibly were deleted. Perhaps the openejb project (and maybe even the Groovy project) pointed to an additional snapshot repository at one point. Carlos, I would appreciate your advice here. I just "hacked" the Groovy pom to have an explicit dependency to castor:castor:0.9.9 and the openejb-related tests work fine. It appears to be the first release they made after the 0.9.9.0-pre SNAPSHOT release. It doesn't feel right to add in this hack though - it really is openejb:openejb:core that needs this fix. Should we look at fixing that? Or is there a better solution? Let me know if it needs a separate issue. Thanks, Paul. > Missing castor version or incorrect groovy/openejb dependencies > --- > > Key: MEV-550 > URL: http://jira.codehaus.org/browse/MEV-550 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Nicolas Kyriazopoulos-Panagiotopoulos > > We have a problem of dependencies: > [INFO] Path to dependency: > [INFO]1) [OUR PROJECT] > [INFO]2) groovy:groovy:jar:1.0 > [INFO]3) openejb:openejb-loader:jar:1.0 > [INFO]4) openejb:openejb-core:jar:1.0 > [INFO]5) castor:castor:jar:0.9.9.0-pre > The problem is new (we are using groovy for almost a year) . It seems that > someone very recently erased this version of the castor jar and grovy cannot > work without it (unless the problem is caused by newly changed poms). Finding > this particular version of castor on the web seems very difficult. > This is VERY URGENT: there is no newer stable version of groovy so we have > no alternative, and the problem makes new application deployments impossible > (unless we do kung fu with the downloaded poms to refer to other versions, > which is impractical and dangerous). > Thanks in advance! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-169) Confluence module does not recognize line breaks (\\)
[
http://jira.codehaus.org/browse/DOXIA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111396
]
Lukas Theussl commented on DOXIA-169:
-
I've had a quick look at this patch and have some issues:
* first, please adhere to our coding conventions, in particular, no tabs, no
System.out/err
* the EOL string is available to the ConfluenceParser through the Markup
interface, it should also be available to the BlockParser
* a confluence linebreak element should produce a sink lineBreak(), not an EOL.
Ie, your test input
{noformat}
Line\\
break.
{noformat}
should produce the following TextSink output:
{noformat}
begin:paragraph
text: Line
lineBreak
text: break.
end:paragraph
{noformat}
instead of
{noformat}
begin:paragraph
text: Line
break.
end:paragraph
{noformat}
* last but not least: in the future I will refuse to apply any patch that has
the doxia tree checked out under a directory called 'crap'... ;)
> Confluence module does not recognize line breaks (\\)
> -
>
> Key: DOXIA-169
> URL: http://jira.codehaus.org/browse/DOXIA-169
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.0-alpha-8
>Reporter: Dave Syer
> Attachments: linebeak-patch.txt
>
>
> Confluence module does not recognize line breaks (\\)
--
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-169) Confluence module does not recognize line breaks (\\)
[ http://jira.codehaus.org/browse/DOXIA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111397 ] Dave Syer commented on DOXIA-169: - * Coding conventions: is there an Eclipse prefs file anywhere? * EOL - wasn't needed in the parser but thanks for the tip. * lineBreak - didn't know about that one, thank. * "crap" is just a name. In the future I will refuse to submit patches if arbitrary rules are applied to them. Maybe I'm not the right person to be doing this. If there are rules and pieces of Doxia knowledge that other people know more about I am quite happy to sit back and wait. But obviously I won't be using the Confluence module until it is in better shape. > Confluence module does not recognize line breaks (\\) > - > > Key: DOXIA-169 > URL: http://jira.codehaus.org/browse/DOXIA-169 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Attachments: linebeak-patch.txt > > > Confluence module does not recognize line breaks (\\) -- 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-169) Confluence module does not recognize line breaks (\\)
[ http://jira.codehaus.org/browse/DOXIA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111399 ] Lukas Theussl commented on DOXIA-169: - Coding conventions: http://maven.apache.org/guides/development/guide-m2-development.html#Maven_Code_Style For the crap line: it was meant as a pun, don't let my bad english prevent you from calling your patches whatever you want... :) If you are not the right person for doing this, then I don't see who else, because as you might have inferred from the response on the list, none of the current doxia committers is that familiar with the confluence module. So please, keep the patches coming, I promise we'll have at least a look at it. > Confluence module does not recognize line breaks (\\) > - > > Key: DOXIA-169 > URL: http://jira.codehaus.org/browse/DOXIA-169 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Attachments: linebeak-patch.txt > > > Confluence module does not recognize line breaks (\\) -- 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-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated MNG-3252: -- Attachment: (was: pomProjectB.xml) > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: maven-update-policy-test.zip, settings.xml > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > thanks. -- 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-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated MNG-3252: -- Attachment: (was: pomProjectA.xml) > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: maven-update-policy-test.zip, settings.xml > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > thanks. -- 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-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated MNG-3252: -- Attachment: (was: settings.xml) > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: maven-update-policy-test.zip > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > thanks. -- 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-3252) SNAPSHOTS: updatePolicy always gets ignored
[ http://jira.codehaus.org/browse/MNG-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111401 ] Mauro Talevi commented on MNG-3252: --- Good! Yes - checksum validation is always a good practice. I've removed the original files attached, now superceded for future reference by the refactored ones in the attachment uploaded, which can be among other things be used on any platform out-of-the-box (it uses java.io.tmpdir to create the internal-repo). > SNAPSHOTS: updatePolicy always gets ignored > --- > > Key: MNG-3252 > URL: http://jira.codehaus.org/browse/MNG-3252 > Project: Maven 2 > Issue Type: Bug > Components: General, POM, Settings >Affects Versions: 2.0.7 >Reporter: manuel aldana >Assignee: Mauro Talevi >Priority: Blocker > Attachments: maven-update-policy-test.zip > > > i am working with snapshots and therefore i am setting the > always of internal repository. This is not > working and basically makes working with SNAPSHOTS impossible, which is > highly severe in many maven development processes. > for details see attached files. the setting is that project A is depending on > project B. when a new SNAPSHOT version of project B gets deployed and a 'mvn > compile' of project A gets executed, maven does not look up for a fresh > version of project B. > in my view it ignores the always snapshot setting and uses the default daily > flag. the reason for this assumption is that the day after executing 'mvn > compile', it checked for a new version. > please advice what i can do to have this issue fixed (this is a total blocker > with working with maven in our development). if this cannot be fixed for > 2.0.7 quickly, please tell which version i can use, maybe it has been fixed > already (though could not find a matching bug report). > when trying to reproduce with attached files watch out, that the url of > internal repository needs to be adjusted. > thanks. -- 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-1492) error when trying to run data management tool when behind a proxied firewall
[ http://jira.codehaus.org/browse/CONTINUUM-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111404 ] Emmanuel Venisse commented on CONTINUUM-1492: - post beta-3, it read the settings.xml > error when trying to run data management tool when behind a proxied firewall > > > Key: CONTINUUM-1492 > URL: http://jira.codehaus.org/browse/CONTINUUM-1492 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Tomislav Stojcevich > > Using -Dhttp.proxyHost=proxyhost.com, -Dhttp.proxyPort=80 > -Dproxy.User=myuserid -Dhttp.proxyPassword=mypassword doesn't work > Setting -Djava.net.useSystemProxies=true doesn't work > Setting -Dhttp.auth.ntlm.domain=mydomain doesn't work > Nor does it pick up the proxy settings in my settings.xml file. > 0 [main] INFO org.apache.maven.continuum.management.DataManagementCli - > Processing Continuum database... > Exception in thread "main" > org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: > -- > 1) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-3 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.continuum > -DartifactId=data-management-jdo \ > -Dversion=1.1-beta-3 -Dpackaging=jar -Dfile=/path/to/file > Path to dependency: > 1) dummy:dummy:pom:1.0 > 2) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-3 > -- > 1 required artifact is missing. > for artifact: > dummy:dummy:pom:1.0 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243) > at > org.apache.maven.continuum.management.DataManagementCli.downloadArtifact(DataManagementCli.java:292) > at > org.apache.maven.continuum.management.DataManagementCli.processDatabase(DataManagementCli.java:173) > at > org.apache.maven.continuum.management.DataManagementCli.main(DataManagementCli.java:146) -- 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: (MRRESOURCES-25) Inccorect URL for issue tracking
Inccorect URL for issue tracking Key: MRRESOURCES-25 URL: http://jira.codehaus.org/browse/MRRESOURCES-25 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Reporter: Emmanuel Hugonnet Priority: Trivial On the plugin'site the JIRA url is http://jira.codehaus.org/browse/MPA instead of http://jira.codehaus.org/browse/MRRESOURCES. Emmauel -- 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: (MECLIPSE-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111414 ] Pascal Thivent commented on MECLIPSE-333: - I have downloaded the tar with all new files and applied the patch on a clean maven-eclipse-plugin checkout. I ran mvn install and got one error in the testJeeSimple() method of the EclipsePluginTest because of a missing dependency. I did a mvn install on the j2ee-simple bundled project as workaround to make the build pass. I can't remember out of my head which artifact was missing but I finally succeeded to build the plugin without skipping the tests. The strange part is that I just tried to reproduce this (after a mvn clean and removing everything related to the plugin from my local repository) but... unsuccessfully. When I check target\test-classes\m2repo\root\project, I see all required artifacts this time so they must have been build correctly. This try has been done under WindowsXP when the first attempt was under Linux. I'll try again at home. Another thing : I'm using a JDK6 and noticed I had to add some maven-compiler-plugin configuration in my pom.xml to get the correct Java Facet in eclipse. Without this, the generated Java Facet was 1.4. This happens only when I had configuration for WTP2.0 support. This is non blocking but I just wanted to let you know. Nice work anyway. > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Attachments: maven-eclipse-plugin_only_new.tar.gz, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new 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: (DOXIA-169) Confluence module does not recognize line breaks (\\)
[ http://jira.codehaus.org/browse/DOXIA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-169: Attachment: linebeak-patch-1.txt Updated patch (*-1.txt) with correct use of lineBreak(). > Confluence module does not recognize line breaks (\\) > - > > Key: DOXIA-169 > URL: http://jira.codehaus.org/browse/DOXIA-169 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Attachments: linebeak-patch-1.txt, linebeak-patch.txt > > > Confluence module does not recognize line breaks (\\) -- 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: (MAVENUPLOAD-1783) please upload jsdoc 1.3.3
please upload jsdoc 1.3.3 - Key: MAVENUPLOAD-1783 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1783 Project: maven-upload-requests Issue Type: Wish Reporter: nicolas de loof Jsdoc is a documentation tool for javascript, inspired by javadoc. This is a resources jar (no classes). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1536) Data management cli doesn't read settings.xml
Data management cli doesn't read settings.xml
-
Key: CONTINUUM-1536
URL: http://jira.codehaus.org/browse/CONTINUUM-1536
Project: Continuum
Issue Type: Bug
Components: Data Management
Affects Versions: 1.1-beta-3, 1.1-beta-2
Reporter: Damien Lecan
Priority: Critical
DMC doesn't read settings.xml file (proxy + Continuum beta-4 stage repository)
settings.xml file is located under ${user.home}/.m2/
Here is what I get when I try to execute DMC and then dependency:resolve with
DMC pom file.
DMC alone :
[EMAIL PROTECTED] ~]$ java -jar data-management-cli-1.1-beta-4-app.jar ...
0 [main] INFO org.apache.maven.continuum.management.DataManagementCli
- Processing Continuum database...
Exception in thread "main"
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException:
Missing:
--
1) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-4
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.continuum
-DartifactId=data-management-jdo \
-Dversion=1.1-beta-4 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) dummy:dummy:pom:1.0
2) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-4
--
1 required artifact is missing.
for artifact:
dummy:dummy:pom:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
at
org.apache.maven.continuum.management.DataManagementCli.downloadArtifact(DataManagementCli.java:304)
at
org.apache.maven.continuum.management.DataManagementCli.processDatabase(DataManagementCli.java:185)
at
org.apache.maven.continuum.management.DataManagementCli.main(DataManagementCli.java:158)
<= same session, same maven 2, same settings.xml =>
Then, with DMC pom file :
[EMAIL PROTECTED] ~]$ mvn dependency:resolve
[INFO] Scanning for projects...
Downloading:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-data-management/1.1-beta-4/continuum-data-management-1.1-beta-4.pom
2K downloaded
Downloading:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-parent/1.1-beta-4/continuum-parent-1.1-beta-4.pom
25K downloaded
...
Maven itself finds settings.xml and its configuration, but DMC fails.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-91) NPE when known host file is empty
NPE when known host file is empty - Key: WAGON-91 URL: http://jira.codehaus.org/browse/WAGON-91 Project: wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-2 Environment: xp, linux Reporter: Dan Tran There is an issue where HostKeyRepository hkr = sch.getHostKeyRepository(); return null due to empty known host file or when using NullKnownHostProvider. AbstractJschWagon should check for null which means no host key to process -- 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-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-176: Attachment: mylyn-context.zip > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol > Attachments: mylyn-context.zip, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "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-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-176: Attachment: section-title-patch.txt N.B. this patch also includes the patch for DOXIA-169 (the updated version "-1"). > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol > Attachments: mylyn-context.zip, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "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: (WAGON-91) NPE when known host file is empty
[ http://jira.codehaus.org/browse/WAGON-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-91: -- Attachment: WAGON-91.diff patch WAGON-91.diff > NPE when known host file is empty > - > > Key: WAGON-91 > URL: http://jira.codehaus.org/browse/WAGON-91 > Project: wagon > Issue Type: Bug > Components: wagon-ssh >Affects Versions: 1.0-beta-2 > Environment: xp, linux >Reporter: Dan Tran > Attachments: WAGON-91.diff > > > There is an issue where HostKeyRepository hkr = sch.getHostKeyRepository(); > return null due to empty known host file or when using NullKnownHostProvider. > AbstractJschWagon should check for null which means no host key to process -- 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: (MAVENUPLOAD-1784) Upload Unitils 1.0 rc 5
Upload Unitils 1.0 rc 5 --- Key: MAVENUPLOAD-1784 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1784 Project: maven-upload-requests Issue Type: Task Reporter: Tim Ducheyne Could you please upload the unitils-1.0-rc-5 bundle? Thank you, Tim -- 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-1779) please upload JsUnit 2.1.4 test runner
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111435 ] nicolas de loof commented on MAVENUPLOAD-1779: -- I just noticed the POM has been made available on central. This one has a typo that makes it XML invalid (missing "/" for ). I've updated the bundle with a valid one. sorry for this error. > please upload JsUnit 2.1.4 test runner > -- > > Key: MAVENUPLOAD-1779 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1779 > Project: maven-upload-requests > Issue Type: Wish >Reporter: nicolas de loof > > jsunit is a port of junit to javascript. > the test runner is the client part of the jsunit framework. This bundle is a > javascript archive of this runner, packaged as a jar for the (mojo) > javascript 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] Commented: (MRRESOURCES-25) Inccorect URL for issue tracking
[ http://jira.codehaus.org/browse/MRRESOURCES-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111471 ] Dennis Lundberg commented on MRRESOURCES-25: This has already been added to the pom. Someone just needs to deploy the site. > Inccorect URL for issue tracking > > > Key: MRRESOURCES-25 > URL: http://jira.codehaus.org/browse/MRRESOURCES-25 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Reporter: Emmanuel Hugonnet >Priority: Trivial > > On the plugin'site the JIRA url is http://jira.codehaus.org/browse/MPA > instead of http://jira.codehaus.org/browse/MRRESOURCES. > Emmauel -- 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-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-567:
---
Priority: Blocker (was: Critical)
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {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: (MRM-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111475
]
Joakim Erdfelt commented on MRM-567:
Updates to archiva/trunk seem to have solved the snapshots dependencies issues.
There are now unit tests for requesting a snapshot artifact from archiva's
repository, with every possible configuration of the snapshot policy setup.
Now to test the snapshots plugin issue.
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {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] Closed: (MRM-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-567.
--
Resolution: Fixed
Adding units tests for SNAPSHOT plugin downloading into archiva/trunk revision
588460.
Tested with actual archiva instance and maven project.
Verified that tests with SNAPSHOT plugins work too.
Closing as fixed.
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {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] Created: (MSITE-267) Relative path in inherited sites broken for depth of 2
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] Commented: (MRM-567) Unable to download plugin SNAPSHOT's from proxy.
[
http://jira.codehaus.org/browse/MRM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111484
]
Arnaud Heritier commented on MRM-567:
-
Ok, I'll test it on monday and we'll give you my feedback...
Thx
> Unable to download plugin SNAPSHOT's from proxy.
>
>
> Key: MRM-567
> URL: http://jira.codehaus.org/browse/MRM-567
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Affects Versions: 1.0-beta-3
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-4
>
>
> Reported in IRC.
> {noformat}
> Hi all
> is there someone who tried to test to proxy a repository with
> plugins snapshots
> like people.apache.org/maven2
> with the last beta
> I'm not sure but I think I have an issue
> Arnaud: I'll try cleaning my local repo and see
> Arnaud: havent had time to test yet :(
> get in line :)
> ;-)
> I put archiva in debug
> I can get those plugins
> org.apache.maven.plugins:maven-war-plugin:2.0.3-20070317.140722-3
> org.apache.maven.plugins:maven-surefire-plugin:2.3-SNAPSHOT
> There were a host of plugin related fixed commit'd yesterday.
> not sure your issue is related tho.
> in proxy connectors I have :
> cache=ignored,releases=disabled,snapshots=hourly,checksum=fix
> Arnaud, what's the remote repo url?
> http://people.apache.org/repo/m2-snapshot-repository
> lemme file the ticket.
> {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
