[jira] Commented: (MRM-531) Unable to download snapshots behind proxy with authentication
[ http://jira.codehaus.org/browse/MRM-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113278 ] Mathias Arens commented on MRM-531: --- Well, now with Archiva 1.0-beta-3 I can download snapshots. It works fine. Although there is a little problem if I don't set releases to once in the proxy adapter for that snapshot repository. If releases is set to disabled, then the metadata.xml files cannot be download and the complete snapshot download fails. But with the workaround setting releases to once it works fine. Thanks a lot. > Unable to download snapshots behind proxy with authentication > - > > Key: MRM-531 > URL: http://jira.codehaus.org/browse/MRM-531 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-beta-2 > Environment: solaris 5.10, jdk1.6.0_02, proxy with basic > authentication >Reporter: Mathias Arens >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-3 > > > I am able to download artifacts from several remote repositories into the > internal repository. But I cannot download any dependencies into the > snapshots repository. I always get a http-'Server redirected too many times > (20)'-error. I read that this error occurs if the proxy authentication > properties are not set correctly in the http client. I am behind a proxy with > basic authentication and an empty password. This configuration works fine for > the internal repository, but not for the snapshot repository. > Here are the logs: > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [cache-failures] policy with [ignored] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to > fetch, check-failures policy set to IGNORED. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [releases] policy with [disabled] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:releases - OK to update, > release policy does not apply for snapshot versions. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying > [snapshots] policy with [daily] > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,987 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.policies.PreDownloadPolicy:snapshots - OK to update > snapshots, local file does not exist. > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:08,988 > [SocketListener0-7] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Retrieving org/apache/maven/artifact/maven-artifact/3.0-SNAPSHOT/mave > n-artifact-3.0-SNAPSHOT.pom from Apache Snapshots Repository if updated > INFO | jvm 1| 2007/10/02 11:50:09 | 2007-10-02 11:50:09,087 > [SocketListener0-7] WARN > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Download > failure:Error transferring file > INFO | jvm 1| 2007/10/02 11:50:09 | > org.apache.maven.wagon.TransferFailedException: Error transferring file > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:94) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferSimpleFile(DefaultRepositoryProxyConnectors.java:566) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transferFile(DefaultRepositoryProxyConnectors.java:434) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:143) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.applyServerSideRelocation(ProxiedDavServer.java:286) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:243) > INFO | jvm 1| 2007/10/02 11:50:09 | at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.j
[jira] Updated: (SUREFIRE-316) [M206] Test doesn't work anymore
[ http://jira.codehaus.org/browse/SUREFIRE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marat Radchenko updated SUREFIRE-316: - Attachment: SUREFIRE-156.patch Attached patch allows Surefire to pass testcase written by Gamnacke. > [M206] Test doesn't work anymore > > > Key: SUREFIRE-316 > URL: http://jira.codehaus.org/browse/SUREFIRE-316 > Project: Maven Surefire > Issue Type: Bug > Environment: Windows XP >Reporter: Denis Cabasson >Assignee: Brett Porter > Fix For: 2.3.1 > > Attachments: 206-test.zip, diff.txt, pom.xml, SUREFIRE-156.patch, > test-exec-205.txt, test-exec-206.txt, test.tgz, test.zip > > > When running "mvn test" on the simple use cas attached, M205 is doing fine, > while M206 is crashing with a java.lang.IllegalArgumentException, apparently > due to a diffrence in the command line used to fork the JVM for surefire. > Attached are the 2 executions, with M205 and M206. I haven't managed to > figure out where this bug is coming from -- 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-584) Newly created user cannot login
Newly created user cannot login --- Key: MRM-584 URL: http://jira.codehaus.org/browse/MRM-584 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-beta-4 Reporter: Maria Odea Ching A new user which has just been created cannot login to Archiva because the user is not validated yet. No email for the new user to validate his/her account is being sent to the user after the account is created. The work around is to click 'Resend Validation' in the User Account page so a validation email is sent to the user and the user can login to Archiva after validating his/her account. Should this be in redback? -- 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-584) Newly created user cannot login
[ http://jira.codehaus.org/browse/MRM-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-584: - Fix Version/s: 1.1 > Newly created user cannot login > --- > > Key: MRM-584 > URL: http://jira.codehaus.org/browse/MRM-584 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-beta-4 >Reporter: Maria Odea Ching > Fix For: 1.1 > > > A new user which has just been created cannot login to Archiva because the > user is not validated yet. No email for the new user to validate his/her > account is being sent to the user after the account is created. The work > around is to click 'Resend Validation' in the User Account page so a > validation email is sent to the user and the user can login to Archiva after > validating his/her account. > Should this be in redback? -- 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: (SUREFIRE-316) [M206] Test doesn't work anymore
[ http://jira.codehaus.org/browse/SUREFIRE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marat Radchenko updated SUREFIRE-316: - Attachment: SUREFIRE-316.patch Woops, sorry, wrong patch. This one is correct. > [M206] Test doesn't work anymore > > > Key: SUREFIRE-316 > URL: http://jira.codehaus.org/browse/SUREFIRE-316 > Project: Maven Surefire > Issue Type: Bug > Environment: Windows XP >Reporter: Denis Cabasson >Assignee: Brett Porter > Fix For: 2.3.1 > > Attachments: 206-test.zip, diff.txt, pom.xml, SUREFIRE-156.patch, > SUREFIRE-316.patch, test-exec-205.txt, test-exec-206.txt, test.tgz, test.zip > > > When running "mvn test" on the simple use cas attached, M205 is doing fine, > while M206 is crashing with a java.lang.IllegalArgumentException, apparently > due to a diffrence in the command line used to fork the JVM for surefire. > Attached are the 2 executions, with M205 and M206. I haven't managed to > figure out where this bug is coming from -- 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-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113286 ] Ionut S commented on CONTINUUM-884: --- What file do I need to modify to set that level ? I looked inside the entire continuum folder for something related to maven-scm but I couldn't find something meaningful.. > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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-578) unfinished scanning after NPE
[ http://jira.codehaus.org/browse/MRM-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-578: - Fix Version/s: (was: 1.0-beta-4) 1.0 > unfinished scanning after NPE > - > > Key: MRM-578 > URL: http://jira.codehaus.org/browse/MRM-578 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-beta-3 > Environment: macosx 1.4, jdk 1.5, archiva beta3 >Reporter: Milos Kleint > Fix For: 1.0 > > Attachments: error.txt, error2.txt > > > I repeatedly tried to index a mirror of central repository. In previous > attempts, usually got "Too many files opened" kind of errors. This time it's > a NPE, see attached console output -- 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-545) Documentation for configuring for Tomcat is invalid
[
http://jira.codehaus.org/browse/MRM-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Odea Ching updated MRM-545:
-
Fix Version/s: (was: 1.0-beta-4)
1.0
> Documentation for configuring for Tomcat is invalid
> ---
>
> Key: MRM-545
> URL: http://jira.codehaus.org/browse/MRM-545
> Project: Archiva
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.0-beta-2
> Environment: Windows XP, Tomcat-5.5.17/Tomcat-5.5.20, JDK-1.5.0_06
>Reporter: William Ferguson
>Priority: Critical
> Fix For: 1.0
>
> Attachments: bad-log-filename.log, mail-auth-class-not-found.log
>
>
> Following http://maven.apache.org/archiva/guides/getting-started.html for
> Tomcat didn't get me started.
> I'll go through it point by point
> # Create a directory in tomcat called archiva, at the same level as bin,
> conf, logs and the others.
> # Copy the war file from apps/archiva/lib into the new directory
> There is not apps/archiva/lib in the 1.0-beta-2 distribution.
> apps contains a single file : archiva-plexus-application-1.0-beta-2.jar which
> does itself contain a war file, so I extracted that file and copied it to the
> TOMCAT_HOME/archiva folder.
> NB IMHO modifying TOMCAT in this manner smells all wrong.
> # Create a conf/Catalina/localhost/archiva.xml file with the following data:
> yadda, yadda
> The docBase attribute refers to archiva-webapp-1.0-SNAPSHOT.war instead of
> archiva-webapp-1.0-beta-2.war
> No idea why a javax.mail.Session needs to be configured here, haven't seen
> any documentation in Archiva that suggests it send, receives email. But this
> was a slight pain when configuring for Tomcat-5.5.20 as I needed to follow
> the extra steps for the missing classes. If the MailSession is not required
> it would be better to avoid this pain by simplifying the config.
> Again modifying TOMCAT like this does not feel right. Surely this config
> could be contained within the webapp.
> # Copy $HOME/.m2/org/apache/derby/derby/10.1.3.1/derby-10.1.3.1.jar (or from
> the remote repository) into the Tomcat common/lib
> I am *really* against this as I have now introduced Derby-10.1.3.1 into the
> classpath of 8all* my other applications running on that Tomcat instance.
> Surely this library could be packaged up into the webapp.
> # To deal with a current bug, you'll also need to add the following to your
> $catalina.home/conf/web.xml in the relevant section (search for jspx):
> Again, surely this could be included in the config for the Archiva webapp
> instead of introduced into Tomcat generally. This heavy handed approach makes
> maintenance difficult, eg upgrading to a new version of Tomcat is now
> extremely onerous.
> OK, so having followed the instructions above, when I try to startup Tomcat
> the first thin I get is a failure with the logging sub system. see attached
> bad-log-filename.log. I believe this is due to the fact that
> ${appserver.base} in log4j.xml has never been set:
> {code}
>
> {code}
> Next, it fails as it can't find javax.mail.Authenticator (this is
> Tomcat-5.5.17).
> NB I never saw any indication that "schema SA does not exist" as the final
> note suggests. But perhaps this was because Archiva never got that far.
> Certainly no application is available at http://localhost:8080/archiva/
> Anyway, by this stage I became discouraged enough that I gave up.
> Its a shame really as I would have liked to be able to compare Archiva
> against Proximity and Artifactory, both of which I managed to get setup in
> under 10 mins including vastly restructuring the default repository config
> that they ship with.
> Brett, hope that helps.
> Further notes:
> I really don't like modifying the contents of TOMCAT_HOME other than to
> deploy a WAR to TOMCAT_HOME/webapps.
> And the infrastructure team weren't impressed either and its makes
> maintenance high cost.
> Better to keep all config solely within the confines of the webapp or use a
> environment variable to declare a separate proxy_home where all the config is
> contained (like Artifactory does).
--
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-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113288 ] Emmanuel Venisse commented on CONTINUUM-884: log4j.xml under WEB-INF/classes > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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-585) Project models for Maven 1 artifacts cannot be found in repo browse
[ http://jira.codehaus.org/browse/MRM-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-585: - Fix Version/s: 1.1 > Project models for Maven 1 artifacts cannot be found in repo browse > --- > > Key: MRM-585 > URL: http://jira.codehaus.org/browse/MRM-585 > Project: Archiva > Issue Type: Bug > Components: browser >Affects Versions: 1.0-beta-4 >Reporter: Maria Odea Ching > Fix For: 1.1 > > > This error occurs when browsing for a Maven 1 artifact (ex. acegisecurity): > Unable to find project model for [acegisecurity:acegi-security:0.7.0]. -- 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-585) Project models for Maven 1 artifacts cannot be found in repo browse
Project models for Maven 1 artifacts cannot be found in repo browse --- Key: MRM-585 URL: http://jira.codehaus.org/browse/MRM-585 Project: Archiva Issue Type: Bug Components: browser Affects Versions: 1.0-beta-4 Reporter: Maria Odea Ching Fix For: 1.1 This error occurs when browsing for a Maven 1 artifact (ex. acegisecurity): Unable to find project model for [acegisecurity:acegi-security:0.7.0]. -- 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: (SUREFIRE-351) maven-surefire-plugin's parameter isn't getting set correctly
[
http://jira.codehaus.org/browse/SUREFIRE-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113289
]
Marat Radchenko commented on SUREFIRE-351:
--
This is not a bug. Instead, use the following:
{code:xml}
maven-surefire-plugin
true
it
integration-test
test
false
{code}
P.S. duplicate declarations of the same plugin isn't a good idea.
> maven-surefire-plugin's parameter isn't getting set correctly
> -
>
> Key: SUREFIRE-351
> URL: http://jira.codehaus.org/browse/SUREFIRE-351
> Project: Maven Surefire
> Issue Type: Bug
> Components: plugin
>Affects Versions: 2.3
> Environment: Maven version: 2.0.7
> Java version: 1.5.0_10
> OS name: "linux" version: "2.6.18-4-686" arch: "i386"
>Reporter: Tom Cort
> Fix For: 2.3.1
>
> Attachments: output.txt
>
>
> I'm trying to get maven-surefire-plugin to skip the unit tests during the
> 'test' phase and run them during the 'integration-test' phase. I was
> successful in getting the plugin to skip tests during the 'test' phase and to
> execute during the 'integration-test' phase, but even if I set skip to false
> the tests are still skipped during the 'integration-test' phase. Here is the
> relevant part of my pom.xml:
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.3
>
> true
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.3
>
> false
>
>
>
> it
> integration-test
>
> test
>
>
> false
>
>
>
>
> I'm attaching the full output of "mvn -e -X clean install" You'll notice that
> even though the 'it' execution has skip set to false in pom.xml, it says
> [DEBUG] (f) skip = true
> and
> [INFO] [surefire:test {execution: it}]
> [INFO] Tests are skipped.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-458) Trigger scripts ?
[ http://jira.codehaus.org/browse/CONTINUUM-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-458. -- Assignee: Emmanuel Venisse Resolution: Duplicate Fix Version/s: (was: 1.1) Duplicate CONTINUUM-347 > Trigger scripts ? > -- > > Key: CONTINUUM-458 > URL: http://jira.codehaus.org/browse/CONTINUUM-458 > Project: Continuum > Issue Type: New Feature > Components: Documentation, XMLRPC Interface >Affects Versions: 1.0.1 >Reporter: Grégory Joseph >Assignee: Emmanuel Venisse > > http://maven.apache.org/continuum/guides/getting-started/index.html mentions > 2 python scripts. > However, these are not present in the 1.0.1 tgz distribution. > I hope these are useable as on-commit scripts, to trigger builds when > commiting. > Could be extra nice to have (or others) downloadable as separate artifact, in > order to use them as on-commit trigger scripts, for instance when your > continuum instance runs remotely from the scm server, you wouldn't > necessarily want your scm admin to have to get the 12mb archive ;) -- 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-1541) NPE with "Provide Release Parameters"
[ http://jira.codehaus.org/browse/CONTINUUM-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1541: Assignee: Emmanuel Venisse > NPE with "Provide Release Parameters" > - > > Key: CONTINUUM-1541 > URL: http://jira.codehaus.org/browse/CONTINUUM-1541 > Project: Continuum > Issue Type: Bug > Components: Release >Affects Versions: 1.1-beta-4 > Environment: Continuum 1.1.-beta-4 > Ubuntu 7 Server >Reporter: Wendy Smoak >Assignee: Emmanuel Venisse > Fix For: 1.1 > > > To reproduce: > 1. Complete 'Prepare for Release' as usual > 2. Choose "Perform project release" > 3. Select "Provide Release Parameters" (rather than selecting the version > number you just prepared) > 4. Fill in the scm credentials and an existing tag, such as 'hello-1.0.3' > 5. Click 'Done' > It should work, but instead you get a NPE: > Error Occurred > java.lang.NullPointerException > Show/hide Stack Trace > java.lang.NullPointerException > at java.util.Hashtable.get(Hashtable.java:336) > at > org.apache.maven.continuum.web.action.ReleaseInProgressAction.execute(ReleaseInProgressAction.java:63) > 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:358) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192) > at > org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > 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:190) > at > org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > 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:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interc
[jira] Updated: (CONTINUUM-1472) No navigation on Project Release Summary page
[ http://jira.codehaus.org/browse/CONTINUUM-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1472: Assignee: Emmanuel Venisse > No navigation on Project Release Summary page > - > > Key: CONTINUUM-1472 > URL: http://jira.codehaus.org/browse/CONTINUUM-1472 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Maria Catherine Tan >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > If you click 'View Output' after Prepare for Release finishes, the only way > to get back from the Project Release Summary page is to use the browser back > button. -- 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: (MCOMPILER-10) display summary information including number of compiler errors when compiler plugin fails.
[ http://jira.codehaus.org/browse/MCOMPILER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113291 ] Thomas Hart commented on MCOMPILER-10: -- I had the same problem in the Maven Integration Plugin for Eclipse. The attached patch shows the compile error messages to the eclipse console. I don't know if this the right issue but it works for me. > display summary information including number of compiler errors when compiler > plugin fails. > --- > > Key: MCOMPILER-10 > URL: http://jira.codehaus.org/browse/MCOMPILER-10 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: John Casey >Priority: Minor > Attachments: logExample.bmp, patch.txt > > -- 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: (MCOMPILER-10) display summary information including number of compiler errors when compiler plugin fails.
[ http://jira.codehaus.org/browse/MCOMPILER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Hart updated MCOMPILER-10: - Attachment: patch.txt > display summary information including number of compiler errors when compiler > plugin fails. > --- > > Key: MCOMPILER-10 > URL: http://jira.codehaus.org/browse/MCOMPILER-10 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: John Casey >Priority: Minor > Attachments: logExample.bmp, patch.txt > > -- 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: (MCOMPILER-10) display summary information including number of compiler errors when compiler plugin fails.
[ http://jira.codehaus.org/browse/MCOMPILER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113292 ] Milos Kleint commented on MCOMPILER-10: --- maybe something wrong with the eclipse embedder code? I'm getting this compilation output when running within netbeans. [compiler:compile] Compiling 5 source files to /home/mkleint/src/mevenide/mevenide2/netbeans/webframeworks/target/classes [ERROR]BUILD FAILURE Compilation failure org/codehaus/mevenide/webframeworks/PanelSupportedFrameworksVisual.java.java:[376,39] cannot find symbol symbol : variable JAVA_EE_SPEC_50_LABEL location: class org.codehaus.mevenide.webframeworks.PanelSupportedFrameworksVisual org/codehaus/mevenide/webframeworks/PanelSupportedFrameworksVisual.java.java:[379,39] cannot find symbol symbol : variable J2EE_SPEC_14_LABEL location: class org.codehaus.mevenide.webframeworks.PanelSupportedFrameworksVisual org/codehaus/mevenide/webframeworks/PanelSupportedFrameworksVisual.java.java:[382,39] cannot find symbol symbol : variable J2EE_SPEC_13_LABEL location: class org.codehaus.mevenide.webframeworks.PanelSupportedFrameworksVisual Total time: 25 seconds Finished at: Fri Nov 09 12:29:05 CET 2007 Final Memory: 130M/254M > display summary information including number of compiler errors when compiler > plugin fails. > --- > > Key: MCOMPILER-10 > URL: http://jira.codehaus.org/browse/MCOMPILER-10 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: John Casey >Priority: Minor > Attachments: logExample.bmp, patch.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-185) Add encoding support
Add encoding support Key: DOXIA-185 URL: http://jira.codehaus.org/browse/DOXIA-185 Project: Maven Doxia Issue Type: Improvement Components: Sink API Affects Versions: 1.0-alpha-10 Reporter: Vincent Siveton -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1472) No navigation on Project Release Summary page
[ http://jira.codehaus.org/browse/CONTINUUM-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1472. --- Resolution: Fixed Done. > No navigation on Project Release Summary page > - > > Key: CONTINUUM-1472 > URL: http://jira.codehaus.org/browse/CONTINUUM-1472 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Maria Catherine Tan >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > If you click 'View Output' after Prepare for Release finishes, the only way > to get back from the Project Release Summary page is to use the browser back > button. -- 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-578) unfinished scanning after NPE
[ http://jira.codehaus.org/browse/MRM-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113304 ] Brett Porter commented on MRM-578: -- what you've done should be as clean as you can get, I think. I don't get the restart problem - the complaints at the start are about SA and JPOX_ tables which can be safely ignored. If you are getting other problems, then there is certainly something going on where you have a database still in use somehow. looking at the exceptions it seems to indicate a race condition. I can't see what would cause it though - so one thing to try might be to avoid any interaction with the web interface during the initial scan. We should spend some time investigating this - but I'm inclined to move it post 1.0... wdyt? > unfinished scanning after NPE > - > > Key: MRM-578 > URL: http://jira.codehaus.org/browse/MRM-578 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-beta-3 > Environment: macosx 1.4, jdk 1.5, archiva beta3 >Reporter: Milos Kleint > Fix For: 1.0 > > Attachments: error.txt, error2.txt > > > I repeatedly tried to index a mirror of central repository. In previous > attempts, usually got "Too many files opened" kind of errors. This time it's > a NPE, see attached console output -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1541) NPE with "Provide Release Parameters"
[ http://jira.codehaus.org/browse/CONTINUUM-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1541. --- Resolution: Fixed Fixed. > NPE with "Provide Release Parameters" > - > > Key: CONTINUUM-1541 > URL: http://jira.codehaus.org/browse/CONTINUUM-1541 > Project: Continuum > Issue Type: Bug > Components: Release >Affects Versions: 1.1-beta-4 > Environment: Continuum 1.1.-beta-4 > Ubuntu 7 Server >Reporter: Wendy Smoak >Assignee: Emmanuel Venisse > Fix For: 1.1 > > > To reproduce: > 1. Complete 'Prepare for Release' as usual > 2. Choose "Perform project release" > 3. Select "Provide Release Parameters" (rather than selecting the version > number you just prepared) > 4. Fill in the scm credentials and an existing tag, such as 'hello-1.0.3' > 5. Click 'Done' > It should work, but instead you get a NPE: > Error Occurred > java.lang.NullPointerException > Show/hide Stack Trace > java.lang.NullPointerException > at java.util.Hashtable.get(Hashtable.java:336) > at > org.apache.maven.continuum.web.action.ReleaseInProgressAction.execute(ReleaseInProgressAction.java:63) > 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:358) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192) > at > org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > 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:190) > at > org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > 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:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.intercept
[jira] Created: (MAVENUPLOAD-1806) rsync request: gr.abiss
rsync request: gr.abiss Key: MAVENUPLOAD-1806 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1806 Project: maven-upload-requests Issue Type: Bug Reporter: Manos Batsis Attachments: gr.abiss.sh Hello, This is an rsync request. You can verify I'm (Manos Batsis) a team member in all projects of dev.abiss.gr by checking out the m2 team report for each project (I'm also a co-fouder of Abiss.gr), for example [1]. Our releases repo is at [2] and our OS project list at [3]. Anyway, have not done this before so tried to work out a basic, non-ssh version of the script (attached), hope it works :-) [1] http://dev.abiss.gr/md4j/team-list.html [2] http://dev.abiss.gr/m2repo/releases [3] http://dev.abiss.gr Thanks, Manos -- 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: (SUREFIRE-335) forkMode = none is incompatible with useSystemClassLoader = true
[ http://jira.codehaus.org/browse/SUREFIRE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113322 ] Marat Radchenko commented on SUREFIRE-335: -- Well, actually it cannot be compatible (and stable) because you cannot modify bootclasspath of JVM you're running in. The only way you can modify bootclasspath is to fork another JVM. However I wonder, what JVMs require useSystemClassLoader trick? > forkMode = none is incompatible with useSystemClassLoader = true > > > Key: SUREFIRE-335 > URL: http://jira.codehaus.org/browse/SUREFIRE-335 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.3.1 > > > these options are obviously not compatible as the method of implementation of > the latter requires forking. An alternate implementation should be used that > includes the system class loader > However, the following occurs in Archiva: > Caused by: java.lang.ClassNotFoundException: > org.apache.maven.archiva.configuration.ArchivaConfigurationTest > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at > org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:87) > ... 27 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113321 ] Elias Ross commented on MRELEASE-173: - I'm 100% for this patch. All our builds are automated by Quickbuild and it is ridiculous to have to pipe in input from a file to supply the versioning information. > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113325 ] Christophe Lallement commented on SCM-317: -- Hello I can see thst the issue depend on MRELEASE-189 . It's not the truth, it's opposite. I have made a path to add cvs edit feature The patch is based on the 1.0 released (svn tag). In fix impact the 3 project: * maven-scm-provider-cvs-commons * maven-scm-provider-cvsexe * maven-scm-provider-cvsjava I have tested the both mode (native and command line) with success. In fact the fix is in 2 parts: 1/ add the features into maven scm cvs plugins 2/ make a little patch because javacvs (netbeans) provide a default cvs command factory which does not include edit !!! (even the Edit command is present in the library. let me know if you planne ti include this in a next release. Regards Christophe PS: it's the first time i create a svn patch, if you want i can attach the complete source. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.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: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lallement updated SCM-317: - Attachment: provider-cvs-with-edit.patch diff with 1.0 tag > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-161) performRelease=true breaks install/deploy with multimodule projects
[
http://jira.codehaus.org/browse/MJAVADOC-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113324
]
Francois Fernandes commented on MJAVADOC-161:
-
I can verify that this issue is caused due to the maven-javadoc-plugin. Thank
you Sebastian for your note! Whithout this a release of our software wouldn't
be possible using the release plugin. I think this problem correlates to
MJAVADOC-137
> performRelease=true breaks install/deploy with multimodule projects
> ---
>
> Key: MJAVADOC-161
> URL: http://jira.codehaus.org/browse/MJAVADOC-161
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Julien HENRY
> Attachments: unTest.zip
>
>
> Hi,
> To build my project, I use:
> mvn clean install -DperformRelease=true
> In a multimodule project, it doesn't work if all dependencies are not already
> in the local repository.
> Step to reproduce:
> 1) create a multimodule project with moduleA and moduleB. moduleA depends on
> moduleB.
> 2) Hit mvn clean install: should work
> 3) Clean your local repository (remove moduleA and moduleB)
> 4) Hit mvn clean install -DperformRelease=true:
> {quote}
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO] Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
> [INFO] Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory D:\test\unTest\target
> [INFO] Deleting directory D:\test\unTest\target\classes
> [INFO] Deleting directory D:\test\unTest\target\test-classes
> [INFO] Deleting directory D:\test\unTest\target\site
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO] [source:jar {execution: attach-sources}]
> [INFO] Preparing javadoc:jar
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO] snapshot com.capgemini:moduleB:1.0-SNAPSHOT: checking for updates from
> illiade-maven-repository-snapshots
> Downloading:
> http://illiade.sud.capgemini.fr/maven2-snapshots/com/capgemini/moduleB/1.0-SNAPSHOT/moduleB-1.0-SNAPSHOT.jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) com.capgemini:moduleB:jar:1.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.capgemini -DartifactId=moduleB \
> -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) com.capgemini:moduleA:jar:1.0-SNAPSHOT
> 2) com.capgemini:moduleB:jar:1.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> com.capgemini:moduleA:jar:1.0-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> illiade-maven-repository-snapshots
> (http://illiade.sud.capgemini.
[jira] Updated: (DOXIA-160) Book output in doc-book format is not well formed
[ http://jira.codehaus.org/browse/DOXIA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-160: Attachment: mylyn-context.zip > Book output in doc-book format is not well formed > - > > Key: DOXIA-160 > URL: http://jira.codehaus.org/browse/DOXIA-160 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > Fix For: 1.0-beta-1 > > Attachments: DOXIA-160.patch, mylyn-context.zip > > > I tried using the output from a book in doc-book to run it through a > postprocesing step with docbook and found that it barfed on the source > generated by doxia. Not surprising when you consider that it is not well > formed, e.g. it has two <<>> headers in it, and no root element: > +--- > > BarThis is bar > > > > SpamThis is spam > > > > +--- > When I changed it to this it worked better > +--- > "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";> > > BarThis is bar > > > SpamThis is spam > > > > +--- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-160) Book output in doc-book format is not well formed
[ http://jira.codehaus.org/browse/DOXIA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-160: Attachment: DOXIA-160.patch Patch (DOXIA-160.patch) attached. Splits DocBook Book generation into a separate Sink in the book module, following the pattern of Xhtml. There are some outstanding tasks for tidying up which I will raise separately since they might or might not be valid and/or doable. > Book output in doc-book format is not well formed > - > > Key: DOXIA-160 > URL: http://jira.codehaus.org/browse/DOXIA-160 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > Fix For: 1.0-beta-1 > > Attachments: DOXIA-160.patch, mylyn-context.zip > > > I tried using the output from a book in doc-book to run it through a > postprocesing step with docbook and found that it barfed on the source > generated by doxia. Not surprising when you consider that it is not well > formed, e.g. it has two <<>> headers in it, and no root element: > +--- > > BarThis is bar > > > > SpamThis is spam > > > > +--- > When I changed it to this it worked better > +--- > "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";> > > BarThis is bar > > > SpamThis is spam > > > > +--- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-166) Book output ignores book, chapter and section titles
[ http://jira.codehaus.org/browse/DOXIA-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113330 ] Dave Syer commented on DOXIA-166: - N.B. the patch for DOXIA-160 fixes all these issues as well for DocBook output. Maybe someone else has some opinions on the other formats? > Book output ignores book, chapter and section titles > > > Key: DOXIA-166 > URL: http://jira.codehaus.org/browse/DOXIA-166 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > Fix For: 1.0-beta-1 > > Attachments: docbook-test-patch.txt > > > Book output ignores book, chapter and section titles (for xhtml and doc-book > at least). For PDF the chapter titles are used but not the book or sections. > Maybe this is intentional (but then what are they there for in the book > model)? At least there should be some configuration to switch on/off titles? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-251) expression in a POM cannot be updated during release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113332 ] Nick Stolwijk commented on MRELEASE-251: I can reproduce it with a fresh checkout of the maven-2.0.x branch, but when I update the maven-release-plugin to 2.0-beta-8-SNAPSHOT. (Latest checkout of the release plugin) this is not reproducible. > expression in a POM cannot be updated during release:prepare > > > Key: MRELEASE-251 > URL: http://jira.codehaus.org/browse/MRELEASE-251 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Brett Porter >Priority: Critical > Fix For: 2.0 > > > eg. > The artifact (org.apache.maven:maven-error-diagnostics) requires a different > version (2.0.7) than what is found (2.0.7) for the expression (mavenVersion) > in the project (org.apache.maven:maven). > This is achieved by running mvn -DdryRun=true release:prepare on the > maven-2.0.x branch and selecting "2.0.7" as the release version for all, > "maven-2.0.7" as the tag and "2.0.8-SNAPSHOT" as the next version for them > all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1807) Sync-Script for liquibase
Sync-Script for liquibase - Key: MAVENUPLOAD-1807 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1807 Project: maven-upload-requests Issue Type: Task Reporter: Nathan Voxland Attachments: org.liquibase.sh I have created a sync script for LiquiBase (http://www.liquibase.org) Let me know if there are any problems -- 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-1555) Password set by Administrator is not verified against security rules
Password set by Administrator is not verified against security rules Key: CONTINUUM-1555 URL: http://jira.codehaus.org/browse/CONTINUUM-1555 Project: Continuum Issue Type: Bug Reporter: Andreas Guther I have created user accounts using an administration account. The password entered here is not verified against the security rules (at least one number). I entered simple passwords and enabled that the user has to change the password. User complained that their given password does not work. It appears that Continuum is not accepting the password if it does not follow the rules during logon check. Expected: The admin user set-up must have the same password validation checks as for the normal users when they change their password. I am not sure if my impression is correct that the logon does not validate the password against the system if the password does not conform with the password pattern rules. But if that is the case, the system should not validate the password during logon against the rule. It should only check the password against the stored one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-317: - Description: (was: I'll look at it in details later (I don't know when) but it seems to be good, so I'll can include it.) I'll look at it in details later (I don't know when) but it seems to be good, so I'll can include it. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.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: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-317: - Description: I'll look at it in details later (I don't know when) but it seems to be good, so I'll can include it. > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse > Fix For: 1.x > > Attachments: provider-cvs-with-edit.patch > > > I'll look at it in details later (I don't know when) but it seems to be good, > so I'll can include it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-160) Book output in doc-book format is not well formed
[ http://jira.codehaus.org/browse/DOXIA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113338 ] Lukas Theussl commented on DOXIA-160: - Dave, I can't apply this patch, something's wrong with the directory structure. Did you create it wrt current svn trunk? > Book output in doc-book format is not well formed > - > > Key: DOXIA-160 > URL: http://jira.codehaus.org/browse/DOXIA-160 > Project: Maven Doxia > Issue Type: Bug > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer > Fix For: 1.0-beta-1 > > Attachments: DOXIA-160.patch, mylyn-context.zip > > > I tried using the output from a book in doc-book to run it through a > postprocesing step with docbook and found that it barfed on the source > generated by doxia. Not surprising when you consider that it is not well > formed, e.g. it has two <<>> headers in it, and no root element: > +--- > > BarThis is bar > > > > SpamThis is spam > > > > +--- > When I changed it to this it worked better > +--- > "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";> > > BarThis is bar > > > SpamThis is spam > > > > +--- -- 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-570) Documentation to add for war deployment in several container
[ http://jira.codehaus.org/browse/CONTINUUM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-570: --- Description: - Need doc for Jetty - Need doc for Tomcat - Need doc for GlassFish - Need doc for Geronimo - Need doc for Weblogic (if we can access to a server) - Need doc for Websphere (if we can access to a server) - [Add other here] was: - Need doc for Jetty 6 - Need doc for Jetty 5 - Need doc for Tomcat 4 - Need doc for Tomcat 5 - Need doc for Weblogic (if we can access to a server) - Need doc for Websphere (if we can access to a server) - [Add other here] > Documentation to add for war deployment in several container > > > Key: CONTINUUM-570 > URL: http://jira.codehaus.org/browse/CONTINUUM-570 > Project: Continuum > Issue Type: Task > Components: Documentation >Reporter: Emmanuel Venisse > Fix For: 1.1 > > > - Need doc for Jetty > - Need doc for Tomcat > - Need doc for GlassFish > - Need doc for Geronimo > - Need doc for Weblogic (if we can access to a server) > - Need doc for Websphere (if we can access to a server) > - [Add other here] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-570) Documentation to add for war deployment in several container
[ http://jira.codehaus.org/browse/CONTINUUM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111490 ] Emmanuel Venisse edited comment on CONTINUUM-570 at 11/9/07 2:50 PM: - Tomcat: DONE Geronimo: DONE GlassFish: DONE was: Tomcat: DONE Geronimo: DONE > Documentation to add for war deployment in several container > > > Key: CONTINUUM-570 > URL: http://jira.codehaus.org/browse/CONTINUUM-570 > Project: Continuum > Issue Type: Task > Components: Documentation >Reporter: Emmanuel Venisse > Fix For: 1.1 > > > - Need doc for Jetty > - Need doc for Tomcat > - Need doc for GlassFish > - Need doc for Geronimo > - Need doc for Weblogic (if we can access to a server) > - Need doc for Websphere (if we can access to a server) > - [Add other here] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3251) Test fails on windows due to locked files
[ http://jira.codehaus.org/browse/MNG-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3251. --- Assignee: Brian Fox Resolution: Fixed brian fixed it by ignoring failure to delete, since it's in a temp location it should be cleaned out later. > Test fails on windows due to locked files > -- > > Key: MNG-3251 > URL: http://jira.codehaus.org/browse/MNG-3251 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Brian Fox > Fix For: 2.1-alpha-1 > > > maven-core/src/test/java/org/apache/maven/extension/DefaultExtensionManagerTest.java.tearDown > fails on windows, the test-extension-1.jar is locked for deletion > I traced it and seems to get locked at getRealm().findRealmResources( name ) > in org.codehaus.plexus.classworlds.strategy.DefaultStrategy:146 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3251) Test fails on windows due to locked files
[ http://jira.codehaus.org/browse/MNG-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113342 ] Carlos Sanchez commented on MNG-3251: - my concern was not the test but the actual code, if maven locks files it's going to be a problem for long lived processes > Test fails on windows due to locked files > -- > > Key: MNG-3251 > URL: http://jira.codehaus.org/browse/MNG-3251 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Brian Fox > Fix For: 2.1-alpha-1 > > > maven-core/src/test/java/org/apache/maven/extension/DefaultExtensionManagerTest.java.tearDown > fails on windows, the test-extension-1.jar is locked for deletion > I traced it and seems to get locked at getRealm().findRealmResources( name ) > in org.codehaus.plexus.classworlds.strategy.DefaultStrategy:146 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1790) jline 0.9.92
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MAVENUPLOAD-1790. --- Assignee: John Casey Resolution: Fixed done. > jline 0.9.92 > > > Key: MAVENUPLOAD-1790 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1790 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Prud'hommeaux >Assignee: John Casey > > JLine is a popular Java library for handling console input. It is similar in > functionality to BSD editline and GNU readline. People familiar with the > readline/editline capabilities for modern shells (such as bash and tcsh) will > find most of the command editing features of JLine to be familiar. > See also: http://jira.codehaus.org/browse/MAVENUPLOAD-1003 -- 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: (MWAR-130) warSourceExcludes not working for war:inplace
warSourceExcludes not working for war:inplace - Key: MWAR-130 URL: http://jira.codehaus.org/browse/MWAR-130 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0.2 Reporter: Adrian warSourceExcludes appears to work only for war:war but not war:inplace or war:exploded. This would be usefull so JARs aren't put in src/main/webapp/WEB-INF/lib with war:inplace. Related to mails : http://www.nabble.com/-war--warSourceExcludes-not-working-for-war%3Ainplace-tf4773104s177.html#a13654205 and http://www.nabble.com/Is-it-possible-to-customize-maven-war-plugin-so-JARs-aren%27t-put-in-src-main-webapp-WEB-INF-lib-when-using-war%3Ainplace--tf4466701s177.html#a12759424 -- 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-1152) Using multiple Ant projects with Continuum and Perforce SCM - the perforce views are incorrectly created
[ http://jira.codehaus.org/browse/CONTINUUM-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113345 ] Spencer White commented on CONTINUUM-1152: -- I am having this issue as well. I have tried: 1) continuum-plexus-runtime-1.1-alpha-2-bin.tar.gz 2) continuum-plexus-runtime-1.1-beta-1-bin.tar.gz 3) continuum-plexus-runtime-1.1-beta-2-bin.tar.gz 4) apache-continuum-1.1-beta-3.tar.gz 5) apache-continuum-1.1-beta-4.tar.bz2 6) continuum-1.0.3-bin.tar.bz2 I have the same issue. When I look at the client specs that are in the continuum logs, continuum is overwriting the client spec on each run and still updates every file, so it performs a build every time it runs. I see a few references to others having the same problem. Has it been fixed and I don't know how to implement the fix? Thanks. --Spencer > Using multiple Ant projects with Continuum and Perforce SCM - the perforce > views are incorrectly created > > > Key: CONTINUUM-1152 > URL: http://jira.codehaus.org/browse/CONTINUUM-1152 > Project: Continuum > Issue Type: Bug > Components: SCM >Affects Versions: 1.0.3 > Environment: Windows Server 2003 > Ant 1.6.5 > Maven 2.0.4 > Continuum 1.0.3 > JDK 1.5.0_06 >Reporter: Joseph Heck > Fix For: Future > > > Using multiple Ant projects with Continuum and Perforce SCM - the perforce > views are incorrectly created > The first client created automagically works correctly. > The second project generates a client that references the first. From the log > files: > 1052282 [Thread-3] INFO org.apache.maven.continuum.scm.ContinuumScm - > Checking out project: 'GUR - Crc Generator', id: '2' to > 'C:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\2'. > 1052282 [Thread-3] INFO org.apache.maven.scm.manager.ScmManager - Checkout > working directory: > C:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\2 > 1052282 [Thread-3] INFO org.apache.maven.scm.manager.ScmManager - > Executing: p4 client -i > 1052282 [Thread-3] DEBUG org.apache.maven.scm.manager.ScmManager - Updating > clientspec: > Client: > webguest-sepoe-build2-MavenSCM-C:\continuum-1.0.3\apps\continuum\working-directory\1 > Root: C:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\2 > Owner: webguest > View: > //p4-tss/gur/Development/CrcGenerator/1.0/... > //webguest-sepoe-build2-MavenSCM-C:\continuum-1.0.3\apps\continuum\working-directory\1/... > Description: > Created by maven-scm-provider-perforce > This client that has been generated should be references > working-directory\2/... not 1 > Adding a third project shows that it also references the first "client": > 1080922 [Thread-3] INFO org.apache.maven.continuum.scm.ContinuumScm - > Checking out project: 'GUR - Crc Local', id: '3' to > 'C:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\3'. > 1080922 [Thread-3] INFO org.apache.maven.scm.manager.ScmManager - Checkout > working directory: > C:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\3 > 1080922 [Thread-3] INFO org.apache.maven.scm.manager.ScmManager - > Executing: p4 client -i > 1080922 [Thread-3] DEBUG org.apache.maven.scm.manager.ScmManager - Updating > clientspec: > Client: > webguest-sepoe-build2-MavenSCM-C:\continuum-1.0.3\apps\continuum\working-directory\1 > Root: C:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\3 > Owner: webguest > View: > //p4-tss/gur/Development/CrcLocalApi/1.0/... > //webguest-sepoe-build2-MavenSCM-C:\continuum-1.0.3\apps\continuum\working-directory\1/... > Description: > Created by maven-scm-provider-perforce > I haven't yet dug into the code to determine where the client view gets set, > but that appears to be where the mistake is being made. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1808) Javassist 3.6.ga
Javassist 3.6.ga Key: MAVENUPLOAD-1808 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1808 Project: maven-upload-requests Issue Type: Task Reporter: Howard M. Lewis Ship Javassist bytecode library, LGPL/BSD dual license -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1808) Javassist 3.6.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113348 ] Howard M. Lewis Ship commented on MAVENUPLOAD-1808: --- ... but I am a big fan, and Tapestry really leverages Javassist! > Javassist 3.6.ga > > > Key: MAVENUPLOAD-1808 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1808 > Project: maven-upload-requests > Issue Type: Task >Reporter: Howard M. Lewis Ship > > Javassist bytecode library, LGPL/BSD dual license -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2464) [regression] maven 2.1 uses snapshot repository to look for plugins
[ http://jira.codehaus.org/browse/MNG-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-2464. --- Assignee: John Casey Resolution: Fixed Appears to be fixed. See attached test case. While plugin dependencies can be resolved from snapshot repositories, the plugin artifacts themselves only come from release repositories. > [regression] maven 2.1 uses snapshot repository to look for plugins > --- > > Key: MNG-2464 > URL: http://jira.codehaus.org/browse/MNG-2464 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0-alpha-1, 2.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: mvn2.0.4.log, mvn2.1.log, test-plugin-resolution.tar.gz > > > Building components trunk with 2.0.4 and 2.1-SNAPSHOT from > http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113350 ] Benjamin Bentmann commented on MNG-3228: I fear "this behavior is by design". According to John Casey's post at http://www.nabble.com/Profile-inheritance-tf2953156s177.html#a8260582 and some docs at http://docs.codehaus.org/display/MAVEN/Build+Profiles, profiles by themselves are not inherited at all but only their effects after being applied to the POM. Now, when a profile is not inherited, its activation is not inherited, neither. Nevertheless, I would consider profile inheritance useful, too. To name a further use-case, imagine one wants to overwrite certain aspects of a profile for a module POM that inherits from a parent POM. For example, slightly change a plugin configuration that is inherited when the profile is activated. Currently, one needs to redefine the element in the module POM for such a thing to work. But as we all know, copy&paste is bad. > Maven profile activation does not work when profile is defined in inherited > 'parent' pom > > > Key: MNG-3228 > URL: http://jira.codehaus.org/browse/MNG-3228 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: tony nys > Fix For: Reviewed Pending Version Assignment > > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2464) [regression] maven 2.1 uses snapshot repository to look for plugins
[ http://jira.codehaus.org/browse/MNG-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-2464: Attachment: test-plugin-resolution.tar.gz This is a test case to check this issue. See test.sh for setup, execution, and criteria for success. > [regression] maven 2.1 uses snapshot repository to look for plugins > --- > > Key: MNG-2464 > URL: http://jira.codehaus.org/browse/MNG-2464 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0-alpha-1, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > Attachments: mvn2.0.4.log, mvn2.1.log, test-plugin-resolution.tar.gz > > > Building components trunk with 2.0.4 and 2.1-SNAPSHOT from > http://maven.zones.apache.org/~maven/builds/trunk/m2-20060724.103002.tar.gz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3097) Build extension not working if not placed in the pom.xml where a reactor build is initiated
[ http://jira.codehaus.org/browse/MNG-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3097: Affects Version/s: 2.0.x 2.0.4 2.0.5 2.0.6 2.0.7 Fix Version/s: (was: 2.1-alpha-1) 2.x I'm not sure we'll ever have an elegant way to solve this problem. Part of the snag is that extensions by definition change the way the build runs. If the extension is meant to be part of the build, then we have the potential for a chicken-and-egg scenario where the extension is built and then modifies the build to exclude its own module (in the case of a profile activator, for example). In any case, this is not a regression, so I'm moving it a little further out so we can do some discussion and design work. > Build extension not working if not placed in the pom.xml where a reactor > build is initiated > --- > > Key: MNG-3097 > URL: http://jira.codehaus.org/browse/MNG-3097 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.x, 2.1-alpha-1 >Reporter: Vincent Massol > Fix For: 2.x > > > If I have a multi module build and if the build extension is located in one > of the sub modules being built it's ignored. It has to be placed in the > pom.xml where the multi module build is initiated to be taken into account. -- 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-1556) Empty Group Description causes Freemarker error in Group Edit mode
Empty Group Description causes Freemarker error in Group Edit mode
--
Key: CONTINUUM-1556
URL: http://jira.codehaus.org/browse/CONTINUUM-1556
Project: Continuum
Issue Type: Bug
Reporter: Andreas Guther
Cannot edit Group if description field is initially empty. Below copy of email
exchange with more details. I have also attached at the bottom of the entry
the Freemarker error stack.
-Original Message-
From: Andreas Guther [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 4:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [1.1-beta-3] Description: $build.buildDefinition.description
That seems to be a bug. First I think if the description is empty than there
should be an empty entry in the email rather than the variable name.
Then I noticed that when trying to add the description later with Edit under
Group I cannot save the changes but see a huge FreeMarker Template Error stack
in yellow.
I will file a bug on this.
Andreas
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 1:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [1.1-beta-3] Description: $build.buildDefinition.description
Edit the build definition used by your project (project group or project level)
and set the description field.
Emmanuel
Andreas Guther a écrit :
> I see the following line in my build status mail notifications:
>
> Description: $build.buildDefinition.description
>
> It comes up under the Build Definition section. Where is this entry
> defined or missing so I can add the missing content?
>
> Andreas
>
>
>
>
> Build Defintion:
>
>
> POM filename: pom.xml
> Goals: clean install
> Arguments: --batch-mode --non-recursive
> Build Fresh: false
> Always Build: false
> Default Build Definition: true
> Schedule: DEFAULT_SCHEDULE
> Description: $build.buildDefinition.description
>
>
FreeMarker Error Stack
===
FreeMarker template error!
Error on line 48, column 13 in template/simple/select.ftl
stack.findString(parameters.listValue) is undefined.
It cannot be assigned to itemValue
The problematic instruction:
--
==> assignment: itemValue=stack.findString(parameters.listValue) [on line
48, column 13 in template/simple/select.ftl]
in user-directive ww.iterator [on line 40, column 1 in
template/simple/select.ftl]
in include "/${parameters.templateDir}/simple/select.ftl" [on line 2, column 1
in template/default/select.ftl]
--
Java backtrace for programmers:
--
freemarker.core.InvalidReferenceException: Error on line 48, column 13 in
template/simple/select.ftl
stack.findString(parameters.listValue) is undefined.
It cannot be assigned to itemValue
at freemarker.core.Assignment.accept(Assignment.java:111)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.IfBlock.accept(IfBlock.java:82)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.visit(Environment.java:233)
at freemarker.core.UnifiedCall.accept(UnifiedCall.java:116)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.include(Environment.java:1375)
at freemarker.core.Include.accept(Include.java:155)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.process(Environment.java:176)
at freemarker.template.Template.process(Template.java:231)
at
com.opensymphony.webwork.components.template.FreemarkerTemplateEngine.renderTemplate(FreemarkerTemplateEngine.java:126)
at
com.opensymphony.webwork.components.UIBean.mergeTemplate(UIBean.java:642)
at com.opensymphony.webwork.components.UIBean.end(UIBean.java:596)
at
com.opensymphony.webwork.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:21)
at
org.apache.jsp.WEB_002dINF.jsp.projectGroupEdit_jsp._jspx_meth_ww_select_0(projectGroupEdit_jsp.java:698)
at
org.apache.jsp.WEB_002dINF.jsp.projectGroupEdit_jsp._jspx_meth_ww_iterator_0(projectGroupEdit_jsp.java:596)
at
org.apache.jsp.WEB_002dINF.jsp.projectGroupEdit_jsp._jspx_meth_ww_form_0(projectGroupEdit_jsp.java:286)
a
[jira] Commented: (MWAR-94) Skip archivhing if any of resources is older than already existing archive.
[ http://jira.codehaus.org/browse/MWAR-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113353 ] EJ Ciramella commented on MWAR-94: -- We are suffering from the same problem as well - how can we get this addressed? > Skip archivhing if any of resources is older than already existing archive. > --- > > Key: MWAR-94 > URL: http://jira.codehaus.org/browse/MWAR-94 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Olexandr Zakordonskyy > > Add ability to set flag for skipping archiving if any of resources that is > going to be archived is older than already existing archive. This issue is > probably common for all archives. Would be great to get such functionality at > least for war and ear. We are working with large wars, and ear archives and > archiving takes 80% of time, even if nothing was changed. -- 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: (MEJB-24) It should be possible not to include the META-INF/maven directory in produced jars
[ http://jira.codehaus.org/browse/MEJB-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113354 ] EJ Ciramella commented on MEJB-24: -- Because of this behavior, the ejbs ALWAYS get built and installed into the repository. (I've got the same issue right now as well) > It should be possible not to include the META-INF/maven directory in produced > jars > -- > > Key: MEJB-24 > URL: http://jira.codehaus.org/browse/MEJB-24 > Project: Maven 2.x Ejb Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Prasad Kashyap > > http://jira.codehaus.org/browse/MNG-1598 > The in the other archiver plugins exclude the pom and > .properties files from the created archives. If the packaging of a pom is set > to "ejb", then the produced jar still contains these maven descriptors. > My 2.1 maven-jar-plugin is configured to > false. When my pom packaging is set > to "jar", the descriptors does get excluded. > Problem is with the "ejb" packaging and/or maven-ejb-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1556) Empty Group Description causes Freemarker error in Group Edit mode
[
http://jira.codehaus.org/browse/CONTINUUM-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated CONTINUUM-1556:
Fix Version/s: 1.1
> Empty Group Description causes Freemarker error in Group Edit mode
> --
>
> Key: CONTINUUM-1556
> URL: http://jira.codehaus.org/browse/CONTINUUM-1556
> Project: Continuum
> Issue Type: Bug
>Reporter: Andreas Guther
> Fix For: 1.1
>
>
> Cannot edit Group if description field is initially empty. Below copy of
> email exchange with more details. I have also attached at the bottom of the
> entry the Freemarker error stack.
> -Original Message-
> From: Andreas Guther [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 09, 2007 4:40 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [1.1-beta-3] Description: $build.buildDefinition.description
> That seems to be a bug. First I think if the description is empty than there
> should be an empty entry in the email rather than the variable name.
> Then I noticed that when trying to add the description later with Edit under
> Group I cannot save the changes but see a huge FreeMarker Template Error
> stack in yellow.
> I will file a bug on this.
> Andreas
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 09, 2007 1:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [1.1-beta-3] Description: $build.buildDefinition.description
> Edit the build definition used by your project (project group or project
> level) and set the description field.
> Emmanuel
> Andreas Guther a écrit :
> > I see the following line in my build status mail notifications:
> >
> > Description: $build.buildDefinition.description
> >
> > It comes up under the Build Definition section. Where is this entry
> > defined or missing so I can add the missing content?
> >
> > Andreas
> >
> >
> >
> >
> > Build Defintion:
> >
> >
> > POM filename: pom.xml
> > Goals: clean install
> > Arguments: --batch-mode --non-recursive
> > Build Fresh: false
> > Always Build: false
> > Default Build Definition: true
> > Schedule: DEFAULT_SCHEDULE
> > Description: $build.buildDefinition.description
> >
> >
> FreeMarker Error Stack
> ===
> FreeMarker template error!
> Error on line 48, column 13 in template/simple/select.ftl
> stack.findString(parameters.listValue) is undefined.
> It cannot be assigned to itemValue
> The problematic instruction:
> --
> ==> assignment: itemValue=stack.findString(parameters.listValue) [on line
> 48, column 13 in template/simple/select.ftl]
> in user-directive ww.iterator [on line 40, column 1 in
> template/simple/select.ftl]
> in include "/${parameters.templateDir}/simple/select.ftl" [on line 2, column
> 1 in template/default/select.ftl]
> --
> Java backtrace for programmers:
> --
> freemarker.core.InvalidReferenceException: Error on line 48, column 13 in
> template/simple/select.ftl
> stack.findString(parameters.listValue) is undefined.
> It cannot be assigned to itemValue
> at freemarker.core.Assignment.accept(Assignment.java:111)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.IfBlock.accept(IfBlock.java:82)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.MixedContent.accept(MixedContent.java:92)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.Environment.visit(Environment.java:233)
> at freemarker.core.UnifiedCall.accept(UnifiedCall.java:116)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.MixedContent.accept(MixedContent.java:92)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.Environment.include(Environment.java:1375)
> at freemarker.core.Include.accept(Include.java:155)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.MixedContent.accept(MixedContent.java:92)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.Environment.process(Environment.java:176)
> at freemarker.template.Template.process(Template.java:231)
> at
> com.opensymphony.webwork.components.template.FreemarkerTemplateEngine.renderTemplate(FreemarkerTemplateEngine.java:126)
> at
> com.opensymphony.webwork.components.UIBean.mergeTemplate(UIBean.java:642)
> at com.opensymphony.webwork.components.UIBean.end(UIBean.java:596)
> at
> com.opensymphony.webwork.views.jsp.ComponentTagSupport.doEndTa
[jira] Created: (MAVENUPLOAD-1809) Please upload EZMorph-1.0.4
Please upload EZMorph-1.0.4 --- Key: MAVENUPLOAD-1809 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1809 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray EZMorph is simple java library for transforming an Object to another Object. This release covers minor enhancements. -- 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
