[jira] Commented: (MCHANGES-72) Build Failure using IBM JDK 1.4.2 SR7
[ http://jira.codehaus.org/browse/MCHANGES-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89500 ] Joerg Schaible commented on MCHANGES-72: Hint: Caused by: java.lang.NoClassDefFoundError: com/sun/net/ssl/internal/ssl/Provider ;-) > Build Failure using IBM JDK 1.4.2 SR7 > - > > Key: MCHANGES-72 > URL: http://jira.codehaus.org/browse/MCHANGES-72 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-2 > Environment: Windows XP Pro > Maven 2.0.5 > IBM JDK 1.4.2 SR7 >Reporter: Patrick Schneider > Attachments: changes-ibmjdk.txt > > > Attached is the -e output from running 'mvn site:site'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-510) Missing StrutsTestCase for servlet api 2.4
Missing StrutsTestCase for servlet api 2.4 -- Key: MEV-510 URL: http://jira.codehaus.org/browse/MEV-510 Project: Maven Evangelism Issue Type: New Feature Components: Missing POM Reporter: Victor Letunovsky Missing in repository last version of StrutsTestCase 2.1.3 for JSP API 1.2 and Servlet API 2.4. StrutsTestCase hosted on sourceforge.net: http://strutstestcase.sourceforge.net/ (files: http://sourceforge.net/project/showfiles.php?group_id=39190) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2863) Refactor lifecycle executor to allow viewing/modification of a declarative build 'plan'
[ http://jira.codehaus.org/browse/MNG-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89488 ] John Casey commented on MNG-2863: - I've created a branch of trunk, called '2.1-lifecycle-refactor' to do this work without destabilizing trunk itself. The branch can be checked out here: http://svn.apache.org/repos/asf/maven/components/branches/2.1-lifecycle-refactor > Refactor lifecycle executor to allow viewing/modification of a declarative > build 'plan' > --- > > Key: MNG-2863 > URL: http://jira.codehaus.org/browse/MNG-2863 > Project: Maven 2 > Issue Type: New Feature > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: John Casey > Assigned To: John Casey > Fix For: 2.1.x > > > Currently, Maven basically discovers the next step in the build once the last > one is executed, according to profile injection, POM inheritance, lifecycle > mappings, and the default mojos bound to a give lifecycle. The fact that all > of this happens "magically" (completely behind the scenes) makes it quite > difficult to understand how the build will execute ahead of time in some > cases. If a given mojo specifies an @execute annotation, then this can > further confound users trying to understand the build process. > As preparation for adding fine-grained mojo ordering within a phase, as well > as mojo suppression and replacement, we need the ability to see ahead of a > build's execution exactly what steps it will traverse. This should act much > like the effective-pom or effective-settings as a diagnosis tool, and help > users target certain behaviors they want to modify through their POMs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2863) Refactor lifecycle executor to allow viewing/modification of a declarative build 'plan'
[ http://jira.codehaus.org/browse/MNG-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-2863: Assignee: John Casey Fix Version/s: 2.1.x Complexity: Expert (was: Intermediate) > Refactor lifecycle executor to allow viewing/modification of a declarative > build 'plan' > --- > > Key: MNG-2863 > URL: http://jira.codehaus.org/browse/MNG-2863 > Project: Maven 2 > Issue Type: New Feature > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: John Casey > Assigned To: John Casey > Fix For: 2.1.x > > > Currently, Maven basically discovers the next step in the build once the last > one is executed, according to profile injection, POM inheritance, lifecycle > mappings, and the default mojos bound to a give lifecycle. The fact that all > of this happens "magically" (completely behind the scenes) makes it quite > difficult to understand how the build will execute ahead of time in some > cases. If a given mojo specifies an @execute annotation, then this can > further confound users trying to understand the build process. > As preparation for adding fine-grained mojo ordering within a phase, as well > as mojo suppression and replacement, we need the ability to see ahead of a > build's execution exactly what steps it will traverse. This should act much > like the effective-pom or effective-settings as a diagnosis tool, and help > users target certain behaviors they want to modify through their POMs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2863) Refactor lifecycle executor to allow viewing/modification of a declarative build 'plan'
Refactor lifecycle executor to allow viewing/modification of a declarative build 'plan' --- Key: MNG-2863 URL: http://jira.codehaus.org/browse/MNG-2863 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle Affects Versions: 2.0.5 Reporter: John Casey Fix For: 2.1.x Currently, Maven basically discovers the next step in the build once the last one is executed, according to profile injection, POM inheritance, lifecycle mappings, and the default mojos bound to a give lifecycle. The fact that all of this happens "magically" (completely behind the scenes) makes it quite difficult to understand how the build will execute ahead of time in some cases. If a given mojo specifies an @execute annotation, then this can further confound users trying to understand the build process. As preparation for adding fine-grained mojo ordering within a phase, as well as mojo suppression and replacement, we need the ability to see ahead of a build's execution exactly what steps it will traverse. This should act much like the effective-pom or effective-settings as a diagnosis tool, and help users target certain behaviors they want to modify through their POMs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1701) Validate that a plugin is not configured twice in the pom
[ http://jira.codehaus.org/browse/MNG-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89486 ] Duncan McNaught commented on MNG-1701: -- I agree with Kenney - with the exec-maven-plugin I would like to be able to specify different actions on mvn install or mvn deploy. Can you confirm it this issue is going to allow multiple plugin sections for the same plugin, or is it going to validate this isn't possible. > Validate that a plugin is not configured twice in the pom > - > > Key: MNG-1701 > URL: http://jira.codehaus.org/browse/MNG-1701 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Priority: Trivial > Fix For: 2.1.x > > > Check that there're no two elements of the same plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1155) Continuum should be able to use cached username/password credentials when the scm provider supports it
[ http://jira.codehaus.org/browse/CONTINUUM-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89484 ] Wendy Smoak commented on CONTINUUM-1155: Project Information tab -> Edit has a checkbox for "Use SCM Credentials Cache, if available" This option needs to be available when adding a project to Continuum. (For example, on the 'Add Maven 2.0+ project page.) Otherwise, it will be necessary to visit every project and edit it to check the box. > Continuum should be able to use cached username/password credentials when the > scm provider supports it > -- > > Key: CONTINUUM-1155 > URL: http://jira.codehaus.org/browse/CONTINUUM-1155 > Project: Continuum > Issue Type: New Feature > Components: Environmental >Affects Versions: 1.0.3 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Fix For: 1.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-189) plugin not correctly interpolating POM variables like project.build.directory
plugin not correctly interpolating POM variables like project.build.directory
-
Key: MASSEMBLY-189
URL: http://jira.codehaus.org/browse/MASSEMBLY-189
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: I used both released version 2.1 and also 2.2-SNAPSHOT
Reporter: Ray Suliteanu
Priority: Critical
I have a assembly descriptor file with ${project.build.directory} in the
element of a . I get an error "Failed to create assembly: File
to filter not found" because the file path has "${project.build.directory}"
rather than the value of ${project.build.directory}.
I have traced the problem to AssemblyInterpolator.interpolateElementValue(). It
tries to look up build.directory in ReflectionValueExtractor.evaluate() rather
than project.build.directory, and it can't evaluate build.directory. A hack
workaround is ...
if (value == null)
{
try
{
value = ReflectionValueExtractor.evaluate(realExpr, project);
if (value == null)
{
// HACK: strip ${ and } and retry
wholeExpr = wholeExpr.substring(2, wholeExpr.length() - 1);
value = ReflectionValueExtractor.evaluate(wholeExpr, project);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2261) Profiles ignored when working with non-projects (such as archetype:create)
[ http://jira.codehaus.org/browse/MNG-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak reopened MNG-2261: -- Reopening based on comments and ARCHETYPE-66. > Profiles ignored when working with non-projects (such as archetype:create) > -- > > Key: MNG-2261 > URL: http://jira.codehaus.org/browse/MNG-2261 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.4 >Reporter: Joakim Erdfelt > Assigned To: John Casey >Priority: Blocker > Fix For: 2.0.5 > > Attachments: MNG-2261-2.patch, MNG-2261.patch > > > Several conditions have to be met to show this bug. > 1) Be in an environment that does not have access to repo1.maven.org, (such > as a corporate environment) > 2) Have no content in your local repository (a fresh install of maven 2.0.4) > 3) Attempt to use a plugin that has no project requirement (such as > archetype:create) > The plugin fails because access to repo1.maven.org cannot be accessed. > Recommended solution: > Create a settings.xml profile that changes the location of the 'central' > repository to point to an internal resource (such as a maven-proxy > installation). > > > > use_internal > > > central > Internal Central Repository > http://repo.internal.com/maven2 > > true > > > true > > > > > > central > Internal Central Repository > http://repo.internal.com/maven2 > > true > > > true > > > > > > > use_internal > > > Try again. > Still fails. > The reason is that the default behaviour for non-project execution is to use > the maven super pom, however there is a bug with that flow that does not > allow for the merging of the settings.xml 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] Moved: (ARCHETYPE-66) The archetype:create goal ignores activated profiles in local settings.xml
[
http://jira.codehaus.org/browse/ARCHETYPE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak moved MNG-2862 to ARCHETYPE-66:
---
Affects Version/s: (was: 2.0.5)
Complexity: (was: Intermediate)
Key: ARCHETYPE-66 (was: MNG-2862)
Project: Maven Archetype (was: Maven 2)
> The archetype:create goal ignores activated profiles in local settings.xml
> ---
>
> Key: ARCHETYPE-66
> URL: http://jira.codehaus.org/browse/ARCHETYPE-66
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Bruce Snyder
> Attachments: mvn.log
>
>
> Because Incubating projects at the ASF cannot publish releases to the central
> repo, I've created and activated [a profile for the Apache Incubating
> repo|http://incubator.apache.org/servicemix/4-examples.html#4.Examples-Mavenconfiguration].
> But it appears that the {{archetype:create}} goal doesn't recognize this
> profile at all. Below is the command I'm using:
> {panel}
> mvn archetype:create \
> -DarchetypeGroupId=org.apache.servicemix.tooling \
> -DarchetypeArtifactId=servicemix-binding-component \
> -DarchetypeVersion=3.1-incubating \
> -DgroupId=org.apache.servicemix.samples.helloworld.bc \
> -DartifactId=hello-world-bc
> {panel}
> I'm also attaching the debug log output that shows Maven is only searching
> the central repo instead of also searching the Incubating repo listed in the
> profile.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1208) Continuum email notification doesn't have the correct url for log file
Continuum email notification doesn't have the correct url for log file
--
Key: CONTINUUM-1208
URL: http://jira.codehaus.org/browse/CONTINUUM-1208
Project: Continuum
Issue Type: Bug
Components: Notifier - Mail
Affects Versions: 1.0.3
Environment: XP Pro SP2
Reporter: nakees Vivek
Build failure notification send by continuum doesn't have the correct url
to download logs. I believe there is a bug filed for this.
ie "Download as test" doesn't resolve to correct url
for example
if you open link send out my email
http://myserver.com:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/193
download text link point to
http://myserver.com:8080/continuum/servlet/browse?file=$requestUtil.getParameter('id')/${requestUtil.getParameter('buildId')}.log.txt
instead it should point to
http://myserver.com:8080/continuum/servlet/browse?file=1/193.log.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: (MCHANGES-72) Build Failure using IBM JDK 1.4.2 SR7
[ http://jira.codehaus.org/browse/MCHANGES-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89480 ] Dennis Lundberg commented on MCHANGES-72: - This seems plexus related. You probably get this error on other plugins as well. > Build Failure using IBM JDK 1.4.2 SR7 > - > > Key: MCHANGES-72 > URL: http://jira.codehaus.org/browse/MCHANGES-72 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-2 > Environment: Windows XP Pro > Maven 2.0.5 > IBM JDK 1.4.2 SR7 >Reporter: Patrick Schneider > Attachments: changes-ibmjdk.txt > > > Attached is the -e output from running 'mvn site:site'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2862) The archetype:create goal ignores activated profiles in local settings.xml
[
http://jira.codehaus.org/browse/MNG-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder closed MNG-2862.
-
Resolution: Won't Fix
Thanks for the tip, Wendy!
> The archetype:create goal ignores activated profiles in local settings.xml
> ---
>
> Key: MNG-2862
> URL: http://jira.codehaus.org/browse/MNG-2862
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.5
>Reporter: Bruce Snyder
> Attachments: mvn.log
>
>
> Because Incubating projects at the ASF cannot publish releases to the central
> repo, I've created and activated [a profile for the Apache Incubating
> repo|http://incubator.apache.org/servicemix/4-examples.html#4.Examples-Mavenconfiguration].
> But it appears that the {{archetype:create}} goal doesn't recognize this
> profile at all. Below is the command I'm using:
> {panel}
> mvn archetype:create \
> -DarchetypeGroupId=org.apache.servicemix.tooling \
> -DarchetypeArtifactId=servicemix-binding-component \
> -DarchetypeVersion=3.1-incubating \
> -DgroupId=org.apache.servicemix.samples.helloworld.bc \
> -DartifactId=hello-world-bc
> {panel}
> I'm also attaching the debug log output that shows Maven is only searching
> the central repo instead of also searching the Incubating repo listed in the
> profile.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-2862) The archetype:create goal ignores activated profiles in local settings.xml
[
http://jira.codehaus.org/browse/MNG-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89477
]
Wendy Smoak commented on MNG-2862:
--
I don't think archetype looks at settings.xml at all.
You can use -DremoteRepositories=... to retrieve the archetype from an
alternate remote repo during archetype:create.
http://maven.apache.org/plugins/maven-archetype-plugin/create-mojo.html
Then the pom.xml in the created project could have the incubating repository
configured, so that 'mvn install' will work and pull additional artifacts from
that repo.
> The archetype:create goal ignores activated profiles in local settings.xml
> ---
>
> Key: MNG-2862
> URL: http://jira.codehaus.org/browse/MNG-2862
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.5
>Reporter: Bruce Snyder
> Attachments: mvn.log
>
>
> Because Incubating projects at the ASF cannot publish releases to the central
> repo, I've created and activated [a profile for the Apache Incubating
> repo|http://incubator.apache.org/servicemix/4-examples.html#4.Examples-Mavenconfiguration].
> But it appears that the {{archetype:create}} goal doesn't recognize this
> profile at all. Below is the command I'm using:
> {panel}
> mvn archetype:create \
> -DarchetypeGroupId=org.apache.servicemix.tooling \
> -DarchetypeArtifactId=servicemix-binding-component \
> -DarchetypeVersion=3.1-incubating \
> -DgroupId=org.apache.servicemix.samples.helloworld.bc \
> -DartifactId=hello-world-bc
> {panel}
> I'm also attaching the debug log output that shows Maven is only searching
> the central repo instead of also searching the Incubating repo listed in the
> profile.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2862) The archetype:create goal ignores activated profiles in local settings.xml
The archetype:create goal ignores activated profiles in local settings.xml
---
Key: MNG-2862
URL: http://jira.codehaus.org/browse/MNG-2862
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.5
Reporter: Bruce Snyder
Attachments: mvn.log
Because Incubating projects at the ASF cannot publish releases to the central
repo, I've created and activated [a profile for the Apache Incubating
repo|http://incubator.apache.org/servicemix/4-examples.html#4.Examples-Mavenconfiguration].
But it appears that the {{archetype:create}} goal doesn't recognize this
profile at all. Below is the command I'm using:
{panel}
mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-binding-component \
-DarchetypeVersion=3.1-incubating \
-DgroupId=org.apache.servicemix.samples.helloworld.bc \
-DartifactId=hello-world-bc
{panel}
I'm also attaching the debug log output that shows Maven is only searching the
central repo instead of also searching the Incubating repo listed in the
profile.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MCHANGES-72) Build Failure using IBM JDK 1.4.2 SR7
Build Failure using IBM JDK 1.4.2 SR7 - Key: MCHANGES-72 URL: http://jira.codehaus.org/browse/MCHANGES-72 Project: Maven 2.x Changes Plugin Issue Type: Bug Affects Versions: 2.0-beta-2 Environment: Windows XP Pro Maven 2.0.5 IBM JDK 1.4.2 SR7 Reporter: Patrick Schneider Attachments: changes-ibmjdk.txt Attached is the -e output from running 'mvn site:site'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1207) Need to be able to define default build definition used when adding new project
[ http://jira.codehaus.org/browse/CONTINUUM-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89476 ] Wendy Smoak commented on CONTINUUM-1207: Related thread... http://www.nabble.com/Changing-the-goal-of-a-project-t3306596s177.html > Need to be able to define default build definition used when adding new > project > --- > > Key: CONTINUUM-1207 > URL: http://jira.codehaus.org/browse/CONTINUUM-1207 > Project: Continuum > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: thierry lach >Priority: Minor > > The default build definition of "clean install --batch-mode --non-recursive" > is hard coded in DefaultContinuum.java, it should be configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2261) Profiles ignored when working with non-projects (such as archetype:create)
[ http://jira.codehaus.org/browse/MNG-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89473 ] Jason Melnick commented on MNG-2261: This bug needs to be reopened as it still does not work > Profiles ignored when working with non-projects (such as archetype:create) > -- > > Key: MNG-2261 > URL: http://jira.codehaus.org/browse/MNG-2261 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.4 >Reporter: Joakim Erdfelt > Assigned To: John Casey >Priority: Blocker > Fix For: 2.0.5 > > Attachments: MNG-2261-2.patch, MNG-2261.patch > > > Several conditions have to be met to show this bug. > 1) Be in an environment that does not have access to repo1.maven.org, (such > as a corporate environment) > 2) Have no content in your local repository (a fresh install of maven 2.0.4) > 3) Attempt to use a plugin that has no project requirement (such as > archetype:create) > The plugin fails because access to repo1.maven.org cannot be accessed. > Recommended solution: > Create a settings.xml profile that changes the location of the 'central' > repository to point to an internal resource (such as a maven-proxy > installation). > > > > use_internal > > > central > Internal Central Repository > http://repo.internal.com/maven2 > > true > > > true > > > > > > central > Internal Central Repository > http://repo.internal.com/maven2 > > true > > > true > > > > > > > use_internal > > > Try again. > Still fails. > The reason is that the default behaviour for non-project execution is to use > the maven super pom, however there is a bug with that flow that does not > allow for the merging of the settings.xml 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] Created: (CONTINUUM-1207) Need to be able to define default build definition used when adding new project
Need to be able to define default build definition used when adding new project --- Key: CONTINUUM-1207 URL: http://jira.codehaus.org/browse/CONTINUUM-1207 Project: Continuum Issue Type: New Feature Affects Versions: 1.1 Reporter: thierry lach Priority: Minor The default build definition of "clean install --batch-mode --non-recursive" is hard coded in DefaultContinuum.java, it should be configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCHANGELOG-56) Date format not understood by CVS
[
http://jira.codehaus.org/browse/MCHANGELOG-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89471
]
Stefan Seidel commented on MCHANGELOG-56:
-
No, there is only one pair of quotes. I've tried with another CVS version -
with 1.12.9 this works fine. Maybe the date format could be user-configurable,
or just use the second form (with spaces in between).
> Date format not understood by CVS
> -
>
> Key: MCHANGELOG-56
> URL: http://jira.codehaus.org/browse/MCHANGELOG-56
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
> Environment: CVS 1.12.13, Linux 2.6.18-4-xen-686 #1 SMP Thu Jan 25
> 02:34:40 UTC 2007 i686 GNU/Linux
>Reporter: Stefan Seidel
>
> In my pom.xml:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.0-SNAPSHOT
>
> ...
> {code}
> mvn site output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building ReportingsPortlet
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [site:site]
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [INFO] Generate "Change Log" report.
> [INFO] Generating changed sets xml to:
> /home/stefan/workspace/alles/xpm-portal/portlets/Reportings/target/changelog.xml
> [INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log
> -d 2007-01-29T15:46:22+0100<2007-03-01T15:46:22+0100
> [INFO] Working directory:
> /home/stefan/workspace/alles/xpm-portal/portlets/Reportings/src/main/java
> [ERROR] Provider message:
> [ERROR] The cvs command failed.
> [ERROR] Command output:
> [ERROR] cvs [log aborted]: Can't parse date/time: `2007-01-29T15:46:22+0100'
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error is occurred during
> changelog command :
> Command failed.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Feb 28 15:46:22 GMT+01:00 2007
> [INFO] Final Memory: 20M/116M
> [INFO]
>
> {code}
> It is understandable, because this CVS version just does not support this
> strange date format.
> Running
> {code}
> cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log -d "2007-01-29
> 15:46:22 +0100<2007-03-01 15:46:22 +0100"
> {code}
> on the command line instead does work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2861) NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions.
NullPointerException in DefaultArtifactCollector for relocated resolvedArtifacts with different version ranges and available versions. -- Key: MNG-2861 URL: http://jira.codehaus.org/browse/MNG-2861 Project: Maven 2 Issue Type: Bug Components: Artifacts Affects Versions: 2.0.5 Reporter: Micah Whitacre In a remoteRepository that I am populating I have a project. Previously I was deploying artifacts with an old groupId and then decided to switch to having a new more descriptive groupId. For the old groupId I have deployed versions 1.0 and 1.1. For the new groupId I have deployed 1.2 and 2.0. I deployed a relocation POM to the old groupId for the 1.2 version. I also updated the metadata.xml files to include 1.2 as an available version. This way projects using version ranges [1,2) will be able to pick up the newest version. So in the repository I now have: oldgroupId:project:1.0 oldgroupId:project:1.1 oldgroupId:project:1.2 - redirecting to newgroupId:project:1.2 newgroupId:project:1.2 newgroupId:project:2.0 The oldgroupId's metadata lists the available versions as [1.0,1.1,1.2]. The newgroupId's metadata lists the available versions has [1,2]. I have 3 additional projects A, B, C. A depends on B and C. B depends on oldgroupId:project:[1,2). Project B has also finished development and been released so we are avoiding rereleasing it for the groupId change. C depends on newgroupId:project:[2,3). When I try to build project A, Maven dies and gives me the following stack trace. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.NullPointerException at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:168) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:305) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1142) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:374) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Since the key for common dependency is the same it tries to resolve the dependency by restricting the version ranges of the current and previous resolved artifacts. It restricts the previous version to the range of to be [2,3). However since the only available versions are [1.0,1.1,1.2] it cannot find and match and on line 168 it calls toString()
[jira] Commented: (MNG-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89465 ] Sebastien Brunot commented on MNG-1412: --- I've tried the new 2.0.5 version and the problem is still present in my case. For some reasons (that i cannot change), i'm using a library library-patch.jar that redefines a class of library.jar adding some extra methods to it. Whatever the order in which i declare the library-patch.jar and library.jar dependencies of my project, library.jar is always the first one in the classpath. So my project, which expect the patch class from library-patch.jar is not compiling. :-( > dependency sorting in classpath > --- > > Key: MNG-1412 > URL: http://jira.codehaus.org/browse/MNG-1412 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark Hobson > Assigned To: fabrizio giustina > Fix For: 2.1.x > > Attachments: artifact-order_maven-artifact-manager.txt, > artifact-order_maven-artifact.txt, artifact-order_maven-project.txt, > MNG-1412-maven-2.0.x-r507746.patch > > > The .classpath file entries should be ordered by nearest transitiveness (if > that's a word). > For example, I have project A that depends on B that depends on C. The > classpath for A is generated in the order C, B. Ideally the classpath should > be in order of how near they are to the project, i.e. B, C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MRELEASE-131) release:prepare failed in 'cvs ... commit' phase for multi-module build
[
http://jira.codehaus.org/browse/MRELEASE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated MRELEASE-131:
--
Fix Version/s: 2.0-beta-5
> release:prepare failed in 'cvs ... commit' phase for multi-module build
> ---
>
> Key: MRELEASE-131
> URL: http://jira.codehaus.org/browse/MRELEASE-131
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: redhat linux, cvs 1.11.17, maven 2.0.4
>Reporter: Hung Le
> Fix For: 2.0-beta-5
>
>
> I have a multi-module setup
> parent-module
>child-module-1
>child-module-2
>...
> In CVS, they are peer, to establish the parent-child layout, manually first
> check out
> . parent-module (which has only the pom.xml)
> then 'cd to parent-module' and manually check out each of the child
> module (using 'cvs co -d outputDir module_name)
> when I use 'release:prepare', Maven2 failed at the 'commit phase'. After
> playing with the 'cvs commit ...' it appears that changing the order the
> 'list of modified POM's' gives different results. One that allow an OK
> 'commit' involves ordering the list of the modified POM's so that the parent
> POM is first in the list.
> It does look as if this is a cvs-specific issue but if we can do something to
> help as work-around, that will be great. I did quick experiment by modifying
> ScmCommitPhase.java. In method createPomFiles(reactorProjects), sort the list
> before returning and it did let me complete the release:prepare step:
> // [EMAIL PROTECTED]
> System.out.println("preSorted, pomFiles=" + pomFiles);
> boolean sortPomFiles = true;
> if (sortPomFiles) {
> Comparator comp = new Comparator() {
> public int compare(Object o1, Object o2) {
> File f1 = (File) o1;
> File f2 = (File) o2;
> String str1 = f1.getAbsolutePath();
> String str2 = f2.getAbsolutePath();
> int rv = (str1.length() - str2.length());
> if (rv == 0) {
> rv = f1.compareTo(f2);
> }
> return rv;
> }
> };
> Collections.sort(pomFiles, comp);
> }
> System.out.println("postSorted, pomFiles=" + pomFiles);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-131) release:prepare failed in 'cvs ... commit' phase for multi-module build
[
http://jira.codehaus.org/browse/MRELEASE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89463
]
Peter De Velder commented on MRELEASE-131:
--
Same problem, tested this out in cvs (1.11.1p1),
1) Problem reproduced when using option: -d MYCVSROOT,
2) No more problem without option: -d MYCVSROOT
~/maven_parent> cvs -nq update -d
M pom.xml
M child1/pom.xml
M child2/pom.xml
#---
# Problem: parent pom.xml is not committed, together with the child poms
#---
~/maven_parent> cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs/play commit -m
"test" pom.xml child1/pom.xml child2/pom.xml
Checking in admin_focus/pom.xml;
/home/cvs/play/maven_parent/child1/pom.xml,v <-- pom.xml
new revision: 1.81; previous revision: 1.80
done
Checking in focus_core/pom.xml;
/home/cvs/play/maven_parent/child1/pom.xml,v <-- pom.xml
new revision: 1.74; previous revision: 1.73
done
#---
# Problem fixed: No longer using -d option
#---
~/maven_parent> cvs commit -m "test" pom.xml child1/pom.xml child2/pom.xml
Checking in pom.xml;
/home/cvs/play/maven_parent/pom.xml,v <-- pom.xml
new revision: 1.30; previous revision: 1.29
done
Checking in admin_focus/pom.xml;
/home/cvs/play/maven_parent/child1/pom.xml,v <-- pom.xml
new revision: 1.82; previous revision: 1.81
done
Checking in focus_core/pom.xml;
/home/cvs/play/maven_parent/child2/pom.xml,v <-- pom.xml
new revision: 1.75; previous revision: 1.74
done
> release:prepare failed in 'cvs ... commit' phase for multi-module build
> ---
>
> Key: MRELEASE-131
> URL: http://jira.codehaus.org/browse/MRELEASE-131
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: redhat linux, cvs 1.11.17, maven 2.0.4
>Reporter: Hung Le
>
> I have a multi-module setup
> parent-module
>child-module-1
>child-module-2
>...
> In CVS, they are peer, to establish the parent-child layout, manually first
> check out
> . parent-module (which has only the pom.xml)
> then 'cd to parent-module' and manually check out each of the child
> module (using 'cvs co -d outputDir module_name)
> when I use 'release:prepare', Maven2 failed at the 'commit phase'. After
> playing with the 'cvs commit ...' it appears that changing the order the
> 'list of modified POM's' gives different results. One that allow an OK
> 'commit' involves ordering the list of the modified POM's so that the parent
> POM is first in the list.
> It does look as if this is a cvs-specific issue but if we can do something to
> help as work-around, that will be great. I did quick experiment by modifying
> ScmCommitPhase.java. In method createPomFiles(reactorProjects), sort the list
> before returning and it did let me complete the release:prepare step:
> // [EMAIL PROTECTED]
> System.out.println("preSorted, pomFiles=" + pomFiles);
> boolean sortPomFiles = true;
> if (sortPomFiles) {
> Comparator comp = new Comparator() {
> public int compare(Object o1, Object o2) {
> File f1 = (File) o1;
> File f2 = (File) o2;
> String str1 = f1.getAbsolutePath();
> String str2 = f2.getAbsolutePath();
> int rv = (str1.length() - str2.length());
> if (rv == 0) {
> rv = f1.compareTo(f2);
> }
> return rv;
> }
> };
> Collections.sort(pomFiles, comp);
> }
> System.out.println("postSorted, pomFiles=" + pomFiles);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-279) Clearcase scm:update Hangs After Stream Configuration Has Changed (patch included)
[ http://jira.codehaus.org/browse/SCM-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-279: - Fix Version/s: 1.0 > Clearcase scm:update Hangs After Stream Configuration Has Changed (patch > included) > -- > > Key: SCM-279 > URL: http://jira.codehaus.org/browse/SCM-279 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.0-beta-4 > Environment: Windows XP, Maven 2.0.4, JDK 1.4.2_10 > ClearCase version 2003.06.00 (Fri Apr 18 13:06:18 2003) > @(#) MVFS version 2003.06.00 (Mar 24 2003 16:39:07) > cleartool 2003.06.00 (Wed Apr 2 21:00:48 2003) > db_server 2003.06.00 (Fri Mar 28 09:00:29 2003) > VOB database schema version: 54 >Reporter: Dave Blumenfeld >Priority: Critical > Fix For: 1.0 > > Attachments: ClearCaseUpdateCommand.java, DebugOutput.txt, > scm-clearcase-update.patch > > > Maven hangs when running scm:update goal on a Clearcase snapshot view for a > stream that has been rebased (see attached debug output). The same goal works > fine once the view is manually updated to the new configuration. Using a > custom config spec seems to make no difference (though I'm no expert on > config specs). > The project POM includes the following lines: > > scm:clearcase:no_spec > > The hang is caused by the 'cleartool update' command, which requires an extra > argument (-force) to prevent it from displaying the following message and > waiting for input: > The stream's configuration has changed. > This update operation will make the view show the new configuration. > Do you want to update the view now? [yes] > Note that this issue has caused our CruiseControl server to hang, as there > does not seem to be any timeout on the scm:update operation. > A patch is attached, which fixes the problem by adding the -force argument to > the cleartool command. I'll let you guys decide whether there are any other > unwanted side-effects of doing this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1203) java.lang.NullPointerException when saving company details in the "Appearance" configuration
[ http://jira.codehaus.org/browse/CONTINUUM-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1203. --- Resolution: Fixed Fix Version/s: 1.1 > java.lang.NullPointerException when saving company details in the > "Appearance" configuration > - > > Key: CONTINUUM-1203 > URL: http://jira.codehaus.org/browse/CONTINUUM-1203 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 > Environment: AIX >Reporter: apache maillist > Assigned To: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > Attachments: java.lang.NullPointerException.doc > > > Company Details > Enter the details of the company super POM below. If it exists, the > organization name, URL and logo will be read from it. > Group ID: < I enter my company Group ID > > Artifact ID: < I enter my company Artifact ID > > when click "Save" > I get java.lang.NullPointerException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-279) Clearcase scm:update Hangs After Stream Configuration Has Changed (patch included)
[ http://jira.codehaus.org/browse/SCM-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89458 ] Bharat Haria commented on SCM-279: -- We have the same issue as we use Clearcase UCM and multiple teams use different streams (branches) for development and we converge in the Integration stream. Our cruisecontrol service on the integration hangs unless we patch the code using the same mechanism described above. > Clearcase scm:update Hangs After Stream Configuration Has Changed (patch > included) > -- > > Key: SCM-279 > URL: http://jira.codehaus.org/browse/SCM-279 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.0-beta-4 > Environment: Windows XP, Maven 2.0.4, JDK 1.4.2_10 > ClearCase version 2003.06.00 (Fri Apr 18 13:06:18 2003) > @(#) MVFS version 2003.06.00 (Mar 24 2003 16:39:07) > cleartool 2003.06.00 (Wed Apr 2 21:00:48 2003) > db_server 2003.06.00 (Fri Mar 28 09:00:29 2003) > VOB database schema version: 54 >Reporter: Dave Blumenfeld >Priority: Critical > Attachments: ClearCaseUpdateCommand.java, DebugOutput.txt, > scm-clearcase-update.patch > > > Maven hangs when running scm:update goal on a Clearcase snapshot view for a > stream that has been rebased (see attached debug output). The same goal works > fine once the view is manually updated to the new configuration. Using a > custom config spec seems to make no difference (though I'm no expert on > config specs). > The project POM includes the following lines: > > scm:clearcase:no_spec > > The hang is caused by the 'cleartool update' command, which requires an extra > argument (-force) to prevent it from displaying the following message and > waiting for input: > The stream's configuration has changed. > This update operation will make the view show the new configuration. > Do you want to update the view now? [yes] > Note that this issue has caused our CruiseControl server to hang, as there > does not seem to be any timeout on the scm:update operation. > A patch is attached, which fixes the problem by adding the -force argument to > the cleartool command. I'll let you guys decide whether there are any other > unwanted side-effects of doing this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (CONTINUUM-1203) java.lang.NullPointerException when saving company details in the "Appearance" configuration
[ http://jira.codehaus.org/browse/CONTINUUM-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CONTINUUM-1203 started by Emmanuel Venisse. > java.lang.NullPointerException when saving company details in the > "Appearance" configuration > - > > Key: CONTINUUM-1203 > URL: http://jira.codehaus.org/browse/CONTINUUM-1203 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 > Environment: AIX >Reporter: apache maillist > Assigned To: Emmanuel Venisse >Priority: Minor > Attachments: java.lang.NullPointerException.doc > > > Company Details > Enter the details of the company super POM below. If it exists, the > organization name, URL and logo will be read from it. > Group ID: < I enter my company Group ID > > Artifact ID: < I enter my company Artifact ID > > when click "Save" > I get java.lang.NullPointerException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCHANGELOG-56) Date format not understood by CVS
[
http://jira.codehaus.org/browse/MCHANGELOG-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89456
]
Marnix van Bochove commented on MCHANGELOG-56:
--
Is there a relation with this issue:
http://jira.codehaus.org/browse/SCM-187
> Date format not understood by CVS
> -
>
> Key: MCHANGELOG-56
> URL: http://jira.codehaus.org/browse/MCHANGELOG-56
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
> Environment: CVS 1.12.13, Linux 2.6.18-4-xen-686 #1 SMP Thu Jan 25
> 02:34:40 UTC 2007 i686 GNU/Linux
>Reporter: Stefan Seidel
>
> In my pom.xml:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.0-SNAPSHOT
>
> ...
> {code}
> mvn site output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building ReportingsPortlet
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [site:site]
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [INFO] Generate "Change Log" report.
> [INFO] Generating changed sets xml to:
> /home/stefan/workspace/alles/xpm-portal/portlets/Reportings/target/changelog.xml
> [INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log
> -d 2007-01-29T15:46:22+0100<2007-03-01T15:46:22+0100
> [INFO] Working directory:
> /home/stefan/workspace/alles/xpm-portal/portlets/Reportings/src/main/java
> [ERROR] Provider message:
> [ERROR] The cvs command failed.
> [ERROR] Command output:
> [ERROR] cvs [log aborted]: Can't parse date/time: `2007-01-29T15:46:22+0100'
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error is occurred during
> changelog command :
> Command failed.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Feb 28 15:46:22 GMT+01:00 2007
> [INFO] Final Memory: 20M/116M
> [INFO]
>
> {code}
> It is understandable, because this CVS version just does not support this
> strange date format.
> Running
> {code}
> cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/cvs -q log -d "2007-01-29
> 15:46:22 +0100<2007-03-01 15:46:22 +0100"
> {code}
> on the command line instead does work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1205) disable logging of SQL because a warn message is printed in logs for each object not found in database
[ http://jira.codehaus.org/browse/CONTINUUM-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1205. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 > disable logging of SQL because a warn message is printed in logs for each > object not found in database > -- > > Key: CONTINUUM-1205 > URL: http://jira.codehaus.org/browse/CONTINUUM-1205 > Project: Continuum > Issue Type: Task > Components: Web - Configuration >Reporter: Lester Ecarma > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: CONTINUUM-1205.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] Closed: (MRM-288) Error on startup: NPE, configuration can not be null
[ http://jira.codehaus.org/browse/MRM-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-288. Resolution: Fixed Fix Version/s: 1.0 > Error on startup: NPE, configuration can not be null > > > Key: MRM-288 > URL: http://jira.codehaus.org/browse/MRM-288 > Project: Archiva > Issue Type: Bug > Environment: r510897 >Reporter: Lester Ecarma > Assigned To: Brett Porter > Fix For: 1.0 > > > 2007-02-23 18:11:34.480::WARN: Failed startup of context [EMAIL > PROTECTED]/,/home/lecarma/workspace/mergere/OSS/apache/archiva/trunk/archiva-webapp/src/main/webapp} > java.lang.NullPointerException: configuration can not be null > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.(CommonsConfigurationRegistry.java:89) > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.getSection(CommonsConfigurationRegistry.java:422) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.addChangeListener(DefaultArchivaConfiguration.java:86) > at > org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.start(DefaultRepositoryTaskScheduler.java:91) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:143) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:87) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:101) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:313) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) > at > org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:54) > at > org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:928) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:876) > at > org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:853) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:222) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:236) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:76) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginWebApplication.start(Jetty6PluginWebApplication.java:147) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.changesDetected(AbstractJettyRunMojo.java:372) > at org.mortbay.jetty.plugin.util.Scanner.run(Scanner.java:159) > This causes a 404 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1203) java.lang.NullPointerException when saving company details in the "Appearance" configuration
[ http://jira.codehaus.org/browse/CONTINUUM-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89447 ] Emmanuel Venisse commented on CONTINUUM-1203: - Please don't use Word document. You can paste in the issue the content or attach a text file. > java.lang.NullPointerException when saving company details in the > "Appearance" configuration > - > > Key: CONTINUUM-1203 > URL: http://jira.codehaus.org/browse/CONTINUUM-1203 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 > Environment: AIX >Reporter: apache maillist >Priority: Minor > Attachments: java.lang.NullPointerException.doc > > > Company Details > Enter the details of the company super POM below. If it exists, the > organization name, URL and logo will be read from it. > Group ID: < I enter my company Group ID > > Artifact ID: < I enter my company Artifact ID > > when click "Save" > I get java.lang.NullPointerException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-288) Error on startup: NPE, configuration can not be null
[ http://jira.codehaus.org/browse/MRM-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89445 ] Emmanuel Venisse commented on MRM-288: -- config-forceCreate doesn't exist in commons-configuration-1.3 > Error on startup: NPE, configuration can not be null > > > Key: MRM-288 > URL: http://jira.codehaus.org/browse/MRM-288 > Project: Archiva > Issue Type: Bug > Environment: r510897 >Reporter: Lester Ecarma > Assigned To: Brett Porter > > 2007-02-23 18:11:34.480::WARN: Failed startup of context [EMAIL > PROTECTED]/,/home/lecarma/workspace/mergere/OSS/apache/archiva/trunk/archiva-webapp/src/main/webapp} > java.lang.NullPointerException: configuration can not be null > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.(CommonsConfigurationRegistry.java:89) > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.getSection(CommonsConfigurationRegistry.java:422) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.addChangeListener(DefaultArchivaConfiguration.java:86) > at > org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.start(DefaultRepositoryTaskScheduler.java:91) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:143) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:87) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:101) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:313) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) > at > org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:54) > at > org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:928) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:876) > at > org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:853) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:222) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:236) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:76) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginWebApplication.start(Jetty6PluginWebApplication.java:147) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.changesDetected(AbstractJettyRunMojo.java:372) > at org.mortbay.jetty.plugin.util.Scanner.run(Scanner.java:159) > This causes a 404 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MRM-288) Error on startup: NPE, configuration can not be null
[ http://jira.codehaus.org/browse/MRM-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-288 started by Brett Porter. > Error on startup: NPE, configuration can not be null > > > Key: MRM-288 > URL: http://jira.codehaus.org/browse/MRM-288 > Project: Archiva > Issue Type: Bug > Environment: r510897 >Reporter: Lester Ecarma > Assigned To: Brett Porter > > 2007-02-23 18:11:34.480::WARN: Failed startup of context [EMAIL > PROTECTED]/,/home/lecarma/workspace/mergere/OSS/apache/archiva/trunk/archiva-webapp/src/main/webapp} > java.lang.NullPointerException: configuration can not be null > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.(CommonsConfigurationRegistry.java:89) > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.getSection(CommonsConfigurationRegistry.java:422) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.addChangeListener(DefaultArchivaConfiguration.java:86) > at > org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.start(DefaultRepositoryTaskScheduler.java:91) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:143) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:87) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:101) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:313) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) > at > org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:54) > at > org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:928) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:876) > at > org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:853) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:222) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:236) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:76) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginWebApplication.start(Jetty6PluginWebApplication.java:147) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.changesDetected(AbstractJettyRunMojo.java:372) > at org.mortbay.jetty.plugin.util.Scanner.run(Scanner.java:159) > This causes a 404 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MVERIFIER-4) Feature request
Feature request
--
Key: MVERIFIER-4
URL: http://jira.codehaus.org/browse/MVERIFIER-4
Project: Maven 2.x Verifier Plugin
Issue Type: New Feature
Reporter: Olle Hallin
I would like to verify that my filtered resources like properties files are
free from unexpanded placeholders.
In theory, this is possible to to with regexp, but it
would be much simpler and more intuitive to do with
\$\{.*\}
(Compare to grep -v)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-289) configuration NPE failed to start application trunk rev 511355
[ http://jira.codehaus.org/browse/MRM-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-289. Assignee: Brett Porter Resolution: Duplicate > configuration NPE failed to start application trunk rev 511355 > -- > > Key: MRM-289 > URL: http://jira.codehaus.org/browse/MRM-289 > Project: Archiva > Issue Type: Bug > Environment: all >Reporter: Olivier Lamy > Assigned To: Brett Porter > Attachments: MRM-289 > > > Due to a NPE in plexus-registry-commons PLXCOMP-60. > The app failed to start. > Then a change must be apply to prevent NPE in archiva-configuration. > in plexus.xml in archiva-plexus-runtime, a dataSource is missing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1206) registration validation eamil sender shows as From: "[EMAIL PROTECTED]"
[
http://jira.codehaus.org/browse/CONTINUUM-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-1206.
---
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: 1.1
already fixed in plexus-security.
You can configure your own address in security.properties with
email.from.address property
> registration validation eamil sender shows as From: "[EMAIL PROTECTED]"
> ---
>
> Key: CONTINUUM-1206
> URL: http://jira.codehaus.org/browse/CONTINUUM-1206
> Project: Continuum
> Issue Type: Bug
> Components: Notifier - Mail
>Affects Versions: 1.1
> Environment: AIX
>Reporter: apache maillist
> Assigned To: Emmanuel Venisse
>Priority: Minor
> Fix For: 1.1
>
>
> is ${user.name} configurable?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
