[jira] Commented: (MSUREFIRE-136) Add option to redirect stdout from tests to a file
[ http://jira.codehaus.org/browse/MSUREFIRE-136?page=comments#action_67232
]
Henry S. Isidro commented on MSUREFIRE-136:
---
I've patched surefire-booter as well as maven-surefire-plugin to exhibit this
behavior. The plugin now accepts a boolean parameter, consoleOutputToFile, that
if set to true, all stdouot from tests are placed in a file. The file is
console_output.txt and is placed in ${project.build.directory}/surefire-reports.
> Add option to redirect stdout from tests to a file
> --
>
> Key: MSUREFIRE-136
> URL: http://jira.codehaus.org/browse/MSUREFIRE-136
> Project: Maven 2.x Surefire Plugin
> Type: Improvement
> Versions: 2.1.3, 2.2
> Reporter: Carlos Sanchez
> Assignee: Henry S. Isidro
>
>
> Instead of
> ---
> T E S T S
> ---
> Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest
> 17:59:47.546 EVENT Stopping Acceptor
> ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=10007]
> 17:59:47.546 EVENT Stopped SocketListener on 0.0.0.0:10007
> 17:59:47.546 EVENT Stopped ServletHttpContext[/dav]
> 17:59:47.546 EVENT Stopped [EMAIL PROTECTED]
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec
> show just
> ---
> T E S T S
> ---
> Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec
--
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: (MSUREFIRE-136) Add option to redirect stdout from tests to a file
[ http://jira.codehaus.org/browse/MSUREFIRE-136?page=all ] Henry S. Isidro updated MSUREFIRE-136: -- Attachment: maven-surefire-plugin.patch SurefireBooter.patch > Add option to redirect stdout from tests to a file > -- > > Key: MSUREFIRE-136 > URL: http://jira.codehaus.org/browse/MSUREFIRE-136 > Project: Maven 2.x Surefire Plugin > Type: Improvement > Versions: 2.1.3, 2.2 > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Attachments: SurefireBooter.patch, maven-surefire-plugin.patch > > > Instead of > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > 17:59:47.546 EVENT Stopping Acceptor > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=10007] > 17:59:47.546 EVENT Stopped SocketListener on 0.0.0.0:10007 > 17:59:47.546 EVENT Stopped ServletHttpContext[/dav] > 17:59:47.546 EVENT Stopped [EMAIL PROTECTED] > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec > show just > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec -- 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: (MSUREFIRE-136) Add option to redirect stdout from tests to a file
[ http://jira.codehaus.org/browse/MSUREFIRE-136?page=all ] Henry S. Isidro updated MSUREFIRE-136: -- Attachment: (was: SurefireBooter.patch) > Add option to redirect stdout from tests to a file > -- > > Key: MSUREFIRE-136 > URL: http://jira.codehaus.org/browse/MSUREFIRE-136 > Project: Maven 2.x Surefire Plugin > Type: Improvement > Versions: 2.1.3, 2.2 > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Attachments: maven-surefire-plugin.patch > > > Instead of > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > 17:59:47.546 EVENT Stopping Acceptor > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=10007] > 17:59:47.546 EVENT Stopped SocketListener on 0.0.0.0:10007 > 17:59:47.546 EVENT Stopped ServletHttpContext[/dav] > 17:59:47.546 EVENT Stopped [EMAIL PROTECTED] > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec > show just > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec -- 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: (MSUREFIRE-136) Add option to redirect stdout from tests to a file
[ http://jira.codehaus.org/browse/MSUREFIRE-136?page=all ] Henry S. Isidro updated MSUREFIRE-136: -- Attachment: (was: maven-surefire-plugin.patch) > Add option to redirect stdout from tests to a file > -- > > Key: MSUREFIRE-136 > URL: http://jira.codehaus.org/browse/MSUREFIRE-136 > Project: Maven 2.x Surefire Plugin > Type: Improvement > Versions: 2.1.3, 2.2 > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > > > Instead of > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > 17:59:47.546 EVENT Stopping Acceptor > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=10007] > 17:59:47.546 EVENT Stopped SocketListener on 0.0.0.0:10007 > 17:59:47.546 EVENT Stopped ServletHttpContext[/dav] > 17:59:47.546 EVENT Stopped [EMAIL PROTECTED] > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec > show just > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec -- 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: (MSUREFIRE-136) Add option to redirect stdout from tests to a file
[ http://jira.codehaus.org/browse/MSUREFIRE-136?page=all ] Henry S. Isidro updated MSUREFIRE-136: -- Attachment: MSUREFIRE-136-surefire-booter.patch MSUREFIRE-136-maven-surefire-plugin.patch > Add option to redirect stdout from tests to a file > -- > > Key: MSUREFIRE-136 > URL: http://jira.codehaus.org/browse/MSUREFIRE-136 > Project: Maven 2.x Surefire Plugin > Type: Improvement > Versions: 2.1.3, 2.2 > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Attachments: MSUREFIRE-136-maven-surefire-plugin.patch, > MSUREFIRE-136-surefire-booter.patch > > > Instead of > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > 17:59:47.546 EVENT Stopping Acceptor > ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=10007] > 17:59:47.546 EVENT Stopped SocketListener on 0.0.0.0:10007 > 17:59:47.546 EVENT Stopped ServletHttpContext[/dav] > 17:59:47.546 EVENT Stopped [EMAIL PROTECTED] > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec > show just > --- > T E S T S > --- > Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.406 sec -- 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-747) Continuum can't add a project with pom in https with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-747?page=comments#action_68667
]
Henry S. Isidro commented on CONTINUUM-747:
---
I tested MungedHttpsURL with the test fragment below and was able to get a
connection as well as print out the content object.
public void testConnection() throws IOException
{
MungedHttpsURL mungedHttpsURL = new
MungedHttpsURL("https://uname:[EMAIL PROTECTED]/path");
if( mungedHttpsURL.isValid() )
{
HttpURLConnection urlc = mungedHttpsURL.getURLConnection();
Object content = urlc.getContent();
System.out.println( content );
}
}
It seems that in between creating MungedHttpsURL object and the actually
download of the pom, the connection status changes from a 200 to a 401. Could
the connection be timing out in such a short time?
> Continuum can't add a project with pom in https with authentication
> ---
>
> Key: CONTINUUM-747
> URL: http://jira.codehaus.org/browse/CONTINUUM-747
> Project: Continuum
> Type: Bug
> Versions: 1.0.3
> Reporter: Carlos Sanchez
> Assignee: Henry S. Isidro
> Priority: Critical
> Fix For: 1.1
>
>
> When trying to add a project with this type of url
> https://username:[EMAIL PROTECTED]/foo/trunk/pom.xml
> I get a 401 Unauthorized HTTP error code
> Seems that the problem is in
> http://svn.codehaus.org/plexus/trunk/plexus-components/plexus-formica/src/main/java/org/codehaus/plexus/formica/util/MungedHttpsURL.java
> I added a test case with the right url and get that 401 too
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-764) Make acegi authenticate against Continuum DB
[ http://jira.codehaus.org/browse/CONTINUUM-764?page=all ] Henry S. Isidro updated CONTINUUM-764: -- Attachment: CONTINUUM-764-continuum-core.patch > Make acegi authenticate against Continuum DB > > > Key: CONTINUUM-764 > URL: http://jira.codehaus.org/browse/CONTINUUM-764 > Project: Continuum > Type: Sub-task > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Fix For: 1.1 > Attachments: CONTINUUM-764-continuum-core.patch > > > Implement the Acegi authentication interface to load the users from the DB > using JDO. -- 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-764) Make acegi authenticate against Continuum DB
[ http://jira.codehaus.org/browse/CONTINUUM-764?page=all ] Henry S. Isidro updated CONTINUUM-764: -- Attachment: CONTINUUM-764-continuum-acegi.zip > Make acegi authenticate against Continuum DB > > > Key: CONTINUUM-764 > URL: http://jira.codehaus.org/browse/CONTINUUM-764 > Project: Continuum > Type: Sub-task > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Fix For: 1.1 > Attachments: CONTINUUM-764-continuum-acegi.zip, > CONTINUUM-764-continuum-core.patch > > > Implement the Acegi authentication interface to load the users from the DB > using JDO. -- 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-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=all ] Henry S. Isidro updated CONTINUUM-771: -- Attachment: CONTINUUM-771-continuum-webapp.patch > Add user management screens > --- > > Key: CONTINUUM-771 > URL: http://jira.codehaus.org/browse/CONTINUUM-771 > Project: Continuum > Type: Sub-task > Components: Web interface > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Fix For: 1.1 > Attachments: CONTINUUM-771-continuum-webapp.patch > > > Add a page for listing the users, with options to add/edit/delete user > Users can have an unlimited number of roles (Continuum Permission) like > addProject, addUser,... they are already created by the ContinuumInitializer > and are static (no new roles/permissions can be added) -- 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-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=comments#action_69689 ] Henry S. Isidro commented on CONTINUUM-771: --- Yup, I just figured it out with your reply to Teodoro above; will submit a new patch later. > Add user management screens > --- > > Key: CONTINUUM-771 > URL: http://jira.codehaus.org/browse/CONTINUUM-771 > Project: Continuum > Type: Sub-task > Components: Web interface > Reporter: Carlos Sanchez > Assignee: Henry S. Isidro > Fix For: 1.1 > Attachments: CONTINUUM-771-continuum-webapp.patch > > > Add a page for listing the users, with options to add/edit/delete user > Users can have an unlimited number of roles (Continuum Permission) like > addProject, addUser,... they are already created by the ContinuumInitializer > and are static (no new roles/permissions can be added) -- 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-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=all ] Henry S. Isidro updated CONTINUUM-771: -- Attachment: CONTINUUM-771-continuum-webapp-with-improved-logging.patch Here's a new patch with the imporved logging using Jesse's patch to CONTINUUM-759. It also includes a combined user add and edit screen. > Add user management screens > --- > > Key: CONTINUUM-771 > URL: http://jira.codehaus.org/browse/CONTINUUM-771 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > Attachments: > CONTINUUM-771-continuum-webapp-with-improved-logging.patch, > CONTINUUM-771-continuum-webapp.patch > > > Add a page for listing the users, with options to add/edit/delete user > Users can have an unlimited number of roles (Continuum Permission) like > addProject, addUser,... they are already created by the ContinuumInitializer > and are static (no new roles/permissions can be added) -- 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-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=all ] Henry S. Isidro updated CONTINUUM-771: -- Attachment: CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch File Attached: CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch Here's an updated patch with working user management screen. This implements a straightforward permission management for each user (only add and delete with no zones or roles). This patch also uses Jesse's patch in CONTINUUM-781. > Add user management screens > --- > > Key: CONTINUUM-771 > URL: http://jira.codehaus.org/browse/CONTINUUM-771 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > Attachments: > CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch, > CONTINUUM-771-continuum-webapp-with-improved-logging.patch, > CONTINUUM-771-continuum-webapp.patch > > > Add a page for listing the users, with options to add/edit/delete user > Users can have an unlimited number of roles (Continuum Permission) like > addProject, addUser,... they are already created by the ContinuumInitializer > and are static (no new roles/permissions can be added) -- 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-783) Use standard jstl for links or they will break
[ http://jira.codehaus.org/browse/CONTINUUM-783?page=all ]
Henry S. Isidro updated CONTINUUM-783:
--
Attachment: CONTINUUM-778-continuum-webapp.patch
attached: CONTINUUM-778-continuum-webapp.patch
Here's a patch that fixes all the jsps in the webapp module.
> Use standard jstl for links or they will break
> --
>
> Key: CONTINUUM-783
> URL: http://jira.codehaus.org/browse/CONTINUUM-783
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Reporter: Carlos Sanchez
> Assigned To: Henry S. Isidro
> Fix For: 1.1
>
> Attachments: CONTINUUM-778-continuum-webapp.patch
>
>
> I see a lot of links constructed like this
>href="${pageContext.request.contextPath}/deleteUser!doDelete.action?accountId=${pageScope.user.accountId}&username=${pageScope.user.username}"> name="delete"/>
> This will break under certain circustancies, like cookies disabled or
> variables with some chars that need to be encoded
> Also jstl automatically adds the contextPath at the beggining
> See http://www-128.ibm.com/developerworks/java/library/j-jstl0318/#N105D3 for
> more info
> The right way do do it is
>
>
>
>
>name="delete"/>
> when no parameters need to be added it can just be
> "> name="delete"/>
--
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-790) continuum-acegi branch webapp doesn't work with jetty
[ http://jira.codehaus.org/browse/CONTINUUM-790?page=all ] Henry S. Isidro updated CONTINUUM-790: -- Attachment: CONTINUUM-790-continuum-webapp.patch Attached FIle: CONTINUUM-790-continuum-webapp.patch Here's a patch for this. I also changed the pom to use the latest maven jetty plugin (just removed the '6' from the artifactId). You can try running it via a 'mvn jetty:run' at a console. > continuum-acegi branch webapp doesn't work with jetty > - > > Key: CONTINUUM-790 > URL: http://jira.codehaus.org/browse/CONTINUUM-790 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Jesse McConnell > Assigned To: Henry S. Isidro > Attachments: CONTINUUM-790-continuum-webapp.patch > > > :WARN: /summary.action > org.apache.jasper.JasperException: /navigations/DefaultTop.jsp(6,0) According > to TLD or attribute directive in tag file, attribute value does not accept > any expressions > at > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39) > at org.apache.jasper.compi > the following url describes this: > http://forum.springframework.org/showthread.php?t=13911 > the fix from that issue actually makes the initial page load up when running > jetty from the maven plugin in the continuum-webapp directory. > carlos wanted me to ping you on this issue to fix it in the relevant places. > <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> > to > <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> > in this case. -- 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-790) continuum-acegi branch webapp doesn't work with jetty
[ http://jira.codehaus.org/browse/CONTINUUM-790?page=all ] Henry S. Isidro updated CONTINUUM-790: -- Attachment: (was: CONTINUUM-790-continuum-webapp.patch) > continuum-acegi branch webapp doesn't work with jetty > - > > Key: CONTINUUM-790 > URL: http://jira.codehaus.org/browse/CONTINUUM-790 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Jesse McConnell > Assigned To: Henry S. Isidro > Attachments: CONTINUUM-790-continuum-webapp.patch > > > :WARN: /summary.action > org.apache.jasper.JasperException: /navigations/DefaultTop.jsp(6,0) According > to TLD or attribute directive in tag file, attribute value does not accept > any expressions > at > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39) > at org.apache.jasper.compi > the following url describes this: > http://forum.springframework.org/showthread.php?t=13911 > the fix from that issue actually makes the initial page load up when running > jetty from the maven plugin in the continuum-webapp directory. > carlos wanted me to ping you on this issue to fix it in the relevant places. > <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> > to > <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> > in this case. -- 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-790) continuum-acegi branch webapp doesn't work with jetty
[ http://jira.codehaus.org/browse/CONTINUUM-790?page=all ] Henry S. Isidro updated CONTINUUM-790: -- Attachment: CONTINUUM-790-continuum-webapp.patch > continuum-acegi branch webapp doesn't work with jetty > - > > Key: CONTINUUM-790 > URL: http://jira.codehaus.org/browse/CONTINUUM-790 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Jesse McConnell > Assigned To: Henry S. Isidro > Attachments: CONTINUUM-790-continuum-webapp.patch > > > :WARN: /summary.action > org.apache.jasper.JasperException: /navigations/DefaultTop.jsp(6,0) According > to TLD or attribute directive in tag file, attribute value does not accept > any expressions > at > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39) > at org.apache.jasper.compi > the following url describes this: > http://forum.springframework.org/showthread.php?t=13911 > the fix from that issue actually makes the initial page load up when running > jetty from the maven plugin in the continuum-webapp directory. > carlos wanted me to ping you on this issue to fix it in the relevant places. > <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> > to > <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> > in this case. -- 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-783) Use standard jstl for links or they will break
[ http://jira.codehaus.org/browse/CONTINUUM-783?page=comments#action_70960
]
Henry S. Isidro commented on CONTINUUM-783:
---
A patch for CONTINUUM-790 contains the fix for addUserRole.jsp.
> Use standard jstl for links or they will break
> --
>
> Key: CONTINUUM-783
> URL: http://jira.codehaus.org/browse/CONTINUUM-783
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Reporter: Carlos Sanchez
> Assigned To: Henry S. Isidro
> Fix For: 1.1
>
> Attachments: CONTINUUM-778-continuum-webapp.patch
>
>
> I see a lot of links constructed like this
>href="${pageContext.request.contextPath}/deleteUser!doDelete.action?accountId=${pageScope.user.accountId}&username=${pageScope.user.username}"> name="delete"/>
> This will break under certain circustancies, like cookies disabled or
> variables with some chars that need to be encoded
> Also jstl automatically adds the contextPath at the beggining
> See http://www-128.ibm.com/developerworks/java/library/j-jstl0318/#N105D3 for
> more info
> The right way do do it is
>
>
>
>
>name="delete"/>
> when no parameters need to be added it can just be
> "> name="delete"/>
--
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-790) continuum-acegi branch webapp doesn't work with jetty
[ http://jira.codehaus.org/browse/CONTINUUM-790?page=comments#action_70961 ] Henry S. Isidro commented on CONTINUUM-790: --- The patch also contains a fix for addUserRole.jsp as commented on by Carlos in CONTINUUM-783. > continuum-acegi branch webapp doesn't work with jetty > - > > Key: CONTINUUM-790 > URL: http://jira.codehaus.org/browse/CONTINUUM-790 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Jesse McConnell > Assigned To: Henry S. Isidro > Attachments: CONTINUUM-790-continuum-webapp.patch > > > :WARN: /summary.action > org.apache.jasper.JasperException: /navigations/DefaultTop.jsp(6,0) According > to TLD or attribute directive in tag file, attribute value does not accept > any expressions > at > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39) > at org.apache.jasper.compi > the following url describes this: > http://forum.springframework.org/showthread.php?t=13911 > the fix from that issue actually makes the initial page load up when running > jetty from the maven plugin in the continuum-webapp directory. > carlos wanted me to ping you on this issue to fix it in the relevant places. > <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> > to > <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> > in this case. -- 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-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=all ] Henry S. Isidro updated CONTINUUM-771: -- Attachment: CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch Attached File: CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch Refactored the user management actions so that they will be reusable. > Add user management screens > --- > > Key: CONTINUUM-771 > URL: http://jira.codehaus.org/browse/CONTINUUM-771 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > Attachments: CONTINUUM-771-continuum-webapp-menu.patch, > CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch, > CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch, > CONTINUUM-771-continuum-webapp-with-improved-logging.patch, > CONTINUUM-771-continuum-webapp.patch, CONTINUUM-771-continuum-webapp.patch > > > Add a page for listing the users, with options to add/edit/delete user > Users can have an unlimited number of roles (Continuum Permission) like > addProject, addUser,... they are already created by the ContinuumInitializer > and are static (no new roles/permissions can be added) -- 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-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Henry S. Isidro updated CONTINUUM-800: -- Attachment: CONTINUUM-800-maven-user.patch Attached File: CONTINUUM-800-maven-user.patch Implemented DefaultUserManager.java as well as edited som poms for dependencies. One question that came up is how do we handle PasswordEncoder? > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- 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-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Henry S. Isidro updated CONTINUUM-800: -- Attachment: CONTINUUM-800-continuum-webapp.patch File Attached: CONTINUUM-800-continuum-webapp.patch I keep getting an NPE. It seems that the getPersistenceManager() method from DefaultUserManager returns a null. Is it a problem with injection from plexus? > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- 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-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Henry S. Isidro updated CONTINUUM-800: -- Attachment: CONTINUUM-800-continuum-acegi-branch.patch File Attached: CONTINUUM-800-continuum-acegi-branch.patch This patch makes continuum use maven-user. ContinuumUser now extends the classes in maven-user-model. > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-continuum-acegi-branch.patch, > CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-model-testing.patch, > CONTINUUM-800-maven-user-model-update-2.patch, > CONTINUUM-800-maven-user-webapp-update-2.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- 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-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74024 ] Henry S. Isidro commented on CONTINUUM-842: --- - user list page shows user.username user.email It seems that extremcomponents cannot get the localization info correctly. In fact, the MavenUsers.properties file which contains the values for user.username and user.email is not in continuum-webapp. I think that when maven-user-webapp was overlayed, MavenUsers.properties was not included. > Maven-user improvements > --- > > Key: CONTINUUM-842 > URL: http://jira.codehaus.org/browse/CONTINUUM-842 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > - user list page shows user.username user.email > - when adding a user, the roles list shouldn't show up, only on editing -- 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-869) From build result top tabs don't work
[ http://jira.codehaus.org/browse/CONTINUUM-869?page=all ] Henry S. Isidro updated CONTINUUM-869: -- Attachment: CONTINUUM-869-continuum-webapp.patch File Attached: CONTINUUM-869-continuum-webapp.patch The query string was giving a blank projectId, this fixes the problem. > From build result top tabs don't work > - > > Key: CONTINUUM-869 > URL: http://jira.codehaus.org/browse/CONTINUUM-869 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > Attachments: CONTINUUM-869-continuum-webapp.patch, > CONTINUUM-869-continuum-webapp.patch2 > > > They don't set the projectId parameter probably -- 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-869) From build result top tabs don't work
[ http://jira.codehaus.org/browse/CONTINUUM-869?page=all ] Henry S. Isidro updated CONTINUUM-869: -- Attachment: CONTINUUM-869-continuum-webapp.patch2 File Attached: CONTINUUM-869-continuum-webapp.patch2 New patch using nested ww:param in ww:url > From build result top tabs don't work > - > > Key: CONTINUUM-869 > URL: http://jira.codehaus.org/browse/CONTINUUM-869 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > Attachments: CONTINUUM-869-continuum-webapp.patch, > CONTINUUM-869-continuum-webapp.patch2 > > > They don't set the projectId parameter probably -- 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-873) Clicking "Add" in the Notifiers section of a project causes an exception
[ http://jira.codehaus.org/browse/CONTINUUM-873?page=all ]
Henry S. Isidro updated CONTINUUM-873:
--
Attachment: CONTINUUM-873-continuum-webapp.patch
File Attached: CONTINUUM-873-continuum-webapp.patch
This fixes the problem.
> Clicking "Add" in the Notifiers section of a project causes an exception
>
>
> Key: CONTINUUM-873
> URL: http://jira.codehaus.org/browse/CONTINUUM-873
> Project: Continuum
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Windows
>Reporter: David Schwartz
> Assigned To: Henry S. Isidro
> Fix For: 1.1
>
> Attachments: CONTINUUM-873-continuum-webapp.patch
>
>
> When I click on the "Add" button in the Notifiers section of a project I get
> the following exception:
> 2006-09-13 20:36:14,828 [btpool0-0] INFO Action:addNotifier -
> checking the continuum configuration
> :WARN: EXCEPTION
> org.apache.jasper.JasperException: /notifierSelectType.jsp(17,16) PWC6038:
> "#{ 'mail' : 'Mail', 'irc' : 'IRC', 'jabber' : 'Jabber', 'msn' : 'MSN'}"
> contains invalid expression(s): javax.el.ELException: Error Parsing: #{
> 'mail' : 'Mail', 'irc' : 'IRC', 'jabber' : 'Jabber', 'msn' : 'MSN'}
> at
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:49)
> at
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:461)
> at
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:211)
> at
> org.apache.jasper.compiler.JspUtil.validateExpressions(JspUtil.java:629)
> at
> org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1261)
> at
> org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1037)
> at
> org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:820)
> at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1469)
> at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2244)
> at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2294)
> at
> org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:840)
> at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1469)
> at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2244)
> at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2294)
> at
> org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:840)
> at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1469)
> at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2244)
> at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2294)
> at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2300)
> at org.apache.jasper.compiler.Node$Root.accept(Node.java:468)
> at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2244)
> at org.apache.jasper.compiler.Validator.validate(Validator.java:1759)
> at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:278)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:620)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:602)
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:618)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:440)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:335)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:442)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:357)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:615)
> at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:263)
> at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:125)
> at
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
> at
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
> at
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:311)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:206)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168)
> at
[jira] Commented: (CONTINUUM-872) Project Build Definition Errors
[ http://jira.codehaus.org/browse/CONTINUUM-872?page=comments#action_74812 ] Henry S. Isidro commented on CONTINUUM-872: --- I can't seem to replicate your problem with issue number 2. I tried doing everything as you described and issues 1 to 3 seem to be fixed. > Project Build Definition Errors > --- > > Key: CONTINUUM-872 > URL: http://jira.codehaus.org/browse/CONTINUUM-872 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows >Reporter: David Schwartz > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > There are a number of problems with trying to Edit or Add Build Definitions > for a project: > 1) If you create a new schedule and the project uses the DEFAULT_SCHEDULE, > the wrong schedule is selected by default when you edit the current build > definition. In my project, even though it should use DEFAULT_SCHEDULE, the > new schedule called EVERY_MINUTE is selected by default in the pull down menu. > 2) When I try to submit changes to the Build Definition such as the goal from > "clean install" to "clean install site-deploy" and select DEFAULT_SCHEDULE, I > get the following error: > 2006-09-13 20:28:22,437 [btpool0-0] INFO Interceptor:exceptionLogging - > Error ocurred during execution > org.apache.maven.continuum.ContinuumException: failed update, build > definition didn't exist in project group > at > org.apache.maven.continuum.core.action.AbstractBuildDefinitionContinuumAction.updateBuildDefinitionInList(AbstractBuildDefinitionContinuumAction.java:179) > at > org.apache.maven.continuum.core.action.UpdateBuildDefinitionFromProjectAction.execute(UpdateBuildDefinitionFromProjectAction.java:45) > at > org.apache.maven.continuum.DefaultContinuum.executeAction(DefaultContinuum.java:2269) > at > org.apache.maven.continuum.DefaultContinuum.updateBuildDefinitionForProject(DefaultContinuum.java:1390) > at > org.apache.maven.continuum.security.acegi.AcegiContinuum.updateBuildDefinitionForProject_aroundBody148(AcegiContinuum.java:507) > at > org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure149.run(AcegiContinuum.java:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) > at > org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) > at > org.apache.maven.continuum.security.acegi.AcegiContinuum.updateBuildDefinitionForProject(AcegiContinuum.java:1) > at > org.apache.maven.continuum.web.action.BuildDefinitionAction.saveToProject(BuildDefinitionAction.java:139) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocatio
[jira] Updated: (CONTINUUM-872) Project Build Definition Errors
[ http://jira.codehaus.org/browse/CONTINUUM-872?page=all ] Henry S. Isidro updated CONTINUUM-872: -- Attachment: CONTINUUM-872-continuum-webapp.patch File Attached: CONTINUUM-872-continuum-webapp.patch This fixes the problems. > Project Build Definition Errors > --- > > Key: CONTINUUM-872 > URL: http://jira.codehaus.org/browse/CONTINUUM-872 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows >Reporter: David Schwartz > Assigned To: Henry S. Isidro > Fix For: 1.1 > > Attachments: CONTINUUM-872-continuum-webapp.patch > > > There are a number of problems with trying to Edit or Add Build Definitions > for a project: > 1) If you create a new schedule and the project uses the DEFAULT_SCHEDULE, > the wrong schedule is selected by default when you edit the current build > definition. In my project, even though it should use DEFAULT_SCHEDULE, the > new schedule called EVERY_MINUTE is selected by default in the pull down menu. > 2) When I try to submit changes to the Build Definition such as the goal from > "clean install" to "clean install site-deploy" and select DEFAULT_SCHEDULE, I > get the following error: > 2006-09-13 20:28:22,437 [btpool0-0] INFO Interceptor:exceptionLogging - > Error ocurred during execution > org.apache.maven.continuum.ContinuumException: failed update, build > definition didn't exist in project group > at > org.apache.maven.continuum.core.action.AbstractBuildDefinitionContinuumAction.updateBuildDefinitionInList(AbstractBuildDefinitionContinuumAction.java:179) > at > org.apache.maven.continuum.core.action.UpdateBuildDefinitionFromProjectAction.execute(UpdateBuildDefinitionFromProjectAction.java:45) > at > org.apache.maven.continuum.DefaultContinuum.executeAction(DefaultContinuum.java:2269) > at > org.apache.maven.continuum.DefaultContinuum.updateBuildDefinitionForProject(DefaultContinuum.java:1390) > at > org.apache.maven.continuum.security.acegi.AcegiContinuum.updateBuildDefinitionForProject_aroundBody148(AcegiContinuum.java:507) > at > org.apache.maven.continuum.security.acegi.AcegiContinuum$AjcClosure149.run(AcegiContinuum.java:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) > at > org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) > at > org.apache.maven.continuum.security.acegi.AcegiContinuum.updateBuildDefinitionForProject(AcegiContinuum.java:1) > at > org.apache.maven.continuum.web.action.BuildDefinitionAction.saveToProject(BuildDefinitionAction.java:139) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultA
[jira] Commented: (CONTINUUM-887) After saving project details the top tab doesn't work, missing projectId parameter
[ http://jira.codehaus.org/browse/CONTINUUM-887?page=comments#action_74852 ] Henry S. Isidro commented on CONTINUUM-887: --- Adding a param to the ww:url tag in ProjectMenu.jsp solved the problem. > After saving project details the top tab doesn't work, missing projectId > parameter > -- > > Key: CONTINUUM-887 > URL: http://jira.codehaus.org/browse/CONTINUUM-887 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 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] Created: (CONTINUUM-905) Deleting a project build definition by clicking the 'delete' link results in a 404.
Deleting a project build definition by clicking the 'delete' link results in a 404. --- Key: CONTINUUM-905 URL: http://jira.codehaus.org/browse/CONTINUUM-905 Project: Continuum Issue Type: Bug Environment: continuum-acegi branch Linux Reporter: Henry S. Isidro -- 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-907) Deleting a project group build definition by clicking the 'delete' link results in an internal server error.
Deleting a project group build definition by clicking the 'delete' link results in an internal server error. Key: CONTINUUM-907 URL: http://jira.codehaus.org/browse/CONTINUUM-907 Project: Continuum Issue Type: Bug Reporter: Henry S. Isidro -- 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-931) Project Group Summary page has no internationalization.
Project Group Summary page has no internationalization. --- Key: CONTINUUM-931 URL: http://jira.codehaus.org/browse/CONTINUUM-931 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1 Reporter: Henry S. Isidro Priority: Minor -- 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-922) Out of memory when trying to download from working copy
[ http://jira.codehaus.org/browse/CONTINUUM-922?page=comments#action_76058 ] Henry S. Isidro commented on CONTINUUM-922: --- Some questions: - Is the 100k limit enough or would a smaller number be better? - Should we also consider downloading binaries that wouldn't display properly such as images, class files, jars, wars, etc? > Out of memory when trying to download from working copy > --- > > Key: CONTINUUM-922 > URL: http://jira.codehaus.org/browse/CONTINUUM-922 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > When clicking in a big file in the working copy tab seems that it's trying to > show it in the jsp page instead of downloading it and causes an out of memory > exception > 53182594 [btpool0-0] INFO > com.opensymphony.xwork.interceptor.Interceptor:exceptionLogging - Error > ocurred during execution > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:62) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:113) > at > org.acegisecurity.webwork.AcegiDispatcherUtils.serviceAction(AcegiDispatcherUtils.java:117) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041) > at > com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(Pag
[jira] Commented: (CONTINUUM-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105062 ] Henry S. Isidro commented on CONTINUUM-1234: I'm thinking of separating the interface into two parts, one a list of checkboxes for the non-templated roles and a grid of checkboxes for the templated roles (the project group roles). These checkboxes would be a toggle where the user can check or uncheck roles for the user. Comments? > Improve user role management > - > > Key: CONTINUUM-1234 > URL: http://jira.codehaus.org/browse/CONTINUUM-1234 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak > Fix For: Future > > > With three roles per project group, even a moderate number of groups means a > very long list of roles to look through when assigning roles to users. > There is no way to sort the roles, and they seem to be listed in the order > the project groups were added to Continuum. > Consider listing the project group roles in a grid, with 'User' 'Developer' > and 'Administrator' across the top, and the project group name down the side. > Also, the name of the role is misleading, it says "Project User" when it is > really "Project Group User" -- we don't have per-project roles, just > per-group roles. -- 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-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated CONTINUUM-1234: --- Attachment: proposed_ui.html Here's a mock up of the proposed user roles UI. This should be done in redback, do we have an open issue for this? > Improve user role management > - > > Key: CONTINUUM-1234 > URL: http://jira.codehaus.org/browse/CONTINUUM-1234 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-alpha-1 >Reporter: Wendy Smoak > Fix For: Future > > Attachments: proposed_ui.html > > > With three roles per project group, even a moderate number of groups means a > very long list of roles to look through when assigning roles to users. > There is no way to sort the roles, and they seem to be listed in the order > the project groups were added to Continuum. > Consider listing the project group roles in a grid, with 'User' 'Developer' > and 'Administrator' across the top, and the project group name down the side. > Also, the name of the role is misleading, it says "Project User" when it is > really "Project Group User" -- we don't have per-project roles, just > per-group roles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-319) Web UI Tests for Archiva Search Function
Web UI Tests for Archiva Search Function Key: MRM-319 URL: http://jira.codehaus.org/browse/MRM-319 Project: Archiva Issue Type: Test Components: web application Reporter: Henry S. Isidro -- 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-319) Web UI Tests for Archiva Search Function
[ http://jira.codehaus.org/browse/MRM-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated MRM-319: Attachment: MRM-319-archiva-webapp-test.patch FIle Attached: MRM-319-archiva-webapp-test.patch > Web UI Tests for Archiva Search Function > > > Key: MRM-319 > URL: http://jira.codehaus.org/browse/MRM-319 > Project: Archiva > Issue Type: Test > Components: web application >Reporter: Henry S. Isidro > Attachments: MRM-319-archiva-webapp-test.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] Created: (CONTINUUM-1292) Error when clicking build icon in Project Build Definitions summary
Error when clicking build icon in Project Build Definitions summary --- Key: CONTINUUM-1292 URL: http://jira.codehaus.org/browse/CONTINUUM-1292 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Henry S. Isidro Priority: Minor Steps to replicate: 1. Create a Project group. 2. Add a member Project using Project Group Actions. 3. Then go to the Build Definitions and add a Project Group Build Definition. 4. Click the Build icon of the newly-created Project Group Build Definition. This will cause an error: Here's the log: org.apache.maven.continuum.ContinuumException: could not find project group containing 0 Show/hide Stack Trace org.apache.maven.continuum.ContinuumException: could not find project group containing 0 at org.apache.maven.continuum.DefaultContinuum.getProjectGroupByProjectId(DefaultContinuum.java:240) at org.apache.maven.continuum.web.action.BuildProjectAction.getProjectGroupName(BuildProjectAction.java:157) at org.apache.maven.continuum.web.action.BuildProjectAction.execute(BuildProjectAction.java:51) 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 com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:73) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:103) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:175) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:147) at com.opensymphony.xwork.DefaultActionInvocation.
[jira] Updated: (CONTINUUM-1292) Error when clicking build icon in Project Build Definitions summary
[ http://jira.codehaus.org/browse/CONTINUUM-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated CONTINUUM-1292: --- Attachment: CONTINUUM-1292-continuum-webapp.patch File Attached: CONTINUUM-1292-continuum-webapp.patch Please review, thanks. > Error when clicking build icon in Project Build Definitions summary > --- > > Key: CONTINUUM-1292 > URL: http://jira.codehaus.org/browse/CONTINUUM-1292 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Reporter: Henry S. Isidro >Priority: Minor > Attachments: CONTINUUM-1292-continuum-webapp.patch > > > Steps to replicate: > 1. Create a Project group. > 2. Add a member Project using Project Group Actions. > 3. Then go to the Build Definitions and add a Project Group Build Definition. > 4. Click the Build icon of the newly-created Project Group Build Definition. > This will cause an error: > Here's the log: > org.apache.maven.continuum.ContinuumException: could not find project group > containing 0 > Show/hide Stack Trace > org.apache.maven.continuum.ContinuumException: could not find project group > containing 0 > at > org.apache.maven.continuum.DefaultContinuum.getProjectGroupByProjectId(DefaultContinuum.java:240) > at > org.apache.maven.continuum.web.action.BuildProjectAction.getProjectGroupName(BuildProjectAction.java:157) > at > org.apache.maven.continuum.web.action.BuildProjectAction.execute(BuildProjectAction.java:51) > 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 > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:73) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:103) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:175) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(Defau
[jira] Created: (MRM-416) Find artifact does not work.
Find artifact does not work. Key: MRM-416 URL: http://jira.codehaus.org/browse/MRM-416 Project: Archiva Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Henry S. Isidro Finding an artifact always shows the 'No results found' message even though the artifact that is being looked for is in the 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] Updated: (CONTINUUM-986) Edit group notifier gets a "page not found" problem
[ http://jira.codehaus.org/browse/CONTINUUM-986?page=all ] Henry S. Isidro updated CONTINUUM-986: -- Attachment: CONTINUUM-986-continuum-webapp.patch This fixes the problem described above. > Edit group notifier gets a "page not found" problem > --- > > Key: CONTINUUM-986 > URL: http://jira.codehaus.org/browse/CONTINUUM-986 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1 >Reporter: Christian Gruber > Assigned To: Henry S. Isidro > Attachments: CONTINUUM-986-continuum-webapp.patch > > > Either the edit page is missing for edit group notifiers, or it's mis-linked. -- 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-1052) Create a new notifier that will deploy the build result to a given url.
Create a new notifier that will deploy the build result to a given url. --- Key: CONTINUUM-1052 URL: http://jira.codehaus.org/browse/CONTINUUM-1052 Project: Continuum Issue Type: New Feature Reporter: Henry S. Isidro Using wagon, and a provided url, deploy the build report to that url. -- 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-1052) Create a new notifier that will deploy the build result to a given url.
[ http://jira.codehaus.org/browse/CONTINUUM-1052?page=all ] Henry S. Isidro updated CONTINUUM-1052: --- Attachment: continuum-notifier-wagon.zip This implements the described functionality. > Create a new notifier that will deploy the build result to a given url. > --- > > Key: CONTINUUM-1052 > URL: http://jira.codehaus.org/browse/CONTINUUM-1052 > Project: Continuum > Issue Type: New Feature >Reporter: Henry S. Isidro > Assigned To: Henry S. Isidro > Attachments: continuum-notifier-wagon.zip > > > Using wagon, and a provided url, deploy the build report to that url. -- 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-1052) Create a new notifier that will deploy the build result to a given url.
[ http://jira.codehaus.org/browse/CONTINUUM-1052?page=all ] Henry S. Isidro updated CONTINUUM-1052: --- Attachment: [CONTINUUM-1052]-continuum-webapp.patch File Attached: modified application.xml for component > Create a new notifier that will deploy the build result to a given url. > --- > > Key: CONTINUUM-1052 > URL: http://jira.codehaus.org/browse/CONTINUUM-1052 > Project: Continuum > Issue Type: New Feature >Reporter: Henry S. Isidro > Assigned To: Henry S. Isidro > Attachments: [CONTINUUM-1052]-continuum-webapp.patch, > continuum-notifier-wagon.zip > > > Using wagon, and a provided url, deploy the build report to that url. -- 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-1060) Delete Project confirmation page does not give project name.
Delete Project confirmation page does not give project name. Key: CONTINUUM-1060 URL: http://jira.codehaus.org/browse/CONTINUUM-1060 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Henry S. Isidro Priority: Minor The delete project confirmation page displays the following: Are you sure you want to delete the project ""? The project name is not shown inside the double quotes. -- 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-1060) Delete Project confirmation page does not give project name.
[ http://jira.codehaus.org/browse/CONTINUUM-1060?page=all ] Henry S. Isidro updated CONTINUUM-1060: --- Attachment: [CONTINUUM-1060]-continuum-webapp.patch File Attached: [CONTINUUM-1060]-continuum-webapp.patch > Delete Project confirmation page does not give project name. > > > Key: CONTINUUM-1060 > URL: http://jira.codehaus.org/browse/CONTINUUM-1060 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1060]-continuum-webapp.patch > > > The delete project confirmation page displays the following: > Are you sure you want to delete the project ""? > The project name is not shown inside the double quotes. -- 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-1068) Confirmation message displayed when deleting a notifier is not informative enough.
Confirmation message displayed when deleting a notifier is not informative enough. -- Key: CONTINUUM-1068 URL: http://jira.codehaus.org/browse/CONTINUUM-1068 Project: Continuum Issue Type: Bug Reporter: Henry S. Isidro The confirmation message displayed when deleting a notifier is something like this: "would you like to delete notifier '66'?" This is not meaningful enough, it should give details of the notifier to be deleted. -- 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-1068) Confirmation message displayed when deleting a notifier is not informative enough.
[ http://jira.codehaus.org/browse/CONTINUUM-1068?page=all ] Henry S. Isidro updated CONTINUUM-1068: --- Attachment: [CONTINUUM-1068]-continuum-webapp.patch File Attached: [CONTINUUM-1068]-continuum-webapp.patch The patch makes the confirmation message more meaningful by adding the recipient details to the message. > Confirmation message displayed when deleting a notifier is not informative > enough. > -- > > Key: CONTINUUM-1068 > URL: http://jira.codehaus.org/browse/CONTINUUM-1068 > Project: Continuum > Issue Type: Bug >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1068]-continuum-webapp.patch > > > The confirmation message displayed when deleting a notifier is something like > this: > "would you like to delete notifier '66'?" > This is not meaningful enough, it should give details of the notifier to be > deleted. -- 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-1070) Recipient in project group notifiers screen is always set to 'unknown'.
Recipient in project group notifiers screen is always set to 'unknown'. --- Key: CONTINUUM-1070 URL: http://jira.codehaus.org/browse/CONTINUUM-1070 Project: Continuum Issue Type: Bug Reporter: Henry S. Isidro -- 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-1070) Recipient in project group notifiers screen is always set to 'unknown'.
[ http://jira.codehaus.org/browse/CONTINUUM-1070?page=all ] Henry S. Isidro updated CONTINUUM-1070: --- Component/s: Web interface > Recipient in project group notifiers screen is always set to 'unknown'. > --- > > Key: CONTINUUM-1070 > URL: http://jira.codehaus.org/browse/CONTINUUM-1070 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1070]-continuum-webapp.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] Updated: (CONTINUUM-1070) Recipient in project group notifiers screen is always set to 'unknown'.
[ http://jira.codehaus.org/browse/CONTINUUM-1070?page=all ] Henry S. Isidro updated CONTINUUM-1070: --- Attachment: [CONTINUUM-1070]-continuum-webapp.patch File Attached: [CONTINUUM-1070]-continuum-webapp.patch This fixes the described problem above. > Recipient in project group notifiers screen is always set to 'unknown'. > --- > > Key: CONTINUUM-1070 > URL: http://jira.codehaus.org/browse/CONTINUUM-1070 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1070]-continuum-webapp.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] Created: (CONTINUUM-1111) When a checkout/update is queued, the checkout icon should still be used in preference to the 'queued build' icon.
When a checkout/update is queued, the checkout icon should still be used in preference to the 'queued build' icon. -- Key: CONTINUUM- URL: http://jira.codehaus.org/browse/CONTINUUM- Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Henry S. Isidro Priority: Minor -- 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-1111) When a checkout/update is queued, the checkout icon should still be used in preference to the 'queued build' icon.
[ http://jira.codehaus.org/browse/CONTINUUM-?page=all ] Henry S. Isidro updated CONTINUUM-: --- Attachment: [CONTINUUM-]-continuum-webapp.patch File Attached: [CONTINUUM-]-continuum-webapp.patch This changes the "in queue" image to a "checkout" image. > When a checkout/update is queued, the checkout icon should still be used in > preference to the 'queued build' icon. > -- > > Key: CONTINUUM- > URL: http://jira.codehaus.org/browse/CONTINUUM- > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-]-continuum-webapp.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] Created: (CONTINUUM-1117) Cannot add a wagon notifier because it doesn't appear in the notifiers list.
Cannot add a wagon notifier because it doesn't appear in the notifiers list. Key: CONTINUUM-1117 URL: http://jira.codehaus.org/browse/CONTINUUM-1117 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Henry S. Isidro -- 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-1117) Cannot add a wagon notifier because it doesn't appear in the notifiers list.
[ http://jira.codehaus.org/browse/CONTINUUM-1117?page=all ] Henry S. Isidro updated CONTINUUM-1117: --- Attachment: [CONTINUUM-1117]-continuum-webapp.patch File Attached: [CONTINUUM-1117]-continuum-webapp.patch This adds the wagon notifier to the list of notifiers as well as the functionality of adding a wagon notifier to the build. > Cannot add a wagon notifier because it doesn't appear in the notifiers list. > > > Key: CONTINUUM-1117 > URL: http://jira.codehaus.org/browse/CONTINUUM-1117 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1117]-continuum-webapp.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] Updated: (CONTINUUM-1117) Cannot add a wagon notifier because it doesn't appear in the notifiers list.
[ http://jira.codehaus.org/browse/CONTINUUM-1117?page=all ] Henry S. Isidro updated CONTINUUM-1117: --- Attachment: [CONTINUUM-1117]-continuum-webapp.patch-2 File Attached: [CONTINUUM-1117]-continuum-webapp.patch-2 Here's a revised patch. > Cannot add a wagon notifier because it doesn't appear in the notifiers list. > > > Key: CONTINUUM-1117 > URL: http://jira.codehaus.org/browse/CONTINUUM-1117 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1117]-continuum-webapp.patch, > [CONTINUUM-1117]-continuum-webapp.patch-2 > > -- 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-1131) Wagon notifier does not use configuration.
Wagon notifier does not use configuration. -- Key: CONTINUUM-1131 URL: http://jira.codehaus.org/browse/CONTINUUM-1131 Project: Continuum Issue Type: Bug Reporter: Henry S. Isidro Wagon notifier (which is used to deploy build history report to the project site) does not get it's configuration setting from configuration. -- 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-1131) Wagon notifier does not use configuration.
[ http://jira.codehaus.org/browse/CONTINUUM-1131?page=all ] Henry S. Isidro updated CONTINUUM-1131: --- Attachment: [CONTINUUM-1131]-continuum-notifier-wagon.patch File Attached: [CONTINUUM-1131]-continuum-notifier-wagon.patch This patch makes wagon notifier read the configuration for its destination url. If the url is not set in configuration, it uses the one set in in the distributionManagement section of the pom. > Wagon notifier does not use configuration. > -- > > Key: CONTINUUM-1131 > URL: http://jira.codehaus.org/browse/CONTINUUM-1131 > Project: Continuum > Issue Type: Bug >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1131]-continuum-notifier-wagon.patch > > > Wagon notifier (which is used to deploy build history report to the project > site) does not get it's configuration setting from configuration. -- 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-1132) Project view page does not show the recipient of the wagon notifier.
Project view page does not show the recipient of the wagon notifier. Key: CONTINUUM-1132 URL: http://jira.codehaus.org/browse/CONTINUUM-1132 Project: Continuum Issue Type: Bug Components: Web interface Reporter: Henry S. Isidro -- 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-1132) Project view page does not show the recipient of the wagon notifier.
[ http://jira.codehaus.org/browse/CONTINUUM-1132?page=all ] Henry S. Isidro updated CONTINUUM-1132: --- Attachment: [CONTINUUM-1132]-continuum-webapp.patch File Attached: [CONTINUUM-1132]-continuum-webapp.patch This fixes the described bug. > Project view page does not show the recipient of the wagon notifier. > > > Key: CONTINUUM-1132 > URL: http://jira.codehaus.org/browse/CONTINUUM-1132 > Project: Continuum > Issue Type: Bug > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1132]-continuum-webapp.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] Created: (CONTINUUM-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
Project Site URL in wagon notifier edit pages is required but doesn't have validation - Key: CONTINUUM-1133 URL: http://jira.codehaus.org/browse/CONTINUUM-1133 Project: Continuum Issue Type: Bug Components: Notification Subsystem Reporter: Henry S. Isidro Priority: Minor -- 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-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
[ http://jira.codehaus.org/browse/CONTINUUM-1133?page=all ] Henry S. Isidro updated CONTINUUM-1133: --- Attachment: [CONTINUUM-1133]-continuum-webapp.patch File Attached: [CONTINUUM-1133]-continuum-webapp.patch The patch adds the necessary validation. > Project Site URL in wagon notifier edit pages is required but doesn't have > validation > - > > Key: CONTINUUM-1133 > URL: http://jira.codehaus.org/browse/CONTINUUM-1133 > Project: Continuum > Issue Type: Bug > Components: Notification Subsystem >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1133]-continuum-webapp.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] Updated: (CONTINUUM-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
[ http://jira.codehaus.org/browse/CONTINUUM-1133?page=all ] Henry S. Isidro updated CONTINUUM-1133: --- Attachment: [CONTINUUM-1133]-continuum-webapp.patch-2 File Attached: [CONTINUUM-1133]-continuum-webapp.patch-2 The first patch is incorrect, it only validates an ordinary URL, whereas wagon uses URLs like dav:http:// The second patch has a custom validator for this. > Project Site URL in wagon notifier edit pages is required but doesn't have > validation > - > > Key: CONTINUUM-1133 > URL: http://jira.codehaus.org/browse/CONTINUUM-1133 > Project: Continuum > Issue Type: Bug > Components: Notification Subsystem >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1133]-continuum-webapp.patch, > [CONTINUUM-1133]-continuum-webapp.patch-2 > > -- 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-1137) Add a link to the schecule in the schedule column of build definitions table
Add a link to the schecule in the schedule column of build definitions table Key: CONTINUUM-1137 URL: http://jira.codehaus.org/browse/CONTINUUM-1137 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Henry S. Isidro Priority: Minor -- 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-1137) Add a link to the schecule in the schedule column of build definitions table
[ http://jira.codehaus.org/browse/CONTINUUM-1137?page=all ] Henry S. Isidro updated CONTINUUM-1137: --- Attachment: [CONTINUUM-1137]-continuum-webapp.patch File Attached: [CONTINUUM-1137]-continuum-webapp.patch > Add a link to the schecule in the schedule column of build definitions table > > > Key: CONTINUUM-1137 > URL: http://jira.codehaus.org/browse/CONTINUUM-1137 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1137]-continuum-webapp.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] Updated: (CONTINUUM-1137) Add a link to the schecule in the schedule column of build definitions table
[ http://jira.codehaus.org/browse/CONTINUUM-1137?page=all ] Henry S. Isidro updated CONTINUUM-1137: --- Attachment: [CONTINUUM-1137]-continuum-webapp.patch-2 File Attached: [CONTINUUM-1137]-continuum-webapp.patch-2 Please disregard the first patch, this new patch adds permission checks. > Add a link to the schecule in the schedule column of build definitions table > > > Key: CONTINUUM-1137 > URL: http://jira.codehaus.org/browse/CONTINUUM-1137 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1137]-continuum-webapp.patch, > [CONTINUUM-1137]-continuum-webapp.patch-2 > > -- 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-675) Add Working Copy to the Legends
[ http://jira.codehaus.org/browse/CONTINUUM-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated CONTINUUM-675: -- Attachment: [CONTINUUM-675]-continuum-webapp.patch File Attached: [CONTINUUM-675]-continuum-webapp.patch This adds the 'working copy' icon to the legends list. > Add Working Copy to the Legends > --- > > Key: CONTINUUM-675 > URL: http://jira.codehaus.org/browse/CONTINUUM-675 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Shinobu Kawai >Priority: Trivial > Fix For: 1.1 > > Attachments: [CONTINUUM-675]-continuum-webapp.patch > > > Add "Working Copy" to the Legends on the left -- 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-675) Add Working Copy to the Legends
[ http://jira.codehaus.org/browse/CONTINUUM-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated CONTINUUM-675: -- Attachment: legendbg.gif File Attached: legendbg.gif This is the background gif for the legends list. > Add Working Copy to the Legends > --- > > Key: CONTINUUM-675 > URL: http://jira.codehaus.org/browse/CONTINUUM-675 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Shinobu Kawai >Priority: Trivial > Fix For: 1.1 > > Attachments: [CONTINUUM-675]-continuum-webapp.patch, legendbg.gif > > > Add "Working Copy" to the Legends on the left -- 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-1153) Add a Project Group Level Release Button
Add a Project Group Level Release Button Key: CONTINUUM-1153 URL: http://jira.codehaus.org/browse/CONTINUUM-1153 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Henry S. Isidro We should have a Release button under the Project Group Actions This button would be functionally equivalent to clicking the release icon of the parent project within that project group. -- 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-1153) Add a Project Group Level Release Button
[ http://jira.codehaus.org/browse/CONTINUUM-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated CONTINUUM-1153: --- Attachment: [CONTINUUM-1153]-continuum.patch File Attached: [CONTINUUM-1153]-continuum.patch The patch adds the described button. Please review, thanks. > Add a Project Group Level Release Button > > > Key: CONTINUUM-1153 > URL: http://jira.codehaus.org/browse/CONTINUUM-1153 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Henry S. Isidro > Attachments: [CONTINUUM-1153]-continuum.patch > > > We should have a Release button under the Project Group Actions > This button would be functionally equivalent to clicking the release icon of > the parent project within that project group. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-287) The context is not included in repository links when browsing artifacts.
The context is not included in repository links when browsing artifacts. Key: MRM-287 URL: http://jira.codehaus.org/browse/MRM-287 Project: Archiva Issue Type: Bug Components: web application Reporter: Henry S. Isidro When browsing, searching and finding an artifact, the resulting page displays links to navigate to the various levels of the artifact's group as well as to the top of the tree. These links have urls which do not include the context of the web application so if archiva is deployed in a different context, these links will generate 404s. -- 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-287) The context is not included in repository links when browsing artifacts.
[ http://jira.codehaus.org/browse/MRM-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated MRM-287: Attachment: [MRM-287]-archiva-webapp.patch File Attached: [MRM-287]-archiva-webapp.patch This patch adds the context to the generated urls of the navigation links when browsing an artifact. > The context is not included in repository links when browsing artifacts. > > > Key: MRM-287 > URL: http://jira.codehaus.org/browse/MRM-287 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henry S. Isidro > Attachments: [MRM-287]-archiva-webapp.patch > > > When browsing, searching and finding an artifact, the resulting page displays > links to navigate to the various levels of the artifact's group as well as to > the top of the tree. These links have urls which do not include the context > of the web application so if archiva is deployed in a different context, > these links will generate 404s. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-296) Error 404 after logging in from archiva when prompted
Error 404 after logging in from archiva when prompted - Key: MRM-296 URL: http://jira.codehaus.org/browse/MRM-296 Project: Archiva Issue Type: Bug Components: web application Reporter: Henry S. Isidro I've gotten a 404 after being unexpectedly prompted to log in while doing something in Archiva. After logging in, the url is: http://localhost:8080/archiva/security/index!input.action?externalResult=security-login-success And the the result is: HTTP ERROR: 404 There is no Action mapped for namespace /security and action name index. Check if there is such an action name with such namespace defined in the xwork.xml and also if such an action class exists. Check also the log to see if the action class is successfully loaded. RequestURI=/archiva/security/index!input.action At this point I am logged in, if I use the browser back button and choose another link, everything is fine. -- 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-296) Error 404 after logging in from archiva when prompted
[ http://jira.codehaus.org/browse/MRM-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated MRM-296: Attachment: [MRM-296]-archiva-webapp.patch > Error 404 after logging in from archiva when prompted > - > > Key: MRM-296 > URL: http://jira.codehaus.org/browse/MRM-296 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henry S. Isidro > Attachments: [MRM-296]-archiva-webapp.patch > > > I've gotten a 404 after being unexpectedly prompted to log in while doing > something in Archiva. > After logging in, the url is: > http://localhost:8080/archiva/security/index!input.action?externalResult=security-login-success > And the the result is: > HTTP ERROR: 404 > There is no Action mapped for namespace /security and action name index. > Check if there is such an action name with such namespace defined in the > xwork.xml and also if such an action class exists. Check also the log to see > if the action class is successfully loaded. > RequestURI=/archiva/security/index!input.action > At this point I am logged in, if I use the browser back button and choose > another link, everything is fine. -- 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-296) Error 404 after logging in from archiva when prompted
[ http://jira.codehaus.org/browse/MRM-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88981 ] Henry S. Isidro commented on MRM-296: - File Attached: [MRM-296]-archiva-webapp.patch Please review. Thanks. > Error 404 after logging in from archiva when prompted > - > > Key: MRM-296 > URL: http://jira.codehaus.org/browse/MRM-296 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Henry S. Isidro > Attachments: [MRM-296]-archiva-webapp.patch > > > I've gotten a 404 after being unexpectedly prompted to log in while doing > something in Archiva. > After logging in, the url is: > http://localhost:8080/archiva/security/index!input.action?externalResult=security-login-success > And the the result is: > HTTP ERROR: 404 > There is no Action mapped for namespace /security and action name index. > Check if there is such an action name with such namespace defined in the > xwork.xml and also if such an action class exists. Check also the log to see > if the action class is successfully loaded. > RequestURI=/archiva/security/index!input.action > At this point I am logged in, if I use the browser back button and choose > another link, everything is fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-43) wagon-ftp sometimes does not build due to socket errors in tests
wagon-ftp sometimes does not build due to socket errors in tests Key: WAGON-43 URL: http://jira.codehaus.org/browse/WAGON-43 Project: wagon Type: Bug Versions: 1.0-alpha-7 Environment: linux, maven 2.0.4 Reporter: Henry S. Isidro Priority: Minor The wagon-ftp provider build sometimes do not continue due to a SocketException in the unit test. This message is displayed several times: [ERROR] Exception accepting connection java.net.SocketException: Socket is closed at java.net.ServerSocket.accept(ServerSocket.java:417) at org.apache.avalon.cornerstone.blocks.connection.Connection.run(Connection.java:134) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:90) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:136) There are times though that the build will succeed so this seems to be an inconsistent occurrence. -- 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: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=comments#action_64023 ] Henry S. Isidro commented on WAGON-40: -- It works for me as well. Tried it on a mapped drive on a Windows 2003 Server and Maven 2.0.4. Resolving this issue now. > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Components: wagon-file > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: site.error.txt > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/sec
[jira] Resolved: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=all ] Henry S. Isidro resolved WAGON-40: -- Resolution: Cannot Reproduce Cannot reproduce described behavior. Environment: WinXP, Windows 2003 Server, Maven 2.0.4 > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Components: wagon-file > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: site.error.txt > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [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/Administrator
[jira] Updated: (WAGON-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=all ] Henry S. Isidro updated WAGON-40: - Fix Version: (was: 1.0-beta-1) > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Components: wagon-file > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Assignee: Henry S. Isidro > Priority: Critical > Attachments: site.error.txt > > Time Spent: 2 hours, 30 minutes >Remaining: 0 minutes > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [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] Commented: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
[ http://jira.codehaus.org/browse/WAGON-42?page=comments#action_64035 ] Henry S. Isidro commented on WAGON-42: -- I am wondering if it is a good idea to place this functionality in wagon-scm or should it go higher like in maven-scm-api? > wagon-scm (svn provider) - large paths under windows breaks download. > - > > Key: WAGON-42 > URL: http://jira.codehaus.org/browse/WAGON-42 > Project: wagon > Type: Bug > Components: wagon-scm > Versions: 1.0-alpha-6 > Reporter: Joakim Erdfelt > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > > > I have a deep path in windows, plus a repository housed in svn. > When performing a 'mvn compile', it fails with not finding the artifact. > Using mvn --debug shows no error message from wagon-scm (svn). > If I go into the target/checkout/ directory, i see an empty directory > with the '.svn' working directory. > performing a 'svn update .' in that directory reveals the reason ... > [EMAIL PROTECTED] > /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT > $ svn update . > svn: Can't open file > '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': > File name too long > I think a general "if windows, and path exceeds maximum, throw error before > attempting process' kind of functionality needs to exist. -- 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-189) Maven SCM should check if OS is Windows and destination path would exceed Windows maximum before a checkout
Maven SCM should check if OS is Windows and destination path would exceed Windows maximum before a checkout --- Key: SCM-189 URL: http://jira.codehaus.org/browse/SCM-189 Project: Maven SCM Type: Bug Components: maven-scm-api Versions: 1.0-beta-3 Environment: Windows XP, Maven 2.0.4 Reporter: Henry S. Isidro -- 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: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
[ http://jira.codehaus.org/browse/WAGON-42?page=comments#action_64148 ] Henry S. Isidro commented on WAGON-42: -- I made a deep path in windows and a repository in svn. I tried mvn compile and it seems to be working, i.e. I can get the artifacts from my svn repository. I can't see the .svn directory in target/checkout though. > wagon-scm (svn provider) - large paths under windows breaks download. > - > > Key: WAGON-42 > URL: http://jira.codehaus.org/browse/WAGON-42 > Project: wagon > Type: Bug > Components: wagon-scm > Versions: 1.0-alpha-6 > Reporter: Joakim Erdfelt > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > > Time Spent: 4 hours >Remaining: 0 minutes > > I have a deep path in windows, plus a repository housed in svn. > When performing a 'mvn compile', it fails with not finding the artifact. > Using mvn --debug shows no error message from wagon-scm (svn). > If I go into the target/checkout/ directory, i see an empty directory > with the '.svn' working directory. > performing a 'svn update .' in that directory reveals the reason ... > [EMAIL PROTECTED] > /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT > $ svn update . > svn: Can't open file > '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': > File name too long > I think a general "if windows, and path exceeds maximum, throw error before > attempting process' kind of functionality needs to exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
[ http://jira.codehaus.org/browse/WAGON-42?page=all ] Henry S. Isidro updated WAGON-42: - Attachment: ScmWagon.patch > wagon-scm (svn provider) - large paths under windows breaks download. > - > > Key: WAGON-42 > URL: http://jira.codehaus.org/browse/WAGON-42 > Project: wagon > Type: Bug > Components: wagon-scm > Versions: 1.0-alpha-6 > Reporter: Joakim Erdfelt > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: ScmWagon.patch > > Time Spent: 4 hours >Remaining: 0 minutes > > I have a deep path in windows, plus a repository housed in svn. > When performing a 'mvn compile', it fails with not finding the artifact. > Using mvn --debug shows no error message from wagon-scm (svn). > If I go into the target/checkout/ directory, i see an empty directory > with the '.svn' working directory. > performing a 'svn update .' in that directory reveals the reason ... > [EMAIL PROTECTED] > /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT > $ svn update . > svn: Can't open file > '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': > File name too long > I think a general "if windows, and path exceeds maximum, throw error before > attempting process' kind of functionality needs to exist. -- 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] Resolved: (WAGON-42) wagon-scm (svn provider) - large paths under windows breaks download.
[ http://jira.codehaus.org/browse/WAGON-42?page=all ] Henry S. Isidro resolved WAGON-42: -- Resolution: Fixed Resolving this, wagon-scm now displays a message that the checkout path exceeds the windows maximum. > wagon-scm (svn provider) - large paths under windows breaks download. > - > > Key: WAGON-42 > URL: http://jira.codehaus.org/browse/WAGON-42 > Project: wagon > Type: Bug > Components: wagon-scm > Versions: 1.0-alpha-6 > Reporter: Joakim Erdfelt > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: ScmWagon.patch > > Time Spent: 5 hours, 30 minutes >Remaining: 0 minutes > > I have a deep path in windows, plus a repository housed in svn. > When performing a 'mvn compile', it fails with not finding the artifact. > Using mvn --debug shows no error message from wagon-scm (svn). > If I go into the target/checkout/ directory, i see an empty directory > with the '.svn' working directory. > performing a 'svn update .' in that directory reveals the reason ... > [EMAIL PROTECTED] > /c/code/mergere/amex/AXP-EntBuildEnv/tools/branches/mergere-discovery-wizard/mergere-discovery-core/target/checkout/org/apache/maven/repository/maven-repository-indexer/1.0-SNAPSHOT > $ svn update . > svn: Can't open file > '.svn/text-base/maven-repository-indexer-1.0-20060418.201022-1.jar.md5.svn-base': > File name too long > I think a general "if windows, and path exceeds maximum, throw error before > attempting process' kind of functionality needs to exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: FtpWagon.patch > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: FtpWagon.patch > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: (was: FtpWagon.patch) > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: WebDavWagon.patch > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: WebDavWagon.patch, wagon.patch > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-19) Make file upload more robust
[ http://jira.codehaus.org/browse/WAGON-19?page=all ] Henry S. Isidro updated WAGON-19: - Attachment: wagon.patch > Make file upload more robust > > > Key: WAGON-19 > URL: http://jira.codehaus.org/browse/WAGON-19 > Project: wagon > Type: Improvement > Components: wagon-webdav, wagon-ssh-external, wagon-ssh, wagon-ftp, > wagon-file > Environment: All scp, sftp and ftp upload of files to Repositories > Reporter: Mark Diggory > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: WebDavWagon.patch, wagon.patch > > > We would recommend that for upload of files to a repository that the > following cases be handled to provide greater robustness. > 1.) All uploads be to a "staging" area, this staging area could be the same > directory or a temp directory and would upload the file with the file name > extension of > Henk Penning comments: > > That would be great. > > > > I think, the best way for adding/replace stuff is > > > > -- write a 'temp' > > -- rename 'temp' to 'file' > > > > because a rename is truly atomic if 'temp' and 'file' are > > in the same file system. > > > > If you can implement the 'temp' for 'file' to be, > > for instance, '.tmp.file', I can easily teach the checkers > > to ignore '.tmp.*' files. I think rsync does something > > like that (even better .tmp.$$.file). > > > So the goals here are to verify that rsync handles ".tmp.$$.file" which will > stop it from attempting to sync partial uploads. Henk can alter the md5 > checking utilities at Apache to postpone checking .tmp files md5 signatures. > 2.) All file permissions on uploaded files would best handled to be only > writable by the individual user, not writable by group and readable by all. > All directory permissions should be writable for user and group and readable > by all. This forces the following implementation to be required. > Any file upload that attempts to overwrite a file should instead, move that > file out of the way to a temporary location, upload to the new file using > strategy (1) and then name it to the old file, once this is completed the old > file can be removed. This provides a means be which file "ownership" can be > determined and maintained. The problem this solves is the following, if files > are "group writable" then any individual in the group can overwite the file > altering its contents, historically we cannot tell who actually made the > alteration. If there are concerns about the integrity of the artifact or its > signature, it is unclear who was responsible for the alteration. > -Mark Diggory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-70) {inceptionYear} is not evaluated when inceptionYear is not specified in pom.
{inceptionYear} is not evaluated when inceptionYear is not specified in pom.
Key: MJAVADOC-70
URL: http://jira.codehaus.org/browse/MJAVADOC-70
Project: Maven 2.x Javadoc Plugin
Type: Bug
Versions: 2.0-beta-3
Reporter: Henry S. Isidro
Priority: Minor
Fix For: 2.0-beta-3
Attachments: maven-javadoc-plugin.patch
The javadoc site shows {inceptionYear} if the inceptionYear parameter is not
set in pom.xml. The attached patch remedies this.
--
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
