[jira] Created: (MNGSITE-106) Documentation about inheritance of parts (distributionManagement) is missing
Documentation about inheritance of parts (distributionManagement) is missing Key: MNGSITE-106 URL: http://jira.codehaus.org/browse/MNGSITE-106 Project: Maven 2 Project Web Site Issue Type: Bug Environment: All Reporter: Karl Heinz Marbaise The web-site documents which parts are inherited from a parent POM to it's childs whereas the distributionManagement is missing on the web site. http://old.nabble.com/Documentation-about-inheritance-of-POM-elements..-td27175352.html#a27175352 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNGSITE-106) Documentation about inheritance of parts (distributionManagement) is missing
[ http://jira.codehaus.org/browse/MNGSITE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207275#action_207275 ] Karl Heinz Marbaise commented on MNGSITE-106: - The following page is the page which is not complete: http://maven.apache.org/pom.html#Inheritance Documentation about inheritance of parts (distributionManagement) is missing Key: MNGSITE-106 URL: http://jira.codehaus.org/browse/MNGSITE-106 Project: Maven 2 Project Web Site Issue Type: Bug Environment: All Reporter: Karl Heinz Marbaise The web-site documents which parts are inherited from a parent POM to it's childs whereas the distributionManagement is missing on the web site. http://old.nabble.com/Documentation-about-inheritance-of-POM-elements..-td27175352.html#a27175352 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNGSITE-4) broken links on http://maven.apache.org/plugins
[ http://jira.codehaus.org/browse/MNGSITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207277#action_207277 ] Peter van der Velde commented on MNGSITE-4: --- On http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html the FAQ link http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/faq.html#module-binaries is broken. broken links on http://maven.apache.org/plugins --- Key: MNGSITE-4 URL: http://jira.codehaus.org/browse/MNGSITE-4 Project: Maven 2 Project Web Site Issue Type: Bug Reporter: Tom Huybrechts a list of broken links on the maven site http://maven.apache.org/plugins/maven-repository-plugin/faq.html http://maven.apache.org/plugins/maven-war-plugin/faq.html http://maven.apache.org/plugins/maven-dependency-plugin/faq.html http://maven.apache.org/plugins/maven-docck-plugin/taglist.html http://maven.apache.org/plugins/maven-repository-plugin/usage.html http://maven.apache.org/plugins/maven-jxr-plugin/faq.html http://maven.apache.org/plugins/maven-checkstyle-plugin/dependencies.html http://maven.apache.org/plugins/maven-verifier-plugin/faq.html http://maven.apache.org/plugins/maven-doap-plugin/examples/options.html http://maven.apache.org/plugins/maven-ejb-plugin/usage.html http://maven.apache.org/plugins/maven-ejb-plugin/faq.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2720) Please change the group of the extrema-sistemas synchronized repository
Please change the group of the extrema-sistemas synchronized repository --- Key: MAVENUPLOAD-2720 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2720 Project: Maven Upload Requests Issue Type: Wish Reporter: Ignacio Coloma Actually there is a releases repository synchronized with maven central with the following configuration: org.extrema-sistemas.loom,mavens...@web.sourceforge.net:/home/groups/l/lo/loom/htdocs/repository Now, we want to add another project org.extrema-sistemas.simpleds, so we wanted to change the configuration to this: org.extrema-sistemas,mavens...@web.sourceforge.net:/home/groups/l/lo/loom/htdocs/repository (The repository is the same, only the group name changes) If you need anything else, I will be glad to help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-4535) Enable SSL downloads for maven repository
Enable SSL downloads for maven repository - Key: MNG-4535 URL: http://jira.codehaus.org/browse/MNG-4535 Project: Maven 2 3 Issue Type: Wish Components: Artifacts and Repositories Reporter: Simon Hartmann Currently maven2 repositories are only accessible via HTTP. In some corporate environments security settings require downloads of artifacts via HTTPS (SSL) protocol. Would it be possible to allow SSL access to one of the maven repositories as this is merely a minor web server configuration 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: (MCHANGES-191) changes schema version should be determined from the document, not speficied in the pom
changes schema version should be determined from the document, not speficied in
the pom
---
Key: MCHANGES-191
URL: http://jira.codehaus.org/browse/MCHANGES-191
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: changes-report
Affects Versions: 2.3
Reporter: Karl Palsson
With multiple changes.xsd schema versions, the changes validator should
determine the document version from the document itself, instead of relying on
a configuration parameter.
Currently, you need
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
version${changesPluginVersion}/version
executions
execution
...
configuration
changesXsdVersion1.0.1/changesXsdVersion
/configuration
/execution
/executions
/plugin
{code}
To actually use a different schema version, regardless of what the target
namespace of the changes.xml file is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207290#action_207290
]
Thomas Wabner commented on MJAVADOC-276:
We have the same problem:
Multi-Module project
- parent
-- war
-- ear
The ear depends on the war project and the javadoc fails if I try to run (for
example) javadoc:jar from the parent.
Version 2.6 has not this problem.
Initial builds of a multi-module project fail
-
Key: MJAVADOC-276
URL: http://jira.codehaus.org/browse/MJAVADOC-276
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: bug.zip
I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
build failed ({{mvn clean install site}}) because Javadoc fails when run from
the top-level parent. When it is building _module A_, the javadoc complains
that _module B_ and _module C_ are missing -- of course they are, they
haven't been built yet. Note that running {{mvn clean install}} from _module
A_ works fine -- the behavior is limited to running from the top-level parent
-- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
have given it what it needs and so you won't see the error.
The attached example exhibits the problem. It was created from the
_j2ee-simple_ archetype -- I only added the explicit javadoc plugin
declaration to the top level pom to control the version being used. To
recreate the problem, unzip and simply: {{mvn clean install site}}. You
will get an error message like:
{noformat}
[INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) root.project.projects:logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=
[id]
Path to dependency:
1) root.project:primary-source:jar:1.0
2) root.project.projects:logging:jar:1.0
--
1 required artifact is missing.
for artifact:
root.project:primary-source:jar:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
{noformat}
As you can see, it seems to think that a submodule (in this case
{{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
for the project... Since this is the first time that this is being built,
the submodule does not exist (yet).
I have replicated this problem on two different computing environments, so
I'm convinced that the Maven version is not relevant.
(It is unclear to me if this problem also existed with Javadoc 2.6, but I
don't think so.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-192) Allow releases to provide links to download/artifacts
Allow releases to provide links to download/artifacts
-
Key: MCHANGES-192
URL: http://jira.codehaus.org/browse/MCHANGES-192
Project: Maven 2.x Changes Plugin
Issue Type: New Feature
Components: announcement, changes-report
Affects Versions: 2.3, 2.2
Reporter: Karl Palsson
Attachments: mchanges-192__artifacts-download-link-schema.diff
Currently, the announcement generator has a pom level config property
urlDownload which can only be specified once for the project, and the changes
report built during site generation has no links for url download whatsoever.
I propose an attribute on each release, like so...
{code:xml}
release version=2.4 description=something
artifacts=http://example.org/releases/2.4;
action dev=me type=addblah blah adding artifact links./action
/release
{code}
This would then generate a link in each release section.
For the announcement mail, I'm unsure of the best way of relating these, but as
a default, I propose that if urlDownload is _not_ specified, then the most
recent release's artifact url is used as the urlDownload, if specified at all.
Patch is attached, notes about the patch:
* New schema version!
-- Both 1.0.0 and 1.0.1 are generated and packaged now.
-- changes.mdo had to be overhauled a bit to allow generating both versions
at once. Mostly 1.0.0 - 1.0.0+
* to take advantage of new schema, you must actually specify it in the config
(see MCHANGES-191)
* No translations for the new text: report.changes.text.artifacts=Artifact
download link:
(Sorry, I don't speak french, german or swedish :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[ http://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ol reopened MRELEASE-138: - I think this issue is linked to MRELEASE-261. It's not a duplicate of MRELEASE-6. I 'm still facing errors when trying to release a parent project that have some modules in another folder : \parent \moduleA \moduleB release:prepare fails when checking in modified POMs of a multi-modules project --- Key: MRELEASE-138 URL: http://jira.codehaus.org/browse/MRELEASE-138 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Environment: WinXP + Eclipse Reporter: ol Assignee: Emmanuel Venisse Priority: Critical Here is the project structure on the disk : c:\javadev\prj\myproject\module1 c:\javadev\prj\myproject\module2 c:\javadev\prj\myproject\master These 3 folders represent the 3 eclipse projects, each one containing a pom.xml. The master project's pom is the parent of the modules. When I execute the release:prepare goal, Everything works fine (it asks to me the tag name, the next dev version, ...) until I receive this error : [INFO] Checking in modified POMs... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not contained in C:\javadev\prj\myproject\master [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not contained in C:\javadev\prj\myproject\master at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) The problem is that the project structure is the only one that can be used with eclipse. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2721) New Maven Repository Upload Request
New Maven Repository Upload Request --- Key: MAVENUPLOAD-2721 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2721 Project: Maven Upload Requests Issue Type: Wish Reporter: Don Corley net.sourceforge.jcalendarbutton,mavens...@web.sourceforge.net:/home/groups/j/jc/jcalendarbutton/htdocs/m2repo,rsync_ssh,Don Corley,d...@donandann.com,, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207308#action_207308
]
Andreas Höhmann commented on MJAVADOC-276:
--
Please fix this issue!
Example:
Parent
Module A
Module B
B depends on A
For me it's not clear why the javadoc creation of module A invoke the
javadoc creation of module B?! Module A don't have any dependency to B.
regards
Andreas
Initial builds of a multi-module project fail
-
Key: MJAVADOC-276
URL: http://jira.codehaus.org/browse/MJAVADOC-276
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: bug.zip
I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
build failed ({{mvn clean install site}}) because Javadoc fails when run from
the top-level parent. When it is building _module A_, the javadoc complains
that _module B_ and _module C_ are missing -- of course they are, they
haven't been built yet. Note that running {{mvn clean install}} from _module
A_ works fine -- the behavior is limited to running from the top-level parent
-- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
have given it what it needs and so you won't see the error.
The attached example exhibits the problem. It was created from the
_j2ee-simple_ archetype -- I only added the explicit javadoc plugin
declaration to the top level pom to control the version being used. To
recreate the problem, unzip and simply: {{mvn clean install site}}. You
will get an error message like:
{noformat}
[INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) root.project.projects:logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=
[id]
Path to dependency:
1) root.project:primary-source:jar:1.0
2) root.project.projects:logging:jar:1.0
--
1 required artifact is missing.
for artifact:
root.project:primary-source:jar:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
{noformat}
As you can see, it seems to think that a submodule (in this case
{{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
for the project... Since this is the first time that this is being built,
the submodule does not exist (yet).
I have replicated this problem on two different computing environments, so
I'm convinced that the Maven version is not relevant.
(It is unclear to me if this problem also existed with Javadoc 2.6, but I
don't think so.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPSITE-63) mvangosso
mvangosso - Key: MPSITE-63 URL: http://jira.codehaus.org/browse/MPSITE-63 Project: Maven 1.x Site Plugin Issue Type: Improvement Components: plugin Affects Versions: 1.7.2 Environment: Doap apache sofware Reporter: Roger Mbiama Assogo Fix For: 1.7.2 project mysite distributionManagement site idwww.angosso.com/id urlhttp://www.angosso.com/www/docs/project//url /site /distributionManagement file:///C:/Users/angosso.com/Desktop/doap_licenses_angosso.com_index.html.xml /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4536) Long build time - enforcer running too many times
Long build time - enforcer running too many times - Key: MNG-4536 URL: http://jira.codehaus.org/browse/MNG-4536 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-alpha-6 Environment: Apache Maven 3.0-alpha-6 (r896384; 2010-01-06 11:00:46+) Java version: 1.6.0_16 Java home: C:\Java\jdk1.6.0_16\jre Default locale: en_GB, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: James Nord Attachments: m3.0-a6.zip A simple mvn clean validate has more than tripled in time on a multi module project I'm working on (when compared to 2.2.1). From what I've read on the list the 3.0-alpha-6 is supposed to be quicker than 2.x so I'm quite surprised by this. The project is a multi-module project, with a corporate pom at the top of the tree. From my interpretation of the build log the enforcer plugin is now validating more than just the current module's pom for each module build. e.g. Corp Pom (defines validation rules) ProjA (parent is corp pom) + ModA + Mod B + Mod C That is when mvn validate is run on proj A when the reactor moves to a mod A it runs the enforcer rules on ProjA ModA, ModB and ModC, and again when it builds Mod B it runs the enforecer rules again on all these modules etc... I would only expect the enforcer to run against the project/module that it is currently building (like maven 2.2.1). Note: the test project attached does not show the massive slowdown but does show the enforcer running too many times (mvn clean validate | grep enforce). The massive slowdown is due to the company enfrcer rules that perform a svn status for each invocation of the enforcer rules - but any enforcer rule which takes some time to complete will show the same results when run needlessly. mvn 2.2.1 output (mvn validate) [INFO] [INFO] Reactor Summary: [INFO] [INFO] Project : Parent .. SUCCESS [4.704s] [INFO] Project : Mod A ... SUCCESS [2.225s] [INFO] Project : Mod B ... SUCCESS [2.225s] [INFO] Project : Mod C ... SUCCESS [2.225s] [INFO] Project : Mod D ... SUCCESS [2.215s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 14 seconds mvn 3.0-alpha-6 output (mvn validate) [INFO] [INFO] Reactor Summary: [INFO] [INFO] Project : Parent .. SUCCESS [7.361s] [INFO] Project : Mod A ... SUCCESS [6.079s] [INFO] Project : Mod B ... SUCCESS [6.068s] [INFO] Project : Mod C ... SUCCESS [6.069s] [INFO] Project : Mod D ... SUCCESS [6.029s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 31.866s The reason by looking at the logs seems the enforcer rule is run for each module in the build for every module build. [INFO] [INFO] Building Project : Mod C 0.0.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ modc --- [INFO] complex enforcer rule starting [INFO] complex enforcer rule finished [INFO] [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ parent --- [INFO] complex enforcer rule starting [INFO] complex enforcer rule finished [INFO] [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ moda --- [INFO] complex enforcer rule starting [INFO] complex enforcer rule finished [INFO] [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ modb --- [INFO] complex enforcer rule starting [INFO] complex enforcer rule finished [INFO] [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ modc --- [INFO] complex enforcer rule starting [INFO] complex enforcer rule finished [INFO] [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ modd --- [INFO] complex enforcer rule starting [INFO] complex enforcer rule finished [INFO] [INFO] --- maven-scm-plugin:1.2:validate (validate) @ modc --- [INFO] Whilst in Maven 2.2.1 the rules are run twice for each
[jira] Commented: (MNGSITE-4) broken links on http://maven.apache.org/plugins
[ http://jira.codehaus.org/browse/MNGSITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207311#action_207311 ] Dennis Lundberg commented on MNGSITE-4: --- The link in Assembly Plugin was fixed in [r900452|http://svn.apache.org/viewvc?view=revisionrevision=900452]. broken links on http://maven.apache.org/plugins --- Key: MNGSITE-4 URL: http://jira.codehaus.org/browse/MNGSITE-4 Project: Maven 2 Project Web Site Issue Type: Bug Reporter: Tom Huybrechts a list of broken links on the maven site http://maven.apache.org/plugins/maven-repository-plugin/faq.html http://maven.apache.org/plugins/maven-war-plugin/faq.html http://maven.apache.org/plugins/maven-dependency-plugin/faq.html http://maven.apache.org/plugins/maven-docck-plugin/taglist.html http://maven.apache.org/plugins/maven-repository-plugin/usage.html http://maven.apache.org/plugins/maven-jxr-plugin/faq.html http://maven.apache.org/plugins/maven-checkstyle-plugin/dependencies.html http://maven.apache.org/plugins/maven-verifier-plugin/faq.html http://maven.apache.org/plugins/maven-doap-plugin/examples/options.html http://maven.apache.org/plugins/maven-ejb-plugin/usage.html http://maven.apache.org/plugins/maven-ejb-plugin/faq.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-4) broken links on http://maven.apache.org/plugins
[ http://jira.codehaus.org/browse/MNGSITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-4. - Resolution: Fixed Assignee: Dennis Lundberg Closing this now that all issues have been fixed in SVN. broken links on http://maven.apache.org/plugins --- Key: MNGSITE-4 URL: http://jira.codehaus.org/browse/MNGSITE-4 Project: Maven 2 Project Web Site Issue Type: Bug Reporter: Tom Huybrechts Assignee: Dennis Lundberg a list of broken links on the maven site http://maven.apache.org/plugins/maven-repository-plugin/faq.html http://maven.apache.org/plugins/maven-war-plugin/faq.html http://maven.apache.org/plugins/maven-dependency-plugin/faq.html http://maven.apache.org/plugins/maven-docck-plugin/taglist.html http://maven.apache.org/plugins/maven-repository-plugin/usage.html http://maven.apache.org/plugins/maven-jxr-plugin/faq.html http://maven.apache.org/plugins/maven-checkstyle-plugin/dependencies.html http://maven.apache.org/plugins/maven-verifier-plugin/faq.html http://maven.apache.org/plugins/maven-doap-plugin/examples/options.html http://maven.apache.org/plugins/maven-ejb-plugin/usage.html http://maven.apache.org/plugins/maven-ejb-plugin/faq.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRELEASE-83: Fix Version/s: (was: 2.0) Moving to a later version. Wrong username during release:prepare tagging - Key: MRELEASE-83 URL: http://jira.codehaus.org/browse/MRELEASE-83 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Reporter: Niclas Hedhman If I my Svn repository requires a different username than the login name, and I issue mvn -dmaven.username=nic...@hedhman.org release:prepare The first phase (checking in modified POMs) will succeed with that username. Then somewhere between that point and writing out the release.properties file, the user name falls back to the login name (in my case niclas), which is written into the release.properties file, and used during the tagging of the repository. Now, looking at the source, I think that is unwise to keep a username both in the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that there is some type of sequencing problem in there. WORKAROUND; Before starting the release:prepare, create a release.properties file manually which contains maven.username=nic...@hedhman.org and everything will work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-449) Parent snapshot version is not rewritten to resolved non-snapshot version during release:prepare
[
http://jira.codehaus.org/browse/MRELEASE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MRELEASE-449:
-
Fix Version/s: (was: 2.0)
Moving to a later version.
Parent snapshot version is not rewritten to resolved non-snapshot version
during release:prepare
Key: MRELEASE-449
URL: http://jira.codehaus.org/browse/MRELEASE-449
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Reporter: Steve Gilbert
Priority: Critical
Attachments: maven-release-rewrite-parent-bug.patch,
parent_version_rewrite_bug.zip
When a pom has a parent specified with a snapshot version, when mvn
release:prepare is executed, the version entered by the user when prompted
to resolve the parent version is not used when the pom is rewritten. The
parent version remains at the snapshot version in the rewritten pom.
This happens in dry run mode and normal mode.
I will attach a zip file with a simple example/test case that shows the bug.
The steps to reproduce using the zip file:
1. cd to parent
2. execute mvn install
3. cd to ../child
4. execute mvn -DdryRun=true release:prepare answering yes to the first
resolve dependencies? question and then answering with the default to
all the other questions
5. cat pom.xml.tag noticing the parent SNAPSHOT version has not been replaced
The cause of this appears to be in AbstractRewritePomsPhase.rewriteParent.
This method only consults the mappedVersions Map, however when the release
plugin is executed from the command line and the user enters the version
number to resolve the snapshot dependency (even using the default provided by
the release plugin) the values are stored in the resolvedSnapshotDependencies
Map only.
I've modified the code to consult both Maps which is what other methods in
the class do when rewriting dependency snapshot revisions. I have provided a
patch with the modified code. The patch also contains a new test method in
RewritePomsForReleasePhaseTest that will fail without the patch and pass with
it.
The patch was taken from maven-release 2.0-beta-9 and can be applied with
{code}
patch -p0 ~/maven-release-rewrite-parent-bug.patch
{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: (MPSITE-63) mvangosso
[ http://jira.codehaus.org/browse/MPSITE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPSITE-63. -- Resolution: Incomplete Fix Version/s: (was: 1.7.2) It's not at all clear what you are reporting. mvangosso - Key: MPSITE-63 URL: http://jira.codehaus.org/browse/MPSITE-63 Project: Maven 1.x Site Plugin Issue Type: Improvement Components: plugin Affects Versions: 1.7.2 Environment: Doap apache sofware Reporter: Roger Mbiama Assogo Original Estimate: 1 year, 7 weeks, 6 days Remaining Estimate: 1 year, 7 weeks, 6 days project mysite distributionManagement site idwww.angosso.com/id urlhttp://www.angosso.com/www/docs/project//url /site /distributionManagement file:///C:/Users/angosso.com/Desktop/doap_licenses_angosso.com_index.html.xml /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2722) Please sync net.sf.easyweb4j automatically
Please sync net.sf.easyweb4j automatically -- Key: MAVENUPLOAD-2722 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2722 Project: Maven Upload Requests Issue Type: Wish Reporter: Chandra Sekar S net.sf.easyweb4j,mavens...@web.sourceforge.net:/home/groups/e/ea/easyweb4j/htdocs/repo,rsync_ssh,Chandra Sekar S,chandru...@gmail.com,, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MSHARED-142) mvn not found when invoking the verifier from IDEA
[
http://jira.codehaus.org/browse/MSHARED-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MVERIFIER-5 to MSHARED-142:
--
Key: MSHARED-142 (was: MVERIFIER-5)
Project: Maven Shared Components (was: Maven 2.x Verifier Plugin)
mvn not found when invoking the verifier from IDEA
--
Key: MSHARED-142
URL: http://jira.codehaus.org/browse/MSHARED-142
Project: Maven Shared Components
Issue Type: Bug
Components: maven-verifier
Environment: MacOsX
Reporter: Stephane Nicoll
Priority: Minor
When i use the verifier in Intellij IDEA, the verifier is unable to find mvn
in the path. I don't have the problem on Linux/Windows XP.
The path is set properly
{noformat}
org.apache.maven.it.VerificationException:
org.apache.maven.it.util.cli.CommandLineException: Error while executing
process.
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:907)
at org.apache.maven.it.Verifier.executeGoal(Verifier.java:780)
at org.apache.maven.it.Verifier.executeGoal(Verifier.java:774)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:84)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:114)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:132)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:161)
at
org.apache.maven.plugin.ear.EarMojoTest.testProject038(EarMojoTest.java:411)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
Caused by: org.apache.maven.it.util.cli.CommandLineException: Error while
executing process.
at
org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:737)
at
org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:101)
at
org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:87)
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:901)
... 23 more
Caused by: java.io.IOException: mvn: not found
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.init(UNIXProcess.java:52)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at
org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:732)
... 26 more
{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: (MSHARED-142) mvn not found when invoking the verifier from IDEA
[
http://jira.codehaus.org/browse/MSHARED-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MSHARED-142:
-
Component/s: maven-verifier
mvn not found when invoking the verifier from IDEA
--
Key: MSHARED-142
URL: http://jira.codehaus.org/browse/MSHARED-142
Project: Maven Shared Components
Issue Type: Bug
Components: maven-verifier
Environment: MacOsX
Reporter: Stephane Nicoll
Priority: Minor
When i use the verifier in Intellij IDEA, the verifier is unable to find mvn
in the path. I don't have the problem on Linux/Windows XP.
The path is set properly
{noformat}
org.apache.maven.it.VerificationException:
org.apache.maven.it.util.cli.CommandLineException: Error while executing
process.
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:907)
at org.apache.maven.it.Verifier.executeGoal(Verifier.java:780)
at org.apache.maven.it.Verifier.executeGoal(Verifier.java:774)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:84)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:114)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:132)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:161)
at
org.apache.maven.plugin.ear.EarMojoTest.testProject038(EarMojoTest.java:411)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
Caused by: org.apache.maven.it.util.cli.CommandLineException: Error while
executing process.
at
org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:737)
at
org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:101)
at
org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:87)
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:901)
... 23 more
Caused by: java.io.IOException: mvn: not found
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.init(UNIXProcess.java:52)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at
org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:732)
... 26 more
{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] Moved: (MPA-115) Enable SSL downloads for maven repository
[ http://jira.codehaus.org/browse/MPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-4535 to MPA-115: --- Complexity: (was: Intermediate) Component/s: (was: Artifacts and Repositories) Repository Management Reporter: Brett Porter (was: Simon Hartmann) Key: MPA-115 (was: MNG-4535) Project: Maven Project Administration (was: Maven 2 3) Enable SSL downloads for maven repository - Key: MPA-115 URL: http://jira.codehaus.org/browse/MPA-115 Project: Maven Project Administration Issue Type: Wish Components: Repository Management Reporter: Brett Porter Currently maven2 repositories are only accessible via HTTP. In some corporate environments security settings require downloads of artifacts via HTTPS (SSL) protocol. Would it be possible to allow SSL access to one of the maven repositories as this is merely a minor web server configuration 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] Updated: (MPA-115) Enable SSL downloads for maven repository
[ http://jira.codehaus.org/browse/MPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MPA-115: - Reporter: Simon Hartmann (was: Brett Porter) Enable SSL downloads for maven repository - Key: MPA-115 URL: http://jira.codehaus.org/browse/MPA-115 Project: Maven Project Administration Issue Type: Wish Components: Repository Management Reporter: Simon Hartmann Currently maven2 repositories are only accessible via HTTP. In some corporate environments security settings require downloads of artifacts via HTTPS (SSL) protocol. Would it be possible to allow SSL access to one of the maven repositories as this is merely a minor web server configuration 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] Closed: (MPA-112) Removed MAVENREPOMAINT
[ http://jira.codehaus.org/browse/MPA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-112. Resolution: Fixed Removed MAVENREPOMAINT -- Key: MPA-112 URL: http://jira.codehaus.org/browse/MPA-112 Project: Maven Project Administration Issue Type: Bug Affects Versions: 2007-q4 Reporter: Vincent Siveton Priority: Minor Seems that http://jira.codehaus.org/browse/MAVENREPOMAINT is unused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-114) Merge JIRA projects WAGONSSH, WAGONFTP and WAGONHTTP into the corresponding components over at WAGON
[ http://jira.codehaus.org/browse/MPA-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-114. Resolution: Fixed Assignee: Brett Porter Merge JIRA projects WAGONSSH, WAGONFTP and WAGONHTTP into the corresponding components over at WAGON Key: MPA-114 URL: http://jira.codehaus.org/browse/MPA-114 Project: Maven Project Administration Issue Type: Task Components: Issue Management Reporter: Benjamin Bentmann Assignee: Brett Porter Priority: Minor We currently have some duplicate spaces to go for wagon issues. There's WAGON which seems to be the primary project, having components for the various providers, and yet there are separate projects for WAGONSSH, WAGONFTP and WAGONHTTP. I guess the later ones should be moved into the components over at WAGON and then get removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-261) release:prepare should support flat directory multi-module projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207331#action_207331
]
Dennis Lundberg commented on MRELEASE-261:
--
Eric,
I've been playing around with your example on my virtual Ubuntu to try to
reproduce your problems.
I'm having problems understanding what the directory structure in SVN looks
like for your example.
Can you please describe it for us?
Here's what I think, based on the POMs.
{noformat}
+--release-parent/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
|
+--release-module1/trunk/pom.xml
{noformat}
Is that correct?
Is that how multi module projects with a flat structure are usually stored in
SVN?
release:prepare should support flat directory multi-module projects
---
Key: MRELEASE-261
URL: http://jira.codehaus.org/browse/MRELEASE-261
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Environment: linux / maven2 / svn
Reporter: paul.whe...@gmail.com
Assignee: Maria Odea Ching
Fix For: 2.0
Attachments: flatProject.main.patch, flatProject.test.patch,
maven-release-issue.tar.gz, maven-release-issue.zip,
MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch,
MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png,
PrepareReleaseMojo.patch
What I mean by flat file structure firstly.
parent/pom.xml
module1/pom.xml
module2/pom.xml
.
.
.
module15/pom.xml
the parent references the modules like so
modules
module../module1/module
module../module2/module
.
.
.
module../module15/module
/modules
When i release:prepare only the parent project is tagged the modules
projects versions are incremented etc but the modules are not tagged in svn.
I use this structure as i use eclipse as my IDE.
I would love to see a fix for the issue marked as closed here
http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
each submodule of the projects but it would be so nice to have the release
plugin do this for me.
forgive my english.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MPA-88) move ci.sh to continuum
[ http://jira.codehaus.org/browse/MPA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-88. --- Resolution: Fixed Assignee: (was: Brett Porter) move ci.sh to continuum --- Key: MPA-88 URL: http://jira.codehaus.org/browse/MPA-88 Project: Maven Project Administration Issue Type: Task Reporter: Brett Porter Priority: Minor there shouldn't be any need for a manual CI build - let's move it to coninuum when we can. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-78) add license text to confluence wikis
[ http://jira.codehaus.org/browse/MPA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-78. --- Resolution: Won't Fix add license text to confluence wikis Key: MPA-78 URL: http://jira.codehaus.org/browse/MPA-78 Project: Maven Project Administration Issue Type: Task Components: Sites Reporter: Brett Porter we should add a notice to the wiki (perhaps in the footer?) that indicates to users and contributors what the license for submitted content is (presumably, ASL) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-32) make suitable arrangements with other maven mirrors
[ http://jira.codehaus.org/browse/MPA-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-32. --- Resolution: Fixed make suitable arrangements with other maven mirrors --- Key: MPA-32 URL: http://jira.codehaus.org/browse/MPA-32 Project: Maven Project Administration Issue Type: Sub-task Components: Repository Management Affects Versions: 2006-q3 Reporter: Brett Porter once we turn off the additional syncing of maven1 content, then the other mirrors will not get updated. We should see if they can map the content using mod_rewrite as well -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-33) turn off maven1 sync/uploads
[ http://jira.codehaus.org/browse/MPA-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-33. --- Resolution: Fixed turn off maven1 sync/uploads Key: MPA-33 URL: http://jira.codehaus.org/browse/MPA-33 Project: Maven Project Administration Issue Type: Sub-task Components: Repository Management Affects Versions: 2006-q3 Reporter: Brett Porter we need to stop uploading new artifacts to the maven1 repo, and stop syncing outwards to ibiblio (we still need to sync in from other sources, however, but this will soon be taken care of by the repo application). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-31) have ibiblio convert .htaccess rules to httpd.conf
[ http://jira.codehaus.org/browse/MPA-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-31. --- Resolution: Won't Fix have ibiblio convert .htaccess rules to httpd.conf -- Key: MPA-31 URL: http://jira.codehaus.org/browse/MPA-31 Project: Maven Project Administration Issue Type: Sub-task Components: Repository Management Affects Versions: 2006-q3 Reporter: Brett Porter after a sufficient period of testing, ibiblio has requested that the rules be moved to httpd.conf as its performance will be better than in .htaccess -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-100) resolve integration test problems
[ http://jira.codehaus.org/browse/MPA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-100. Resolution: Fixed resolve integration test problems - Key: MPA-100 URL: http://jira.codehaus.org/browse/MPA-100 Project: Maven Project Administration Issue Type: Task Reporter: Brett Porter Assignee: John Casey http://docs.codehaus.org/display/MAVEN/IT+Problems Inidividual tasks for this should be created in the MNG JIRA itself. Issues should be linked here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPA-29) Create mod_rewrite rules to divert m1 repository requests to the m2 repository
[ http://jira.codehaus.org/browse/MPA-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-29. --- Resolution: Fixed Create mod_rewrite rules to divert m1 repository requests to the m2 repository -- Key: MPA-29 URL: http://jira.codehaus.org/browse/MPA-29 Project: Maven Project Administration Issue Type: Task Components: Repository Management Affects Versions: 2006-q3 Reporter: Jason van Zyl Assignee: Brett Porter It is possible for us not to have to convert the repositories by turning an m1 repository request into an m2 style request and direct it at the m2 repository. This would allow us to maintain the one canonical 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] Closed: (MPA-107) Add a new Jira project for Plugin Tools
[ http://jira.codehaus.org/browse/MPA-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-107. Resolution: Won't Fix they are in the plugin project now Add a new Jira project for Plugin Tools --- Key: MPA-107 URL: http://jira.codehaus.org/browse/MPA-107 Project: Maven Project Administration Issue Type: Task Components: Issue Management Affects Versions: 2008-q1 Reporter: Vincent Siveton Maven project https://svn.apache.org/repos/asf/maven/plugin-tools/trunk Proposal for the Jira project MPLUGINTOOLS -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MPA-80) Open a staging sites area at http://maven.zones.apache.org/staging/
[ http://jira.codehaus.org/browse/MPA-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-80. --- Resolution: Won't Fix Open a staging sites area at http://maven.zones.apache.org/staging/ --- Key: MPA-80 URL: http://jira.codehaus.org/browse/MPA-80 Project: Maven Project Administration Issue Type: Task Components: Sites Affects Versions: 2006-q3 Reporter: Arnaud Heritier Assignee: Jason van Zyl Priority: Minor As discussed here [1] it could be interesting for us to have a common staging area to deploy our documentations (instead of using our accounts on people.apache.org). Brett proposed to use the zone for that : http://maven.zones.apache.org/staging/ (maven 2) http://maven.zones.apache.org/staging/maven-1.x/ (maven 1 ie, following live site structure). I think that all committers must have the rights to deploy the web sites here. [1] http://www.nabble.com/CI-for-M1-%3A-Can-I-use-a-continuum-instance-somewhere---tf2051570.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPA-72) Please make sources jar available to Maven1 users
[ http://jira.codehaus.org/browse/MPA-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-72. --- Resolution: Won't Fix Please make sources jar available to Maven1 users --- Key: MPA-72 URL: http://jira.codehaus.org/browse/MPA-72 Project: Maven Project Administration Issue Type: Bug Components: Repository Management Reporter: Emmanuel Venisse Assignee: Brett Porter Hello guys, From a previous post I know Maven1 repo is a redirect to maven2 repository content, with path transcripted to match maven2 hierarchy. commons-collection (as an example) has sources jar in maven2 repo (http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.1/commons-collections-3.1-sources.jar), but I cannot get them using maven1 from http://www.ibiblio.org/maven/commons-collections/java-sources/commons-collections-3.1-sources.jar Maybe a new Apache rewrite rule may be required for this. I would also be very interested if someone can give me the rewrite rule used on ibiblio to convert m1 dependency path to m2 repo hierarchy. Nicolas De Loof -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ http://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207349#action_207349 ] Ian Springer commented on MNG-1991: --- Note: The maven warpath plugin (http://static.appfuse.org/maven-warpath-plugin/) provides a workaround to this issue. I tried it out, and it worked nicely for me. Can't get transitive dependencies from a war pom when this war is added as a depdency of a project -- Key: MNG-1991 URL: http://jira.codehaus.org/browse/MNG-1991 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.2 Reporter: Emmanuel Venisse Fix For: 3.x (to be reviewed) I have a project (continuum-core-it) that need to use all transitive dependencies of a war (continuum-webapp). If i add the war as a dependency of the project with packaging war, war dependencies aren't shown by project, maven doesn't try to resolve them and doesn't add them in classpath. If if replace packaging from war to pom, all dependencies are resolved and added to classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-634) projectNameTemplate not applied to project references
projectNameTemplate not applied to project references
-
Key: MECLIPSE-634
URL: http://jira.codehaus.org/browse/MECLIPSE-634
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : .project
Affects Versions: 2.7
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_16
Java home: C:\Program Files\Java\jdk1.6.0_16\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows vista version: 6.0 arch: amd64 Family: windows
Reporter: Gary Gregory
When I run the command:
mvn -Psetup.eclipse -Declipse.projectNameTemplate=[artifactId]-2.2.x
I get .project files like this one:
{code:xml}
projectDescription
namecxf-api-2.2.x/name
comment/
projects
projectcxf-common-schemas/project
projectcxf-common-utilities/project
projectcxf-xjc-dv/project
/projects
buildSpec
buildCommand
nameorg.eclipse.jdt.core.javabuilder/name
/buildCommand
buildCommand
namenet.sourceforge.pmd.eclipse.plugin.pmdBuilder/name
/buildCommand
buildCommand
namenet.sf.eclipsecs.core.CheckstyleBuilder/name
/buildCommand
buildCommand
namecom.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder/name
/buildCommand
/buildSpec
natures
natureorg.eclipse.jdt.core.javanature/nature
naturenet.sourceforge.pmd.eclipse.plugin.pmdNature/nature
naturenet.sf.eclipsecs.core.CheckstyleNature/nature
naturecom.atlassw.tools.eclipse.checkstyle.CheckstyleNature/nature
/natures
/projectDescription
{code}
You will notice the name has been correctly written:
{code:xml}
namecxf-api-2.2.x/name
{code}
BUT, the references do not have the correct names:
{code:xml}
projects
projectcxf-common-schemas/project
projectcxf-common-utilities/project
projectcxf-xjc-dv/project
/projects
{code}
They should be:
{code:xml}
projects
projectcxf-common-schemas-2.2.x/project
projectcxf-common-utilities-2.2.x/project
projectcxf-xjc-dv-2.2.x/project
/projects
{code}
Which cause the projects to be marked with errors in Eclipse and the workspace
build cannot complete.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207361#action_207361 ] Eric Miles commented on MRELEASE-261: - Dennis, Yes, you are correct in that's the structure. I'm not sure how flat multi-module projects are usually stored in SVN, however, I'm a consultant and have been on 3 different clients/projects i the last 2 years and all 3 of these clients had their subversion repo setup this way (were setup LONG before I got there). Regardless, I would think the release plugin would work appropriately no matter what my SVN structure is considering that metadata is provided in the POM. I would think it shouldn't care how it's stored in SVN (or any SCM for that matter) nor should it care what structure it is in as long as the parent pom is available (in the reactor or available via relativePath). release:prepare should support flat directory multi-module projects --- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Fix For: 2.0 Attachments: flatProject.main.patch, flatProject.test.patch, maven-release-issue.tar.gz, maven-release-issue.zip, MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207361#action_207361 ] Eric Miles edited comment on MRELEASE-261 at 1/18/10 7:02 PM: -- Dennis, Yes, you are correct in that's the structure. I'm not sure how flat multi-module projects are usually stored in SVN, however, I'm a consultant and have been on 3 different clients/projects i the last 2 years and all 3 of these clients had their subversion repo setup this way (were setup LONG before I got there). Regardless, I would think the release plugin would work appropriately no matter what my SVN structure is considering that metadata is provided in the POM. I would think it shouldn't care how it's stored in SVN (or any SCM for that matter) nor should it care what structure it is in as long as the parent pom is available (in the reactor or available via relativePath). I'm guessing that's a false assumption at this point :) was (Author: bigehokie): Dennis, Yes, you are correct in that's the structure. I'm not sure how flat multi-module projects are usually stored in SVN, however, I'm a consultant and have been on 3 different clients/projects i the last 2 years and all 3 of these clients had their subversion repo setup this way (were setup LONG before I got there). Regardless, I would think the release plugin would work appropriately no matter what my SVN structure is considering that metadata is provided in the POM. I would think it shouldn't care how it's stored in SVN (or any SCM for that matter) nor should it care what structure it is in as long as the parent pom is available (in the reactor or available via relativePath). release:prepare should support flat directory multi-module projects --- Key: MRELEASE-261 URL: http://jira.codehaus.org/browse/MRELEASE-261 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Environment: linux / maven2 / svn Reporter: paul.whe...@gmail.com Assignee: Maria Odea Ching Fix For: 2.0 Attachments: flatProject.main.patch, flatProject.test.patch, maven-release-issue.tar.gz, maven-release-issue.zip, MRELEASE-261-sample-project.zip, MRELEASE-261-with-its-v3.patch, MRELEASE-261-with-its.patch, MRELEASE-261.patch, odd-tags.png, PrepareReleaseMojo.patch What I mean by flat file structure firstly. parent/pom.xml module1/pom.xml module2/pom.xml . . . module15/pom.xml the parent references the modules like so modules module../module1/module module../module2/module . . . module../module15/module /modules When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn. I use this structure as i use eclipse as my IDE. I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me. forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-4537) --update-snapshots command line option flag is misleading, as it actually updates releases too
--update-snapshots command line option flag is misleading, as it actually updates releases too -- Key: MNG-4537 URL: http://jira.codehaus.org/browse/MNG-4537 Project: Maven 2 3 Issue Type: Improvement Components: Command Line Affects Versions: 3.0-alpha-6, 3.0-alpha-5, 2.2.1, 2.0.10, 2.0.9 Reporter: Matthew McCullough Attachments: remove-misleading-updatesnapshots-option.patch Had a discussion with Brett Porter, Brian Fox, and Benjamin Bentmann on IRC about how the --update-snapshots command line option is misleading. I, as well as some of my students, we using -up, expecting downloads that previously failed to be tried again. However, that flag only checks for metadata updates to see if a newer version of the plugin has been released. What we were after is the -U flag (synonymous with --update-snapshots) which also checks again remotely for SNAPSHOT and RELEASE downloads that previously failed. Brett and Brian suggested that we either deprecate the old --update-snapshots long option, but that's not entirely possible since the short and long options are tied together. So, as a compromise solution, I'm indicating that the --update-snapshots option flag (name) may go away in the future and adding a migrate-to option called --update-all which was suggested in the above IRC conversation. Functionally, this long flag performs the same operation as --update-snapshots, but the name much more effectively communicates that it updates all artifacts from remote repos, not just snapshots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-4537) --update-snapshots command line option flag is misleading, as it actually updates releases too
[
http://jira.codehaus.org/browse/MNG-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=207402#action_207402
]
Matthew McCullough commented on MNG-4537:
-
When an artifact is not found, it points to [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
Benjamin and I have added an update and a comment respectively to this page to
clarify the usage of -U for forcing an update of artifacts.
[sample-webapp] mvn package
Using Java version: 1.6
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.ambientideas:sample-webapp:war:1.0-SNAPSHOT
[WARNING] The expression ${version} is deprecated. Please use
${project.version} instead. @ com.ambientideas:sample-webapp:1.0-SNAPSHOT,
/Users/mccm06/Documents/Temp/Scratch/sample-webapp/pom.xml
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO]
[INFO] Building sample-webapp Maven Webapp 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.325s
[INFO] Finished at: Mon Jan 18 14:33:51 MST 2010
[INFO] Final Memory: 3M/80M
[INFO]
[ERROR] Plugin org.mule.galaxy:galaxy-maven-publish-plugin:2.0-M4 or one of its
dependencies could not be resolved: Missing:
--
1) org.mule.galaxy:galaxy-maven-publish-plugin:maven-plugin:2.0-M4
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.mule.galaxy
-DartifactId=galaxy-maven-publish-plugin -Dversion=2.0-M4
-Dpackaging=maven-plugin -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.mule.galaxy
-DartifactId=galaxy-maven-publish-plugin -Dversion=2.0-M4
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
--
1 required artifact is missing.
for artifact:
org.mule.galaxy:galaxy-maven-publish-plugin:maven-plugin:2.0-M4
from the specified remote repositories:
nexus-public-releases (http://localhost:8081/nexus/content/groups/public,
releases=true, snapshots=true)
- [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
--update-snapshots command line option flag is misleading, as it actually
updates releases too
--
Key: MNG-4537
URL: http://jira.codehaus.org/browse/MNG-4537
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line
Affects Versions: 2.0.9, 2.0.10, 2.2.1, 3.0-alpha-5, 3.0-alpha-6
Reporter: Matthew McCullough
Attachments: remove-misleading-updatesnapshots-option.patch
Had a discussion with Brett Porter, Brian Fox, and Benjamin Bentmann on IRC
about how the --update-snapshots command line option is misleading. I, as
well as some of my students, we using -up, expecting downloads that
previously failed to be tried again. However, that flag only checks for
metadata updates to see if a newer version of the plugin has been released.
What we were after is the -U flag (synonymous with --update-snapshots) which
also checks again remotely for SNAPSHOT and RELEASE downloads that previously
failed.
Brett and Brian suggested that we either deprecate the old --update-snapshots
long option, but that's not entirely possible since the short and long
options are tied together. So, as a compromise solution, I'm indicating that
the --update-snapshots option flag (name) may go away in the future and
adding a migrate-to option called --update-all which was suggested in the
above IRC conversation. Functionally, this long flag performs the same
operation as --update-snapshots, but the name much more effectively
communicates that it updates all artifacts from remote repos, not just
snapshots.
--
This
