[jira] Updated: (DOXIA-157) Doxia Book doesn't work with xdoc source files
[ http://jira.codehaus.org/browse/DOXIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giovanni Pedone updated DOXIA-157: -- Attachment: gioMaven.rar Hello, this is the project I tried with. I could generate the xdoc only. If need more informations I'll be gladly available to provide them :) thank you Giovanni > Doxia Book doesn't work with xdoc source files > -- > > Key: DOXIA-157 > URL: http://jira.codehaus.org/browse/DOXIA-157 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: gioMaven.rar > > > Files with xml extension are parsed by the docbook parser. Doxia book doesn't > recognize the standard Maven site structure to determine the site module. -- 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-157) Doxia Book doesn't work with xdoc source files
[ http://jira.codehaus.org/browse/DOXIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108803 ] Lukas Theussl commented on DOXIA-157: - Just two comments about your project: * Your input file bindings.xml is not a valid xdoc: you need a declaration and the text "ciao ciao gio" should be inside a tag (or any block level element, see http://maven.apache.org/doxia/references/xdoc-format.html ) * the generated xdocs are rubbish as well since they were produced via the docbook parser. It's just an accident, because xdoc and docbook are relatively similar formats, that the xdoc sink doesn't bomb (like the itext sink), but the result is still useless. None of this is of any importance for the current issue though... > Doxia Book doesn't work with xdoc source files > -- > > Key: DOXIA-157 > URL: http://jira.codehaus.org/browse/DOXIA-157 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: gioMaven.rar > > > Files with xml extension are parsed by the docbook parser. Doxia book doesn't > recognize the standard Maven site structure to determine the site module. -- 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: (CONTINUUM-1403) Error on edit project group page
[ http://jira.codehaus.org/browse/CONTINUUM-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1403. --- Resolution: Fixed Yes, a project group with a null name generate this exception. It must be removed on the vmbuild db. I fixed trunk in r.581164 to don't have this exception in future. > Error on edit project group page > > > Key: CONTINUUM-1403 > URL: http://jira.codehaus.org/browse/CONTINUUM-1403 > Project: Continuum > Issue Type: Bug > Components: Web interface > Environment: > http://vmbuild1.apache.org/continuum/editProjectGroup.action >Reporter: Henri Yandell >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1403.trace > > > When clicking Edit on the Group page -- 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: (CONTINUUM-1502) After changing the name of a project group, the project dissapears and is not accessible, not even by the admin user.
[ http://jira.codehaus.org/browse/CONTINUUM-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1502. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1-beta-4 > After changing the name of a project group, the project dissapears and is not > accessible, not even by the admin user. > - > > Key: CONTINUUM-1502 > URL: http://jira.codehaus.org/browse/CONTINUUM-1502 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 > Environment: Linux CentOS4, Maven2.0.7, Java-5 >Reporter: Iker Almandoz >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-beta-4 > > > In the project view for a given project, if i change the name of the project > (project group name), then the project disappears and is not accessible from > continuum. > Not even the admin can see it... > I have changed the project name from "name" to "name " in my test. > I was able to recover the projects by directly connecting to the derby > database and updating the projectgroup table doing > >update projectgroup set name='name' where name='name '; -- 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-271) perform goal sometimes fails with multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108810 ] Dennis Kieselhorst commented on MRELEASE-271: - At first I assumed that this is a consecutive fault of MNG-2784 because I didn't have the problem before updating to maven 2.0.7. But now it doesn't work with 2.0.6 either. Workaround works for me too. > 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-4, 2.0-beta-6 > 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] Created: (MRM-531) Unable to download snapshots behind proxy with authentication
Unable to download snapshots behind proxy with authentication - Key: MRM-531 URL: http://jira.codehaus.org/browse/MRM-531 Project: Archiva Issue Type: Bug Components: remote proxy Affects Versions: 1.0-beta-2 Environment: solaris 5.10, jdk1.6.0_02, proxy with basic authentication Reporter: Mathias Arens I am able to download artifacts from several remote repositories into the internal repository. But I cannot download any dependencies into the snapshots repository. I always get a http-'Server redirected too many times (20)'-error. I read that this error occurs if the proxy authentication properties are not set correctly in the http client. I am behind a proxy with basic authentication and an empty password. This configuration works fine for the internal repository, but not for the snapshot repository. Here are the logs: INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 [SocketListener0-7] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [cache-failures] policy with [ignored] INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 [SocketListener0-7] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to fetch, check-failures policy set to IGNORED. INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 [SocketListener0-7] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [releases] policy with [disabled] INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 [SocketListener0-7] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:releases - OK to update, release policy does not apply for snapshot versions. INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 [SocketListener0-7] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [snapshots] policy with [daily] INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 [SocketListener0-7] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:snapshots - OK to update snapshots, local file does not exist. INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,988 [SocketListener0-7] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Retrieving org/apache/maven/artifact/maven-artifact/3.0-SNAPSHOT/mave n-artifact-3.0-SNAPSHOT.pom from Apache Snapshots Repository if updated INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:09,087 [SocketListener0-7] WARN org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Download failure:Error transferring file INFO | jvm 1| 2007/10/02 11:50:09 | org.apache.maven.wagon.TransferFailedException: Error transferring file INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:94) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferSimpleFile(DefaultRepositoryProxyConnectors.java:566) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferFile(DefaultRepositoryProxyConnectors.java:434) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:143) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.archiva.web.repository.ProxiedDavServer.applyServerSideRelocation(ProxiedDavServer.java:286) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:243) INFO | jvm 1| 2007/10/02 11:50:09 | at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) INFO | jvm 1| 2007/10/02 11:50:09 | at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) INFO | jvm 1| 2007/10/02 11:50:09 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) INFO | jvm 1| 2007/10/02 11:50:09 | at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) INFO | jvm 1| 2007/10/02 11:50:09 | at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) INFO | jvm 1| 2007/10/02 11:50:09 | at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) INFO | jvm 1| 2007/10/02 11:50:09 | at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandle
[jira] Closed: (CONTINUUM-1494) Maximum length for name column exceeded in makeAndStoreBuildResult
[ http://jira.codehaus.org/browse/CONTINUUM-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1494. --- Assignee: Emmanuel Venisse Resolution: Fixed Applied. Thanks. > Maximum length for name column exceeded in makeAndStoreBuildResult > -- > > Key: CONTINUUM-1494 > URL: http://jira.codehaus.org/browse/CONTINUUM-1494 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1-beta-2 >Reporter: André Næss >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-4 > > Attachments: maxlength.patch > > > This bug is similar to a bunch of other bugs like this, it seems the data > model has been consistently designed with too few characters in the name > field. This particular bugs occurs when Continuum tries to store the test > results (SuiteResult in the model). Using -Dmaven.test.skip=true made the > problem disappear. > I've attached a very simple fix for the problem, however, I note that > TestCaseFailure has no stash.maxSize set, and as soon as my Test breaks it > will probably crash with the same problem. > Here's the stack trace: > 863290102 [Thread-6] ERROR > org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - > Error executing task > edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: > javax.jdo.JDOFatalUserException: Attempt to store value > "/new-web/newweb-erp-integration/trunk/src/main/ja > va/com/pointcarbon/erp/agresso/domain/agressostatus/AcuhistrStatus.java (from > /new-web/newweb-erp-integration/trunk/src/main/java/com/pointcarbon/erp/agresso/domain/agressos > tatus/AcuhistrStatusEnum.java:4297)" in column ""NAME"" that has maximum > length of 255. Please correct your data! > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) > at > edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:118) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) > Caused by: javax.jdo.JDOFatalUserException: Attempt to store value > "/new-web/newweb-erp-integration/trunk/src/main/java/com/pointcarbon/erp/agresso/domain/agressostatus/Acuh > istrStatus.java (from > /new-web/newweb-erp-integration/trunk/src/main/java/com/pointcarbon/erp/agresso/domain/agressostatus/AcuhistrStatusEnum.java:4297)" > in column ""NAME"" > that has maximum length of 255. Please correct your data! > at > org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) > at > org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) > at > org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) > at > org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) > at > org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideField(ChangeFile.java) > at > org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideFields(ChangeFile.java) > at > org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) > at > org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) > at > org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) > at > org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772) > at > org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:386) > at > org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209) > at > org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464) > at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) > at org.jpox.store.StoreManager.insert(StoreManager.java:920) > at > org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) > at > org.jpox.state.StateManag
[jira] Created: (MNG-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-3228 URL: http://jira.codehaus.org/browse/MNG-3228 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: tony nys The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a "parent" pom, it is never activated. this works: ... TONY user.name WINTONY So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the "parent" pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... TONY user.name WINTONY ... CHILD POM (the one being built) com.capgemini.be.proj1 parent 4.0.2 [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- 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: (MINSTALL-42) classifier seems to be ignored
[ http://jira.codehaus.org/browse/MINSTALL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108827 ] Stephane Nicoll commented on MINSTALL-42: - Blocker issue without a way to reproduce is a bit funny. Call your command with mvn -X and check the install plugin configuration. > classifier seems to be ignored > -- > > Key: MINSTALL-42 > URL: http://jira.codehaus.org/browse/MINSTALL-42 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven 2.0.7. I'm unsure of the specific plugin version. >Reporter: Brill Pappin >Priority: Blocker > > install-file is failing to take into account the classifier option... this > used to work (as of last week) but is being ignored when I do the same thing > again. > The repo structure its using is incorrect. > That or possible maven has changed the way that classifier is used. -- 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: (MINSTALL-42) classifier seems to be ignored
[ http://jira.codehaus.org/browse/MINSTALL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MINSTALL-42: Priority: Major (was: Blocker) > classifier seems to be ignored > -- > > Key: MINSTALL-42 > URL: http://jira.codehaus.org/browse/MINSTALL-42 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven 2.0.7. I'm unsure of the specific plugin version. >Reporter: Brill Pappin > > install-file is failing to take into account the classifier option... this > used to work (as of last week) but is being ignored when I do the same thing > again. > The repo structure its using is incorrect. > That or possible maven has changed the way that classifier is used. -- 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-3083) Ant needs to be upgraded to 1.7.0
[
http://jira.codehaus.org/browse/MNG-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108828
]
Mauro Talevi commented on MNG-3083:
---
I'm struggling to understand the reason for this issue. Maven components don't
depend on ant - only the ant and antrun plugins do. And even there I can't see
the problem in the upgrade.
> Ant needs to be upgraded to 1.7.0
> -
>
> Key: MNG-3083
> URL: http://jira.codehaus.org/browse/MNG-3083
> Project: Maven 2
> Issue Type: Bug
> Components: Ant tasks
>Reporter: Brian Topping
>Priority: Critical
>
> Moving an Ant 1.7.0 build to Maven is currently impossible because there are
> dependencies on 1.6.5 all around Maven and the groupId of Ant has changed
> from {{ant}} to {{org.apache.ant}}. This precludes upgrading the dependency
> through graph distance override.
> In order to fix this, dependencies on Ant 1.6.5 need to be upgraded to 1.7.0.
> Fixing MANTRUN-68 would be nice, but is not as big a deal because it can be
> rebuilt locally.
--
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: (MANTRUN-68) Use ant-1.7.0
[ http://jira.codehaus.org/browse/MANTRUN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108829 ] Mauro Talevi commented on MANTRUN-68: - Why is this dependent on MNG-3083? > Use ant-1.7.0 > - > > Key: MANTRUN-68 > URL: http://jira.codehaus.org/browse/MANTRUN-68 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.2 > Environment: xp, linux >Reporter: Dan Tran > > with out this upgrade, i will need to ant 1.7.0 to use its new > features like abily to do delete,move, etc using filelist -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108832 ] Herve Boutemy commented on MANTTASKS-86: I just ran your testcase and didn't find any problem: I get 9 .jar downloaded, that is perfectly coherent with what is detected in "Project Dependencies" report. Could you be more precise than "there's a few dependencies missing": which ones? And what is the dependency path? > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > 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-88) Add the ability to download javadoc dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-88: --- Fix Version/s: 2.0.8 > Add the ability to download javadoc dependencies > - > > Key: MANTTASKS-88 > URL: http://jira.codehaus.org/browse/MANTTASKS-88 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement > Components: dependencies task >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.6, 2.0.7 > Environment: Linux JDK 1.5 >Reporter: Eric Hartmann >Priority: Minor > Fix For: 2.0.8 > > Attachments: patch.txt > > > The ant task cannot download the javadocs files of dependencies. > Here a small patch to add this enhancement the same way of downloading > sources. -- 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: (CONTINUUM-1474) At the time of an addition of new BuildDefinition with XmlRPC client, the automatically generated buildDefinitionID cannot be recovered
[ http://jira.codehaus.org/browse/CONTINUUM-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1474. --- Assignee: Emmanuel Venisse Resolution: Fixed Fixed in r.581222 > At the time of an addition of new BuildDefinition with XmlRPC client, the > automatically generated buildDefinitionID cannot be recovered > --- > > Key: CONTINUUM-1474 > URL: http://jira.codehaus.org/browse/CONTINUUM-1474 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-2 > Environment: widows with maven 2.0.4 >Reporter: Amine ZAROUK >Assignee: Emmanuel Venisse > Fix For: 1.1-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] Commented: (MINSTALL-42) classifier seems to be ignored
[ http://jira.codehaus.org/browse/MINSTALL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108837 ] Brill Pappin commented on MINSTALL-42: -- I can't get you the config right this moment (have to wait until I'm at the other machine). > classifier seems to be ignored > -- > > Key: MINSTALL-42 > URL: http://jira.codehaus.org/browse/MINSTALL-42 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven 2.0.7. I'm unsure of the specific plugin version. >Reporter: Brill Pappin > > install-file is failing to take into account the classifier option... this > used to work (as of last week) but is being ignored when I do the same thing > again. > The repo structure its using is incorrect. > That or possible maven has changed the way that classifier is used. -- 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: (MINSTALL-42) classifier seems to be ignored
[ http://jira.codehaus.org/browse/MINSTALL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108836 ] Brill Pappin commented on MINSTALL-42: -- Yes, your right... I just didn't have time to produce a test. Should be easy though. The exact command I'm running is: CALL mvn install:install-file -Dfile=gwt-dev-windows.jar -DgroupId=com.google.gwt -DartifactId=gwt-dev -Dversion=1.4.60 -Dpackaging=jar -Dclassifier=windows -DgeneratePom=true -DcreateChecksum=true I expect the repo to have: .m2\repository\com\google\gwt\gwt-dev\1.4.60\gwt-dev-1.4.60-windows.jar but am getting: .m2\repository\com\google\gwt\gwt-dev\1.4.60\gwt-dev-1.4.60.jar quick fix is to copy the gwt-dev-1.4.60.jar to gwt-dev-1.4.60-windows.jar and the dependencies are then resolved. However its not consistent between two on my machines: Both machines are using maven 2.0.7 with an identical environment setup (with regards to java and maven) the only difference being the actual paths. It's not clear if its some sort of environment setting that makes the difference, but because of the nature of the beast it should not be making a difference. A classifier designation should behave the same regardless of the system setup or the version of maven. The *only* thing that might change it is repository layout (which I have not set and the default new version should be used). Now, this could be some sort of bug in maven and not the plugin (maven not passing information to the plugin) but I am unable to verify that right now. > classifier seems to be ignored > -- > > Key: MINSTALL-42 > URL: http://jira.codehaus.org/browse/MINSTALL-42 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven 2.0.7. I'm unsure of the specific plugin version. >Reporter: Brill Pappin > > install-file is failing to take into account the classifier option... this > used to work (as of last week) but is being ignored when I do the same thing > again. > The repo structure its using is incorrect. > That or possible maven has changed the way that classifier is used. -- 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-1482) XmlRpc API - add method buildAll(...) to ProjectGroupSummary
[ http://jira.codehaus.org/browse/CONTINUUM-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108844 ] Emmanuel Venisse commented on CONTINUUM-1482: - what do you want exactly? you can build a group with buildGroup methods > XmlRpc API - add method buildAll(...) to ProjectGroupSummary > - > > Key: CONTINUUM-1482 > URL: http://jira.codehaus.org/browse/CONTINUUM-1482 > Project: Continuum > Issue Type: New Feature >Affects Versions: 1.1-beta-2 >Reporter: Amine ZAROUK > Fix For: 1.1-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-513) Support remote repositories with passwords
[ http://jira.codehaus.org/browse/MRM-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-513. -- Resolution: Fixed Thank you. Committed in revision 581324 of archiva/trunk. > Support remote repositories with passwords > -- > > Key: MRM-513 > URL: http://jira.codehaus.org/browse/MRM-513 > Project: Archiva > Issue Type: Wish > Components: remote proxy >Affects Versions: 1.0-beta-1, 1.0-beta-2 >Reporter: James William Dumay >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > Attachments: archiva-remote-auth.patch > > > Support remote repositories with passwords. > Currently archiva cannot authenticate to other http auth protected > repositories. -- 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-526) cache-failure policy timeout should be easily configurable
[ http://jira.codehaus.org/browse/MRM-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-526: --- Affects Version/s: 1.0-beta-2 Fix Version/s: 1.0-beta-3 Component/s: remote proxy > cache-failure policy timeout should be easily configurable > -- > > Key: MRM-526 > URL: http://jira.codehaus.org/browse/MRM-526 > Project: Archiva > Issue Type: Improvement > Components: remote proxy >Affects Versions: 1.0-beta-2 >Reporter: JR Boyens > Fix For: 1.0-beta-3 > > > set in a plexus.xml deep in archiva-policy.jar -- 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-202) Change the top-left logo to be an Archiva logo that goes to the front page of the instance
[ http://jira.codehaus.org/browse/MRM-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-202. -- Resolution: Fixed Commit to revision 581332 of archiva/trunk. > Change the top-left logo to be an Archiva logo that goes to the front page of > the instance > -- > > Key: MRM-202 > URL: http://jira.codehaus.org/browse/MRM-202 > Project: Archiva > Issue Type: Wish > Components: web application >Reporter: Henri Yandell >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-3 > > > It's very jarring to click on the Maven link in the top left and be taken to > the Maven website. In other apps this would take me to the front page for the > app. > I'd also wish for it to be customisable, rather than having to show an > Archiva logo. -- 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-531) Unable to download snapshots behind proxy with authentication
[ http://jira.codehaus.org/browse/MRM-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-531: --- Priority: Blocker (was: Major) Fix Version/s: 1.0-beta-3 > Unable to download snapshots behind proxy with authentication > - > > Key: MRM-531 > URL: http://jira.codehaus.org/browse/MRM-531 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-2 > Environment: solaris 5.10, jdk1.6.0_02, proxy with basic > authentication >Reporter: Mathias Arens >Priority: Blocker > Fix For: 1.0-beta-3 > > > I am able to download artifacts from several remote repositories into the > internal repository. But I cannot download any dependencies into the > snapshots repository. I always get a http-'Server redirected too many times > (20)'-error. I read that this error occurs if the proxy authentication > properties are not set correctly in the http client. I am behind a proxy with > basic authentication and an empty password. This configuration works fine for > the internal repository, but not for the snapshot repository. > Here are the logs: > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [ignored] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to IGNORED. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [disabled] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:releases - OK to update, > release policy does not apply for snapshot versions. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [daily] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:snapshots - OK to update > snapshots, local file does not exist. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,988 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/artifact/maven-artifact/3.0-SNAPSHOT/mave > n-artifact-3.0-SNAPSHOT.pom from Apache Snapshots Repository if updated > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:09,087 > [SocketListener0-7] WARN > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Download > failure:Error transferring file > INFO | jvm 1| 2007/10/02 11:50:09 | > org.apache.maven.wagon.TransferFailedException: Error transferring file > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:94) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferSimpleFile(DefaultRepositoryProxyConnectors.java:566) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferFile(DefaultRepositoryProxyConnectors.java:434) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:143) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.applyServerSideRelocation(ProxiedDavServer.java:286) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:243) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) > INFO | jvm 1| 2007/10/02 11:50:09 | at > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.mortbay.jetty.servlet.ServletHolder
[jira] Updated: (MRM-524) Determine HTTP Cache-Control rules for all repository content.
[ http://jira.codehaus.org/browse/MRM-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-524: --- Fix Version/s: 1.0-beta-3 > Determine HTTP Cache-Control rules for all repository content. > -- > > Key: MRM-524 > URL: http://jira.codehaus.org/browse/MRM-524 > Project: Archiva > Issue Type: Task > Components: repository interface >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > With the recently added Cache-Control on maven-metadata.xml files from > MRM-503, it becomes apparent that we need to investigate the Cache-Control > rules for other repository content such as ... > * Release Artifacts > * Snapshot Artifacts > * Hashcodes (sha1, md5) -- 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-444) intermittent test failures on proxy
[ http://jira.codehaus.org/browse/MRM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-444. -- Assignee: Joakim Erdfelt Resolution: Fixed Brett's commit on 574859 increased the delta to 2 ms. > intermittent test failures on proxy > --- > > Key: MRM-444 > URL: http://jira.codehaus.org/browse/MRM-444 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-1 > Environment: mac os x >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > testGetDefaultLayoutAlreadyPresentPolicyIgnored(org.apache.maven.archiva.proxy.ManagedDefaultTransferTest) > Time elapsed: 0.114 sec <<< FAILURE! > junit.framework.AssertionFailedError: Check file timestamp is that of > original managed file: expected within range lo:<1186125890450> > hi:<1186125891550> but was:<1186125892000> > at junit.framework.Assert.fail(Assert.java:47) > at > org.apache.maven.archiva.proxy.ManagedDefaultTransferTest.testGetDefaultLayoutAlreadyPresentPolicyIgnored(ManagedDefaultTransferTest.java:139) -- 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-128) better handling of jar artifacts without a pom
[ http://jira.codehaus.org/browse/MRM-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-128. -- Assignee: Joakim Erdfelt Resolution: Fixed No longer a problem. Likely fixed in earlier version. > better handling of jar artifacts without a pom > -- > > Key: MRM-128 > URL: http://jira.codehaus.org/browse/MRM-128 > Project: Archiva > Issue Type: Bug > Components: indexing >Reporter: Milos Kleint >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > when indexing jar artifacts, the name and description (plus other fields) are > read from the artifact's pom file. When indexing local repository I figured > that some artifacts don't have pom files. Specifically the archetype > artifacts (see ARCHETYPE-48), there might be otehr cases. > So it would be nice to consult the pom file in the actual artifact if pom not > present. (it's stored at META-INF/maven if I recall correctly) -- 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-446) Mail notification should be configurable to notify on every build
[ http://jira.codehaus.org/browse/CONTINUUM-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108850 ] Ammar Hasan commented on CONTINUUM-446: --- Hellos I am having the same issue but the workaround works only for 1.0.2 but I have 1.0.3 installed. So replacing the jar didn't work in my case. Can this change be done in the UI. I think this requirement is very common to have mail sent always. Thanks Ammar > Mail notification should be configurable to notify on every build > - > > Key: CONTINUUM-446 > URL: http://jira.codehaus.org/browse/CONTINUUM-446 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Wim Deblauwe > Attachments: continuum-notifier-api-1.0.2_jamieedits.jar, > notification-edits.txt > > > Continuum currently always optimizes the number of mails it sends by only > sending a mail if the state changes from ok to not ok or vice versa. It would > be better if this is configurable to always send a mail for every build (for > instance for a nightly build). -- 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-476) ability to use file protocol using UNC path for Managed repository
[ http://jira.codehaus.org/browse/MRM-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108851 ] Joakim Erdfelt commented on MRM-476: I just tried 1.0-beta-2 on my winXP (SP2) Laptop, and it allows for the creation of a Managed Repository using only UNC urls. However, the security around UNC is apparently not supported by java. I get a windows popup auth dialog when archiva attempts to access the UNC path. I'm not sure how windows caches those auth credentials. I can't figure out how to get a server webapp to use UNC and provide credentials on the attempt to access that filesystem. I believe this is beyond the capabilities of the standard Java file.io.* libs. I'm going to be closing this jira as fixed. Please open a new Jira if you feel that auth is important with UNC on Archiva. For now, I think we should recommend that people mount their windows file shares properly to gain the benefit of OS provided security/auth. > ability to use file protocol using UNC path for Managed repository > -- > > Key: MRM-476 > URL: http://jira.codehaus.org/browse/MRM-476 > Project: Archiva > Issue Type: New Feature > Components: WebDAV interface >Affects Versions: 1.0-beta-1 > Environment: window NT, apache tomcat 5.5, >Reporter: Patrick Gallagher > Fix For: 1.0-beta-3 > > > Currently, if I try to use a network share with a UNC path when creating a > Managed Repository, the path is replaced with a newly created directory on > the system root. For example, using the path of > file:/\\path_to_network_share gets changed to file:/C:/path_to_network share. > I have tried a combination of strings for the url but have not been able to > connect to a network share. -- 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-476) ability to use file protocol using UNC path for Managed repository
[ http://jira.codehaus.org/browse/MRM-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-476. -- Assignee: Joakim Erdfelt Resolution: Fixed > ability to use file protocol using UNC path for Managed repository > -- > > Key: MRM-476 > URL: http://jira.codehaus.org/browse/MRM-476 > Project: Archiva > Issue Type: New Feature > Components: WebDAV interface >Affects Versions: 1.0-beta-1 > Environment: window NT, apache tomcat 5.5, >Reporter: Patrick Gallagher >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Currently, if I try to use a network share with a UNC path when creating a > Managed Repository, the path is replaced with a newly created directory on > the system root. For example, using the path of > file:/\\path_to_network_share gets changed to file:/C:/path_to_network share. > I have tried a combination of strings for the url but have not been able to > connect to a network share. -- 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-203) Reports should be public, not an administration feature
[ http://jira.codehaus.org/browse/MRM-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-203. -- Assignee: Joakim Erdfelt Resolution: Fixed Closing, as this is currently this is configurable by the archiva administrator. They can choose to grant the archiva-access-reports to anyone they choose. > Reports should be public, not an administration feature > --- > > Key: MRM-203 > URL: http://jira.codehaus.org/browse/MRM-203 > Project: Archiva > Issue Type: Wish > Components: web application >Reporter: Henri Yandell >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Unless I'm missing something, reports are only seen by people with special > permissions. This seems pretty lame. -- 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-309) relocated artifacts are not delivered
[ http://jira.codehaus.org/browse/MRM-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-309. -- Assignee: Joakim Erdfelt Resolution: Duplicate Duplicate: Fixed by MRM-153, commited by oching on revision 576032 (Sept 15, 2007) > relocated artifacts are not delivered > - > > Key: MRM-309 > URL: http://jira.codehaus.org/browse/MRM-309 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: latest version from SVN (rev. 521221) > archiva running in tomcat-5.5.17 on a linux system >Reporter: Joerg Vater >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > One managed repository with two proxied repositories. > When I request an artifact that is relocated in the proxied repository, the > relocaated artifact is downloaded to the local repository but not delivered > to the requestor. > -- log messages: > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact > requested is: easymock:easymock:jar:2.0:runtime > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/easymock/easymock/2.0/easymock-2.0.pom > does not exist > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository > 2007-03-22 13:32:05,877 8868794 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > 2007-03-22 13:32:05,889 8868806 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact > easymock:easymock:2.0 has been relocated to org.easymock:easymock:2.0 > 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository > 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.pom > does not exist > 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository > 2007-03-22 13:32:06,157 8869074 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.jar from ComBOTS Maven2 Repository > 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.jar > does not exist > 2007-03-22 13:32:06,159 8869076 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.jar from Maven2 Central Repository > 2007-03-22 13:32:07,017 8869934 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > -- html response: > Error 404 Not Found > Resource in error: > http://mavenproxy:9080/archiva/repository/easymock/easymock/2.0/easymock-2.0.jar/easymock/easymock/2.0/easymock-2.0.jar > Exception details: > it.could.webdav.DAVException: Not found > at it.could.webdav.methods.HEAD.process(HEAD.java:52) > at it.could.webdav.methods.GET.process(GET.java:58) > at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) > at > org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) >
[jira] Commented: (MSITE-253) NoClassDefFoundError for org/codehaus/plexus/util/xml/XmlStreamReader
[ http://jira.codehaus.org/browse/MSITE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108854 ] Dennis Lundberg commented on MSITE-253: --- Can you please create a small project that reproduces this error, and then attach that project to this issue. > NoClassDefFoundError for org/codehaus/plexus/util/xml/XmlStreamReader > - > > Key: MSITE-253 > URL: http://jira.codehaus.org/browse/MSITE-253 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "linux" version: "2.6.20-16-generic" arch: "i386" >Reporter: Ben Tomasini > > When executing mvn site, the build fails with the following error (stack > traces turned on): > [ERROR] BUILD ERROR > [INFO] > > [INFO] Internal error in the plugin manager executing goal > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:site': Unable > to find the mojo > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:site' in the > plugin 'org.apache.maven.plugins:maven-site-plugin' > org/codehaus/plexus/util/xml/XmlStreamReader > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the > plugin manager executing goal > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:site': Unable > to find the mojo > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:site' in the > plugin 'org.apache.maven.plugins:maven-site-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the > mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:site' in > the plugin 'org.apache.maven.plugins:maven-site-plugin' > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:571) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Unable to lookup component > 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-site-plugin:2.0-beta-6-SNAPSHOT:site', > it could not be started > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:339) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) > ... 18 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLifecycleException: > Error starting component > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:109) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) > at >
[jira] Issue Comment Edited: (MECLIPSE-174) Plugin doesn't cache "source not available" status
[ http://jira.codehaus.org/browse/MECLIPSE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108465 ] Chuck Daniels edited comment on MECLIPSE-174 at 10/2/07 3:17 PM: - Looks like this has regressed in version 2.4 of this plugin. The mvn-eclipse-cache.properties file is empty (except for header comment) after running eclipse:eclipse with downloadSources and downloadJavadocs set to true. Now every run of eclipse:eclipse attempts to download sources and javadocs since cache file contains no entries. was: Looks like this has regressed in version 2.5 of this plugin. The mvn-eclipse-cache.properties file is empty (except for header comment) after running eclipse:eclipse with downloadSources and downloadJavadocs set to true. Now every run of eclipse:eclipse attempts to download sources and javadocs since cache file contains no entries. > Plugin doesn't cache "source not available" status > -- > > Key: MECLIPSE-174 > URL: http://jira.codehaus.org/browse/MECLIPSE-174 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Aaron Digulla >Assignee: fabrizio giustina >Priority: Minor > Fix For: 2.3 > > > When the m2 plugin reads the POM files and "Download sources" is set in the > Eclipse preferences, it tries to download the source every time. > Instead, it should cache the "source not available" status somewhere (just > like Maven itself does) and not print thousands of error messages (Unable to > download the artifact from any repository). > This also delays the build considerably (opening network connections) and > real errors are drowned. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-107) maven archetype missing dependency versions breaks archetype:create
maven archetype missing dependency versions breaks archetype:create Key: ARCHETYPE-107 URL: http://jira.codehaus.org/browse/ARCHETYPE-107 Project: Maven Archetype Issue Type: Bug Components: Archetypes Environment: linux 2.6 (Xubuntu) Reporter: Andrew Waterman Priority: Critical When I try to invoke the "create" goal in the 2.0.7 version of maven, I receive the following error message when invoked from a directory with an existing pom.xml: Project ID: org.apache.maven.plugins:maven-archetype-plugin POM Location: Artifact [org.apache.maven.plugins:maven-archetype-plugin:pom:1.0-SNAPSHOT] Validation Messages: [0] 'dependencies.dependency.version' is missing for org.apache.maven.archetype:maven-archetype-creator Reason: Failed to validate POM for project org.apache.maven.plugins:maven-archetype-plugin at Artifact [org.apache.maven.plugins:maven-archetype-plugin:pom:1.0-SNAPSHOT] The currently staged version of the maven-archetype-creator dependency contains a missing version reference: org.apache.maven.archetype maven-archetype-model [source: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-creator/1.0-alpha-7/maven-archetype-creator-1.0-alpha-7.pom] This effectively breaks the archetype:create goal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-235) Eclipse Maven plugin has its own Classpath Container that conflicts with generated class paths when enabled.
[ http://jira.codehaus.org/browse/MECLIPSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hasan Ceylan updated MECLIPSE-235: -- Attachment: q4t_patch.txt Hello, I am back Firstly, I really liked your solution. Secondly, the folk at Google Code, q4t has created a pretty good plugin for eclipse that I now favor over m2eclipse. the new patch is a replica of your M2EclipseMojo, modified to reflect requirements of the q4t plugin. Any plan for a 2.5 release? Regards, Hasan Ceylan > Eclipse Maven plugin has its own Classpath Container that conflicts with > generated class paths when enabled. > > > Key: MECLIPSE-235 > URL: http://jira.codehaus.org/browse/MECLIPSE-235 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Environment: Should be OK for ALL >Reporter: Hasan Ceylan > Fix For: 2.5 > > Attachments: eclipseM2Plugin.diff, q4t_patch.txt > > > When we create eclipse projects using the maven-eclipse-plugin, all the class > path entries for the dependent libraries are added to the .classpath. > For those like me who has eclipse maven plugin, enabling maven2 for the > generated project creates duplicate libraries as maven also introduces its > own container based on the information in the pom.xml. > I took the liberty to modify the head, and introduced the > "eclipse.withM2Plugin" parameter. If this parameter is true in the runtime, > 1) In EclipsePlugin.setup() > a) If "org.maven.ide.eclipse.maven2Nature" nature is not added in the > configuration, it is added automatically. > b) If "org.maven.ide.eclipse.maven2Builder" builder is not added in the > configuration, it is added automatically. > c) If "org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER" container is added > automatically. > 2) In config > introduced the method hasMaven2Nature() which indicates if Maven2 nature is > available > 3) M2_REPO's skipped in EclipseClasspathWriter if config returns true for > hasMaven2Nature() > Hope you like the patch... > Regards, > Hasan Ceylan -- 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: (MJAR-78) jar:sign skip option does not work
[ http://jira.codehaus.org/browse/MJAR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108907 ] Jerome Lacoste commented on MJAR-78: Can someone check in this trivial patch ? > jar:sign skip option does not work > -- > > Key: MJAR-78 > URL: http://jira.codehaus.org/browse/MJAR-78 > Project: Maven 2.x Jar Plugin > Issue Type: Bug > Components: sign >Affects Versions: 2.1, 2.2 >Reporter: Ryan Perkins >Priority: Minor > Fix For: 2.2 > > Attachments: MJAR-78-maven-jar-plugin.patch > > > The skip option added to jar:sign in MJAR-23 prints a message saying that > signing will be skipped, but signing still happens. -- 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: (MJAR-84) Need ability to not attach a jar when not signing in place
Need ability to not attach a jar when not signing in place -- Key: MJAR-84 URL: http://jira.codehaus.org/browse/MJAR-84 Project: Maven 2.x Jar Plugin Issue Type: New Feature Components: sign Affects Versions: 2.1 Reporter: Jerome Lacoste Priority: Blocker Fix For: 2.2 I need the ability to skip attaching a jar when the sign mojo doesn't sign in place. The reason is that I reuse the jarsign mojo in the webstart plugin and get a NPE as no project field has been initialized by plexus. I created a patch that solves my problem. It is currently attached to MWEBSTART-34 (http://jira.codehaus.org/secure/attachment/29710/MJAR_MWEBSTART-34_support_plus_MJAR-67.diff) but I am not completely satisfied: ideally the sign functionality should be independant of the mojo itself and this field should not be necessary. WDYT ? -- 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: (MPEAR-46) Unknown artifact type[java-source]
[ http://jira.codehaus.org/browse/MPEAR-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108914 ] Brian Topping commented on MPEAR-46: I've run into this issue now as well, in 2.0.7. One of my projects generates an artifact of type "template", which is depended upon by several others. Oddly, this worked just fine on one machine, but not another. Will report more as I get it. > Unknown artifact type[java-source] > --- > > Key: MPEAR-46 > URL: http://jira.codehaus.org/browse/MPEAR-46 > Project: Maven 1.x Ear Plugin > Issue Type: Bug > Environment: Windows > Eclipse 3.1 >Reporter: Tom Bollwitt >Priority: Trivial > Fix For: 1.9.1 > > > When a POM (parent or dependency) includes java source jar dependencies they > are not ignored and an error is thrown. > > mygroup > artifact2 > 1.0 > java-source > > When running 'package' or ear:ear I am getting the following error: > [INFO] [ear:generate-application-xml] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to initialize ear modules > Embedded error: Unknown artifact type[java-source] > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to initialize > ear modules > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to > initialize ear modules > at > org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:151) > at > org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown > artifact type[java-source] > at > org.apache.maven.plugin.ear.ArtifactTypeMappingService.getStandardType(ArtifactTypeMappingService.java:153) > at > org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:60) > at > org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:144) > ... 19 more > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Aug 30 11:49:59 CDT 2006 > [INFO] Final Memory: 4M/7M > I added test to the java-source dependency and was able to > work around this issue. The scope is missleading and therefore the desired > behavior would be to not require scoping the java-source dependency. -- 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
