[jira] Commented: (MNG-5094) If POM's parent is not availabe in local repository then DefaultProjectBuilder is unable to resolve this parent while POM build
[ http://jira.codehaus.org/browse/MNG-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268140#action_268140 ] amaresh mourya commented on MNG-5094: - Any update on this? Thanks, Amaresh If POM's parent is not availabe in local repository then DefaultProjectBuilder is unable to resolve this parent while POM build --- Key: MNG-5094 URL: http://jira.codehaus.org/browse/MNG-5094 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.3 Environment: Linux, Using maven 3.0.3 apis to build a MavenProject from a POM file via DefaultProjectBuilder. Reporter: amaresh mourya I created a maven project via mvn archetype:generate with selection item no as 3. Project I created was abc:xyz:1.0:jar. I am using build( File pomFile, ProjectBuildingRequest request ) method of DefaultProjectBuilder which returns ProjectBuildingResult containing MavenProject of POM file. Here is parent section of POM project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent groupIdcom.cedarsoft/groupId artifactIdopen/artifactId version4.0.2/version /parent groupIdabc/groupId artifactIdxyz/artifactId version1.0/version --- /project Problem: My local repository doesn't contain com.cedarsoft:open:4.0.2. So while building with this build method I was expecting it to download parent (com.cedarsoft:open:4.0.2) and move ahead with the building work, but it didn't happen. This used to happen with maven 2.2.1 apis using DefaultMavenProjectBuilder. I debugged and found that while resolving parent (com.cedarsoft:open:4.0.2) repositories list is empty whereas it should provide Central repository from Super POM to resolve this parent artifact. This used to happen with maven 2.2.1 apis What I did to avoid this : Either I add central repository in my POM or add Central repository in ProjectBuildingRequest. So I think this is a bug of maven 3.0.3 where its unable to pass central repository while resolving artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-133) Add a configurable parameter to allow retrying deployment
Add a configurable parameter to allow retrying deployment - Key: MDEPLOY-133 URL: http://jira.codehaus.org/browse/MDEPLOY-133 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Components: deploy:deploy, deploy:deploy-file Affects Versions: 2.6 Reporter: Stephen Connolly In quite a number of cases I have had large build releases fail due to a sudden network very temporary outage affecting one upload operation. it would be good if there was a configurable parameter that would allow the user to specify retrying deployment of individual files a couple of times before bombing out with an error. The parameter should default to 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] Closed: (MDEPLOY-133) Add a configurable parameter to allow retrying deployment
[ http://jira.codehaus.org/browse/MDEPLOY-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-133. Resolution: Fixed Fix Version/s: 2.7 Assignee: Stephen Connolly r1126367 Add a configurable parameter to allow retrying deployment - Key: MDEPLOY-133 URL: http://jira.codehaus.org/browse/MDEPLOY-133 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Components: deploy:deploy, deploy:deploy-file Affects Versions: 2.6 Reporter: Stephen Connolly Assignee: Stephen Connolly Fix For: 2.7 In quite a number of cases I have had large build releases fail due to a sudden network very temporary outage affecting one upload operation. it would be good if there was a configurable parameter that would allow the user to specify retrying deployment of individual files a couple of times before bombing out with an error. The parameter should default to 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: (MANTTASKS-219) artifact:dependencies and ant's restrict name resource filtering does not work
artifact:dependencies and ant's restrict name resource filtering does not work
--
Key: MANTTASKS-219
URL: http://jira.codehaus.org/browse/MANTTASKS-219
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.0.10
Environment: SUSE Linux Enterprise Server 10 SP1 (x86_64)
Ant 1.7.0
Reporter: Wim Symons
We have an Ant build file which calls maven-ant-tasks's dependencies to copy a
bunch of dependencies.
Since we need to exclude some of those jars, we used Ant's resource selectors
to restrict the fileset produced by maven-ant-tasks.
A small snippet from our build.xml:
{code:xml}
artifact:pom file=common-core/pom.xml id=pom.core /
target name=deploy-core-jar depends=package-core-jar
artifact:dependencies scopes=compile,runtime pomrefid=pom.core
filesetid=dependencies.core /
copy todir=${clientlib.dir} flatten=true
restrict
fileset refid=dependencies.core /
rsel:not
rsel:or
!-- remove maven-ant-tasks and
yuicompressor and their dependencies --
rsel:name name=**/yui*.jar /
rsel:name name=**/plexus*.jar /
rsel:name name=**/maven*.jar /
rsel:name name=**/wagon*.jar /
rsel:name name=**/ant*.jar /
rsel:name name=**/classworlds*.jar /
rsel:name name=**/backport*.jar /
/rsel:or
/rsel:not
/restrict
/copy
/target
{code}
But when we ran the target, no files at all were copied. After a long time
searching, we stumbled on the fact that it worked when we left out the line
{noformat}rsel:name name=**/maven*.jar /{noformat} Our local Maven
repository was located in {{/home/user/maven-repository}}. As it seems the
pattern given doesn't respect the standard Ant patterns and also matches the
directories in between (as {{maven*}} matches {{maven-repository}}).
As a workaround, we renamed the directory containing the Maven repository to
something that doesn't match any of the used patterns.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTTASKS-219) artifact:dependencies and ant's restrict name resource filtering does not work
[
http://jira.codehaus.org/browse/MANTTASKS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268152#action_268152
]
Wim Symons commented on MANTTASKS-219:
--
Reported bug at https://issues.apache.org/bugzilla/show_bug.cgi?id=51243 as
well.
artifact:dependencies and ant's restrict name resource filtering does not work
--
Key: MANTTASKS-219
URL: http://jira.codehaus.org/browse/MANTTASKS-219
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.0.10
Environment: SUSE Linux Enterprise Server 10 SP1 (x86_64)
Ant 1.7.0
Reporter: Wim Symons
We have an Ant build file which calls maven-ant-tasks's dependencies to copy
a bunch of dependencies.
Since we need to exclude some of those jars, we used Ant's resource selectors
to restrict the fileset produced by maven-ant-tasks.
A small snippet from our build.xml:
{code:xml}
artifact:pom file=common-core/pom.xml id=pom.core /
target name=deploy-core-jar depends=package-core-jar
artifact:dependencies scopes=compile,runtime pomrefid=pom.core
filesetid=dependencies.core /
copy todir=${clientlib.dir} flatten=true
restrict
fileset refid=dependencies.core /
rsel:not
rsel:or
!-- remove maven-ant-tasks and
yuicompressor and their dependencies --
rsel:name name=**/yui*.jar /
rsel:name name=**/plexus*.jar /
rsel:name name=**/maven*.jar /
rsel:name name=**/wagon*.jar /
rsel:name name=**/ant*.jar /
rsel:name name=**/classworlds*.jar /
rsel:name name=**/backport*.jar /
/rsel:or
/rsel:not
/restrict
/copy
/target
{code}
But when we ran the target, no files at all were copied. After a long time
searching, we stumbled on the fact that it worked when we left out the line
{noformat}rsel:name name=**/maven*.jar /{noformat} Our local Maven
repository was located in {{/home/user/maven-repository}}. As it seems the
pattern given doesn't respect the standard Ant patterns and also matches the
directories in between (as {{maven*}} matches {{maven-repository}}).
As a workaround, we renamed the directory containing the Maven repository to
something that doesn't match any of the used patterns.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MGPG-35) Add support for MDEPLOY-133
Add support for MDEPLOY-133 --- Key: MGPG-35 URL: http://jira.codehaus.org/browse/MGPG-35 Project: Maven 2.x GPG Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Stephen Connolly Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MGPG-36) Add suport for MDEPLOY-48
Add suport for MDEPLOY-48 - Key: MGPG-36 URL: http://jira.codehaus.org/browse/MGPG-36 Project: Maven 2.x GPG Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Stephen Connolly Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MGPG-36) Add suport for MDEPLOY-48
[ http://jira.codehaus.org/browse/MGPG-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MGPG-36. Fix Version/s: 1.3 Resolution: Fixed r1126405 Add suport for MDEPLOY-48 - Key: MGPG-36 URL: http://jira.codehaus.org/browse/MGPG-36 Project: Maven 2.x GPG Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Minor Fix For: 1.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MGPG-35) Add support for MDEPLOY-133
[ http://jira.codehaus.org/browse/MGPG-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MGPG-35. Fix Version/s: 1.3 Resolution: Fixed r1126405 Add support for MDEPLOY-133 --- Key: MGPG-35 URL: http://jira.codehaus.org/browse/MGPG-35 Project: Maven 2.x GPG Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Stephen Connolly Assignee: Stephen Connolly Priority: Minor Fix For: 1.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-53) Should return an error when deploying a version of SNAPSHOT
[
http://jira.codehaus.org/browse/MDEPLOY-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MDEPLOY-53.
---
Resolution: Not A Bug
I think this is a misunderstanding of how version numbers work in Maven 2+
Should return an error when deploying a version of SNAPSHOT
---
Key: MDEPLOY-53
URL: http://jira.codehaus.org/browse/MDEPLOY-53
Project: Maven 2.x Deploy Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Kristof Van Cleemput
The snapshot that I want to use in a maven2 project is created by maven1.
So I deployed it with the following command:
mvn deploy:deploy-file -DgroupId=GROUP -DartifactId=ARTIFACT
-Dversion=SNAPSHOT -Dpackaging=jar -Dfile=ARTIFACT -SNAPSHOT.jar
-DrepositoryId=REPO-Durl=scp://REPO/maven2/dev
This is NOT correct for maven 2 it should state -Dversion=x.x-SNAPSHOT but
everything just deployed without errors.
Later when using ${baseVersion} it doesn't return SNAPSHOT but the number
After cleaning the repo and redeploying the jar with x.x-SNAPHOT everything
worked like it should = ${baseVersion} returns x.x-SNAPSHOT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MDEPLOY-75) uniqueVersion, includeAttachedArtifacts
[
http://jira.codehaus.org/browse/MDEPLOY-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MDEPLOY-75.
---
Resolution: Won't Fix
A pom based project has http://maven.apache.org/pom.html#Repository which
allows specification of the uniqueVersion parameter in
/project/distributionManagement/snapshotRepository
There is no need for the deploy goal of the maven-deploy-plugin to have this
parameter.
The other feature you were looking for goes against the whole spirit of the
lifecycle, but if you still want it considered please raise it in a separate
JIRA (keep one issue per JIRA)
uniqueVersion, includeAttachedArtifacts
---
Key: MDEPLOY-75
URL: http://jira.codehaus.org/browse/MDEPLOY-75
Project: Maven 2.x Deploy Plugin
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Francis Korning
Attachments: MDEPLOY-75-patch.zip
by default the maven deploy plugin is inconsistent in its use of the
uniqueVersion flag, which can be set manually in the explicit deploy-file
goal but isn't present in the implicit deploy goal.
another thing we'd like to do is disabling the deployment of deliverable
attached artifacts, or allowing to select only specific artifacts,
classifiers, or assemblies. for deployment.
new configuration parameters include:
|| parameter || type || default || description ||
| uniqueVersion | boolean | true | use uniqueVersion
buildnumbers (${artifactId}-mmdd-HHmmss-nn) |
| includeAttachedArtifacts| boolean | true | also deploy attached
artifacts |
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MDEPLOY-117) Use GAV from specified pomFIle but not deploy the pom
[ http://jira.codehaus.org/browse/MDEPLOY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-117. Resolution: Duplicate MDEPLOY-48 is essentially a duplicate of a large chunk of this issue and the previously linked issue covers the remainder Use GAV from specified pomFIle but not deploy the pom - Key: MDEPLOY-117 URL: http://jira.codehaus.org/browse/MDEPLOY-117 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Components: deploy:deploy-file Affects Versions: 2.4 Environment: Windows XP Sun Java JDK 1.6.0_18 Maven 3.0-alpha6 Reporter: Anders Hammar For or MRM (Nexus) we have redeployment turned off. When deploying a lot of 3rd party artifacts to it, we do that by a script using the deploy-file goal. This works just fine for the jar artifact, but when the artifact is just a pom or when also trying to deploying a sources artifact, we want to use GAV from a specified pom. However, deploy-file will then also try to deploy the pom which makes the plugin fail as redeployment is turned off. I'll explain through a simple example: We have a pom artifact that we want to deploy. We do that like this: mvn deploy:deploy-file -Dfile=abc.pom -DpomFile=abc.pom -DrepositoryId=... -Durl=... We want to use GAV from the POM and not specify that through params. Otherwise we need to parse the pom for that info, which is difficult in Windows. What happens is that the pom artifact deploys fine, but then plugin also tries to deploy the pom which then fails as reployment is turned off in the repo. This makes it very hard to see if the script executes ok or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-95) Rename plugin (and life-cycle phase) from Deploy to Publish
[ http://jira.codehaus.org/browse/MDEPLOY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MDEPLOY-95. --- Resolution: Won't Fix These are standardized names from the Maven world. I agree that better names should have been chosen, but we are where we are and they are what they are Rename plugin (and life-cycle phase) from Deploy to Publish --- Key: MDEPLOY-95 URL: http://jira.codehaus.org/browse/MDEPLOY-95 Project: Maven 2.x Deploy Plugin Issue Type: Wish Reporter: Neil Crow Priority: Minor Developers often speak about deploying their application to this server or that server, which does not correspond to the usage that maven has for Deploy. To remedy this situation, and to reduce confusion due to overloaded usage (Fallacy of Equivocation), I suggest that the Deploy plugin and related life-cycle phase be renamed to the Publish plugin. A quick google on maven deploy publish shows that many people out there are using the Deploy plugin to Publish artifacts to a maven repository. After Publishing to a maven repository, they will deploy to a server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-124) Deploy without build
[
http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268170#action_268170
]
Stephen Connolly commented on MDEPLOY-124:
--
so this would be a pair of goals, e.g.
deploy:imprint (which takes persists all the attached artifacts and I'm
guessing checksums of them for safety to a file in ${project.build.directory})
deploy:publish (which reads back in the persisted artifact file and publishes
those artifacts)
Deploy without build
Key: MDEPLOY-124
URL: http://jira.codehaus.org/browse/MDEPLOY-124
Project: Maven 2.x Deploy Plugin
Issue Type: New Feature
Reporter: Paul Gier
We have a use case where we would like to run a build (up to the install
phase) and then deploy at a later time. Currently, the deploy plugin
requires that a full build be re-run in order to deploy. Since the build
does not record the list of attached artifacts, the deploy plugin would need
some way to record the list of attached artifacts, and then read them later
for deployment.
Possibly a new goal could be introduced which would create a list of attached
artfiacts. Then the deploy goal could optionally read from this list.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MDEPLOY-124) Deploy without build
[ http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268171#action_268171 ] Wendy Smoak commented on MDEPLOY-124: - It sounds like the release staging feature of one of the various artifact repositories would be useful here. You deploy to one place, do whatever, and then promote the release later. Deploy without build Key: MDEPLOY-124 URL: http://jira.codehaus.org/browse/MDEPLOY-124 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Reporter: Paul Gier We have a use case where we would like to run a build (up to the install phase) and then deploy at a later time. Currently, the deploy plugin requires that a full build be re-run in order to deploy. Since the build does not record the list of attached artifacts, the deploy plugin would need some way to record the list of attached artifacts, and then read them later for deployment. Possibly a new goal could be introduced which would create a list of attached artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSITE-584) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSITE-584) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/MSITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268172#action_268172
]
Aaron Digulla commented on MSITE-584:
-
Here is the full stack trace:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
project ExBib: Error during site generation: error in opening zip file - [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
project ExBib: Error during site generation
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during site
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:131)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:127)
at java.util.zip.ZipFile.init(ZipFile.java:144)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.createContextForSkin(DefaultSiteRenderer.java:616)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:312)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:138)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
... 21 more
{code}
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSITE-584) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/MSITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268173#action_268173
]
Aaron Digulla commented on MSITE-584:
-
Please add a {{try/catch}} in {{createContextForSkin()}} that adds the file
name to the error message (with absolute path).
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-431) Doxia creates illegal URLs from local paths
Doxia creates illegal URLs from local paths --- Key: DOXIA-431 URL: http://jira.codehaus.org/browse/DOXIA-431 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 1.2 Reporter: Aaron Digulla If a local resource contains characters which are illegal in a URL, Doxia creates illegal code or crashes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-431) Doxia creates illegal URLs from local paths
[
http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268177#action_268177
]
Aaron Digulla commented on DOXIA-431:
-
In an external project, there are image files which contain spaces. Instead of
replacing the spaces with %20 or calling {{java.net.URLEncoder.encode()}},
Doxia tries to call {{new java.net.URL(images/The ExTeX Project.png}} which
fails.
I tried a fix but couldn't get it to work in a couple of hours. The problem is
that you use a lot of Strings when you should be using URLs (or at least a
URL-like type). Without such a type, it's impossible to know when a URL must be
encoded/decoded.
Example stacktrace:
{code}
Caused by: java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:842)
at
org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.init(URIPathDescriptor.java:69)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:361)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseBannerPaths(DefaultDecorationModelInheritanceAssembler.java:162)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:61)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1221)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:458)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:285)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:140)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:124)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
... 20 more
Caused by: java.net.URISyntaxException: Illegal character in path at index 10:
images/The ExTeX Project.png
at java.net.URI$Parser.fail(URI.java:2809)
at java.net.URI$Parser.checkChars(URI.java:2982)
at java.net.URI$Parser.parseHierarchical(URI.java:3066)
at java.net.URI$Parser.parse(URI.java:3024)
at java.net.URI.init(URI.java:578)
at java.net.URI.create(URI.java:840)
... 30 more
{code}
Doxia creates illegal URLs from local paths
---
Key: DOXIA-431
URL: http://jira.codehaus.org/browse/DOXIA-431
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Aaron Digulla
If a local resource contains characters which are illegal in a URL, Doxia
creates illegal code or crashes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MDEPLOY-124) Deploy without build
[ http://jira.codehaus.org/browse/MDEPLOY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268189#action_268189 ] Paul Gier commented on MDEPLOY-124: --- Maybe instead of a new imprint goal, there could just be an option to the existing deploy goal which would create the list instead of uploading the artifacts. Something like -DprepareForPublish. Then the second goal publish could read the list of files and actually do the deployment. Deploy without build Key: MDEPLOY-124 URL: http://jira.codehaus.org/browse/MDEPLOY-124 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Reporter: Paul Gier We have a use case where we would like to run a build (up to the install phase) and then deploy at a later time. Currently, the deploy plugin requires that a full build be re-run in order to deploy. Since the build does not record the list of attached artifacts, the deploy plugin would need some way to record the list of attached artifacts, and then read them later for deployment. Possibly a new goal could be introduced which would create a list of attached artfiacts. Then the deploy goal could optionally read from this list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268196#action_268196 ] S Daigle commented on SUREFIRE-742: --- Hi Kristian. It's Monday morning here and I tried reproducing the failure on the same machine we were consistently seeing the failure on late last week and its not crashing at the moment. I can get you the -X run if you still like but I dont know if it would help without the error condition. Please let me know and Ill get you what I can. If we can reproduce the problem again, I will get you the information you requested. Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-521) release:perform does not take the settings specified by the -s option
[ http://jira.codehaus.org/browse/MRELEASE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268199#action_268199 ] Christoph Kutzinski commented on MRELEASE-521: -- I've just confirmed that it still happens with release-plugin 2.1. Another workaround is to append -Darguments=-smy_settings_file to the release:perform call. E.g. mvn -smy_settings_file release:prepare release:perform -Darguments=-smy_settings_file See also http://maven.40175.n5.nabble.com/mvn-release-perform-does-not-honor-servers-server-in-alternate-settings-location-td70612.html release:perform does not take the settings specified by the -s option -- Key: MRELEASE-521 URL: http://jira.codehaus.org/browse/MRELEASE-521 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0-beta-7 Reporter: Kay Kay # mvn -s some.custom.settings.xml release:perform does not take the settings. If we copy the same to - ~/.m2/settings.xml # mvn release:perform works fine. Something does not add up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-5099) Issue with properties inherited from parent POM
Issue with properties inherited from parent POM
---
Key: MNG-5099
URL: http://jira.codehaus.org/browse/MNG-5099
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0.3
Environment: java 1.6.0_24
Reporter: Dan Checkoway
This worked absolutely fine in 2.2.1. Fails in 3.0.3.
./deps/pom.xml has:
properties
mysql.connector.version5.1.16/mysql.connector.version
/properties
./library/pom.xml has:
parent
groupIdcom.mycompany/groupId
artifactIdbase/artifactId
version1.0/version
relativePath../deps/pom.xml/relativePath
/parent
...
dependency
groupIdmysql/groupId
artifactIdmysql-connector-java/artifactId
version${mysql.connector.version}/version
scoperuntime/scope
/dependency
./otherlib/pom.xml has:
dependency
groupIdcom.mycompany/groupId
artifactIdmycompany-library/artifactId
version1.0/version
scopecompile/scope
/dependency
cd library
mvn deploy (all good)
cd otherlib
mvn compile (fails)
[ERROR] Failed to execute goal on project mycompany-otherlib: Could not resolve
dependencies for project com.mycompany:mycompany-otherlib:jar:1.0: Failure to
find mysql:mysql-connector-java:jar:${mysql.connector.version} in
http://repo1.maven.org/maven2 was cached in the local repository, resolution
will not be reattempted until the update interval of central has elapsed or
updates are forced - [Help 1]
It's as if it's treating the ${mysql.connector.version} in the runtime
dependency literally, instead of resolving that property.
I can work around this by adding this to library/pom.xml:
properties
mysql.connector.version5.1.16/mysql.connector.version
/properties
Please let me know if I'm missing something simple, but it worked fine without
the workaround in 2.2.1, and this looks like a bug to me!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (DOXIASITETOOLS-60) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl moved MSITE-584 to DOXIASITETOOLS-60:
---
Component/s: (was: site:run)
Site renderer
Affects Version/s: (was: 3.0-beta-3)
1.2
Issue Type: Improvement (was: Bug)
Key: DOXIASITETOOLS-60 (was: MSITE-584)
Project: Maven Doxia Sitetools (was: Maven 2.x and 3.x Site
Plugin)
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: DOXIASITETOOLS-60
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.2
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (DOXIASITETOOLS-60) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268207#action_268207
]
Lukas Theussl commented on DOXIASITETOOLS-60:
-
What skin are you using (mvn site:effective-site)? Can you check if that skin
jar is not corrupt?
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: DOXIASITETOOLS-60
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.2
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268209#action_268209 ] Kristian Rosenvold commented on SUREFIRE-742: - Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one -unlikely- culprit but I'd really like to see a likely culprit that I can understand) So please let me know how this works out, any which direction. Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268209#action_268209 ] Kristian Rosenvold edited comment on SUREFIRE-742 at 5/23/11 1:03 PM: -- Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one /unlikely/ culprit but I'd really like to see a /likely/ culprit that I can understand) So please let me know how this works out, any which direction. was (Author: krosenvold): Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one -unlikely- culprit but I'd really like to see a likely culprit that I can understand) So please let me know how this works out, any which direction. Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268209#action_268209 ] Kristian Rosenvold edited comment on SUREFIRE-742 at 5/23/11 1:04 PM: -- Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one /unlikely/ culprit but I'd really like to see a /likely/ culprit that I can understand) So please let me know how this works out, any which direction. The -X log is only useful when the problem occurs. was (Author: krosenvold): Is there a chance that your snapshot update frequency on nexus could have delayed the distribution of the updated version ? I'll be holding back the release of 2.9 for at least a week due to this issue. I will also go through the relevant code with a fine tooth comb to see if I can understand the root cause of your initial problem (the fix identified one /unlikely/ culprit but I'd really like to see a /likely/ culprit that I can understand) So please let me know how this works out, any which direction. Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (DOXIASITETOOLS-60) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIASITETOOLS-60.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Lukas Theussl
Improved error message:
[r1126622|http://svn.apache.org/viewvc?rev=1126622view=rev]
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: DOXIASITETOOLS-60
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.2
Reporter: Aaron Digulla
Assignee: Lukas Theussl
Fix For: 1.3
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MSITE-585) site-deploy: empty deploy protocol when properties are used
site-deploy: empty deploy protocol when properties are used --- Key: MSITE-585 URL: http://jira.codehaus.org/browse/MSITE-585 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.3 Reporter: Lukas Theussl See http://www.mail-archive.com/dev@maven.apache.org/msg88029.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-431) Doxia creates illegal URLs from local paths
[ http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268215#action_268215 ] Lukas Theussl commented on DOXIA-431: - Can you be more specific: where does this image come from, from an apt/xdoc source file or site.xml? Doxia 1.2 is not used yet in any site release so I assume you are using a snapshot? Is this a regression then? Is it documented somewhere that image/file references may contain spaces (just for my education, I don't think eg that the apt reference is sufficiently precise in many respects)? Doxia creates illegal URLs from local paths --- Key: DOXIA-431 URL: http://jira.codehaus.org/browse/DOXIA-431 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 1.2 Reporter: Aaron Digulla If a local resource contains characters which are illegal in a URL, Doxia creates illegal code or crashes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268216#action_268216 ] S Daigle commented on SUREFIRE-742: --- My nexus server is definitely pulling in your latest version(s). When you initially flagged this for me before, I'm always looking in my Nexus repo and my M2 cache to make sure we're getting the latest/greatest version you post. It could be that there were some code changes on our end since last Friday that could be masking the problem we were seeing. Ill keep my eye on it and if I can get you a -X run of the crash, Ill definitely get it to you. Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268225#action_268225 ] Kristian Rosenvold commented on SUREFIRE-742: - A few potential problems fixed in r1126700 and 1126701 Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-5100) Hints for setting mem options of mavenplug-ins (for parallel builds)
Hints for setting mem options of mavenplug-ins (for parallel builds) - Key: MNG-5100 URL: http://jira.codehaus.org/browse/MNG-5100 Project: Maven 2 3 Issue Type: Improvement Components: Documentation: Guides Affects Versions: 3.0.3 Reporter: Kari J. Niemi (I enabled parallel builds of maven3 for my project in CI server, it was running quite nicely giving me much faster builds for a multi-module build. But... it brought our CI server on it's knees, other projects suffered from this and the CI build server admin bashed me to get back to serial build :D... oh, he's such a nice guy :D...) I did some googling around and found out that in Linux, forking new processes may be extremely slow in case the parent that forks, has a great memory print. Well, in the past I had (of course) optimized my build for maven2 by throwing it more (some? no,no... _lots_ of) memory with MAVEN_OPTS by setting both Xms and Xms to the same huge value, not forgetting the MaxPermSize and PermSize. I suppose this, together with the linux forking feature, might cause the extreme cpu load? And of course the CI server process itself has an even bigger memory print, times ten or something, fortunately I suppose it's not doing so much forking... I suppose the memory tuning should/could be done quite differently when using parallel build feature because the mem is then used in the forked processes which are smaller? So in parallel build I might set those mem options pretty low, I guess? And also I could be setting -client-mode manually -because otherwise jvm would think it should be running in server mode (due to running in server HW. Actually I don't quite understand why jvm anyway decides based on HW whether it should be running in server or client mode - there's no such relation -not every jvm running on server HW is really a server process...) Is there anything that we could be improve in maven/maven documentation in this respect? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-5100) Hints for setting mem options of mavenplug-ins (for parallel builds)
[ http://jira.codehaus.org/browse/MNG-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268239#action_268239 ] Kari J. Niemi commented on MNG-5100: ( If in doubt about forking being slow in Linux: http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html http://www.google.fi/search?q=fork+is+so+slow+on+Linux+is+because+the+default+page+size+is+4kie=utf-8oe=utf-8aq=trls=org.mozilla:fi:officialclient=firefox-a https://github.com/rtomayko/posix-spawn#readme http://stackoverflow.com/questions/2731531/faster-forking-of-large-processes-on-linux/2874009#2874009 http://kirkwylie.blogspot.com/2008/11/linux-fork-performance-redux-large.html http://kirkwylie.blogspot.com/2008/10/linux-less-terrible-choice-for-java.html http://kirkwylie.blogspot.com/2008/09/solaris-10-terrible-choice-for-java.html#disqus_thread ) Hints for setting mem options of mavenplug-ins (for parallel builds) - Key: MNG-5100 URL: http://jira.codehaus.org/browse/MNG-5100 Project: Maven 2 3 Issue Type: Improvement Components: Documentation: Guides Affects Versions: 3.0.3 Reporter: Kari J. Niemi (I enabled parallel builds of maven3 for my project in CI server, it was running quite nicely giving me much faster builds for a multi-module build. But... it brought our CI server on it's knees, other projects suffered from this and the CI build server admin bashed me to get back to serial build :D... oh, he's such a nice guy :D...) I did some googling around and found out that in Linux, forking new processes may be extremely slow in case the parent that forks, has a great memory print. Well, in the past I had (of course) optimized my build for maven2 by throwing it more (some? no,no... _lots_ of) memory with MAVEN_OPTS by setting both Xms and Xms to the same huge value, not forgetting the MaxPermSize and PermSize. I suppose this, together with the linux forking feature, might cause the extreme cpu load? And of course the CI server process itself has an even bigger memory print, times ten or something, fortunately I suppose it's not doing so much forking... I suppose the memory tuning should/could be done quite differently when using parallel build feature because the mem is then used in the forked processes which are smaller? So in parallel build I might set those mem options pretty low, I guess? And also I could be setting -client-mode manually -because otherwise jvm would think it should be running in server mode (due to running in server HW. Actually I don't quite understand why jvm anyway decides based on HW whether it should be running in server or client mode - there's no such relation -not every jvm running on server HW is really a server process...) Is there anything that we could be improve in maven/maven documentation in this respect? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MINDEXER-26) NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
[
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268241#action_268241
]
Jesse Glick commented on MINDEXER-26:
-
http://statistics.netbeans.org/exceptions/exception.do?id=509289 shows an
apparently similar NPE - {{indexDirectory}} null in
{{DefaultIndexingContext.deleteIndexFiles}} - which is not inside the
constructor.
NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
-
Key: MINDEXER-26
URL: http://jira.codehaus.org/browse/MINDEXER-26
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.0.0
Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09,
Java(TM) SE Runtime
Environment, 1.6.0_23-b05
OS: Windows 7
Reporter: Jesse Glick
http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans
user in a build embedding Maven Indexer 4.0.0.
{noformat}
if ( IndexWriter.isLocked( indexDirectory ) )
{
IndexWriter.unlock( indexDirectory );
}
{noformat}
Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been
called, and this code does not check for that (other code in the same class
does). Can probably be guarded with a simple null check?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-742) Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors
[ http://jira.codehaus.org/browse/SUREFIRE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268246#action_268246 ] S Daigle commented on SUREFIRE-742: --- Thanks again Kristian. Got your latest version 2.8.2-20110523.212645-39 and will give it a try. Latest 2.8.2-SNAPSHOT version having sporadic java.lang.RuntimeException errors --- Key: SUREFIRE-742 URL: http://jira.codehaus.org/browse/SUREFIRE-742 Project: Maven Surefire Issue Type: Bug Affects Versions: Backlog Environment: Linux x64 Reporter: S Daigle Attachments: sf.txt, sf2.txt, sf3.txt We're using the latest 2.8.2-SNAPSHOT (maven-surefire-plugin-2.8.2-20110519.214109-36) and we're seeing sporadic errors with some of our tests: Exception in thread ThreadedStreamConsumer java.lang.RuntimeException: java.util.StringTokenizer@5051207c at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:190) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:106) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:619) Caused by: java.util.NoSuchElementException at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:198) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:181) ... 3 more We've also noted, when run individually, maven reports FAILED but when run with a group of tests, we still see the failures but maven reports SUCCESS. I attached a log with the individual test run using mvn -e. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-5101) Declare artifact is a replacement to avoid excessive exclusions
Declare artifact is a replacement to avoid excessive exclusions
---
Key: MNG-5101
URL: http://jira.codehaus.org/browse/MNG-5101
Project: Maven 2 3
Issue Type: Wish
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Anthony Whitford
Priority: Minor
For those of us using something like [SLF4J|http://slf4j.org/] and including a
[legacy API bridge|http://slf4j.org/legacy.html] like {{jcl-over-slf4j}} as a
replacement to {{commons-logging}}, it would be nice to be able to have the
{{jcl-over-slf4j}} artifact declare in its POM that it is a logical replacement
to {{commons-logging}}, so that one can avoid the excessive {{exclusions}}
for the numerous artifacts that still reference the legacy api:
{code}
exclusions
exclusion
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/exclusion
/exclusions
{code}
One work-around that one can use is to declare {{commons-logging}} as
{{provided}} in a project's pom -- but then it appears in the dependency tree,
which is not really nice.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-5102) Mixin POM fragments
Mixin POM fragments --- Key: MNG-5102 URL: http://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating 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: (MNG-5102) Mixin POM fragments
[ http://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-5102: -- Fix Version/s: 3.1 yes, surprisingly there doesn't appear to be an issue for it, though lots of related ones. Adding to that version. Mixin POM fragments --- Key: MNG-5102 URL: http://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: 3.1 I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating 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] Commented: (MNG-5102) Mixin POM fragments
[ http://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268268#action_268268 ] Brett Porter commented on MNG-5102: --- I've been in greater need of this lately - I'll kick a discussion on the development list Mixin POM fragments --- Key: MNG-5102 URL: http://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: 3.1 I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating 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
