[jira] Commented: (MRM-505) Ability to Aggregate/Report on a variety of artifact criterium
[ http://jira.codehaus.org/browse/MRM-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107618 ] Teodoro Cue Jr. commented on MRM-505: - The examples in the description (a) (b) (c) are described in MRM-506. As for the rest ... d) The number of source files? Do you mean the compressed / embedded source files in the *-sources.jar artifacts? e) "Metadata" is too vague. Do you mean .pom, maven-metadata.xml, maven-metadata-.xml, *-site.xml, or any of the other 'metadata' files? f) License Type is hard to do ATM, we need to create a LicenseTypeMapper lib first, as all license definitions are pretty much free-form, this would mean the mapping that the LicenseTypeMapper needs to be saved / stored in the database, and also screens need to be created that the admin / user can utilize to manage the mapping of the freeform definitions to a known license type. g) The concept of "related" needs more a more clear (precise) definition. > Ability to Aggregate/Report on a variety of artifact criterium > -- > > Key: MRM-505 > URL: http://jira.codehaus.org/browse/MRM-505 > Project: Archiva > Issue Type: New Feature > Components: reporting >Reporter: Teodoro Cue Jr. > > In addition to basic summary information on the total # of files in the > Maestro Repository Manager (MRM) - we need to support the following other > basic summary information: > a) number of unique/discrete projects (based on combo of GroupID and > ArtifactID - or is it just ArtifactID) > b) number of unique community/company projects (based on GroupID) > c) number of wars, jars, ears, etc. (by file extension type) > d) number of source files > e) number of metadata files > f) number of artifacts w/ a certain license type (also number of artifacts > with no license info) > g) number of projects RELATED to a unique community/company > there are other stats, but they are more historical, qualitative vs. > quantitative - should I put them all here? or separate as another issue? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-507) Create LicenseTypeMapper library
Create LicenseTypeMapper library Key: MRM-507 URL: http://jira.codehaus.org/browse/MRM-507 Project: Archiva Issue Type: Sub-task Reporter: Teodoro Cue Jr. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-506) [REPORT] Repository Statistics
[REPORT] Repository Statistics -- Key: MRM-506 URL: http://jira.codehaus.org/browse/MRM-506 Project: Archiva Issue Type: Sub-task Components: reporting Reporter: Teodoro Cue Jr. The repository statistics screen should contain the following |Type|In Corporate Repo|In Snapshots Repo|Total| |File Count|#|#|#| |File Size Totals|#|#|#| |Project Count|#|#|#| |Group Id Count|#|#|#| |Artifact Count|#|#|#| |Plugin Count|#|#|#| |Archetype Count|#|#|#| |Jar Count|#|#|#| |War Count|#|#|#| -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-508) Create LicenseTypeMapper management screens.
Create LicenseTypeMapper management screens. Key: MRM-508 URL: http://jira.codehaus.org/browse/MRM-508 Project: Archiva Issue Type: Sub-task Reporter: Teodoro Cue Jr. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-505) Ability to Aggregate/Report on a variety of artifact criterium
Ability to Aggregate/Report on a variety of artifact criterium -- Key: MRM-505 URL: http://jira.codehaus.org/browse/MRM-505 Project: Archiva Issue Type: New Feature Components: reporting Reporter: Teodoro Cue Jr. In addition to basic summary information on the total # of files in the Maestro Repository Manager (MRM) - we need to support the following other basic summary information: a) number of unique/discrete projects (based on combo of GroupID and ArtifactID - or is it just ArtifactID) b) number of unique community/company projects (based on GroupID) c) number of wars, jars, ears, etc. (by file extension type) d) number of source files e) number of metadata files f) number of artifacts w/ a certain license type (also number of artifacts with no license info) g) number of projects RELATED to a unique community/company there are other stats, but they are more historical, qualitative vs. quantitative - should I put them all here? or separate as another issue? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-504) Find Artifact page needs more onscreen information/instructions
Find Artifact page needs more onscreen information/instructions --- Key: MRM-504 URL: http://jira.codehaus.org/browse/MRM-504 Project: Archiva Issue Type: Improvement Components: web application Reporter: Teodoro Cue Jr. Find Artifact Search for: Checksum: Select the file you would like to locate in the remote repository. The entire file will not be uploaded to the server. See the progress bar below for progress of locally creating a checksum that is uploaded to the server after you hit "Go!". This page and text and the 'Go' button do not help the user understand what they can/need to do. If they should do only one or the other, only one option should be available at a time. Recommend changing 'Go' to 'Submit', for consistency w/ Search page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1455) In a project's working directory it would be nice to see a date and time...
In a project's working directory it would be nice to see a date and time... --- Key: CONTINUUM-1455 URL: http://jira.codehaus.org/browse/CONTINUUM-1455 Project: Continuum Issue Type: Improvement Components: Web - UI Reporter: Teodoro Cue Jr. Priority: Minor http://localhost:9090/workingCopy.action?projectId=5&projectName=Maven+Model&userDirectory=target On the zip/jar files a date and time would be nice to have. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1454) Add ability to Release a Project from the Project View page
Add ability to Release a Project from the Project View page --- Key: CONTINUUM-1454 URL: http://jira.codehaus.org/browse/CONTINUUM-1454 Project: Continuum Issue Type: Improvement Reporter: Maria Catherine Tan 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: (CONTINUUM-1453) Confirmation Page for Deleting a Build Definition is not Informative Enough
Confirmation Page for Deleting a Build Definition is not Informative Enough --- Key: CONTINUUM-1453 URL: http://jira.codehaus.org/browse/CONTINUUM-1453 Project: Continuum Issue Type: Bug Components: Web - UI Environment: Currently, confirmation says: Are you sure you want to delete the build definition "3"? where the number 3 can't be seen in the previous page to be used for verification reference for the delete. Reporter: Maria Catherine Tan Currently, confirmation says: Are you sure you want to delete the build definition "3"? where the number 3 can't be seen in the previous page to be used for verification reference for the delete. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-105) not able to create from project with sibling-dependencies test project
[
http://jira.codehaus.org/browse/ARCHETYPE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated ARCHETYPE-105:
Assignee: Raphaël Piéroni
Fix Version/s: NG-1.0-alpha-1
> not able to create from project with sibling-dependencies test project
> --
>
> Key: ARCHETYPE-105
> URL: http://jira.codehaus.org/browse/ARCHETYPE-105
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: NG-1.0-alpha-1
>Reporter: Brian Fox
>Assignee: Raphaël Piéroni
> Fix For: NG-1.0-alpha-1
>
>
> I'm getting the following error with r576630 trying to create a new archetype
> from the sibling-dependencies test project.
> The file it is trying to find does not exist and I have no idea why it thinks
> it should...there is not even a src folder in that project.
> {noformat}
> E:\svn\Maven\maven-sandbox\archetypeng\archetype-plugin\src\test\projects\sibling-dependency>mvn
> archetype:create-from-project -N -e
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
>
> [INFO] Building Maven ArchetypeNG - Test - Sibling Dependencies
> [INFO]task-segment: [archetype:create-from-project]
> [INFO]
>
> [INFO] [archetype:create-from-project]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Cannot create archetype from this project.
> Embedded error:
> E:\svn\Maven\maven-sandbox\archetypeng\archetype-plugin\src\test\projects\sibling-dependency\src\main\archetype\arch
> etype.properties (The system cannot find the path specified)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Cannot create
> archetype from this project.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot create
> archetype from this project.
> at
> org.apache.maven.plugin.archetype.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:102)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: java.io.FileNotFoundException:
> E:\svn\Maven\maven-sandbox\archetypeng\archetype-plugin\src\test\projects\sibling-dependen
> cy\src\main\archetype\archetype.properties (The system cannot find the path
> specified)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at
> org.apache.maven.plugin.archetype.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:94)
> ... 18 more
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Sep 17 20:3
[jira] Created: (ARCHETYPE-105) not able to create from project with sibling-dependencies test project
not able to create from project with sibling-dependencies test project
--
Key: ARCHETYPE-105
URL: http://jira.codehaus.org/browse/ARCHETYPE-105
Project: Maven Archetype
Issue Type: Bug
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox
Fix For: NG-1.0-alpha-1
I'm getting the following error with r576630 trying to create a new archetype
from the sibling-dependencies test project.
The file it is trying to find does not exist and I have no idea why it thinks
it should...there is not even a src folder in that project.
{noformat}
E:\svn\Maven\maven-sandbox\archetypeng\archetype-plugin\src\test\projects\sibling-dependency>mvn
archetype:create-from-project -N -e
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO]
[INFO] Building Maven ArchetypeNG - Test - Sibling Dependencies
[INFO]task-segment: [archetype:create-from-project]
[INFO]
[INFO] [archetype:create-from-project]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot create archetype from this project.
Embedded error:
E:\svn\Maven\maven-sandbox\archetypeng\archetype-plugin\src\test\projects\sibling-dependency\src\main\archetype\arch
etype.properties (The system cannot find the path specified)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot create archetype
from this project.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot create
archetype from this project.
at
org.apache.maven.plugin.archetype.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:102)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: java.io.FileNotFoundException:
E:\svn\Maven\maven-sandbox\archetypeng\archetype-plugin\src\test\projects\sibling-dependen
cy\src\main\archetype\archetype.properties (The system cannot find the path
specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at
org.apache.maven.plugin.archetype.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:94)
... 18 more
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Mon Sep 17 20:31:18 EDT 2007
[INFO] Final Memory: 3M/6M
[INFO]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-98) parents in modules are not always correctly updated
[
http://jira.codehaus.org/browse/ARCHETYPE-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed ARCHETYPE-98.
--
Resolution: Fixed
tested and verified with 576630
> parents in modules are not always correctly updated
> ---
>
> Key: ARCHETYPE-98
> URL: http://jira.codehaus.org/browse/ARCHETYPE-98
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Reporter: Brian Fox
>Assignee: Raphaël Piéroni
> Fix For: NG-1.0-alpha-1
>
>
> I have the following (in plugin/src/test/projects/deep-inheritence-test)
> project:
> root->a->b where b's parent is a and a's parent is root.
> After generating the project, the group id for all projects is changed, but b
> still has a reference to the a parent from the original project. It wasn't
> changed.
> {noformat}
>
> org.apache.maven.archetype.test.a
> deep-inheritence-test-a
> 1-SNAPSHOT
>
> b
> my.test
> pom
> Inheritence B
> 2-VERSION
> {noformat}
> should be
> {noformat}
>
> my.test.a <--CHange here
> deep-inheritence-test-a
> 1-SNAPSHOT
>
> b
> my.test
> pom
> Inheritence B
> 2-VERSION
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-104) module name changed for unknown reason
module name changed for unknown reason
--
Key: ARCHETYPE-104
URL: http://jira.codehaus.org/browse/ARCHETYPE-104
Project: Maven Archetype
Issue Type: Bug
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox
Fix For: NG-1.0-alpha-1
I tested with 576630 and the sub modules are being changed and I'm not sure
why. The module a becomes test-a, b becomes test-b etc. I used "test" as the
name of my artifact, but I'm not sure its safe to prepend the artifact to every
module.
{noformat}
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";>
4.0.0
nu.infinity.a
test-a
2.0-SNAPSHOT
test-b
pom
Inheritence B
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-104) module name changed for unknown reason
[
http://jira.codehaus.org/browse/ARCHETYPE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated ARCHETYPE-104:
Assignee: Raphaël Piéroni
Fix Version/s: NG-1.0-alpha-1
> module name changed for unknown reason
> --
>
> Key: ARCHETYPE-104
> URL: http://jira.codehaus.org/browse/ARCHETYPE-104
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: NG-1.0-alpha-1
>Reporter: Brian Fox
>Assignee: Raphaël Piéroni
> Fix For: NG-1.0-alpha-1
>
>
> I tested with 576630 and the sub modules are being changed and I'm not sure
> why. The module a becomes test-a, b becomes test-b etc. I used "test" as the
> name of my artifact, but I'm not sure its safe to prepend the artifact to
> every module.
> {noformat}
> 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";>
> 4.0.0
>
> nu.infinity.a
> test-a
> 2.0-SNAPSHOT
>
> test-b
> pom
> Inheritence B
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-97) section is missing after using create-from-project
[
http://jira.codehaus.org/browse/ARCHETYPE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed ARCHETYPE-97.
--
Resolution: Fixed
Tested and fixed with 576630
> section is missing after using create-from-project
>
>
> Key: ARCHETYPE-97
> URL: http://jira.codehaus.org/browse/ARCHETYPE-97
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Brian Fox
>Assignee: Raphaël Piéroni
> Fix For: NG-1.0-alpha-1
>
>
> After running create from project, i find pieces of the pom are missing. I
> noticed that the module section is gone.
> Starting with:
> {noformat}
> 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";>
> 4.0.0
>
> maven-parent
> org.apache.maven
> 6
> ../pom/maven/pom.xml
>
> org.apache.maven.archetype.test
> deep-inheritence-test
> pom
> Inheritence Parent
> 1-SNAPSHOT
>
>
>
> a
>
>
>
> {noformat}
> I end up with:
> {noformat}
> -->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";>
> 4.0.0
>
> maven-parent
> org.apache.maven
> 6
> ../pom/maven/pom.xml
>
> my.test
> fooartifact
> pom
> Inheritence Parent
> 2-VERSION
>
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-103) acrchetype.properties should be in /target not root
[
http://jira.codehaus.org/browse/ARCHETYPE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated ARCHETYPE-103:
Assignee: Raphaël Piéroni
Fix Version/s: NG-1.0-alpha-1
> acrchetype.properties should be in /target not root
> ---
>
> Key: ARCHETYPE-103
> URL: http://jira.codehaus.org/browse/ARCHETYPE-103
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: NG-1.0-alpha-1
>Reporter: Brian Fox
>Assignee: Raphaël Piéroni
>Priority: Minor
> Fix For: NG-1.0-alpha-1
>
>
> the properties file that gets created by create-from-project should go into
> ${build.outputDirectory} (/target) so that clean can really clean up. You
> have to manually remove that file now to start over.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (ARCHETYPE-103) acrchetype.properties should be in /target not root
acrchetype.properties should be in /target not root
---
Key: ARCHETYPE-103
URL: http://jira.codehaus.org/browse/ARCHETYPE-103
Project: Maven Archetype
Issue Type: Bug
Affects Versions: NG-1.0-alpha-1
Reporter: Brian Fox
Priority: Minor
the properties file that gets created by create-from-project should go into
${build.outputDirectory} (/target) so that clean can really clean up. You have
to manually remove that file now to start over.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1724) Upload hibernate-validator:3.0.0.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1724. --- Assignee: Carlos Sanchez Resolution: Won't Fix we can't replace artifacts in the repo, if possible fix in next release, else you can prepare a 3.0.0.ga-1 version > Upload hibernate-validator:3.0.0.ga > --- > > Key: MAVENUPLOAD-1724 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1724 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-validator-3.0.0.ga-bundle.jar > > > This package contains an updated hibernate-validator bundle with corrected > dependencies. > If it is possible, please update the artifact in the repository - otherwise > consider this issue to be filed for historic/reference reasons only and feel > free to close it with WONTFIX. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1725) Upload hibernate-search:3.0.0.cr1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1725. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload hibernate-search:3.0.0.cr1 > - > > Key: MAVENUPLOAD-1725 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1725 > Project: maven-upload-requests > Issue Type: Task >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-search-3.0.0.cr1-bundle.jar > > > Please find attached the hibernate-search release 3.0.0.cr1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRELEASE-286) Classpath errors during release:perform
Classpath errors during release:perform --- Key: MRELEASE-286 URL: http://jira.codehaus.org/browse/MRELEASE-286 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Cameron Jones Priority: Blocker Attachments: sandbox-release-console.log, sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip I have a standard web app project which consists of a core module, a web app and some web services. In the project build i have some automated tasks setup to create the client stub classes by starting a jetty web container, deploying the web app, and then hitting the web service to access the generated wsdl so it can create a stub library. This process works during a standard 'install' goal and when running the 'release:prepare' goal, however when running 'release:perform' i encounter some library conflicts which i can only guess are as a result of a polluted class path. The specific error i get is that there is more than 1 commons-logging library on the classpath. I know this is a common error but i have it sucessfully working in the other goals and i've spent a lot of time making sure it's not an actual commons-logging issue. Also, i've also seen java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a result of running the same config. Is there anything special about the way that the release:perform task manages it's classpath? I notice that the perform task actually executes several iterations of build during this phase, is it possible that the previous iterations classpath is not isolated? To illustrate the issue i've created a test project which mimics the functionality in my app and illustrates the issue. I've attached the project to this jira and also the logs files from running release:prepare and release:perform. Unfortunately the error in jetty is output to the console so i've got that as a separate file. The test project has the following modules: pom.xml - Parent POM core/pom.xml - Core POM using commons-logging with no concrete loggers packaged or as transitive dependencies web/pom.xml - Web App using commons loggins also with no concrete log implementation (log4j is added explicity just for unit tests) test/pom.xml - Client stub generation module (sorry should have renamed to something better). The client stub module starts jetty using cargo during the initialize phase and deploy the web app. In the real app it would generate the stub classes but in this example it just needs to depoy the app for the error to occur. During the compile phase it shuts down jetty. To test i'm afraid you'll have to create a subversion repo for the app but that should be pretty much it. You might need to reconfigue where the site is deploy to as well. The only external property config should be the scm connection details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-286) Classpath errors during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones updated MRELEASE-286: --- Attachment: sandbox-release-console.log > Classpath errors during release:perform > --- > > Key: MRELEASE-286 > URL: http://jira.codehaus.org/browse/MRELEASE-286 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Cameron Jones >Priority: Blocker > Attachments: sandbox-release-console.log, > sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip > > > I have a standard web app project which consists of a core module, a web app > and some web services. In the project build i have some automated tasks setup > to create the client stub classes by starting a jetty web container, > deploying the web app, and then hitting the web service to access the > generated wsdl so it can create a stub library. This process works during a > standard 'install' goal and when running the 'release:prepare' goal, however > when running 'release:perform' i encounter some library conflicts which i can > only guess are as a result of a polluted class path. > The specific error i get is that there is more than 1 commons-logging library > on the classpath. I know this is a common error but i have it sucessfully > working in the other goals and i've spent a lot of time making sure it's not > an actual commons-logging issue. Also, i've also seen > java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a > result of running the same config. > Is there anything special about the way that the release:perform task manages > it's classpath? I notice that the perform task actually executes several > iterations of build during this phase, is it possible that the previous > iterations classpath is not isolated? > To illustrate the issue i've created a test project which mimics the > functionality in my app and illustrates the issue. I've attached the project > to this jira and also the logs files from running release:prepare and > release:perform. Unfortunately the error in jetty is output to the console so > i've got that as a separate file. > The test project has the following modules: > pom.xml - Parent POM > core/pom.xml - Core POM using commons-logging with no concrete loggers > packaged or as transitive dependencies > web/pom.xml - Web App using commons loggins also with no concrete log > implementation (log4j is added explicity just for unit tests) > test/pom.xml - Client stub generation module (sorry should have renamed to > something better). > The client stub module starts jetty using cargo during the initialize phase > and deploy the web app. In the real app it would generate the stub classes > but in this example it just needs to depoy the app for the error to occur. > During the compile phase it shuts down jetty. > To test i'm afraid you'll have to create a subversion repo for the app but > that should be pretty much it. You might need to reconfigue where the site is > deploy to as well. The only external property config should be the scm > connection details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-503) Metadata files need Pragma:no-cache response header.
Metadata files need Pragma:no-cache response header. Key: MRM-503 URL: http://jira.codehaus.org/browse/MRM-503 Project: Archiva Issue Type: Bug Components: repository interface Affects Versions: 1.0-beta-1 Reporter: Joakim Erdfelt The Pragma:no-cache header on the HTTP response should be set on responses of maven-metadata.xml files. This should be done to be friendly to network-proxies that are in the path between the client and the archiva 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: (MRELEASE-286) Classpath errors during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107596 ] Cameron Jones commented on MRELEASE-286: This could be related to MRELEASE-140 > Classpath errors during release:perform > --- > > Key: MRELEASE-286 > URL: http://jira.codehaus.org/browse/MRELEASE-286 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Cameron Jones >Priority: Blocker > Attachments: sandbox-release-console.log, > sandbox-release-perform.log, sandbox-release-prepare.log, sandbox.zip > > > I have a standard web app project which consists of a core module, a web app > and some web services. In the project build i have some automated tasks setup > to create the client stub classes by starting a jetty web container, > deploying the web app, and then hitting the web service to access the > generated wsdl so it can create a stub library. This process works during a > standard 'install' goal and when running the 'release:prepare' goal, however > when running 'release:perform' i encounter some library conflicts which i can > only guess are as a result of a polluted class path. > The specific error i get is that there is more than 1 commons-logging library > on the classpath. I know this is a common error but i have it sucessfully > working in the other goals and i've spent a lot of time making sure it's not > an actual commons-logging issue. Also, i've also seen > java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet errors as a > result of running the same config. > Is there anything special about the way that the release:perform task manages > it's classpath? I notice that the perform task actually executes several > iterations of build during this phase, is it possible that the previous > iterations classpath is not isolated? > To illustrate the issue i've created a test project which mimics the > functionality in my app and illustrates the issue. I've attached the project > to this jira and also the logs files from running release:prepare and > release:perform. Unfortunately the error in jetty is output to the console so > i've got that as a separate file. > The test project has the following modules: > pom.xml - Parent POM > core/pom.xml - Core POM using commons-logging with no concrete loggers > packaged or as transitive dependencies > web/pom.xml - Web App using commons loggins also with no concrete log > implementation (log4j is added explicity just for unit tests) > test/pom.xml - Client stub generation module (sorry should have renamed to > something better). > The client stub module starts jetty using cargo during the initialize phase > and deploy the web app. In the real app it would generate the stub classes > but in this example it just needs to depoy the app for the error to occur. > During the compile phase it shuts down jetty. > To test i'm afraid you'll have to create a subversion repo for the app but > that should be pretty much it. You might need to reconfigue where the site is > deploy to as well. The only external property config should be the scm > connection details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1721) Upload hibernate-commons-annotations:3.0.0.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1721. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload hibernate-commons-annotations:3.0.0.ga > - > > Key: MAVENUPLOAD-1721 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1721 > Project: maven-upload-requests > Issue Type: Task >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-commons-annotations-3.0.0.ga-bundle.jar > > > In [MAVENUPLOAD-1542] Craig Condit posted an invalid bundle of > hibernate-commons-annotations:3.3.0.ga. > He apparently mixed hibernate-annotations with hibernate-commons-annotations, > as well as versions and dependencies. I'd like to correct this mistake and > upload a correct bundle. Here is a relevant issue: > http://opensource.atlassian.com/projects/hibernate/browse/HV-29 > (I'm responsible for uploads of Maven artifacts of Hibernate Entity Manager). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1723) Upload hibernate-entitymanager:3.3.1.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1723. --- Assignee: Carlos Sanchez Resolution: Won't Fix we can't replace artifacts in the repo, if possible fix in next release, else you can prepare a 3.3.1.ga-1 version > Upload hibernate-entitymanager:3.3.1.ga > --- > > Key: MAVENUPLOAD-1723 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1723 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-entitymanager-3.3.1.ga-bundle.jar > > > This package contains an updated hibernate-enitytmanager bundle with > corrected dependencies. > If it is possible, please update the artifact in the repository - otherwise > consider this issue to be filed for historic/reference reasons only and feel > free to close it with WONTFIX. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1722) Upload hibernate-annotations:3.0.0.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1722. --- Assignee: Carlos Sanchez Resolution: Won't Fix we can't replace artifacts in the repo, if possible fix in next release, else you can prepare a 3.0.0.ga-1 version > Upload hibernate-annotations:3.0.0.ga > - > > Key: MAVENUPLOAD-1722 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1722 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Aleksei Valikov >Assignee: Carlos Sanchez > Attachments: hibernate-annotations-3.3.0.ga-bundle.jar > > > This package contains an updated hibernate-annotations bundle with corrected > dependencies. > If it is possible, please update the artifact in the repository - otherwise > consider this issue to be filed for historic/reference reasons only and feel > free to clos it with WONTFIX. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPJAVACC-6) Documentation is missing for package parameters
[ http://jira.codehaus.org/browse/MPJAVACC-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPJAVACC-6. Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.2.1 Patch applied, thanks! However, the parameters are optional, right? > Documentation is missing for package parameters > --- > > Key: MPJAVACC-6 > URL: http://jira.codehaus.org/browse/MPJAVACC-6 > Project: Maven 1.x JavaCC Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: dion gillard >Assignee: Lukas Theussl > Fix For: 1.2.1 > > Attachments: properties.xml.package.patch > > > maven.javacc.javacc.package > and > maven.javacc.jjtree.package > property docs are 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: (MAVENUPLOAD-1716) Asterisk-Java 0.3.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1716. --- Assignee: Carlos Sanchez Resolution: Fixed > Asterisk-Java 0.3.1 > --- > > Key: MAVENUPLOAD-1716 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1716 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stefan Reuter >Assignee: Carlos Sanchez > > http://asterisk-java.org > http://asterisk-java.org/development/team-list.html > The free Java library for Asterisk PBX integration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1715) gwt-user-1.4.60
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1715. --- Assignee: Carlos Sanchez Resolution: Fixed next time please create only one issue listing all bundles > gwt-user-1.4.60 > --- > > Key: MAVENUPLOAD-1715 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1715 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ryan Heaton >Assignee: Carlos Sanchez > > GWT allows you to write an AJAX app in java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1714) gwt-servlet-1.4.60
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1714. --- Assignee: Carlos Sanchez Resolution: Fixed next time please create only one issue listing all bundles > gwt-servlet-1.4.60 > -- > > Key: MAVENUPLOAD-1714 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1714 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ryan Heaton >Assignee: Carlos Sanchez > > server-side components for invoking a GWT-RPC service. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MANTRUN-65) Add a configuration element that allows you to skip plugin's execution
[
http://jira.codehaus.org/browse/MANTRUN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Raible closed MANTRUN-65.
--
Resolution: Fixed
That's good enough for me!
> Add a configuration element that allows you to skip plugin's execution
> -
>
> Key: MANTRUN-65
> URL: http://jira.codehaus.org/browse/MANTRUN-65
> Project: Maven 2.x Antrun Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Matt Raible
>
> The DbUnit, Hibernate3 and SQL Maven 2 Plugins have a "skip" configuration
> element that can be set to true in order to skip execution. This is a nice
> feature because it allows you pass in -Dmaven.test.skip=true and skip
> execution by adding the following in your pom.xml.
>
> ...
> ${maven.test.skip}
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1693) Upload truezip
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107583 ] Carlos Sanchez commented on MAVENUPLOAD-1693: - from http://maven.apache.org/guides/mini/guide-central-repository-upload.html groupId : it will identify your project uniquely across all projects, so we need to enforce a naming schema. For projects with artifacts already uploaded to the Central Repository it can be equal to the one used previously, but for new projects it has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. There are a lot of poorly defined package names so you must provide proof that you control the domain that matches the groupId. Provide proof means that the project is hosted at that domain or it's owned by a member, in that case you must give the link to the registrar database (whois) where the owner is listed and the page in the project web where the owner is associated with the project. eg. If you use a com.sun.xyz package name we expect that the project is hosted at http://xyz.sun.com. Look at More information about package names . Check also the guide about Maven naming conventions > Upload truezip > -- > > Key: MAVENUPLOAD-1693 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1693 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Asankha Perera >Assignee: Carlos Sanchez > > http://people.apache.org/~asankha/temp/truezip-upload.jar > https://truezip.dev.java.net/ > TrueZIP is a Java based Virtual File System (VFS) which enables client > applications to access ZIP, TAR and derivative archive types transparently as > if they were just directories in a file's path name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1710) gwt-widgets-0.1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1710. --- Assignee: Carlos Sanchez Resolution: Fixed next time please create only one issue listing all bundles > gwt-widgets-0.1.5 > - > > Key: MAVENUPLOAD-1710 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1710 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ryan Heaton >Assignee: Carlos Sanchez > > The GWT Widget Library is a set of enhancements and utilities for the Google > Web Toolkit client-side code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1711) gwt-widgets-server-0.1.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1711. --- Assignee: Carlos Sanchez Resolution: Fixed next time please create only one issue listing all bundles > gwt-widgets-server-0.1.4 > > > Key: MAVENUPLOAD-1711 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1711 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ryan Heaton >Assignee: Carlos Sanchez > > The GWT Widget Server Library is a collection of server-side components for > the Google Web Toolkit facilitating publishing of Spring beans as RPC > services. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1693) Upload truezip
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107584 ] Asankha Perera commented on MAVENUPLOAD-1693: - I am aware of this.. and although this is a best practice, the source code package of TrueZip is "de.schlichtherle.io" and not "net.java.dev.truezip".. I see many such discrepancies even for projects under the ASF.. The TrueZip module is not a typical community based project as I am aware of - but controlled largely by a single main contributor. I am an ASF committer who needs to depend on this, and not a developer/contributor for TrueZip. We need to depend on this package for Commons VFS, on which Apache Axis2, Synapse and many other projects can then depend upon on in the near future. Thus it would be great if you could upload this as-is, considering the circumstances. > Upload truezip > -- > > Key: MAVENUPLOAD-1693 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1693 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Asankha Perera >Assignee: Carlos Sanchez > > http://people.apache.org/~asankha/temp/truezip-upload.jar > https://truezip.dev.java.net/ > TrueZIP is a Java based Virtual File System (VFS) which enables client > applications to access ZIP, TAR and derivative archive types transparently as > if they were just directories in a file's path name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRELEASE-285) Unresolved test-jar dependency during release
Unresolved test-jar dependency during release - Key: MRELEASE-285 URL: http://jira.codehaus.org/browse/MRELEASE-285 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Maven version: 2.0.7 Java version: 1.5.0_07 OS name: "mac os x" version: "10.4.10" arch: "i386" Reporter: Rod Coffin Attachments: example.jar I have a multi-module project where one project produces a normal jar and a test-jar (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). Another submodule has a test scoped dependency on the test-jar from the first submodule. For example, this is the structure and produced artifacts for a small sample (attached) I built to reproduce this behavior: release-test-jar (parent project) project-with-test-jar (submodule) => project-with-test-jar-1.0.jar => project-with-test-jar-1.0-tests.jar project-using-test-jar (submodule) => project-user-test-jar-1.0.jar When I run a 'clean install' the build succeeds. However, when I run a 'release:prepare' the build fails with the following error: 1 required artifact is missing. for artifact: com.rfc:project-using-test-jar:jar:1.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) com.rfc:project-with-test-jar:test-jar:tests:1.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.rfc -DartifactId=project-with-test-jar \ -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.rfc -DartifactId=project-with-test-jar \ -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.rfc:project-using-test-jar:jar:1.1 2) com.rfc:project-with-test-jar:test-jar:tests:1.1 -- 1 required artifact is missing. for artifact: com.rfc:project-using-test-jar:jar:1.1 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) Judging from the stack trace this problem seems to occur during dependency resolution as is declared PrepareReleaseMojo with the annotation "@requiresDependencyResolution test". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1719) Berkeley DB Java Edition
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1719. --- Assignee: Carlos Sanchez Resolution: Fixed > Berkeley DB Java Edition > > > Key: MAVENUPLOAD-1719 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1719 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Jasper Blues >Assignee: Carlos Sanchez > Attachments: je-3.2.44-bundle.jar > > > Oracle Berkeley DB Java Edition is a open source, embeddable, transactional > storage engine written entirely in Java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1718) RediJedi Components Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1718. --- Assignee: Carlos Sanchez Resolution: Fixed > RediJedi Components Upload > -- > > Key: MAVENUPLOAD-1718 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1718 > Project: maven-upload-requests > Issue Type: Task >Reporter: Todd Orr >Assignee: Carlos Sanchez > > http://redijedi-t5-components.googlecode.com/files/redijedi-t5-components-0.0.3-bundle.jar > http://redijedi.com/development/redijedi-t5-components/site/team-list.html > http://redijedi.com/development/redijedi-t5-components/site/ > A collection of Tapestry 5 components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1717) please upload a new jdeb release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1717. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload a new jdeb release > > > Key: MAVENUPLOAD-1717 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1717 > Project: maven-upload-requests > Issue Type: Task >Reporter: Torsten Curdt >Assignee: Carlos Sanchez > > adds maven support and more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3212) project model should allow to register and introspect generated classes
project model should allow to register and introspect generated classes --- Key: MNG-3212 URL: http://jira.codehaus.org/browse/MNG-3212 Project: Maven 2 Issue Type: Improvement Components: Embedding Affects Versions: 2.0.x Reporter: Eugene Kuleshov project model should allow to register and introspect generated folders with classes. So, plugins like xmlbeans won't have to do the evil hacks like copying their generated classes from target\generated-classes\xmlbeans into the target\classes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-101) Add dependency:list alias for dependency:resolve
[ http://jira.codehaus.org/browse/MDEP-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson closed MDEP-101. Resolution: Fixed Added dependency:list goal. > Add dependency:list alias for dependency:resolve > > > Key: MDEP-101 > URL: http://jira.codehaus.org/browse/MDEP-101 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: resolve >Affects Versions: 2.0-alpha-4 >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 2.0-alpha-5 > > > It's not immediately obvious that dependency:resolve will provide a list of > resolved dependencies. We should add dependency:list as an alias for the > same goal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-100) Merge dependency:tree branch for new features
[ http://jira.codehaus.org/browse/MDEP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MDEP-100: - Fix Version/s: (was: 2.0-alpha-5) 2.0-alpha-6 Moving back to fix for 2.0-alpha-6 since we need Maven 2.0.8 to be released first. > Merge dependency:tree branch for new features > - > > Key: MDEP-100 > URL: http://jira.codehaus.org/browse/MDEP-100 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: tree >Affects Versions: 2.0-alpha-4 >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 2.0-alpha-6 > > > Reminder to merge the maven-dependency-tree 1.1 branch into trunk after > 2.0-alpha-5 is released: > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-dependency-plugin-tree-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] Updated: (MDEP-100) Merge dependency:tree branch for new features
[ http://jira.codehaus.org/browse/MDEP-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MDEP-100: - Assignee: Mark Hobson (was: Brian Fox) Fix Version/s: 2.0-alpha-5 Changing to fix for 2.0-alpha-5 since the new tree is very usable now and provides lots of new useful features. > Merge dependency:tree branch for new features > - > > Key: MDEP-100 > URL: http://jira.codehaus.org/browse/MDEP-100 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: tree >Affects Versions: 2.0-alpha-4 >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 2.0-alpha-5 > > > Reminder to merge the maven-dependency-tree 1.1 branch into trunk after > 2.0-alpha-5 is released: > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-dependency-plugin-tree-1.1/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-74) dependencies in test scope are not handled properly by analyze
[ http://jira.codehaus.org/browse/MDEP-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107571 ] Mark Hobson commented on MDEP-74: - I can't reproduce this problem with the current maven-dependency-plugin trunk. I've made a few improvements recently, so try again and attach a sample project if it can be reproduced. > dependencies in test scope are not handled properly by analyze > -- > > Key: MDEP-74 > URL: http://jira.codehaus.org/browse/MDEP-74 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0-alpha-3 > Environment: os x 10.4.9, java 1.5.0_07-87, maven 2.0.5 >Reporter: Gregory Kick >Assignee: Brian Fox > Fix For: 2.0-alpha-5 > > > dependency:analyze doesn't recognize test sources for dependencies with test > scope because despite having numerous unit tests, it lists junit as an unused > dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107570 ] Brian Fox commented on MNG-2045: This should be fixed. If you can reproduce, please make an IT test and attach. Instructions for an IT are here: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.6 > > Attachments: it1021.tar.gz, sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-80) Attempt to use proxySettings even when nonProxyHosts is defined
[ http://jira.codehaus.org/browse/WAGON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Champagne updated WAGON-80: -- Attachment: WAGON-80-wagon-provider-api.patch Hi I have created a patch about this issue. I add a method validateNonProxyHosts in a ProxyUtils Class. This methode is called in connect method in AbstractWagon. If the target host validate the non proxy host, the proxyInfo is set to null. The patch contains the class test for the method validateNonProxyHosts. Thomas Champagne > Attempt to use proxySettings even when nonProxyHosts is defined > --- > > Key: WAGON-80 > URL: http://jira.codehaus.org/browse/WAGON-80 > Project: wagon > Issue Type: Bug > Components: wagon-file, wagon-ftp, wagon-http, wagon-provider-api, > wagon-provider-test, wagon-scm, wagon-ssh, wagon-ssh-external, wagon-webdav > Environment: Maven 2.0.5 or maven 2.0.6, this report is based on 2.0.6 >Reporter: David J. M. Karlsen > Attachments: WAGON-80-wagon-provider-api.patch > > > site-deploy hangs because of proxy-settings: > [INFO] Generate "Project Team" report. > [DEBUG] Generating > /tmp/mobilebank/mobilebank-ear/target/site/project-info.html > [DEBUG] Generating > /tmp/mobilebank/mobilebank-ear/target/site/project-reports.html > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:deploy' --> > [DEBUG] (f) inputDirectory = /tmp/mobilebank/mobilebank-ear/target/site > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) settings = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [site:deploy] > If I remove the proxies/proxy element[s] from my settings.xml it works. > Scp is used for deployment. > mvn -X site-deply|grep -i wagon gives: > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5 > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNG-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107556 ] Mikko Koponen edited comment on MNG-2045 at 9/17/07 7:24 AM: - We're also running into this problem, which is that: * We have project A with common test classes in src/main/test * Project A creates a test jar * Project B depends on project A's test jar in *compile* scope * Project B builds fine if built on it's own, but fails when in a reactor build with project A. I know we shouldn't have a dependency from the main code of B to a test artifact of project A, but it would make my job considerably easier if this "just worked", or even if it also failed when only building project B. was: We're also running into this problem, which is that: * We have project A with common test classes in src/main/test * Project A creates a test jar * Project B depends on project A's test jar in *compile* scope * Project B builds fine if built on it's own, but fails when in a reactor build with project A. I know we shouldn't have a dependency from a test artifact to main code, but it would make my job considerably easier if this "just worked", or even if it also failed when only building project B. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.6 > > Attachments: it1021.tar.gz, sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107556 ] Mikko Koponen edited comment on MNG-2045 at 9/17/07 7:23 AM: - We're also running into this problem, which is that: * We have project A with common test classes in src/main/test * Project A creates a test jar * Project B depends on project A's test jar in *compile* scope * Project B builds fine if built on it's own, but fails when in a reactor build with project A. I know we shouldn't have a dependency from a test artifact to main code, but it would make my job considerably easier if this "just worked", or even if it also failed when only building project B. was: We're also running into this problem, which is that: * We have project A with common test classes in src/main/test * Project A creates a test jar * Project B depends on project A's test jar in *compile* scope * Project B builds fine if built on it's own, but fails when in a reactor build with project A. I know we shouldn't have a dependency from a test artifact to main code, but I'm having a very difficult time explaining this to the people who made such a decision, so it would make my job considerably easier if this "just worked". Or even if it also failed when only building project B. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.6 > > Attachments: it1021.tar.gz, sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107556 ] Mikko Koponen commented on MNG-2045: We're also running into this problem, which is that: * We have project A with common test classes in src/main/test * Project A creates a test jar * Project B depends on project A's test jar in *compile* scope * Project B builds fine if built on it's own, but fails when in a reactor build with project A. I know we shouldn't have a dependency from a test artifact to main code, but I'm having a very difficult time explaining this to the people who made such a decision, so it would make my job considerably easier if this "just worked". Or even if it also failed when only building project B. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.6 > > Attachments: it1021.tar.gz, sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPJAVACC-6) Documentation is missing for package parameters
Documentation is missing for package parameters --- Key: MPJAVACC-6 URL: http://jira.codehaus.org/browse/MPJAVACC-6 Project: Maven 1.x JavaCC Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: dion gillard Attachments: properties.xml.package.patch maven.javacc.javacc.package and maven.javacc.jjtree.package property docs are 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] Commented: (MRELEASE-168) All submodule projects must be from the same subversion repository
[ http://jira.codehaus.org/browse/MRELEASE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107554 ] Michael Semb Wever commented on MRELEASE-168: - looks great. thanks. > All submodule projects must be from the same subversion repository > -- > > Key: MRELEASE-168 > URL: http://jira.codehaus.org/browse/MRELEASE-168 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-4 >Reporter: Michael Semb Wever >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-5 > > Attachments: MRELEASE-168.patch > > > It is too restrictive to expect that all modules in a maven project will be > from the same subversion repository. > But if they are not, when "mvn release:prepare" runs, edits all the pom.xml > file, then goes to check them in, it fails. > The check in command looks something like "svn ci pom.xml a/pom.xml b/pom.xml > c/pom.xml" where a, b, and c are modules listed in the first pom.xml. > I'd expect it would be very simple and easy to change the way this command > ran, so that it ran a separate "svn ci ..." for each pom file, thus allowing > cross- subversion repository modules to exist and be supported by this plugin. > We'd like this fixed pretty quickly, so if you could lead to as to which file > I can start getting my teeth stuck into, i'd hopefully submit a patch asap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1725) Upload hibernate-search:3.0.0.cr1
Upload hibernate-search:3.0.0.cr1 - Key: MAVENUPLOAD-1725 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1725 Project: maven-upload-requests Issue Type: Task Reporter: Aleksei Valikov Attachments: hibernate-search-3.0.0.cr1-bundle.jar Please find attached the hibernate-search release 3.0.0.cr1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1724) Upload hibernate-validator:3.0.0.ga
Upload hibernate-validator:3.0.0.ga --- Key: MAVENUPLOAD-1724 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1724 Project: maven-upload-requests Issue Type: Wish Reporter: Aleksei Valikov Attachments: hibernate-validator-3.0.0.ga-bundle.jar This package contains an updated hibernate-validator bundle with corrected dependencies. If it is possible, please update the artifact in the repository - otherwise consider this issue to be filed for historic/reference reasons only and feel free to close it with WONTFIX. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1723) Upload hibernate-entitymanager:3.3.1.ga
Upload hibernate-entitymanager:3.3.1.ga --- Key: MAVENUPLOAD-1723 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1723 Project: maven-upload-requests Issue Type: Wish Reporter: Aleksei Valikov Attachments: hibernate-entitymanager-3.3.1.ga-bundle.jar This package contains an updated hibernate-enitytmanager bundle with corrected dependencies. If it is possible, please update the artifact in the repository - otherwise consider this issue to be filed for historic/reference reasons only and feel free to close it with WONTFIX. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1722) Upload hibernate-annotations:3.0.0.ga
Upload hibernate-annotations:3.0.0.ga - Key: MAVENUPLOAD-1722 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1722 Project: maven-upload-requests Issue Type: Wish Reporter: Aleksei Valikov Attachments: hibernate-annotations-3.3.0.ga-bundle.jar This package contains an updated hibernate-annotations bundle with corrected dependencies. If it is possible, please update the artifact in the repository - otherwise consider this issue to be filed for historic/reference reasons only and feel free to clos it with WONTFIX. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1542) Upload org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107551 ] Aleksei Valikov commented on MAVENUPLOAD-1542: -- Please see the [MAVENUPLOAD-1721] > Upload org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga to ibiblio > -- > > Key: MAVENUPLOAD-1542 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1542 > Project: maven-upload-requests > Issue Type: Task >Reporter: Craig Condit >Assignee: Carlos Sanchez > > http://randomcoder.com/projects/maven-uploads/hibernate-commons-annotations-3.3.0.ga-bundle.jar > http://www.hibernate.org/ > Relational Persistence for Java - Annotations support - Common code > JAR is from hibernate-annotations 3.3.0.ga distribution. > Javadoc and source jars were generated from SVN repository at > http://anonsvn.jboss.org/repos/hibernate/tags/annotations_3_3_0_GA/ > See http://jira.codehaus.org/browse/MAVENUPLOAD-1532#action_95799 for why > this is needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1721) Upload hibernate-commons-annotations:3.0.0.ga
Upload hibernate-commons-annotations:3.0.0.ga - Key: MAVENUPLOAD-1721 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1721 Project: maven-upload-requests Issue Type: Task Reporter: Aleksei Valikov Attachments: hibernate-commons-annotations-3.0.0.ga-bundle.jar In [MAVENUPLOAD-1542] Craig Condit posted an invalid bundle of hibernate-commons-annotations:3.3.0.ga. He apparently mixed hibernate-annotations with hibernate-commons-annotations, as well as versions and dependencies. I'd like to correct this mistake and upload a correct bundle. Here is a relevant issue: http://opensource.atlassian.com/projects/hibernate/browse/HV-29 (I'm responsible for uploads of Maven artifacts of Hibernate Entity Manager). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-157) Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest method
[
http://jira.codehaus.org/browse/SUREFIRE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107549
]
Gerhard Langs commented on SUREFIRE-157:
Re-Implemented the TestNGReporter method below based on the trunk source code
(not submitted to svn). Should now report Before* Errors:
public void onFinish(ITestContext context) {
boolean failureSeen = false;
IResultMap F_rmap = context.getFailedConfigurations();
Iterator F_rset = F_rmap.getAllResults().iterator();
while (F_rset.hasNext()) {
ITestResult F_tres = (ITestResult) F_rset.next();
onTestFailure(F_tres);
failureSeen = true;
}
String rawString = bundle.getString( failureSeen ?
"executeException" : "testSetCompletedNormally" );
ReportEntry report = new ReportEntry(source, context.getName(),
groupString(context.getIncludedGroups(), null),
rawString);
reportManager.testSetCompleted(report);
reportManager.reset();
}
> Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest
> method
> ---
>
> Key: SUREFIRE-157
> URL: http://jira.codehaus.org/browse/SUREFIRE-157
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.0 (2.2 plugin), 2.3
> Environment: Windows XP, JDK 1.5, Maven 2.0.4, TestNG 5.1
>Reporter: Manish Shah
> Fix For: 2.4
>
>
> Create a TestNG test with a method as follows:
> @BeforeTest
> public void beforeTest() {
> throw new RuntimeException("Simulate an exception from a beforeTest
> method");
> }
> When surefire attempts to run this test, the plugin fails with the following
> stack trace:
> org.apache.maven.surefire.booter.SurefireExecutionException: null; nested
> exception is java.lang.NullPointerException: n
> ull
> java.lang.NullPointerException
> at
> org.apache.maven.surefire.report.AbstractTextReporter.testFailed(AbstractTextReporter.java:106)
> at
> org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:299)
> at
> org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:281)
> at
> org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:97)
> at org.testng.internal.Invoker.runTestListeners(Invoker.java:1164)
> at org.testng.internal.Invoker.runTestListeners(Invoker.java:1149)
> at
> org.testng.internal.Invoker.handleConfigurationFailure(Invoker.java:191)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:170)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:236)
> at org.testng.SuiteRunner.run(SuiteRunner.java:145)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(TestNGExecutor.java:64)
> at
> org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-157) Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest method
[
http://jira.codehaus.org/browse/SUREFIRE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107548
]
Gerhard Langs commented on SUREFIRE-157:
Re-Implemented the TestNGReporter method below based on the trunk source code
(not submitted to svn). Should now report Before* Errors:
public void onFinish(ITestContext context) {
boolean failureSeen = false;
IResultMap F_rmap = context.getFailedConfigurations();
Iterator F_rset = F_rmap.getAllResults().iterator();
while (F_rset.hasNext()) {
ITestResult F_tres = (ITestResult) F_rset.next();
onTestFailure(F_tres);
failureSeen = true;
}
String rawString = bundle.getString( failureSeen ?
"executeException" : "testSetCompletedNormally" );
ReportEntry report = new ReportEntry(source, context.getName(),
groupString(context.getIncludedGroups(), null),
rawString);
reportManager.testSetCompleted(report);
reportManager.reset();
}
> Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest
> method
> ---
>
> Key: SUREFIRE-157
> URL: http://jira.codehaus.org/browse/SUREFIRE-157
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.0 (2.2 plugin), 2.3
> Environment: Windows XP, JDK 1.5, Maven 2.0.4, TestNG 5.1
>Reporter: Manish Shah
> Fix For: 2.4
>
>
> Create a TestNG test with a method as follows:
> @BeforeTest
> public void beforeTest() {
> throw new RuntimeException("Simulate an exception from a beforeTest
> method");
> }
> When surefire attempts to run this test, the plugin fails with the following
> stack trace:
> org.apache.maven.surefire.booter.SurefireExecutionException: null; nested
> exception is java.lang.NullPointerException: n
> ull
> java.lang.NullPointerException
> at
> org.apache.maven.surefire.report.AbstractTextReporter.testFailed(AbstractTextReporter.java:106)
> at
> org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:299)
> at
> org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:281)
> at
> org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:97)
> at org.testng.internal.Invoker.runTestListeners(Invoker.java:1164)
> at org.testng.internal.Invoker.runTestListeners(Invoker.java:1149)
> at
> org.testng.internal.Invoker.handleConfigurationFailure(Invoker.java:191)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:170)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:236)
> at org.testng.SuiteRunner.run(SuiteRunner.java:145)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(TestNGExecutor.java:64)
> at
> org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1542) Upload org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga to ibiblio
[
http://jira.codehaus.org/browse/MAVENUPLOAD-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107541
]
Aleksei Valikov commented on MAVENUPLOAD-1542:
--
There are error with this upload.
1) The uploaded artifact is of 3.0.0.ga version, not 3.3.0.ga. 3.3.0.ga is the
version of hibernate-annotations, NOT of the hibernate-commons-annotations. See
the manifest file inside of the JAR for this:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_07-87 ("Apple Computer, Inc.")
Product: Hibernate Commons Annotations
Version: 3.0.0.GA
2) hibernate-commons-annotations DOES NOT have runtime dependencies on
hibernate or JPA. Please see:
http://anonsvn.jboss.org/repos/hibernate/commons-annotations/trunk/lib/README.txt
You have obviously mixed the hibernate-annotations with
hibernate-commons-annotations which are two different things.
I'll prepare a correct 3.0.0.ga bundle.
> Upload org.hibernate:hibernate-commons-annotations:jar:3.3.0.ga to ibiblio
> --
>
> Key: MAVENUPLOAD-1542
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1542
> Project: maven-upload-requests
> Issue Type: Task
>Reporter: Craig Condit
>Assignee: Carlos Sanchez
>
> http://randomcoder.com/projects/maven-uploads/hibernate-commons-annotations-3.3.0.ga-bundle.jar
> http://www.hibernate.org/
> Relational Persistence for Java - Annotations support - Common code
> JAR is from hibernate-annotations 3.3.0.ga distribution.
> Javadoc and source jars were generated from SVN repository at
> http://anonsvn.jboss.org/repos/hibernate/tags/annotations_3_3_0_GA/
> See http://jira.codehaus.org/browse/MAVENUPLOAD-1532#action_95799 for why
> this is needed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3086) NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
[ http://jira.codehaus.org/browse/MNG-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107535 ] Ranjan George commented on MNG-3086: We are facing the same problem with ranges when we upgraded from 2.0.4 to 2.0.7. The former seems to be working fine. Our pom(s) are organized in the following manner: /ProjectA /pom.xml /ProjectB /pom.xml /pom.xml Project A has the following dependency: dom4j dom4j [1.6,) compile xerces xercesImpl [2.6.2,) compile Project B's pom.xml specifies a dependency on Project A. When I have a dependency declared in Project A with a range specified for the version. For eg. [1.6,), I get the exception shown above while compiling of installing ProjectB with Maven 2.0.7. With maven 2.0.6 I get an unable to resolve dependency error showing the below error: Missing: -- 1) xerces:xercesImpl:jar:RELEASE Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \ -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) ProjectB 2) commons-configuration:commons-configuration:jar:1.2 3) xerces:xercesImpl:jar:RELEASE 2) dom4j:dom4j:jar:RELEASE Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=dom4j -DartifactId=dom4j \ -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) ProjectB 2) commons-configuration:commons-configuration:jar:1.2 3) dom4j:dom4j:jar:RELEASE Looks like a dependency resolution problem when evaluating ranges. In commons-configuration the dependency for dom4j & xerces in its pom.xml seems to be as follows: dom4j dom4j 1.4 xerces xerces 2.2.1 > NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) > > > Key: MNG-3086 > URL: http://jira.codehaus.org/browse/MNG-3086 > Project: Maven 2 > Issue Type: Bug > Components: Errors >Affects Versions: 2.0.7 >Reporter: Thomas Leonard > > After upgrading from 2.0.6 to 2.0.7, our build fails with: > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136) > at > org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:89) > 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.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMetho
[jira] Created: (MAVENUPLOAD-1720) Add Eclipse Equinox Http Servlet to m2 Repositoy
Add Eclipse Equinox Http Servlet to m2 Repositoy Key: MAVENUPLOAD-1720 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1720 Project: maven-upload-requests Issue Type: New Feature Reporter: Carsten Ziegeler http://people.apache.org/~cziegeler/http-servlet.jar The Equinox implementation of the Http Servlet Service is used by some Apache projects (like Sling) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
