[jira] Closed: (MNGSITE-26) Maven guide to attached tests contains a bug in the documentation
[ http://jira.codehaus.org/browse/MNGSITE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MNGSITE-26. Assignee: Lukas Theussl Resolution: Fixed Fixed, it will show up after the next site deploy. Thanks! > Maven guide to attached tests contains a bug in the documentation > - > > Key: MNGSITE-26 > URL: http://jira.codehaus.org/browse/MNGSITE-26 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: zalym >Assignee: Lukas Theussl >Priority: Minor > > The maven guide to using attached > tests(http://maven.apache.org/guides/mini/guide-attached-tests.html) contains > a bug. It supposed to state > > com.myco.app > foo > 1.0-SNAPSHOT > tests > test > > as that is what the source code supports. > http://www.nabble.com/forum/ViewPost.jtp?post=12812015&framed=y&skin=177 -- 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-670) State of a project
[ http://jira.codehaus.org/browse/CONTINUUM-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108001 ] George Gastaldi commented on CONTINUUM-670: --- This is surely a "must" for continuum > State of a project > -- > > Key: CONTINUUM-670 > URL: http://jira.codehaus.org/browse/CONTINUUM-670 > Project: Continuum > Issue Type: New Feature > Components: Core system >Reporter: Reinhard Spisser > Fix For: Future > > > I suggest to introduce states of the projects: active, disabled and archived > - active: continuum will check for modifications and build it > - disabled: the project remains on the same "project list" as the > active project (the continuum homepage), but the project links are > greyed out. Continuum will not check for modifications. Projects can > be enabled again to become active. > - archived: the project is not show on the main project list, but on a > "Archived Projects" tab (or something similar). These projects will > not be build, but build history will remain. > With this states, someone could write a program that disables a > project if no commits were done in the last x weeks and archives a > project if no commits were done in the last x months. Also, if a > commit is done in a disabled project then the project is enabled > again. -- 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-1486) Show the type of artifact produced and allow downloads of artifacts
Show the type of artifact produced and allow downloads of artifacts --- Key: CONTINUUM-1486 URL: http://jira.codehaus.org/browse/CONTINUUM-1486 Project: Continuum Issue Type: Wish Components: Web interface Affects Versions: 1.1-beta-2 Reporter: George Gastaldi Each project should show the type of artifact produced as a image (JAR, WAR, EAR, ZIP, etc...) and if possible, a link to download from the repository via continuum. -- 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-489) Repositories are read only even for repository managers
[
http://jira.codehaus.org/browse/MRM-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108000
]
Joakim Erdfelt commented on MRM-489:
Here is the breakdown of the litmus test, with comments.
*Setup:*
* Archiva Trunk revision 578314.
* Tomcat 5.0.28
* JDK 1.5.0_11
* Linux (Ubuntu Fiesty Fawn)
* {{litmus}} version 0.9.4-2
*Configuration:*
* Installed per instructions at
http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat
* 2 repos.
** {{internal}} : with allowed releases and no snapshots.
** {{snapshots}} : with allowed snapshots and no releases.
* Guest user configured with Global Repository Observer.
* Guest user configured with Global Repository Manager.
*Command Line:*
{noformat}
$ litmus http://192.168.1.145:8080/archiva/repository/internal/
{noformat}
*Report:*
-> running `basic':
|| # || Test Name || Result ||
| 0. | init | (/) pass |
| 1. | begin | (/) pass |
| 2. | options | (!) WARNING: server does not claim Class 2 compliance
(/) pass (with 1 warning) |
| 3. | put_get | (/) pass |
| 4. | put_get_utf8_segment | (/) pass |
| 5. | mkcol_over_plain | (/) pass |
| 6. | delete | (/) pass |
| 7. | delete_null | (/) pass |
| 8. | mkcol | (/) pass |
| 9. | mkcol_again | (/) pass |
|10. | delete_coll | (/) pass |
|11. | mkcol_no_parent | (-) FAIL (MKCOL with missing intermediate succeeds) |
|12. | mkcol_with_body | (/) pass |
|13. | finish | (/) pass |
<- summary for `basic': of 14 tests run: 13 passed, 1 failed. 92.9%
-> 1 warning was issued.
See debug.log for network/debug traces.
*Responses to Warnings/Errors*
The warning outlined in test #2 refers to the fact that Archiva is a Level 1,
(Class 1) WebDAV server. That is an intentional decision, and does not violate
the WebDAV standard. It just means Archiva doesn't have advanced locking and
versioning.
The error outlined in test #11 (mkcol_no_parent) refers the ability to MKCOL in
a deep sense, without the need to MKCOL the parent directory first. This is an
internal decision to allow for proxying of content not present in the webdav
collection at the time of the request. This behavior is quite likely a
violation of WebDAV standard (however I cannot find this section in the spec).
> Repositories are read only even for repository managers
> ---
>
> Key: MRM-489
> URL: http://jira.codehaus.org/browse/MRM-489
> Project: Archiva
> Issue Type: Bug
> Components: WebDAV interface
>Affects Versions: 1.0-alpha-2
> Environment: OSX
>Reporter: Andrew Williams
>Assignee: Joakim Erdfelt
>
> Both the OSX client and the litmus test suite report that the repositories
> are read only and cannot be deployed to.
--
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-1436) Add build definition template
[ http://jira.codehaus.org/browse/CONTINUUM-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1436. --- Resolution: Fixed committed in rev 578318. > Add build definition template > - > > Key: CONTINUUM-1436 > URL: http://jira.codehaus.org/browse/CONTINUUM-1436 > Project: Continuum > Issue Type: Improvement > Components: Core system, Web - UI >Reporter: Emmanuel Venisse >Assignee: Olivier Lamy > Fix For: 1.1-beta-4 > > > A build definition template is a set of build definitions that can be add to > a group. > A user will can choose to attach a template (by default no template will be > selected and we'll use the actual mechanism) to a group. > The templates list will be accessible from the admin menu. > h1. Process: > - when the user add a new project, if no project group is selected, he can > choose a template to add to the group > - when the user create a new group, he can choose a template > - from the group build def page, the user can choose a template to add > h1. storage: > Templates will be stored in a new table. Entries in this table will be linked > to some build definitions stored in the build definitions table > These build definitions won't be use directly by groups but only by templates > so when the user want to use a template, continuum will *copy* all build > definitions from the template to the group so templated build definitions > will can be modified without affected build def already used by groups. -- 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-320) ProxiedDavServer breaks update policy
[ http://jira.codehaus.org/browse/MRM-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-320. -- Resolution: Fixed The fix for MRM-153 fixed this bug in subversion. > ProxiedDavServer breaks update policy > - > > Key: MRM-320 > URL: http://jira.codehaus.org/browse/MRM-320 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-1 >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-3 > > > The ProxiedDavServer use hasResource() to bypass proxyRequestHandler if > requested resource is allready in the managed repo. > This sounds a good optimization, but breaks any update capability of archiva. > When I deploy a new snapshot, developper never get an updated one... -- 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-333) Tomcat deployment of archiva results in unstable instance.
[ http://jira.codehaus.org/browse/MRM-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-333. -- Resolution: Fixed Fix Version/s: (was: 1.0.x) 1.0-beta-3 All open issues with Tomcat have been closed. All fixes have been committed to archiva/trunk in svn. The next archiva release (1.0-beta-3?) will contain these fixes. > Tomcat deployment of archiva results in unstable instance. > -- > > Key: MRM-333 > URL: http://jira.codehaus.org/browse/MRM-333 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > When deploying archiva to a tomcat instance, the resulting instance is > unstable and causes many other problems. > We need to identify, and document a tomcat installation. > Wiki docs: http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat > If a specific tomcat topic arises, please link it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-213) cannot undeploy archiva webapp
[ http://jira.codehaus.org/browse/MRM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-213. -- Resolution: Fixed Fix Version/s: (was: 1.0.x) 1.0-beta-3 Upgrading the ehcache version to get the benefits of the reworked shutdown hook has worked. Fix has been commit'd to revision 578314 in archiva/trunk. > cannot undeploy archiva webapp > -- > > Key: MRM-213 > URL: http://jira.codehaus.org/browse/MRM-213 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: I'm running Archiva webapp under tomcat 5.5 / windows > 2003 server >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0-beta-3 > > > I'd like to undeploy without restarting Tomcat (as I don't have admin acces > to the server). When I undelploy archiva webapp using tomcat manager, the > webapp/archiva directory is not removed and WEB-INF/lib still contains: > jpox-1.1.1.jar > plexus-container-default-1.0-alpha-10.jar > plexus-security-authorization-rbac-store-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-keys-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-user-management-provider-jdo-1.0-alpha-6-20061013.204855-1.jar > webwork-2.2.4.jar > xwork-1.2.1.jar > I cannot remove those jars (files locked) > Maybe some background thread is not stopped at application undeploy ? -- 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-1485) CVS checkout is considerably slower
CVS checkout is considerably slower --- Key: CONTINUUM-1485 URL: http://jira.codehaus.org/browse/CONTINUUM-1485 Project: Continuum Issue Type: Bug Components: SCM Affects Versions: 1.1-beta-2 Environment: Running on Windows XP inside Tomcat 5.5.17, communicating with CVSNT server, using CVSNT client. Reporter: Adrian Sox The project tree we are building is fairly large (5,000 files, 220 MB). It normally takes 5-6 minutes to perform a cvs update on this tree when executing from the command line or Eclipse. With Continuum 1.0.3, it took 5-6 minutes to update the project from CVS, before the actual "build" began. With 1.1-beta-2, it takes much longer - 15-20 minutes - to perform the same update. Build Fresh is not checked. The two versions of Continuum are set up identically in all other regards, except that 1.0.3 is run standalone, not from Tomcat. Both run on the same box, as the same user, use the same CVS executable, hit the same CVS server, use the same Java version, the same Maven 2 version, the same disk drive, ... and of course, with only one version of Continuum running at any given time. Aside from this issue, we very much like the changes in 1.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: (MRM-213) cannot undeploy archiva webapp
[ http://jira.codehaus.org/browse/MRM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107994 ] Joakim Erdfelt commented on MRM-213: Encountered this problem not on undeploy specifically, but even Tomcat shutdown. This prevented the proper shutdown of the JDK/JRE too. It was left running in memory, even though the Tomcat threads were no longer running. Tested on Windows XP (SP2) w/ Tomcat 5.0.28 Using Archiva SVN Trunk r578241 JDK 1.5.0_11 > cannot undeploy archiva webapp > -- > > Key: MRM-213 > URL: http://jira.codehaus.org/browse/MRM-213 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: I'm running Archiva webapp under tomcat 5.5 / windows > 2003 server >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0.x > > > I'd like to undeploy without restarting Tomcat (as I don't have admin acces > to the server). When I undelploy archiva webapp using tomcat manager, the > webapp/archiva directory is not removed and WEB-INF/lib still contains: > jpox-1.1.1.jar > plexus-container-default-1.0-alpha-10.jar > plexus-security-authorization-rbac-store-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-keys-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-user-management-provider-jdo-1.0-alpha-6-20061013.204855-1.jar > webwork-2.2.4.jar > xwork-1.2.1.jar > I cannot remove those jars (files locked) > Maybe some background thread is not stopped at application undeploy ? -- 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-323) Managed repo in archiva cannot be accessed thru direct webdav url even with valid credentials (Archiva deployed in Tomcat)
[ http://jira.codehaus.org/browse/MRM-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-323. -- Resolution: Fixed Fix Version/s: (was: 1.0.x) 1.0-beta-3 This has been fixed in archiva/trunk > Managed repo in archiva cannot be accessed thru direct webdav url even with > valid credentials (Archiva deployed in Tomcat) > -- > > Key: MRM-323 > URL: http://jira.codehaus.org/browse/MRM-323 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-1 > Environment: - Tomcat 5.5.20 > - Linux > - Mozilla Firefox >Reporter: Maria Odea Ching >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > Attachments: archiva-0.9.xml, archiva.xml, logs.zip > > > Steps to re-create issue: > - Deploy Archiva in Tomcat, then start tomcat > - Access Archiva in browser and set the required configurations > - Add A Managed Repository with the following configuration: > - id: snapshots > - name: snapshots > - url: snapshots (it would have the value > http://localhost:[PORT]/archiva/repository/snapshots) > - directory: snapshots > - Go to User Management and add the Repository Observer role for the > 'snapshots' repo to the current user > - Open a new tab in your browser then type the webdav URL: > http://localhost:[PORT]/archiva/repository/snapshots > - Supply the user credentials for the 'snapshots' repository. You still > wouldn't be able to access it even if you supply the correct credentials. > Also, the following error shows up in the Archiva logs when you try to build > a Maven project with your settings.xml file configured to use the > repositories in archiva: > 102476 [http-9696-Processor23] ERROR > org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/archiva].[RepositoryServlet] > - Servlet.service() for servlet RepositoryServlet threw exception > javax.servlet.ServletException: Unable to service DAV request due to > unconfigured DavServerComponent for prefix [snapshots]. > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:93) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) > at java.lang.Thread.run(Thread.java:619) -- 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
[jira] Closed: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-243. -- Resolution: Fixed > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-beta-1, 1.0-beta-2 > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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: (MCLOVER-77) Artifact has 2 candidates, please provide a classifier
[ http://jira.codehaus.org/browse/MCLOVER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107991 ] Martin Franklin commented on MCLOVER-77: I have put up a patch on the maven2 ear plugin jira http://jira.codehaus.org/browse/MEAR-76 which resolves this issue. Basically this is caused when the application.xml is generated for an ear and the module is listed in both the dependency section and the Modules section. Clover swizzles the dependencies to refer to the cloverized artifact, but does nothing to the Modules section. When the ear tries to create the application.xml (as per the INFO - [INFO] [ear:generate-application-xml] above) the Modules are checked against the local repository and both the unclovered version and the clovered version are found and so the error is reported. This can be fixed by specifying a classifier in the Modules section for the ear, but means that you must create two poms (or use complicated profiles), one with the classifier set to clover and one set to the empty string. This is a pain and hard to maintain. The patch I have posted resolves this and along with MCLOVER-82 allows for the creation of a true cloverized ear, using cloverized jars. > Artifact has 2 candidates, please provide a classifier > -- > > Key: MCLOVER-77 > URL: http://jira.codehaus.org/browse/MCLOVER-77 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: maya nayak > > INFO - > INFO - [INFO] [clover:instrumentInternal] > INFO - [WARNING] No Clover instrumentation done as no matching sources files > found > INFO - [INFO] [ear:generate-application-xml] > INFO - [INFO] > > INFO - [ERROR] BUILD FAILURE > INFO - [INFO] > > INFO - [INFO] Artifact[jar:com.tsysprepaid.psa:psa-common] has 2 candidates, > please provide a classifier. > INFO - [INFO] > > psa-common is a separate project and i ran clover:instrument successfully on > that. it created psa-common--clover.jar in the local > repository and after that my other project which lists psa-common as a > dependency started to fail on clover:instrument with the above error. > It appears that since psa-common now has psa-common-.jar and > psa-common--clover.jar in the repository, clover > is unable to resolve it and fails it with message artificat has 2 candidates, > please provide a classifier. > How do I provide a classifier? > Is there any way to prevent clover from installing clover artifacts into m2 > repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-76) This resolution resolves the Clover defect MCLOVER-77
This resolution resolves the Clover defect MCLOVER-77 - Key: MEAR-76 URL: http://jira.codehaus.org/browse/MEAR-76 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.2 Environment: windows/jdk1.5/cloer plugin 2.3.1 and above Reporter: Martin Franklin Attachments: cloverclassifier.diff The clover plugin 'swizzles' the dependencies of an artifact when the clover:instrument goal is executed. This adds the classifier 'clover' to those dependencies of the ear which can be resolved as clovered artifacts. However due to some assumptions made in constructing the ear the problem detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created. The cause turns out to be multiple problems - first after clover 'swizzles' the dependencies the list gets new versions added during ear processing. I suspect this is due to the classifier being different so the dependencies of the dependencies are not found and so they get added again. Thus the same dependency is listed in the project.getArtifacts() Set. Once with the clover classifier and once with null. The second problem is the application.xml generation which adds a second set of dependencies. This can be resolved by specifying the classifier for the specific module listed in the Modules section. However this is awkward to use if you wish to use the same pom for both clovered and unclovered ear generation. This patch supports this. This patch will always select an artifact with a classifier rather than one with null set. The matching is only done at the groupid/artifactid level, but I believe that should be sufficient. Duplicate EarModules are also removed so that only the most specific gorupid/artifactid/classifier is used for both inclusion in the ear and inclusion in the application.xml One last point about the patch - I could not get test 42 to run before I started work on the patch, so this test is commented out in the patch. All the other tests worked fine. As creating a test would require creating a linkage with the clover plugin, and the fact that the clover plugin itself needs a patch MCLOVER-82, in order to fully display these effects easily, I haven't created a test case for it. I have tested this with my own projects which show that MCLOVER-77 is now resolved with this patch. -- 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-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107990 ] Joakim Erdfelt commented on MRM-243: The most archiva/trunk has the fix commited. See revision 578241 > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-beta-1, 1.0-beta-2 > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-243: --- Affects Version/s: 1.0-beta-2 1.0-alpha-1 1.0-alpha-2 1.0-beta-1 > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-beta-1, 1.0-beta-2 > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-789) Show SCM branch/tag on summary screen
[ http://jira.codehaus.org/browse/CONTINUUM-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomislav Stojcevich updated CONTINUUM-789: -- Attachment: CONTINUUM-789-continuum-webapp.patch > Show SCM branch/tag on summary screen > - > > Key: CONTINUUM-789 > URL: http://jira.codehaus.org/browse/CONTINUUM-789 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0.3 >Reporter: thierry lach >Priority: Minor > Fix For: Future > > Attachments: CONTINUUM-789-continuum-webapp.patch > > > Since there may be multiple revisions of a project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGSITE-26) Maven guide to attached tests contains a bug in the documentation
Maven guide to attached tests contains a bug in the documentation - Key: MNGSITE-26 URL: http://jira.codehaus.org/browse/MNGSITE-26 Project: Maven Project Web Site Issue Type: Bug Reporter: zalym Priority: Minor The maven guide to using attached tests(http://maven.apache.org/guides/mini/guide-attached-tests.html) contains a bug. It supposed to state com.myco.app foo 1.0-SNAPSHOT tests test as that is what the source code supports. http://www.nabble.com/forum/ViewPost.jtp?post=12812015&framed=y&skin=177 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-211: -- Patch attached: Yes > Can't deploy site using site:deploy due to a ProxyHTTP error > > > Key: MSITE-211 > URL: http://jira.codehaus.org/browse/MSITE-211 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-5 > Environment: linux ubuntu dapper drake >Reporter: Elid OR >Priority: Blocker > Attachments: MSITE-211.patch > > > When I execute the site deployment (with version that comes with maven 2.0.5) > "mvn site:deploy " I got an error see log en debug mode below. This used to > work correctly with maven version 2.04 (so maybe site plugin version > 2.0-beta-4 : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy > error: Forbidden > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > 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:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:324) > 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: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.wagon.authentication.AuthenticationException: > Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: > Forbidden > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) > ... 18 more > Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: > proxy error: Forbidden > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 20 more > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 > [INFO] Final Memory: 3M/7M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-245) parent filesystem site.xml is never be found
[
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MSITE-245:
--
Patch attached: Yes
> parent filesystem site.xml is never be found
>
>
> Key: MSITE-245
> URL: http://jira.codehaus.org/browse/MSITE-245
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.0-beta-5
> Environment: 2.0.7
>Reporter: John Allen
>Assignee: John Casey
>Priority: Blocker
> Attachments: site-patch.txt
>
>
> The current approach used by the getSiteDescriptorFile(File, Locale) is wrong
> as the basedir passed in to it is not just the project's own basedir, it's
> potentially a parent project's basedir and thus the previous code makes no
> sense as we would need to add on the parent's site.xml site directory and
> then try and find the relative path to it and as there's no way (that I know
> of) of a) finding that out from the parent project's object model (even if we
> passed it in) and b) the current code does not append anything to the passed
> in basedir so is always looking for a site.xml in the parents root directory.
> What's more the use of a relative path here is pointless too as we simply
> read in the descriptor file, not persist it into links where relativePaths
> are useful.
> Current code:
> {code}
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
>String relativePath = getRelativePath(
> siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
> File siteDescriptor = new File( relativePath, "site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( relativePath, "site.xml" );
> }
> return siteDescriptor;
> }
> {code}
> Fixed code
> {code}
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
> String sitePath;
>
> if ( basedir.equals( project.getBasedir() ))
> {
> // it's this project's basedir so use our siteDirectory (allows
> this project
> // to use a custom site location)
>
> sitePath = siteDirectory.getAbsolutePath();
> }
> else
> {
> // it's not this project's basedir so it must be one of our
> parent's,
> // so we'll just have to assume they store their site.xml in the
> // standard location (src/site)
>
> sitePath = basedir.getAbsolutePath() + "/src/site";
> }
>
> File siteDescriptor = new File( sitePath, "site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( sitePath, "site.xml" );
> }
> return siteDescriptor;
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-251) tr locale support
[ http://jira.codehaus.org/browse/MSITE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-251: -- Patch attached: Yes > tr locale support > - > > Key: MSITE-251 > URL: http://jira.codehaus.org/browse/MSITE-251 > Project: Maven 2.x Site Plugin > Issue Type: New Feature > Components: localization > Environment: Windows XP >Reporter: gulcan yalcinkaya >Priority: Trivial > Attachments: project-info-report_tr.properties, > site-plugin_tr.properties > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-45) abilitiy to create an ear/war/zip from site
[ http://jira.codehaus.org/browse/MSITE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-45: - Patch attached: Yes > abilitiy to create an ear/war/zip from site > --- > > Key: MSITE-45 > URL: http://jira.codehaus.org/browse/MSITE-45 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Brett Porter > Attachments: MSITE-45-maven-site-plugin.patch, patch.txt > > > I think they should be standalone goals, like in m1 > site:ear -> create ear > site:war -> create war > site:zip -> create zip > I think this one might be a lower priority. I will postpone it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-233) NoSuchMethodError with Java 6
[ http://jira.codehaus.org/browse/MSITE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-233. - Resolution: Fixed This was apparently fixed in beta-5. > NoSuchMethodError with Java 6 > - > > Key: MSITE-233 > URL: http://jira.codehaus.org/browse/MSITE-233 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven 2.0.6, Java 1.6.0_01-b06, maven-site-plugin > 2.0-beta-4 >Reporter: Paul Benedict > Fix For: 2.0-beta-5 > > > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] > org.codehaus.plexus.util.FileUtils.getDefaultExcludes()[Ljava/lang/String; > [INFO] > > [INFO] Trace > java.lang.NoSuchMethodError: > org.codehaus.plexus.util.FileUtils.getDefaultExcludes()[Ljava/lang/String; > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:275) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-233) NoSuchMethodError with Java 6
[ http://jira.codehaus.org/browse/MSITE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-233: -- Affects Version/s: 2.0-beta-4 Fix Version/s: 2.0-beta-5 > NoSuchMethodError with Java 6 > - > > Key: MSITE-233 > URL: http://jira.codehaus.org/browse/MSITE-233 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven 2.0.6, Java 1.6.0_01-b06, maven-site-plugin > 2.0-beta-4 >Reporter: Paul Benedict > Fix For: 2.0-beta-5 > > > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] > org.codehaus.plexus.util.FileUtils.getDefaultExcludes()[Ljava/lang/String; > [INFO] > > [INFO] Trace > java.lang.NoSuchMethodError: > org.codehaus.plexus.util.FileUtils.getDefaultExcludes()[Ljava/lang/String; > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:275) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-409) Email notifications could still include build stats when includeBuildResult is false
[ http://jira.codehaus.org/browse/CONTINUUM-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomislav Stojcevich updated CONTINUUM-409: -- Attachment: CONTINUUM-409-continuum-core.patch Here is a patch that allows a new attribute that can be used to control the summary information. It's not as robust as allowing individual sections to be turned on or off but I think this will at least allow those who want the summary but not the build result in the email to get by until the more robust CONTINUUM-310 gets included. > Email notifications could still include build stats when includeBuildResult > is false > > > Key: CONTINUUM-409 > URL: http://jira.codehaus.org/browse/CONTINUUM-409 > Project: Continuum > Issue Type: Wish > Components: Notifier - Mail >Affects Versions: 1.0 >Reporter: David Blevins > Fix For: Future > > Attachments: CONTINUUM-409-continuum-core.patch > > > I really like the "Build statistics" and "Changes" sections continuum creates > in the emails and definitely want them in every email. It's really just the > section that contains the output generated from the build itself that I don't > want as that will consistently be several megs of text for our project. > Basically, I assumed 'includeBuildResults=false' would just exclude out > everything after these lines > > Output: > > I really don't care what the option is called as long as I can get an email > as described. > Maybe you want to do something like this > true > true > false -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107973 ] Mark Eramo edited comment on MJAR-30 at 9/21/07 3:01 PM: - I do see the code attached above but I was not sure if I needed to pull it from an official repository. Thanks, Mark was: I do see the code attahced above but I was not sure if I needed to pull it from an official repository. Thanks, Mark > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: fail-patch.txt, MJAR-30-maven-jar-plugin-1.patch, > MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- 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-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107975 ] Joakim Erdfelt commented on MRM-243: One extra note about previous comment. The metadata upload that caused the "507 Insufficient Storage" error occured when the SNAPSHOT deploy attempted to upload the metadata file. It did not conflict with the maven-metadata.xml from the previous deploy (as that was on a different repository). It appears that the previous request for the maven-metadata.xml causes the problem with the deploy of the updated maven-metadata.xml file. More research is needed here. I would hate to see this be a problem in the simple-webdav impl. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107974 ] Joakim Erdfelt commented on MRM-243: I was able to duplicate this problem on the following environment ... Tested on WinXP(SP2) w/ Tomcat 5.0.28. Using Archiva SVN Trunk r577463 JDK 1.5.0_11 Using the configuration specified at http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat#ArchivaonTomcat-Tomcat5.0.xSpecifics I created a simple project with a 1.1 version and a copy of the project with a 1.2-SNAPSHOT version. The first deploy (of version 1.1) to the internal repo succeeded, the next deploy (of version 1.2-SNAPSHOT) encountered the "507 Insufficient Storage" problem. > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107973 ] Mark Eramo edited comment on MJAR-30 at 9/21/07 2:17 PM: - I do see the code attahced above but I was not sure if I needed to pull it from an official repository. Thanks, Mark was: Is there a new version of the jar available that contains this patch? If not, how does one go about getting the src and compiling it. Thanks, Mark > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: fail-patch.txt, MJAR-30-maven-jar-plugin-1.patch, > MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- 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-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107973 ] Mark Eramo commented on MJAR-30: Is there a new version of the jar available that contains this patch? If not, how does one go about getting the src and compiling it. Thanks, Mark > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: fail-patch.txt, MJAR-30-maven-jar-plugin-1.patch, > MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- 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-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107972 ] Mark Eramo commented on MJAR-30: Is there a new version of the jar available that contains this patch? If not, how does one go about gettign the src and compiling it. Thanks, Mark > Allow inludes/excludes definition > - > > Key: MJAR-30 > URL: http://jira.codehaus.org/browse/MJAR-30 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Michael Böckling > Attachments: fail-patch.txt, MJAR-30-maven-jar-plugin-1.patch, > MJAR-30-maven-jar-plugin.patch, mjar-30.patch > > > Allow the definition of includes / excludes, so the Jars content can be > customized. -- 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-205) Undesirable Tomcat configuration for .jspf files
[ http://jira.codehaus.org/browse/MRM-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-205. -- Resolution: Fixed Fix Version/s: (was: 1.0.x) 1.0-beta-3 > Undesirable Tomcat configuration for .jspf files > > > Key: MRM-205 > URL: http://jira.codehaus.org/browse/MRM-205 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henri Yandell >Assignee: Joakim Erdfelt > Fix For: 1.0-beta-3 > > > .jspf files need to be picked up as JSP files by Tomcat. This isn't intended > - they should just be static includes. See the following email thread for > more info: > http://mail-archives.apache.org/mod_mbox/maven-archiva-users/200609.mbox/[EMAIL > PROTECTED] -- 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-205) Undesirable Tomcat configuration for .jspf files
[ http://jira.codehaus.org/browse/MRM-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107965 ] Joakim Erdfelt commented on MRM-205: This has been fixed at some point. (not sure when) This problem can no longer be duplicated. > Undesirable Tomcat configuration for .jspf files > > > Key: MRM-205 > URL: http://jira.codehaus.org/browse/MRM-205 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henri Yandell >Assignee: Joakim Erdfelt > Fix For: 1.0.x > > > .jspf files need to be picked up as JSP files by Tomcat. This isn't intended > - they should just be static includes. See the following email thread for > more info: > http://mail-archives.apache.org/mod_mbox/maven-archiva-users/200609.mbox/[EMAIL > PROTECTED] -- 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-213) cannot undeploy archiva webapp
[ http://jira.codehaus.org/browse/MRM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107964 ] Joakim Erdfelt commented on MRM-213: Tested on Linux w/ Tomcat 5.0.28. Using Archiva SVN Trunk r577463 JDK 1.5.0_11 This problem cannot be duplicated. See notes on JAR incompatibilities at http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat#ArchivaonTomcat-Tomcat5.0.xSpecifics Not closing until tested on Tomcat 5.5.x and 6.0.x too. > cannot undeploy archiva webapp > -- > > Key: MRM-213 > URL: http://jira.codehaus.org/browse/MRM-213 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: I'm running Archiva webapp under tomcat 5.5 / windows > 2003 server >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0.x > > > I'd like to undeploy without restarting Tomcat (as I don't have admin acces > to the server). When I undelploy archiva webapp using tomcat manager, the > webapp/archiva directory is not removed and WEB-INF/lib still contains: > jpox-1.1.1.jar > plexus-container-default-1.0-alpha-10.jar > plexus-security-authorization-rbac-store-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-keys-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-user-management-provider-jdo-1.0-alpha-6-20061013.204855-1.jar > webwork-2.2.4.jar > xwork-1.2.1.jar > I cannot remove those jars (files locked) > Maybe some background thread is not stopped at application undeploy ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MRM-213) cannot undeploy archiva webapp
[ http://jira.codehaus.org/browse/MRM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-213 started by Joakim Erdfelt. > cannot undeploy archiva webapp > -- > > Key: MRM-213 > URL: http://jira.codehaus.org/browse/MRM-213 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: I'm running Archiva webapp under tomcat 5.5 / windows > 2003 server >Reporter: nicolas de loof >Assignee: Joakim Erdfelt >Priority: Minor > Fix For: 1.0.x > > > I'd like to undeploy without restarting Tomcat (as I don't have admin acces > to the server). When I undelploy archiva webapp using tomcat manager, the > webapp/archiva directory is not removed and WEB-INF/lib still contains: > jpox-1.1.1.jar > plexus-container-default-1.0-alpha-10.jar > plexus-security-authorization-rbac-store-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-keys-jdo-1.0-alpha-6-20061013.204855-1.jar > plexus-security-user-management-provider-jdo-1.0-alpha-6-20061013.204855-1.jar > webwork-2.2.4.jar > xwork-1.2.1.jar > I cannot remove those jars (files locked) > Maybe some background thread is not stopped at application undeploy ? -- 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-333) Tomcat deployment of archiva results in unstable instance.
[ http://jira.codehaus.org/browse/MRM-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107963 ] Joakim Erdfelt commented on MRM-333: Completed testing and documentation on Jakarta Tomcat 5.0.28 on Linux using JDK 1.5.0_11. Important notes about Jar file compatibility can be found at http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat#ArchivaonTomcat-Tomcat5.0.xSpecifics No problems left. Finishing up documentation and tests on Tomcat 5.5.25 and Tomcat 6.0.14 next. > Tomcat deployment of archiva results in unstable instance. > -- > > Key: MRM-333 > URL: http://jira.codehaus.org/browse/MRM-333 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0.x > > > When deploying archiva to a tomcat instance, the resulting instance is > unstable and causes many other problems. > We need to identify, and document a tomcat installation. > Wiki docs: http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat > If a specific tomcat topic arises, please link it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MRM-333) Tomcat deployment of archiva results in unstable instance.
[ http://jira.codehaus.org/browse/MRM-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-333 started by Joakim Erdfelt. > Tomcat deployment of archiva results in unstable instance. > -- > > Key: MRM-333 > URL: http://jira.codehaus.org/browse/MRM-333 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0.x > > > When deploying archiva to a tomcat instance, the resulting instance is > unstable and causes many other problems. > We need to identify, and document a tomcat installation. > Wiki docs: http://docs.codehaus.org/display/MAVENUSER/Archiva+on+Tomcat > If a specific tomcat topic arises, please link it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1484) Add project version to email subject
Add project version to email subject Key: CONTINUUM-1484 URL: http://jira.codehaus.org/browse/CONTINUUM-1484 Project: Continuum Issue Type: Improvement Components: Notifier - Mail Affects Versions: 1.1-beta-3 Reporter: Tomislav Stojcevich Priority: Trivial Attachments: CONTINUUM-1484-continuum-core.patch The addition of the version of the project in the mail notification subject would be helpful in the case where there are multiple versions of the same project defined within continuum. Patch attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1726) OpenDS Directory Server
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107962 ] Carlos Sanchez commented on MAVENUPLOAD-1726: - groupId must be org.opends > OpenDS Directory Server > --- > > Key: MAVENUPLOAD-1726 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1726 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Jasper Blues > Attachments: openDS-1.0.0-build005-bundle.jar > > > OpenDS is an open source community project building a free and comprehensive > next generation directory service. OpenDS is designed to address large > deployments, to provide high performance, to be highly extensible, and to be > easy to deploy, manage and monitor. > Team List: https://opends.dev.java.net/public/misc/bios.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1726) OpenDS Directory Server
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107961 ] Carlos Sanchez commented on MAVENUPLOAD-1726: - License name has to be CDDL (COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0) > OpenDS Directory Server > --- > > Key: MAVENUPLOAD-1726 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1726 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Jasper Blues > Attachments: openDS-1.0.0-build005-bundle.jar > > > OpenDS is an open source community project building a free and comprehensive > next generation directory service. OpenDS is designed to address large > deployments, to provide high performance, to be highly extensible, and to be > easy to deploy, manage and monitor. > Team List: https://opends.dev.java.net/public/misc/bios.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1727) Upload ZK 3.0 RC to the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1727. --- Assignee: Carlos Sanchez Resolution: Fixed Please setup a synced repo as explained in http://maven.apache.org/guides/mini/guide-central-repository-upload.html for next time > Upload ZK 3.0 RC to the central repository > -- > > Key: MAVENUPLOAD-1727 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1727 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tom M. Yeh >Assignee: Carlos Sanchez > > http://www.zkoss.org/maven/bundles/3.0.0-RC/zcommon-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zweb-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zk-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zul-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zhtml-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zml-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zkmax-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/3.0.0-RC/zkplus-3.0.0-RC-bundle.jar > http://www.zkoss.org/maven/bundles/zkjsp/zuljsp-1.0.0-bundle.jar > http://www.zkoss.org/maven/bundles/zkjsf/zuljsf-0.8.1-bundle.jar > http://www.zkoss.org/maven/bundles/zkforge/timelinez-1.2_1-bundle.jar > http://www.zkoss.org/maven/bundles/zkforge/fckez-2.4.3_1-bundle.jar > http://www.zkoss.org > http://sourceforge.net/users/tomyeh/ > ZK is an open-source Ajax Web framework that enables rich user interface for > Web applications with no JavaScript and little programming. -- 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: (MAVENUPLOAD-1729) please upload the new jdeb 0.4 release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1729. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload the new jdeb 0.4 release > -- > > Key: MAVENUPLOAD-1729 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1729 > Project: maven-upload-requests > Issue Type: Task >Reporter: Torsten Curdt >Assignee: Carlos Sanchez > -- 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: (MAVENUPLOAD-1728) Upload grails-maven-plugin 0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1728. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload grails-maven-plugin 0.2 > -- > > Key: MAVENUPLOAD-1728 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1728 > Project: maven-upload-requests > Issue Type: Task >Reporter: Arnaud Heritier >Assignee: Carlos Sanchez > > The Grails plugin for maven is a set of goals to easily develop a Grails > application using maven 2. > Compared to the 0.1 release, I removed all external repositories definitions. > Additional POMs required by the project : > http://people.apache.org/~aheritier/tmp/mtg-0.2-bundle.jar > http://people.apache.org/~aheritier/tmp/grails-poms-0.2-bundle.jar > http://people.apache.org/~aheritier/tmp/grails-0.6-0.2-bundle.jar > http://people.apache.org/~aheritier/tmp/grails-0.5.6-0.2-bundle.jar > 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: (CONTINUUM-1483) Better support for SCM like clearcase or SYNERGY
Better support for SCM like clearcase or SYNERGY Key: CONTINUUM-1483 URL: http://jira.codehaus.org/browse/CONTINUUM-1483 Project: Continuum Issue Type: Improvement Components: SCM Affects Versions: 1.1-beta-4 Reporter: David Causse Attachments: relative_path.diff SCM providers that honour the relativePath in the scm checkout result are not treated correctly. It is impossible to use group builds for these providers. The patch included tries to adress this issue and allow group builds to work with relative path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1481) datamanagement-cli must support more db
[ http://jira.codehaus.org/browse/CONTINUUM-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1481: Patch Submitted: [Yes] > datamanagement-cli must support more db > --- > > Key: CONTINUUM-1481 > URL: http://jira.codehaus.org/browse/CONTINUUM-1481 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1481-1.patch > > > only derby DB is supported for now -- 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-3218) Plugin Documentation Update
Plugin Documentation Update --- Key: MNG-3218 URL: http://jira.codehaus.org/browse/MNG-3218 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.7 Reporter: Ole Ersoy In the mojo documentation here: http://maven.apache.org/guides/plugin/guide-java-plugin-development.html It says: Listed below is a POM for a plugin which uses the simple sample mojo: I think it's supposed to say: Listed below is an illustration of the sample mojo project's pom with the parameters set as described in the above table: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTRUN-41) Easy access to dependency jars
[
http://jira.codehaus.org/browse/MANTRUN-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabian Bauschulte updated MANTRUN-41:
-
Attachment: MANTRUN-41-maven-antrun-plugin.patch
> Easy access to dependency jars
> --
>
> Key: MANTRUN-41
> URL: http://jira.codehaus.org/browse/MANTRUN-41
> Project: Maven 2.x Antrun Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Patrick Lightbody
>Assignee: Kenney Westerhof
> Fix For: 1.2
>
> Attachments: MANTRUN-41-maven-antrun-plugin.patch
>
>
> It would be nice to have an easy access to the dependency jars located in
> ~/.m2. A couple ideas tossed around in #maven were:
> ${dep.XXX.YYY.jar}, where XXX and YYY are the groupId and artifactId
> OR
> a new Ant task:
>
> Where you could then reference ${jarpath}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-242) transitive dependencies do not get included
transitive dependencies do not get included --- Key: MASSEMBLY-242 URL: http://jira.codehaus.org/browse/MASSEMBLY-242 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: maven 2.0.7 Reporter: manuel aldana Priority: Blocker i am using assembly plugin with standard descriptor jar-with-dependencies. problem is that transitive dependencies do not get included. pom.xml from project A: ... a a 1.0 tran dep 1.0 ... pom.xml from project B: ... b b 1.0 ... enabling assembly-plugin with jar-with-dependencies... a a 1.0 ... i am doing assembly:assembly on b:b. now tran:dep does not get included though it is defined in a:a. that means: if i open the assembled jar-file (from b:b) i cannot see any artifacts from tran:dep. for earlier discussion on mailingslist see http://www.nabble.com/assembly-plugin%3A-transitive-dependencies-do-not-get-included-tf4317601s177.html#a12308820 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1481) datamanagement-cli must support more db
[ http://jira.codehaus.org/browse/CONTINUUM-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107953 ] Damien Lecan edited comment on CONTINUUM-1481 at 9/21/07 9:14 AM: -- Here is a patch to support other databases than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided if OTHER databaseType is used was: Here is a patch to support other databases than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided if OTHER databaseType if used > datamanagement-cli must support more db > --- > > Key: CONTINUUM-1481 > URL: http://jira.codehaus.org/browse/CONTINUUM-1481 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1481-1.patch > > > only derby DB is supported for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1481) datamanagement-cli must support more db
[ http://jira.codehaus.org/browse/CONTINUUM-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107953 ] Damien Lecan edited comment on CONTINUUM-1481 at 9/21/07 9:14 AM: -- Here is a patch to support other databases than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided if OTHER databaseType if used was: Here is a patch to support other databases than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided is OTHER databaseType if used > datamanagement-cli must support more db > --- > > Key: CONTINUUM-1481 > URL: http://jira.codehaus.org/browse/CONTINUUM-1481 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1481-1.patch > > > only derby DB is supported for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1481) datamanagement-cli must support more db
[ http://jira.codehaus.org/browse/CONTINUUM-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107953 ] Damien Lecan edited comment on CONTINUUM-1481 at 9/21/07 9:14 AM: -- Here is a patch to support other databases than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided is OTHER databaseType if used was: Here is a patch to support other database than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided is OTHER databaseType is used > datamanagement-cli must support more db > --- > > Key: CONTINUUM-1481 > URL: http://jira.codehaus.org/browse/CONTINUUM-1481 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1481-1.patch > > > only derby DB is supported for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1481) datamanagement-cli must support more db
[ http://jira.codehaus.org/browse/CONTINUUM-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Lecan updated CONTINUUM-1481: Attachment: CONTINUUM-1481-1.patch Here is a patch to support other database than Derby. I added 6 parameters : -driverClass [String] JDBC driver class -groupId [String] JDBC driver groupId -artifactId [String] JDBC driver artifactId -artifactVersion [String] Artifact version of the JDBC driver class -username [String] Username -password [String] Password They have to be provided is OTHER databaseType is used > datamanagement-cli must support more db > --- > > Key: CONTINUUM-1481 > URL: http://jira.codehaus.org/browse/CONTINUUM-1481 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-4 > > Attachments: CONTINUUM-1481-1.patch > > > only derby DB is supported for now -- 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: (SCM-346) Recursive flag is not implemented in the check out command
Recursive flag is not implemented in the check out command
--
Key: SCM-346
URL: http://jira.codehaus.org/browse/SCM-346
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.0
Reporter: Vincent Siveton
Priority: Blocker
The recursive flag is not use in the SvnCheckOutCommand class.
Here is a small Java code to reproduce it.
{code:title=Sample.java|borderStyle=solid}
String url = "scm:svn:https://svn.apache.org/repos/asf/maven/trunks";;
boolean recursive = true;
ScmManager scmManager = (ScmManager) lookup( ScmManager.ROLE );
ScmRepository repository = scmManager.makeScmRepository( url );
CheckOutScmResult result = scmManager.checkOut( repository, new ScmFileSet(
workingDir ), recursive );
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-264) Support for WTP2.0
[ http://jira.codehaus.org/browse/MECLIPSE-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107944 ] Cris Daniluk commented on MECLIPSE-264: --- This patch was actually broken in 2.5-SNAPSHOT by the application of another patch (which I can't remember off the top of my head). I'd be happy to recreate the patch but have been waiting to because none of the committers seem to be available for this issue, despite it being the most popular open issue in Jira. I will check for a mailing list or something for this plugin to see if I can't get an idea of what is going on. > Support for WTP2.0 > -- > > Key: MECLIPSE-264 > URL: http://jira.codehaus.org/browse/MECLIPSE-264 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Reporter: Geir Pettersen > Attachments: maven-264.patch > > > As far as I can see this plugin only supports WTP version 1.0 and 1.5. while > WTP 2.0 is already released in milestone 6 -- 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: (MANTTASKS-88) Add the ability to download javadoc dependencies
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.7, 2.0.6, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0 Environment: Linux JDK 1.5 Reporter: Eric Hartmann Priority: Minor 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] Commented: (MENFORCER-11) enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to work around it.
[ http://jira.codehaus.org/browse/MENFORCER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107939 ] Damien Lecan commented on MENFORCER-11: --- Multi-module project build doesn't work anymore with alpha-3 for my projects (between 10 and 40 modules) alpha-2 is working fine > enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to > work around it. > - > > Key: MENFORCER-11 > URL: http://jira.codehaus.org/browse/MENFORCER-11 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > > In 1.0-alpha-3, the enforce goal now requires dependency resolution to > support the new dependency rules (noSnapshots, noBannedDependencies). Because > enforce-once extends and adds as an aggregator, this causes the maven bug > MNG-2277 to appear. The work around for now is to use enforce not the > enforce-once goal (the aggregator part of enforce-once doesn't work anyway). > The fix would be to resolve the dependencies manually in the plugin or to > make a new mojo that requires dependency resolution and put enforce and > enforce-once back the way they where. -- 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-1482) XmlRpc API - add method buildAll(...) to ProjectGroupSummary
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 -- 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-264) Support for WTP2.0
[ http://jira.codehaus.org/browse/MECLIPSE-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107931 ] Kristof Jozsa commented on MECLIPSE-264: I just checked using 2.5-SNAPSHOT of the plugin and this patch does not seem to be applied. Are there any plans to merge this anytime soon? > Support for WTP2.0 > -- > > Key: MECLIPSE-264 > URL: http://jira.codehaus.org/browse/MECLIPSE-264 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Reporter: Geir Pettersen > Attachments: maven-264.patch > > > As far as I can see this plugin only supports WTP version 1.0 and 1.5. while > WTP 2.0 is already released in milestone 6 -- 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-58) Update depencies to include all ant artifacts so all ant tasks can be used
[ http://jira.codehaus.org/browse/MANTRUN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107927 ] Alan Mehio commented on MANTRUN-58: --- I had some issue with the dependecy of the following tasks which get executed from mavenantrun plugin the tasks are telnet ftp the dependency are : ant-commons-net commons-net I have checked the plugin class path ( printed out) and found the above dependency are not included. the plug in should bring its dependencies and know about its dependencies. I would say; manvenantrun plugin should include all the depdencies needed to run ant task or at least it should be documented in the examples at http://maven.apache.org/plugins/maven-antrun-plugin/examples/classpaths.html The solution is to explicitly mention the dependency as below which needs to be documented. I found it after opening the source code and analysing the whole code of the manvenantrun plugin which took me some time. org.apache.maven.plugins maven-antrun-plugin commons-net commons-net 1.4.1 ant ant-commons-net 1.6.5 pricingDeployment pricingDeployment run Regards, Alan Mehio London, UK > Update depencies to include all ant artifacts so all ant tasks can be used > -- > > Key: MANTRUN-58 > URL: http://jira.codehaus.org/browse/MANTRUN-58 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Reporter: Jason Chaffee >Priority: Blocker > > Should add ALL ant distribution artifacts as dependencies as some tasks > cannot be run without them. For example, ant-trax is needed to use > with the trax processor. -- 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-1481) datamanagement-cli must support more db
datamanagement-cli must support more db --- Key: CONTINUUM-1481 URL: http://jira.codehaus.org/browse/CONTINUUM-1481 Project: Continuum Issue Type: Bug Components: Data Management Affects Versions: 1.1-beta-3 Reporter: Emmanuel Venisse Priority: Critical Fix For: 1.1-beta-4 only derby DB is supported for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1481) datamanagement-cli must support more db
[ http://jira.codehaus.org/browse/CONTINUUM-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1481: Fix Version/s: 1.1-beta-4 > datamanagement-cli must support more db > --- > > Key: CONTINUUM-1481 > URL: http://jira.codehaus.org/browse/CONTINUUM-1481 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-3 >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-4 > > > only derby DB is supported for now -- 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-1480) Remove duplicate mdo declarations in view-models.mdo and continuum-service.xml
Remove duplicate mdo declarations in view-models.mdo and continuum-service.xml -- Key: CONTINUUM-1480 URL: http://jira.codehaus.org/browse/CONTINUUM-1480 Project: Continuum Issue Type: Improvement Components: Web interface, XMLRPC Interface Affects Versions: 1.1-beta-2 Reporter: Olivier Lamy Fix For: 1.1-beta-4 Actually we have two mdo files which generates the same classes (except the package name). We can merge this files in only one. (in continuum-commons ?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1480) Remove duplicate mdo declarations in view-models.mdo and continuum-service.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1480: Fix Version/s: 1.1-beta-4 > Remove duplicate mdo declarations in view-models.mdo and continuum-service.xml > -- > > Key: CONTINUUM-1480 > URL: http://jira.codehaus.org/browse/CONTINUUM-1480 > Project: Continuum > Issue Type: Improvement > Components: Web interface, XMLRPC Interface >Affects Versions: 1.1-beta-2 >Reporter: Olivier Lamy > Fix For: 1.1-beta-4 > > > Actually we have two mdo files which generates the same classes (except the > package name). > We can merge this files in only one. (in continuum-commons ?) -- 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: (MCHECKSTYLE-77) Allow multiple sources directories in input
Allow multiple sources directories in input --- Key: MCHECKSTYLE-77 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-77 Project: Maven 2.x Checkstyle Plugin Issue Type: Wish Affects Versions: 2.1 Environment: Maven module with multiple sources directories (due to external constraints) Reporter: Gerald Reinhart Priority: Minor For different reasons we can have multiple sources directories even in a Maven Projet. The sourceDirectory attribute allows only one directory, it would be great to allow several directories. http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html#sourceDirectory -- 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
