[jira] Created: (MDEP-45) Documentation is wrong on maven.apache.org
Documentation is wrong on maven.apache.org -- Key: MDEP-45 URL: http://jira.codehaus.org/browse/MDEP-45 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Meghan Claire Pike Priority: Minor http://maven.apache.org/plugins/maven-dependency-plugin/howto.html is wrong, it still points to the maven-dependency-plugin from apache... whereas it should be the dependency-maven-plugin from codehaus instead... right? -- 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-2631) M2 searches artefacts in wrong repo when using ranges
M2 searches artefacts in wrong repo when using ranges
-
Key: MNG-2631
URL: http://jira.codehaus.org/browse/MNG-2631
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.4
Environment: Two repos, one internal for releases and one internal for
snapshots (snapshotRepository) specified in distributionmanagement
Reporter: Sebastian Krebs
dependency
...
version[0.8,)/version
...
/dependency
I get following error while compile this second project:
Downloading:
http://{myServer}/internal/{groupId}/{artifactId}/1.0/{artefactId}-1.0.pom
Downloading:
http://{myServer}/snapshot/{groupId}/{artifactId}/1.0/{artefactId}-1.0.jar
It looks like Maven searches the pom on my internal repo and the belonging
artefact on the snapshotRepo.
As I have understood, reading BetterBuildsWithMaven site 215, Maven should find
my artefact in my normal repo.
--
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-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_78502 ] Bugittaa Pahasti commented on MNG-1577: --- My opinion is that the scope should be also possible to override, because there are so many poms with invalid dependencies. Perhaps we need a second property overrideScope? dependencyManagement does not work for transitive dependencies -- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.1 Attachments: mng1577.patch, mng1577a.patch, mng1577b.patch, mng1577c.patch, mng1577d.patch, mng1577trunk.patch The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- 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-2631) M2 searches artefacts in wrong repo when using ranges
[ http://jira.codehaus.org/browse/MNG-2631?page=comments#action_78506 ]
Carlos Sanchez commented on MNG-2631:
-
distributionManagement is only used for uploads, not for downloads so that's
not the problem. You need to provide more info
M2 searches artefacts in wrong repo when using ranges
-
Key: MNG-2631
URL: http://jira.codehaus.org/browse/MNG-2631
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.4
Environment: Two repos, one internal for releases and one internal
for snapshots (snapshotRepository) specified in distributionmanagement
Reporter: Sebastian Krebs
dependency
...
version[0.8,)/version
...
/dependency
I get following error while compile this second project:
Downloading:
http://{myServer}/internal/{groupId}/{artifactId}/1.0/{artefactId}-1.0.pom
Downloading:
http://{myServer}/snapshot/{groupId}/{artifactId}/1.0/{artefactId}-1.0.jar
It looks like Maven searches the pom on my internal repo and the belonging
artefact on the snapshotRepo.
As I have understood, reading BetterBuildsWithMaven site 215, Maven should
find my artefact in my normal repo.
--
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: (MIDEA-75) mvn idea:idea fails with StringIndexOutOfBoundsException (toRelative method) when adding resource to base project
mvn idea:idea fails with StringIndexOutOfBoundsException (toRelative method)
when adding resource to base project
-
Key: MIDEA-75
URL: http://jira.codehaus.org/browse/MIDEA-75
Project: Maven 2.x Idea Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Silvestrov Ilya
Attachments: ideaPluginBug.zip
I want a base project to handle special resource which is located in not
default location.
Example: I want all my projects to pack file history.txt located in project
basedir into jar.
So, this resource is mentioned in parent project:
build
resources
resource
directory${basedir}/directory
includes
includehistory.txt/include
/includes
/resource
/resources
/build
When I package child project it works well. But when I try to run idea:idea (or
idea:module) it fails with following stacktrace:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1444)
at java.lang.String.substring(String.java:1411)
at
org.apache.maven.plugin.idea.AbstractIdeaMojo.toRelative(AbstractIdeaMojo.java:217)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.getModuleFileUrl(IdeaModuleMojo.java:777)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.getModuleFileUrl(IdeaModuleMojo.java:782)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.addSourceFolder(IdeaModuleMojo.java:797)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.rewriteModule(IdeaModuleMojo.java:278)
at
org.apache.maven.plugin.idea.IdeaMojo.rewriteModule(IdeaMojo.java:205)
at org.apache.maven.plugin.idea.IdeaMojo.execute(IdeaMojo.java:185)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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:324)
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)
parent and child project examples are attached.
--
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-2631) M2 searches artefacts in wrong repo when using ranges
[ http://jira.codehaus.org/browse/MNG-2631?page=comments#action_78507 ]
Sebastian Krebs commented on MNG-2631:
--
Sorry,
my fault, I've forgotten to write the following.
I've specified those two repositories in my settings.xml as well.
profile
repositories
repository
idInternal/id
nameInternal Repository/name
urldav:http://{myServer}/internal/url
snapshots
enabledfalse/enabled
/snapshots
/repository
repository
idsnapshot/id
nameSnaphshot Repository/name
urldav:http://{myServer}/snapshot/url
snapshots
enabledtrue/enabled
/snapshots
/repository
/repositories
/profile
This is my parent.pom
modelVersion4.0.0/modelVersion
groupIdde.myCompany/groupId
artifactIdmyCompany/artifactId
nameMYCOMPANY/name
version1.2/version
packagingpom/packaging
distributionManagement
repository
idInternal/id
name Internal Repository/name
urldav:http://{myServer}/internal/url
/repository
snapshotRepository
idSnapshot/id
nameInternal Snapshot Repository/name
urldav:http://{myServer}/snapshot/url
/snapshotRepository
/distributionManagement
build
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-webdav/artifactId
version1.0-beta-1/version
/extension
/extensions
/build
/project
and all my other projects inherit from this one.
Deploying works fine, in internal repo and in snapshotrepo as well.
Getting the dependencies works correct as long as I define a normal version
like version1.0/version in dependencies
But if I use a version-range, something like version[0.8,)/version
I get the reported error.
M2 searches artefacts in wrong repo when using ranges
-
Key: MNG-2631
URL: http://jira.codehaus.org/browse/MNG-2631
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.4
Environment: Two repos, one internal for releases and one internal
for snapshots (snapshotRepository) specified in distributionmanagement
Reporter: Sebastian Krebs
dependency
...
version[0.8,)/version
...
/dependency
I get following error while compile this second project:
Downloading:
http://{myServer}/internal/{groupId}/{artifactId}/1.0/{artefactId}-1.0.pom
Downloading:
http://{myServer}/snapshot/{groupId}/{artifactId}/1.0/{artefactId}-1.0.jar
It looks like Maven searches the pom on my internal repo and the belonging
artefact on the snapshotRepo.
As I have understood, reading BetterBuildsWithMaven site 215, Maven should
find my artefact in my normal repo.
--
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-2631) M2 searches artefacts in wrong repo when using ranges
[ http://jira.codehaus.org/browse/MNG-2631?page=comments#action_78508 ]
Carlos Sanchez commented on MNG-2631:
-
You haven't set releases to false in the snapshot repo so for maven it's also a
releases repo
M2 searches artefacts in wrong repo when using ranges
-
Key: MNG-2631
URL: http://jira.codehaus.org/browse/MNG-2631
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.4
Environment: Two repos, one internal for releases and one internal
for snapshots (snapshotRepository) specified in distributionmanagement
Reporter: Sebastian Krebs
dependency
...
version[0.8,)/version
...
/dependency
I get following error while compile this second project:
Downloading:
http://{myServer}/internal/{groupId}/{artifactId}/1.0/{artefactId}-1.0.pom
Downloading:
http://{myServer}/snapshot/{groupId}/{artifactId}/1.0/{artefactId}-1.0.jar
It looks like Maven searches the pom on my internal repo and the belonging
artefact on the snapshotRepo.
As I have understood, reading BetterBuildsWithMaven site 215, Maven should
find my artefact in my normal repo.
--
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: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=comments#action_78510 ] Arnaud Heritier commented on MPPDF-57: -- Wendy, which release of maven are you using ? m1.0 or a beta/snapshot of m1.1 ? Unable to remove cover type and version --- Key: MPPDF-57 URL: http://jira.codehaus.org/browse/MPPDF-57 Project: maven-pdf-plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 1.1-RC1-SNAPSHOT Reporter: Wendy Smoak I'm trying to remove the 'cover type' and 'cover version' (set them to blank/nothing.) If I put the following in project.properties: maven.pdf.cover.type= maven.pdf.cover.version= I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version. If I try it again with '.' for both of those properties, cover type works (just prints a dot) but cover version prints 'v..'. This seems to call for something like a 'maven.pdf.cover.version.prefix' property (that can be set to blank.) -- 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-2632) Setting property in profiles is not evaluated for POM validation
Setting property in profiles is not evaluated for POM validation
Key: MNG-2632
URL: http://jira.codehaus.org/browse/MNG-2632
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.4
Environment: WinXP
Reporter: Christoph Amshoff
There seems to be a problem concerning POM validation and setting properties in
profiles.xml: when I set a property in my profiles.xml it is not evaluated for
POM validation in a multi module build.
The details: My project C depends on module B, which itself is a child of
module A. Module A defines a system scope dependency like this:
{code}
dependency
groupIddb2/groupId
artifactIddb2/artifactId
version8.2/version
scopesystem/scope
systemPath${path.db2jar}/systemPath
/dependency
{code}
The path to db2.jar depends on the developer's machine and is specified in the
profiles.xml, toghether with other settings. Both A and B are building and
deploying fine.
Now, when I try to build C, it complains about missing definition for
'path.db2jar':
{code}
[WARNING] POM for '...B:pom:4.4.0-SNAPSHOT:compile' is invalid. It will be
ignored for artifact resolution. Reason:
Failed to validate POM
[DEBUG] Reason: Failed to validate POM
[DEBUG]
Validation Errors:
[DEBUG] For dependency Dependency {groupId=db2, artifactId=db2, version=8.2,
type=jar}: system-scoped dependency
must specify an absolute path systemPath.
{code}
I'm using a profiles.xml section like this one:
{code}
profile
idenv-nb/id
activation
property
nameenv/name
valuenb/value
/property
/activation
properties
path.db2jarc:/programme/IBM/SQLLIB/java/db2java.zip/path.db2jar
...
/properties
/profile
{code}
which is triggered by -Denv=nb, and this activation is working fine since
'help:effective-pom' is correctly showing me something like
{code}
properties
path.db2jarc:/programme/IBM/SQLLIB/java/db2java.zip/path.db2jar
...
/properties
{code}
So the profiles.xml seems to be evaluated correctly, but the property is not
used for validating the POM of dependent modules.
And yes, when I run Maven without the profiles.xml, but with specifying the
property on command line (like '-Dpath.db2jar=...'), all is working fine! But
that's not exactly what we want, since profiles are meant to encapsulate those
kind of settings...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-970) Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared
[ http://jira.codehaus.org/browse/CONTINUUM-970?page=all ] Jesse McConnell closed CONTINUUM-970. - Resolution: Fixed ah yes, so I did. committed now r467991 Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared --- Key: CONTINUUM-970 URL: http://jira.codehaus.org/browse/CONTINUUM-970 Project: Continuum Issue Type: Improvement Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Fix For: 1.1 Attachments: CONTINUUM-970.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=all ] Lukas Theussl updated MPPDF-57: --- Assignee: Lukas Theussl Fix Version/s: 2.5.1 It's fixed in SVN but I can't deploy snapshots for the moment. If you could test it from SVN then we can close this. Unable to remove cover type and version --- Key: MPPDF-57 URL: http://jira.codehaus.org/browse/MPPDF-57 Project: maven-pdf-plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 1.1-RC1-SNAPSHOT Reporter: Wendy Smoak Assigned To: Lukas Theussl Fix For: 2.5.1 I'm trying to remove the 'cover type' and 'cover version' (set them to blank/nothing.) If I put the following in project.properties: maven.pdf.cover.type= maven.pdf.cover.version= I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version. If I try it again with '.' for both of those properties, cover type works (just prints a dot) but cover version prints 'v..'. This seems to call for something like a 'maven.pdf.cover.version.prefix' property (that can be set to blank.) -- 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-1197) Upload jsch.0.1.29 to the maven central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1197?page=comments#action_78517 ] Carlos Sanchez commented on MAVENUPLOAD-1197: - Next time upload to groupId com.jcraft.jsch Upload jsch.0.1.29 to the maven central repository -- Key: MAVENUPLOAD-1197 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1197 Project: maven-upload-requests Issue Type: Task Reporter: Antoine Levy-Lambert Assigned To: Carlos Sanchez Attachments: jsch-0.1.29-bundle.jar Hi, Ant 1.7.0 will soon be released and depends upon jsch 0.1.29 for the ssh and scp tasks. I created an upload bundle based on the previous POM found here http://jira.codehaus.org/browse/MAVENUPLOAD-758 and based on the jar and source zips made available by jcraft. Regards, Antoine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEJB-7) Transitive Classpath not written to the manifest
[ http://jira.codehaus.org/browse/MEJB-7?page=comments#action_78519 ] Sam Wilson commented on MEJB-7: --- That seems to solve the issue. However, given that this is part of the spec, shouldn't this be the default behavior and not require this sort of archane override? I went through the homepage for the plugin, the guides as well as the Better Builds With Maven book and found no reference to this property, which would be required for proper deployment in a compliant container. It would be nice to see this referenced in the documentation somewhere, or to have the default changed to something more appropriate (provided that won't cause other things to brake in a terrible way). Thanks for the solution. Transitive Classpath not written to the manifest Key: MEJB-7 URL: http://jira.codehaus.org/browse/MEJB-7 Project: Maven 2.x Ejb Plugin Issue Type: Bug Reporter: Todd Nine The transitive classpath of all dependencies from the dependencies in an EJB pom are not added to the MANIFEST.MF classpath. This causes the ejb to not deploy correctly. Todd -- 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-82) Invalid jar in the central repository : sitemesh 2.2.1
[ http://jira.codehaus.org/browse/MPA-82?page=all ] Arnaud Heritier closed MPA-82. -- Assignee: Arnaud Heritier (was: Jason van Zyl) Resolution: Cannot Reproduce Fix Version/s: 2006-q4 Seems to be fixed now. There was certainly a problem (temporarily) Invalid jar in the central repository : sitemesh 2.2.1 -- Key: MPA-82 URL: http://jira.codehaus.org/browse/MPA-82 Project: Maven Project Administration Issue Type: Bug Components: repository management Affects Versions: 2006-q4 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 2006-q4 The following jar seems to be corrupted : http://repo1.maven.org/maven2/opensymphony/sitemesh/2.2.1/sitemesh-2.2.1.jar Can it be fixed ? -- 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: (SUREFIRE-56) Test is broken and marked as Fail but works with plain execution with JUnit
Test is broken and marked as Fail but works with plain execution with JUnit --- Key: SUREFIRE-56 URL: http://jira.codehaus.org/browse/SUREFIRE-56 Project: surefire Issue Type: Bug Components: JUnit 3.x support Environment: Linux Mandriva 2007 Windows W2k server Maven 2.04 Reporter: Siegfried Klar we are using Castro for XML configuration processing. We wrote some Unit tests for the generation and the use of configuration to read in the app. If we execute this tests within the maven test cyle it breaks after (AppConfigs)Unmarshaller.unmarshal(AppConfigs.class, reader) And marks the test as failed. But if we run the test on commandline, without surefire ist works fine. Maybe we have a similar behaviour, if we run our MockEJB tests. These are also broken with Maven and Surefire. Any suggestions. Thanks in advance Siegfried Klar -- 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: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=all ] Wendy Smoak updated MPPDF-57: - Attachment: pdf-test.tar.gz Example project with pdf plugin configured. 'mvn site' will build the pdf. Unable to remove cover type and version --- Key: MPPDF-57 URL: http://jira.codehaus.org/browse/MPPDF-57 Project: maven-pdf-plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 1.1-RC1-SNAPSHOT Reporter: Wendy Smoak Assigned To: Lukas Theussl Fix For: 2.5.1 Attachments: pdf-test.tar.gz I'm trying to remove the 'cover type' and 'cover version' (set them to blank/nothing.) If I put the following in project.properties: maven.pdf.cover.type= maven.pdf.cover.version= I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version. If I try it again with '.' for both of those properties, cover type works (just prints a dot) but cover version prints 'v..'. This seems to call for something like a 'maven.pdf.cover.version.prefix' property (that can be set to blank.) -- 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-2633) Unexpected behaviour repository settings in POM.xml.
Unexpected behaviour repository settings in POM.xml. -- Key: MNG-2633 URL: http://jira.codehaus.org/browse/MNG-2633 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: - Win XP - JDK 1.5 Reporter: Davy Toch Attachments: pom.xml Included a POM file which defines two repositories : a non-existing one and the central M2 repository. There is no local settings file ~/.m2/setting.xml and the complete folder ~/.m2/repository/junit is deleted. Now if I run 'maven install', I get the following : $mvn install [INFO] Scanning for projects... [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [install] [INFO] Downloading: http://repo1.maven.org/maven2/junit/junit/3.8.1/junit-3.8.1.pom 145b downloaded [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. Downloading: http://blieblie/junit/junit/3.8.1/junit-3.8.1.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file junit:junit:jar:3.8.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), mybidonrepo (http://blieblie) Path to dependency: 1) testgroup:testartifact:jar:1.0-SNAPSHOT 2) junit:junit:jar:3.8.1 Caused by I/O exception: Server returned HTTP response code: 503 for URL: http://blieblie/junit/junit/3.8.1/junit-3.8.1.jar [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Thu Oct 26 18:53:06 CEST 2006 [INFO] Final Memory: 3M/6M [INFO] Questions: 1. Is it normal that retrieving the artifact (jar) completely fails the build? M2 could still try to connect to http://repo1.maven.org/maven2 to retrieve the artifact. 2. why is the POM file directly retrieved from http://repo1.maven.org/maven2 (no attempt to retrieve it from http://blieblie)? -- 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: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=comments#action_78549 ] Lukas Theussl commented on MPPDF-57: I cannot reproduce any of the above, I see no problems in your test project with neither cover.type nor cover.date. Are you sure you are running the right version of the plugin? Are $MAVEN_HOME and $PATH set correctly? Did you try clearing your cache? (I'm just shooting in the dark here...) Oh, and I guess you meant 'maven site', right? Unable to remove cover type and version --- Key: MPPDF-57 URL: http://jira.codehaus.org/browse/MPPDF-57 Project: maven-pdf-plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 1.1-RC1-SNAPSHOT Reporter: Wendy Smoak Assigned To: Lukas Theussl Fix For: 2.5.1 Attachments: pdf-test.tar.gz I'm trying to remove the 'cover type' and 'cover version' (set them to blank/nothing.) If I put the following in project.properties: maven.pdf.cover.type= maven.pdf.cover.version= I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version. If I try it again with '.' for both of those properties, cover type works (just prints a dot) but cover version prints 'v..'. This seems to call for something like a 'maven.pdf.cover.version.prefix' property (that can be set to blank.) -- 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-45) Documentation is wrong on maven.apache.org
[ http://jira.codehaus.org/browse/MDEP-45?page=all ] Dennis Lundberg closed MDEP-45. --- Resolution: Won't Fix No, the docs are correct. This is explained in the FAQ: http://maven.apache.org/plugins/maven-dependency-plugin/faq.html Documentation is wrong on maven.apache.org -- Key: MDEP-45 URL: http://jira.codehaus.org/browse/MDEP-45 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Meghan Claire Pike Priority: Minor http://maven.apache.org/plugins/maven-dependency-plugin/howto.html is wrong, it still points to the maven-dependency-plugin from apache... whereas it should be the dependency-maven-plugin from codehaus instead... right? -- 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-2634) Archiver should be adding Created-By: Apache Maven _2.0.4_ to the manifest
Archiver should be adding Created-By: Apache Maven _2.0.4_ to the manifest Key: MNG-2634 URL: http://jira.codehaus.org/browse/MNG-2634 Project: Maven 2 Issue Type: Bug Components: maven-archiver Affects Versions: 2.0.4 Reporter: Matthew Beermann The maven-archiver currently adds the string Created-By: Apache Maven to the manifest of all projects. This is good, but it needs to be more specific - e.g. Apache Maven 2.0.4. This would have two major benefits: 1) It would bring it in line with the Build-Jdk field, which has values like 1.5.0_09 2) It would help in having truly repeatable builds - potentially, you need to know which version of Maven was used to build an artifact I'd write the patch myself if I could figure out how to get at the information... it's in a @component called runtimeInformation, but how do you access components from a low-level library like maven-archiver? -- 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: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=all ] Wendy Smoak updated MPPDF-57: - Attachment: svn-intro.pdf Yes, I meant 'maven site'. :) $ echo $MAVEN_HOME c:\java\maven-1.1-RC1-SNAPSHOT $PATH contains $MAVEN_HOME/bin. $ ll $MAVEN_HOME/plugins/ | grep pdf -rwx--+ 1 wsmoak wsmoak 430109 Oct 26 12:05 maven-pdf-plugin-2.5.1-SNAPSHOT.jar I'm using Maven 1.1-RC1, and I've build the pdf plugin from source. I'm fairly sure I've got the latest, because the recent fix for 'cover version' is working (I no longer see v1.0 on the cover). Console output of building the plugin (after deleting the cache) and building the test project follows. The resulting PDF is attached. /cygdrive/c/svn/maven-1/plugins/pdf $ maven plugin:install __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT build:start: plugin:plugin: java:prepare-filesystem: [mkdir] Created dir: C:\svn\maven-1\plugins\pdf\target\classes java:compile: [echo] No java source files to compile. java:jar-resources: Copying 1 file to c:\svn\maven-1\plugins\pdf\target\classes\META-INF Copying 17 files to c:\svn\maven-1\plugins\pdf\target\classes\plugin-resources Copying 4 files to c:\svn\maven-1\plugins\pdf\target\classes test:test: [echo] No tests to run. jar:jar: [jar] Building jar: C:\svn\maven-1\plugins\pdf\target\maven-pdf-plugin-2.5.1 -SNAPSHOT.jar [echo] Rewriting POM... [copy] Copying 1 file to C:\svn\maven-1\plugins\pdf\target [jar] Updating jar: C:\svn\maven-1\plugins\pdf\target\maven-pdf-plugin-2.5.1 -SNAPSHOT.jar [delete] Deleting: C:\svn\maven-1\plugins\pdf\target\project.xml plugin:install: [delete] Deleting 1 files from C:\java\maven-1.1-RC1-SNAPSHOT\plugins [delete] C:\java\m1-repository\plugins not found. [delete] Deleting 24 files from C:\java\m1-repository\cache [delete] Deleted 5 directories from C:\java\m1-repository\cache [copy] Copying 1 file to C:\java\maven-1.1-RC1-SNAPSHOT\plugins BUILD SUCCESSFUL Total time : 6 seconds Finished at : Thursday, October 26, 2006 12:05:20 PM GMT-07:00 /cygdrive/c/svn/maven-1/plugins/pdf $ /cygdrive/c/java/pdf-test $ maven site __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT Directory C:\java\m1-repository\cache does not exist. Attempting to create. Plugin cache will be regenerated build:start: site: xdoc:register-reports: xdoc:init-i18n: [echo] Init the i18n support xdoc:init: [echo] Generates the directory structure required for xdocs pdf:init: [copy] Copying 98 files to C:\java\pdf-test\target\docs\images maven-pdf-plugin:register: site:run-reports: [echo] Generating the PDF Documentation... maven-pdf-plugin:report: xdoc:init-i18n: xdoc:init: [echo] Generates the directory structure required for xdocs xdoc:i18n-validation: [echo] Validation of the locale entries xdoc:register-reports: xdoc:init-i18n: xdoc:init: [echo] Generates the directory structure required for xdocs pdf:init: [copy] Copying 98 files to C:\java\pdf-test\target\docs\images maven-pdf-plugin:register: xdoc:generate-from-pom: [echo] Generating xdocs from POM ... Running post goal: xdoc:generate-from-pom xdoc:init-i18n: xdoc:init: [echo] Generates the directory structure required for xdocs pdf:init: [copy] Copying 98 files to C:\java\pdf-test\target\docs\images pdf:prepare: [copy] Copying 10 files to C:\java\pdf-test\target\pdf [copy] Copying 2 files to C:\java\pdf-test\target\pdf [copy] Copying 98 files to C:\java\pdf-test\target\pdf [copy] Copying 7 files to C:\java\pdf-test\target\pdf fo:fo: [echo] Generating c:\java\pdf-test/target/pdf/project.fo from c:\java\pdf-te st/xdocs/navigation.xml ... [java] Invalid option: coverDate [java] Invalid option: 26 October 2006 pdf:pdf: [echo] Generating c:\java\pdf-test/target/pdf/svn-intro.pdf ... [echo] Config file: c:\java\pdf-test/target/pdf/userconfig.xml [java] [INFO] Using org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser as SA X2 Parser [java] [INFO] Using org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser as SA X2 Parser [java] [INFO] FOP 0.20.5 [java] [INFO] Using org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser as SA X2 Parser [java] [INFO] building formatting object tree [java] [INFO] setting up fonts [java] [INFO] [1] [java] [INFO] [2] (blank) [java] [INFO] [1] [java] [INFO] [2] (blank) [java] [INFO] [1] [java] [INFO] Using org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser as SA X2 Parser [java] [INFO] Parsing of document complete, stopping renderer [copy] Copying 1 file to C:\java\pdf-test\target\docs pdf: xdoc:transform: xdoc:init-i18n: xdoc:init: [echo] Generates the directory structure required for xdocs
[jira] Commented: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=comments#action_78556 ]
Arnaud Heritier commented on MPPDF-57:
--
Lukas, I reproduced (and fixed) it with wendy's testcase
In fact it's logical because there's no test arround the cover type attribute.
If maven.pdf.cover.type is empty or null, the generated command line will be :
-PARAM coverType -PARAM coverVersion ...
Thus coverType=-PARAM and coverVersion isn't used.
I just added the same test like for the version
j:set var=_coverType value=${maven.pdf.cover.type}/
j:if test=${not empty(_coverType)}
arg value=-PARAM/
arg value=coverType/
arg value=${_coverType}/
/j:if
And I removed the default value in project2fo.xslt
I'm not sure if we don't have to this test for each PARAM to be sure to not
reproduce it later..
Unable to remove cover type and version
---
Key: MPPDF-57
URL: http://jira.codehaus.org/browse/MPPDF-57
Project: maven-pdf-plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Maven 1.1-RC1-SNAPSHOT
Reporter: Wendy Smoak
Assigned To: Lukas Theussl
Fix For: 2.5.1
Attachments: pdf-test.tar.gz, svn-intro.pdf
I'm trying to remove the 'cover type' and 'cover version' (set them to
blank/nothing.) If I put the following in project.properties:
maven.pdf.cover.type=
maven.pdf.cover.version=
I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version.
If I try it again with '.' for both of those properties, cover type works
(just prints a dot) but cover version prints 'v..'.
This seems to call for something like a 'maven.pdf.cover.version.prefix'
property (that can be set to blank.)
--
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: (MPPDF-57) Unable to remove cover type and version
[ http://jira.codehaus.org/browse/MPPDF-57?page=all ] Arnaud Heritier closed MPPDF-57. Resolution: Fixed - To avoid problems, be sure to not use a -PARAM without arg - Remove default hardcoded settings to allow users to remove them using an empty property Unable to remove cover type and version --- Key: MPPDF-57 URL: http://jira.codehaus.org/browse/MPPDF-57 Project: maven-pdf-plugin Issue Type: Bug Affects Versions: 2.5 Environment: Maven 1.1-RC1-SNAPSHOT Reporter: Wendy Smoak Assigned To: Lukas Theussl Fix For: 2.5.1 Attachments: pdf-test.tar.gz, svn-intro.pdf I'm trying to remove the 'cover type' and 'cover version' (set them to blank/nothing.) If I put the following in project.properties: maven.pdf.cover.type= maven.pdf.cover.version= I get the text '-PARAM' for the cover type, and 'v1.0' for the cover version. If I try it again with '.' for both of those properties, cover type works (just prints a dot) but cover version prints 'v..'. This seems to call for something like a 'maven.pdf.cover.version.prefix' property (that can be set to blank.) -- 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: (MAVEN-1809) Upgrade maven-pdf-plugin to v 2.5.1
Upgrade maven-pdf-plugin to v 2.5.1 --- Key: MAVEN-1809 URL: http://jira.codehaus.org/browse/MAVEN-1809 Project: Maven 1.x Issue Type: Sub-task Reporter: Arnaud Heritier Assigned To: Arnaud Heritier -- 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: (MAVEN-1810) Upgrade maven-nsis-plugin to v 2.1
Upgrade maven-nsis-plugin to v 2.1 -- Key: MAVEN-1810 URL: http://jira.codehaus.org/browse/MAVEN-1810 Project: Maven 1.x Issue Type: Sub-task Reporter: Arnaud Heritier Assigned To: Arnaud Heritier -- 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: (MAVEN-1809) Upgrade maven-pdf-plugin to v 2.5.1
[ http://jira.codehaus.org/browse/MAVEN-1809?page=all ] Arnaud Heritier updated MAVEN-1809: --- Description: http://jira.codehaus.org/browse/MPPDF?report=com.atlassian.jira.plugin.system.project:roadmap-panel Affects Version/s: 1.1-beta-3 Fix Version/s: 1.1-rc1 Component/s: planning Upgrade maven-pdf-plugin to v 2.5.1 --- Key: MAVEN-1809 URL: http://jira.codehaus.org/browse/MAVEN-1809 Project: Maven 1.x Issue Type: Sub-task Components: planning Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 http://jira.codehaus.org/browse/MPPDF?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1810) Upgrade maven-nsis-plugin to v 2.1
[ http://jira.codehaus.org/browse/MAVEN-1810?page=all ] Arnaud Heritier updated MAVEN-1810: --- Description: http://jira.codehaus.org/browse/MPNSIS?report=com.atlassian.jira.plugin.system.project:roadmap-panel I'm not yet sure to include it in maven 1.1-RC1. There are some new features and enhancements which break our rule to add only bug fixes in the RC1. The counter-part, is that it is a very minor plugin not really used (except to release maven itself, thus if I can release ...) Affects Version/s: 1.1-beta-3 Fix Version/s: 1.1-rc1 Component/s: installer Upgrade maven-nsis-plugin to v 2.1 -- Key: MAVEN-1810 URL: http://jira.codehaus.org/browse/MAVEN-1810 Project: Maven 1.x Issue Type: Sub-task Components: installer Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 http://jira.codehaus.org/browse/MPNSIS?report=com.atlassian.jira.plugin.system.project:roadmap-panel I'm not yet sure to include it in maven 1.1-RC1. There are some new features and enhancements which break our rule to add only bug fixes in the RC1. The counter-part, is that it is a very minor plugin not really used (except to release maven itself, thus if I can release ...) -- 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: (MPARTIFACT-73) DefaultArtifactCollector.recurse can lose versionRange
DefaultArtifactCollector.recurse can lose versionRange
--
Key: MPARTIFACT-73
URL: http://jira.codehaus.org/browse/MPARTIFACT-73
Project: maven-artifact-plugin
Issue Type: Bug
Environment: Linux
Reporter: Bud Osterberg
Attachments: artifact_patch
This affects maven 2.0.4 and 2.0.5 (at least).
I'm not quite sure how to reproduce the bug in a simple test case, but we have
a setup where running the command:
mvn install site source:jar
crashes in ArtifactUtils.copyArtifact because artifact.getVersionRange()
returns null.
The code that seems to be causing the problem is in
DefaultArtifactCollector.recurse(). Because the Artifact sets the version in
setVersionRange, but can't set the VersionRange from setVersion, the
VersionRange should take precedence if it exists. A simple diff follows:
Index:
components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
===
---
components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
(revision 467177)
+++
components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
(working copy)
@@ -114,8 +114,13 @@
fireEvent( ResolutionListener.MANAGE_ARTIFACT, listeners, node,
artifact );
-if ( artifact.getVersion() != null )
+VersionRange range = artifact.getVersionRange();
+if (range != null)
{
+ node.getArtifact().setVersionRange(range);
+}
+else if ( artifact.getVersion() != null )
+{
node.getArtifact().setVersion( artifact.getVersion() );
}
if ( artifact.getScope() != null )
--
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: (MNG-2635) DefaultArtifactCollector.recurse can lose versionRange
[ http://jira.codehaus.org/browse/MNG-2635?page=all ]
Arnaud Heritier moved MPARTIFACT-73 to MNG-2635:
Complexity: Intermediate
Workflow: Maven New (was: jira)
Key: MNG-2635 (was: MPARTIFACT-73)
Project: Maven 2 (was: maven-artifact-plugin)
DefaultArtifactCollector.recurse can lose versionRange
--
Key: MNG-2635
URL: http://jira.codehaus.org/browse/MNG-2635
Project: Maven 2
Issue Type: Bug
Environment: Linux
Reporter: Bud Osterberg
Attachments: artifact_patch
This affects maven 2.0.4 and 2.0.5 (at least).
I'm not quite sure how to reproduce the bug in a simple test case, but we
have a setup where running the command:
mvn install site source:jar
crashes in ArtifactUtils.copyArtifact because artifact.getVersionRange()
returns null.
The code that seems to be causing the problem is in
DefaultArtifactCollector.recurse(). Because the Artifact sets the version in
setVersionRange, but can't set the VersionRange from setVersion, the
VersionRange should take precedence if it exists. A simple diff follows:
Index:
components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
===
---
components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
(revision 467177)
+++
components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
(working copy)
@@ -114,8 +114,13 @@
fireEvent( ResolutionListener.MANAGE_ARTIFACT, listeners, node,
artifact );
-if ( artifact.getVersion() != null )
+VersionRange range = artifact.getVersionRange();
+if (range != null)
{
+ node.getArtifact().setVersionRange(range);
+}
+else if ( artifact.getVersion() != null )
+{
node.getArtifact().setVersion( artifact.getVersion() );
}
if ( artifact.getScope() != null )
--
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-40) use Lowercase alpha
[ http://jira.codehaus.org/browse/MDEP-40?page=all ] Brian Fox closed MDEP-40. - Resolution: Fixed since the repo is trashed anyway, I updated the version correctly. Now when the permissions are unscrewed it will be deployed correctly. use Lowercase alpha - Key: MDEP-40 URL: http://jira.codehaus.org/browse/MDEP-40 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1 Environment: xp, unix Reporter: Dan Tran Assigned To: Brian Fox Fix For: 2.0-alpha-1 By convention, we use lower case. see http://svn.apache.org/viewvc/maven/plugins/tags/ -- 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: (MASSEMBLY-97) multiproject with assembly fails in mysterious ways
[ http://jira.codehaus.org/browse/MASSEMBLY-97?page=all ] John Casey closed MASSEMBLY-97. --- Assignee: John Casey Resolution: Won't Fix Use assembly:single or assembly:directory-single for this type of application. directory-single is added in 2.2-SNAPSHOT multiproject with assembly fails in mysterious ways --- Key: MASSEMBLY-97 URL: http://jira.codehaus.org/browse/MASSEMBLY-97 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Nigel Magnay Assigned To: John Casey Priority: Critical Attachments: bug-assembly-2.0.1.zip, bug-assembly-2.1-SNAPSHOT.zip, bug.zip The attached project has a (very simple) multiproject build. If you edit the root pom.xml and comment out project2, then mvn install will execute correctly and build and assemble the jar files, and deploy them to the local repo. If you have both project1 and project2, then something odd happens - it fails building the package for item1, but the error report is that there is a missing dependency for item2's package - which it hasn't built yet. This means that 'root level' builds for us can't be executed from a clean system as they always fall 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] Updated: (MASSEMBLY-97) multiproject with assembly fails in mysterious ways
[ http://jira.codehaus.org/browse/MASSEMBLY-97?page=all ] John Casey updated MASSEMBLY-97: Fix Version/s: 2.2 multiproject with assembly fails in mysterious ways --- Key: MASSEMBLY-97 URL: http://jira.codehaus.org/browse/MASSEMBLY-97 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Nigel Magnay Assigned To: John Casey Priority: Critical Fix For: 2.2 Attachments: bug-assembly-2.0.1.zip, bug-assembly-2.1-SNAPSHOT.zip, bug.zip The attached project has a (very simple) multiproject build. If you edit the root pom.xml and comment out project2, then mvn install will execute correctly and build and assemble the jar files, and deploy them to the local repo. If you have both project1 and project2, then something odd happens - it fails building the package for item1, but the error report is that there is a missing dependency for item2's package - which it hasn't built yet. This means that 'root level' builds for us can't be executed from a clean system as they always fall 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] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78581 ] THURNER rupert commented on SCM-230: upload a patch and mailbomb scm-dev@maven.apache.org mailing list :) i wonder also if there is a place to document the testcases so that people need not to reverse engineer them by codereading. some poeple prefer a top-down approach ... mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tgz it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78582 ] THURNER rupert commented on SCM-230: btw, thanks a lot for the fixes! we also have this problem. mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tgz it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- 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
