[jira] Created: (MENFORCER-112) Create a rule to check if a xml file exist and with xpath test
Create a rule to check if a xml file exist and with xpath test -- Key: MENFORCER-112 URL: http://jira.codehaus.org/browse/MENFORCER-112 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.0 Reporter: Alexandre Navarro Create a rule to check if a xml file exist and with xpath test. It can be useful to check src/changes/changes.xml if the current release exists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-251) Artifacts qualifier are NOT taken into accounts correctly
[
http://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Brieg updated MDEP-251:
---
Attachment: test.maven-dependency-plugin.zip
I attached a file, which shows an incorrect behavior with classifiers. The
project has a dependency on a zip file with no classifier. A second dependency
is within a profile, which is active by default. The dependency in the profile
uses a classifier. The maven dependency plugin tries to download the
dependency, which is not in the profile, with the classifier of the dependency
in the profile.
Please note that there must not exists any dependencies listed in the project
in your maven repositories in order to demonstrate the incorrect behavior.
> Artifacts qualifier are NOT taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: http://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
> Attachments: test.maven-dependency-plugin.zip
>
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
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: (MDEP-251) Artifacts qualifier are NOT taken into accounts correctly
[
http://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243721#action_243721
]
Andreas Brieg edited comment on MDEP-251 at 11/19/10 3:04 AM:
--
I attached a file, which shows an incorrect behavior with classifiers. The
project has a dependency on a zip file with no classifier. A second dependency
is within a profile, which is active by default. The dependency in the profile
uses a classifier. The maven dependency plugin tries to download the
dependency, which is not in the profile, with the classifier of the dependency
in the profile.
Please note that there must not exist any dependency listed in the project in
your maven repositories in order to demonstrate the incorrect behavior.
was (Author: abr):
I attached a file, which shows an incorrect behavior with classifiers. The
project has a dependency on a zip file with no classifier. A second dependency
is within a profile, which is active by default. The dependency in the profile
uses a classifier. The maven dependency plugin tries to download the
dependency, which is not in the profile, with the classifier of the dependency
in the profile.
Please note that there must not exists any dependencies listed in the project
in your maven repositories in order to demonstrate the incorrect behavior.
> Artifacts qualifier are NOT taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: http://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
> Attachments: test.maven-dependency-plugin.zip
>
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
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-508) Wrong scm url validation for mercurial provider
[ http://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243723#action_243723 ] Laurent Perez commented on SCM-508: --- Dennis, you are probably right, but http://maven.apache.org/scm/bazaar.html and http://maven.apache.org/scm/subversion.html are referencing double slashes and their code is using double slashes too, I don't know why, perhaps it was assumed that the file:// protocol does not need a third slash on windows because there is no "root directory", drive letters start without a mount point. Anyway, feel free to mark this one as wontfix or invalid if needed, I guess that in practice, most people on windows wanting to use a local repo would probably use hg serve and hg clone their http://localhost:8000 repository instead of using a local file: repository. > Wrong scm url validation for mercurial provider > --- > > Key: SCM-508 > URL: http://jira.codehaus.org/browse/SCM-508 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Reporter: Alexander Nemish > Fix For: 1.5 > > Attachments: SCM-508-maven-scm-provider-hg.patch > > > According to documentation (http://maven.apache.org/scm/mercurial.html) scm > url can be of this form: > scm:hg:file://C:/dev/project/v3 > but it doesn't work due to a bug in > https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java > private HgUrlParserResult parseScmUrl( String scmSpecificUrl ) > line 104: if ( !url.startsWith( "file:///" ) && !url.startsWith( > "file://localhost/" ) ) > The fix might be the following (like in svn provider) > line 104: if ( !url.startsWith( "file://" ) && !url.startsWith( > "file://localhost/" ) ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-251) Artifacts qualifier are NOT taken into accounts correctly
[
http://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243724#action_243724
]
Joerg Schaible commented on MDEP-251:
-
@Andreas Brieg: Maven is absolute correct. Different classifier (even "no
classifier") address distinct dependencies. What you do in your profile is
simply adding a second dependency and Maven behaves accordingly.
> Artifacts qualifier are NOT taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: http://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
> Attachments: test.maven-dependency-plugin.zip
>
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-251) Artifacts qualifier are NOT taken into accounts correctly
[
http://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243725#action_243725
]
Andreas Brieg commented on MDEP-251:
@Joerg Schaible:
Looking at the attached test project I would expect that the maven dependency
plugin tries to download {{some-zip-0.0.1-SNAPSHOT.zip}} and not
{{some-zip-0.0.1-SNAPSHOT-x86.zip}} because this artifact does not specify a
classifier.
Even if I add another profile with another classifier the dependency plugin
will use the latest specified classifier for {{some-zip-0.0.1-SNAPSHOT.zip}}.
So if using maven in a complex multi module project one would have to
install/deploy all possible modules to the repository with every possible
classifier. But that would just be redundant, because the majority of modules
wouldn't have differences for different classifiers.
> Artifacts qualifier are NOT taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: http://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
> Attachments: test.maven-dependency-plugin.zip
>
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
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: (SCM-584) Checkout branch with Git uses unfamiliar command sequence which leads to errors during checkout
Checkout branch with Git uses unfamiliar command sequence which leads to errors
during checkout
---
Key: SCM-584
URL: http://jira.codehaus.org/browse/SCM-584
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.4
Reporter: Daniel Strassenburg
Priority: Critical
I want to checkout a specific branch from my git repo using the
maven-scm-plugin. The plugin first clones the repo and gets the default branch
as selected in gitorious. After that the plugin executes git pull ... mybranch
which works fine as long as there are no merge conflicts between current branch
and branch to checkout. In the case of any conflict an error occurs.
The git checkout -b command should be used instead.
{noformat}
[INFO] Working directory:
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace && git
fetch git://gitorious/<...>/my-proj.git
[INFO] Working directory:
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
git checkout HEAD
[INFO] Working directory:
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace && git
ls-files
[INFO] Working directory:
[INFO]
[INFO] --- maven-scm-plugin:1.4:update (switch-branch)
[INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace && git
pull git://gitorious/<..>/deploy.git mysql55
[WARNING] failed to update git, return code 1
[ERROR] Provider message:
[ERROR] The git-pull origin master command failed.
[ERROR] Command output:
[ERROR] From git://gitorious/<...>/deploy
* branchmysql55-> FETCH_HEAD
{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] Commented: (SCM-584) Checkout branch with Git uses unfamiliar command sequence which leads to errors during checkout
[
http://jira.codehaus.org/browse/SCM-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243729#action_243729
]
Daniel Strassenburg commented on SCM-584:
-
Before the git fetch listed above a git clone is performed:
{noformat}
Executing: /bin/sh -c cd && git clone
git://gitorious/<...>/deploy.git/home/maven-proj/target/deploy-workspace
{noformat}
> Checkout branch with Git uses unfamiliar command sequence which leads to
> errors during checkout
> ---
>
> Key: SCM-584
> URL: http://jira.codehaus.org/browse/SCM-584
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.4
>Reporter: Daniel Strassenburg
>Priority: Critical
>
> I want to checkout a specific branch from my git repo using the
> maven-scm-plugin. The plugin first clones the repo and gets the default
> branch as selected in gitorious. After that the plugin executes git pull ...
> mybranch which works fine as long as there are no merge conflicts between
> current branch and branch to checkout. In the case of any conflict an error
> occurs.
> The git checkout -b command should be used instead.
> {noformat}
> [INFO] Working directory:
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git fetch git://gitorious/<...>/my-proj.git
> [INFO] Working directory:
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git checkout HEAD
> [INFO] Working directory:
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git ls-files
> [INFO] Working directory:
> [INFO]
> [INFO] --- maven-scm-plugin:1.4:update (switch-branch)
> [INFO] Executing: /bin/sh -c cd /home/maven-proj/target/deploy-workspace &&
> git pull git://gitorious/<..>/deploy.git mysql55
> [WARNING] failed to update git, return code 1
> [ERROR] Provider message:
> [ERROR] The git-pull origin master command failed.
> [ERROR] Command output:
> [ERROR] From git://gitorious/<...>/deploy
> * branchmysql55-> FETCH_HEAD
> {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: (MNG-4905) Active profiles defined in parent pom are not inherited in children pom
[ http://jira.codehaus.org/browse/MNG-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4905: --- Component/s: (was: Apache or Maven Parent poms) Profiles Inheritance and Interpolation > Active profiles defined in parent pom are not inherited in children pom > --- > > Key: MNG-4905 > URL: http://jira.codehaus.org/browse/MNG-4905 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation, Profiles >Affects Versions: 3.0 > Environment: Windows XP 32 bits SP2 >Reporter: Benoît Berthonneau > > I've a parent pom which contains 2 profiles based on the OS (eg "windows" and > "not windows"). The activation tag i used to determine this and works fine in > this pom. > I've a child pom (eg a module of the parent pom) where I'd like to use the > active profile to tune my build goal. But in this child pom I could not get > the active profile. If I launch "mvn -P myProfile compile" it works fine > everywhere (parent and child). > I'd like to have the inheritance of the active profiles defined in a parent > pom in all its children modules. > Easy to reproduce but could give a test case if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4905) Active profiles defined in parent pom are not inherited in children pom
[ http://jira.codehaus.org/browse/MNG-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4905. -- Resolution: Duplicate Assignee: Benjamin Bentmann > Active profiles defined in parent pom are not inherited in children pom > --- > > Key: MNG-4905 > URL: http://jira.codehaus.org/browse/MNG-4905 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation, Profiles >Affects Versions: 3.0 > Environment: Windows XP 32 bits SP2 >Reporter: Benoît Berthonneau >Assignee: Benjamin Bentmann > > I've a parent pom which contains 2 profiles based on the OS (eg "windows" and > "not windows"). The activation tag i used to determine this and works fine in > this pom. > I've a child pom (eg a module of the parent pom) where I'd like to use the > active profile to tune my build goal. But in this child pom I could not get > the active profile. If I launch "mvn -P myProfile compile" it works fine > everywhere (parent and child). > I'd like to have the inheritance of the active profiles defined in a parent > pom in all its children modules. > Easy to reproduce but could give a test case if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPIR-158) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MPIR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-158. Resolution: Fixed Fix Version/s: 2.3 Assignee: Vincent Siveton fixed in r1036825, snapshot deployed > Artifact ## has no file error. > -- > > Key: MPIR-158 > URL: http://jira.codehaus.org/browse/MPIR-158 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1.1 > Environment: Windows xp, tomcat 5.5 server >Reporter: Damian Sinczak >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.3 > > > During 'mvn site' command on project i receive some strange errors. Their are > no critical, but they are still errors. > Console dump: > [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no > fi > le. > [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 > .2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 > .1 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h > as no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 > has > no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 > ha > s no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 > has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. > 1.2 has no file. > [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no > file. > [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no > file. > [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. > [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. > [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. > [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. > [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga > has n > o file. > [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. > [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. > [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. > [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. > [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. > [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. > [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. > [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. > [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. > [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. > [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. > [ERROR] Artifact: xom:xom:jar:1.0 has no file. > [INFO] Generating "Project Team" report. > [INFO] Generating "Project License" report. > [INFO] Generating "Project Plugins" report. > [INFO] Generating "Maven Surefire Report" report. > [INFO] Generating "FindBugs Report" report. > [INFO] Using source root: > [INFO] C:\edys_workspace\edystok\target\classes > [INFO] Using test source root: > [INFO] C:\edys_workspace\edystok\target\test-classes > [I
[jira] Commented: (ARCHETYPE-303) Externalize Archetype Catalog model into separate module
[ http://jira.codehaus.org/browse/ARCHETYPE-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243745#action_243745 ] Tamás Cservenák commented on ARCHETYPE-303: --- Change applied in http://svn.apache.org/viewvc?view=revision&revision=1036834 > Externalize Archetype Catalog model into separate module > > > Key: ARCHETYPE-303 > URL: http://jira.codehaus.org/browse/ARCHETYPE-303 > Project: Maven Archetype > Issue Type: Improvement >Reporter: Tamás Cservenák > Attachments: archetype-303.patch > > > Externalize Archetype Catalog model into separate module (ideally, without > any dependency). > This model would be likely reused by 3rd parties, but without "dragging" all > the dependencies and other classes in archetype-common module. > Typical example is Nexus's ArchetypePlugin, that publishes the archetype > catalog, but from Nexus Index. Currently, that plugin _copied_ (rev668260) of > Modello model to be able to publish. This obviously may lead to problems > later. -- 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: (MCOMPILER-114) Setting the debug option to false still compiles the code with line numbers resulting in increased class file.
[
http://jira.codehaus.org/browse/MCOMPILER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243746#action_243746
]
Stephen Bannasch commented on MCOMPILER-114:
David, Which versions of the compiler plugin are you using?
I was using v2.3.2 in my tests above.
{code}
...
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
{code}
> Setting the debug option to false still compiles the code with line numbers
> resulting in increased class file.
> --
>
> Key: MCOMPILER-114
> URL: http://jira.codehaus.org/browse/MCOMPILER-114
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Professional Version 5.1.2600 Service Pack 3
> Build 2600, Dell OptiPlex GX280, Total Physical Memory 4,096.00 MB
>Reporter: Grzegorz Solecki
> Attachments: TestApp.zip
>
>
> Given the following example:
> {code:title=Bar.java|borderStyle=solid}
> public class Main {
>public static void main(String[] args) {
> for (StackTraceElement stackTraceElement :
> Thread.currentThread().getStackTrace())
> System.out.println(stackTraceElement);
>}
> }
> {code}
> and pom.xml
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>4.0.0
>com.greg
>TestApp
>1
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>none
>1.5
>1.5
>
>
>
>
>
> {code}
> after compiling and running we get:
> {panel:title=cmd}
> {noformat}
> {TestApp}\target\classes>dir Main.class
> 05/02/2010 XX:XX 564 Main.class
> {TestApp}\target\classes>java -cp . Main
> java.lang.Thread.dumpThreads(Native Method)
> java.lang.Thread.getStackTrace(Thread.java:1383)
> Main.main(Main.java:3)
> {noformat}
> {panel}
> *NOTE !!!: the number of line (Main.java:3) has been shown*
> However when you compile the same java code using the javac we get:
> {panel:title=cmd}
> {noformat}
> {TestApp}\src\main\java>javac -g:none -source 1.5 -target 1.5 Main.java
> {TestApp}\src\main\java>dir Main.class
> 05/02/2010 XX:XX 477 Main.class
> {TestApp}\src\main\java>java -cp . Main
> java.lang.Thread.dumpThreads(Native Method)
> java.lang.Thread.getStackTrace(Thread.java:1383)
> Main.main(Unknown Source){noformat}
> {panel}
> *NOTE !!!: the number of line has not been shown*
> Please find the whole sample project in Eclipse that uses m2eclipse plugin,
> that is configured for using external maven 2.2.1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-177) Allow use of both password and private key
[ http://jira.codehaus.org/browse/WAGON-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243747#action_243747 ] Tuomas Kiviaho commented on WAGON-177: -- Logic is actually vice versa as states the following old chinese saying taken from AbstractSshWagon // If user don't define a password, he want to use a private key I'm transitioning from private key based scp connection to http protocol with encrypted password and it would have been great to maintains backwards compatibility (the password I'm using happens to be different between the two approaches). > Allow use of both password and private key > -- > > Key: WAGON-177 > URL: http://jira.codehaus.org/browse/WAGON-177 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ssh >Reporter: Kenney Westerhof > Fix For: 1.x > > > We have corporate m2 repository over http with Digest authentication. > We specify the and for that repository so the > ArtifactManager can download > artifacts. > We also use scp to deploy artifacts to that same repository. We use the same > username, but > a different password and/or a private key file. > AbstractSshWagon's logic is that it only uses the private key file if there's > no password specified. > It should first try the private key file, and optionally use the password to > decode it if it's password-protected, > then try that private key authentication, and if that fails, try the > password/passphrase authentications. > Ssh allows for multiple authentication methods to be tried before failure. > Even better would be to allow different usernames for the same repository, > depending on if it's > used for deployment or artifact resolution (but that's a maven-core issue). > Right now we have to use two different repository id's and double > configuration for both normal and snapshot repositories, when in fact it's > the same repository with 2 different access methods. > (most of this issue is more appropriately placed in maven-core somewhere, but > the password/privatekey > issue solves part of the problem). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-205) pom task doesn't use auth settings to resolve parent pom
pom task doesn't use auth settings to resolve parent pom Key: MANTTASKS-205 URL: http://jira.codehaus.org/browse/MANTTASKS-205 Project: Maven 2.x Ant Tasks Issue Type: Bug Reporter: Miroslaw Michalski Attachments: patch1.txt In settings.xml I have defined ; in pom there is a pom defined and also a custom . when trying to build this project using ant using to resolve artifacts I get ERROR massage that the parent pom artifact could not be downloaded from my custom repository due to authentication error. I'm attaching a patch that resolved this problem for me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-206) dependecies task overrides custom definition of 'central' repository
dependecies task overrides custom definition of 'central' repository Key: MANTTASKS-206 URL: http://jira.codehaus.org/browse/MANTTASKS-206 Project: Maven 2.x Ant Tasks Issue Type: Bug Affects Versions: 2.1.1 Reporter: Miroslaw Michalski Attachments: patch2.txt While using with pom ... central https://custom/mvn/central true true the task is still trying to resolve my dependecies from http://repo2.maven.org/maven2. A patch resolving this issue is 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: (MANTTASKS-205) pom task doesn't use auth settings to resolve parent pom
[ http://jira.codehaus.org/browse/MANTTASKS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243764#action_243764 ] Miroslaw Michalski commented on MANTTASKS-205: -- Problem exists in version 2.1.1 and previous > pom task doesn't use auth settings to resolve parent pom > > > Key: MANTTASKS-205 > URL: http://jira.codehaus.org/browse/MANTTASKS-205 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Reporter: Miroslaw Michalski > Attachments: patch1.txt > > > In settings.xml I have defined ; in pom there is a pom > defined and also a custom . > when trying to build this project using ant using >cacheDependencyRefs="false" > pathId="maven.dependency.classpath" > useScope="test"> > > > to resolve artifacts I get ERROR massage that the parent pom artifact could > not be downloaded from my custom repository due to authentication error. > I'm attaching a patch that resolved this problem for me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-587) Doesn't run tests if they don't end with Test
[ http://jira.codehaus.org/browse/SUREFIRE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243769#action_243769 ] Gareth Clay commented on SUREFIRE-587: -- I've hit this issue with only pure JUnit4 tests too. Our build machine is currently only running 27 of our 120+ tests (those with class names that begin or end in 'Test'). As I understand it, the only requirement for a JUnit4 test to be run is the presence of the @Test annotation on the test method. The name of the class and the (non)presence of @RunWith on the class should make no difference. The JUnit4 runner in Eclipse follows this behaviour, and correctly identifies all of our tests. All this with JUnit4.4, and surefire 2.7-SNAPSHOT as at 20101119 (since I'd been hoping this had been fixed as part of SUREFIRE-482, but it doesn't seem that way). > Doesn't run tests if they don't end with Test > - > > Key: SUREFIRE-587 > URL: http://jira.codehaus.org/browse/SUREFIRE-587 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.4.3 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Critical > > We have a mix of test - some purely junit4 (e.g. not extending anything and > annotating with @Test) - and some which extends TestCase. > I've discovered that the ones extending TestCase won't run if the classname > doesn't end with Test - so that the class CommonsAttributesParserTests won't > get included (notice the ending "s"). -- 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: (WAGON-317) Do not wait for 401 "authentication needed" response to send the login/pwd on PUT queries
[ http://jira.codehaus.org/browse/WAGON-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243772#action_243772 ] Erwan Ducroquet commented on WAGON-317: --- As per comment from Benjamin Bentmann, I've checked on this docs and found following config to setup in settings.xml : settings/servers/serv...@id=x]/configuration/wagonProvider='httpclient' settings/servers/serv...@id=x]/configuration/httpConfiguration/put/params/param[name='http.authentication.preemptive' && value='%b,true'] It can be allowed as we only use https, so no risk to send "not needed" credentials It is currently being tested > Do not wait for 401 "authentication needed" response to send the login/pwd on > PUT queries > - > > Key: WAGON-317 > URL: http://jira.codehaus.org/browse/WAGON-317 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-6 >Reporter: Erwan Ducroquet > > When the maven repository requires authentication to PUT jars, > 1- the deploy plugin first triggers a HTTP PUT query without login/pwd, > trying to send the jar > 2- then the repo rejects this query as 401 "need authentication" error > 3- then the deploy plugin triggers again same HTTP PUT query with the > login/pwd and sends the jar again > 4- then the repo accepts this second query and uploads the jar > This sequence consumes useless I/O (trying to send the jar on first query) > and causes issues on some configurations like HTTPS with a frontend webserver > : randomly the HTTPS connection is cut (Nginx HTTPS forwarding to Nexus > HTTPS). > It will be better (by default or with some config var) to provide immediately > the login/pwd on PUT queries > => aka: sending the HTTP header "Authentication: BASIC x" > Tested with Maven 2.2.1, Deploy 2.5, Nexus 1.7.2, Nginx -- 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: (MEV-673) Incorrect hashes in http://repo1.maven.org/maven2/org/apache/httpcomponents/project/4.1/
[ http://jira.codehaus.org/browse/MEV-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243773#action_243773 ] SebbASF commented on MEV-673: - MVNCENTRAL-14 was fixed a short while ago - Central should be fixed in an hour or so > Incorrect hashes in > http://repo1.maven.org/maven2/org/apache/httpcomponents/project/4.1/ > > > Key: MEV-673 > URL: http://jira.codehaus.org/browse/MEV-673 > Project: Maven Evangelism > Issue Type: Bug > Components: Checksum Failure >Reporter: SebbASF > > See: https://issues.apache.org/jira/browse/HTTPCLIENT-1017 > We have reset the hashes on Nexus, and the Maven metadata has been updated, > but the updated files have not been replicated. > Please could you resynch the hashes? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-587) Doesn't run tests if they don't end with Test
[ http://jira.codehaus.org/browse/SUREFIRE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243778#action_243778 ] Gareth Clay commented on SUREFIRE-587: -- Hmm... Having taken a *very* brief look at the code, it seems that surefire's JUnit4TestChecker.isValidJUnit4Test() method is doing the right thing. So it's just not getting the right list of test classes to apply that filtering to. Following on from that, I've successfully worked around this issue by explicitly adding **/*.class to my POM. I think this should be the default implicit behaviour - it makes no sense to filter by class name when the only requirement for inclusion is an @Test annotation. > Doesn't run tests if they don't end with Test > - > > Key: SUREFIRE-587 > URL: http://jira.codehaus.org/browse/SUREFIRE-587 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.4.3 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Critical > > We have a mix of test - some purely junit4 (e.g. not extending anything and > annotating with @Test) - and some which extends TestCase. > I've discovered that the ones extending TestCase won't run if the classname > doesn't end with Test - so that the class CommonsAttributesParserTests won't > get included (notice the ending "s"). -- 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: (MCOMPILER-114) Setting the debug option to false still compiles the code with line numbers resulting in increased class file.
[
http://jira.codehaus.org/browse/MCOMPILER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243780#action_243780
]
David H Vree commented on MCOMPILER-114:
@Stephen - I was using 2.0.2. Apparently that is what Maven 2.2.1 uses by
default.
When I switch to 2.3.2 I could replicate your behavior exactly. Apparently
v2.0.2 quietly ignores the configuration option.
> Setting the debug option to false still compiles the code with line numbers
> resulting in increased class file.
> --
>
> Key: MCOMPILER-114
> URL: http://jira.codehaus.org/browse/MCOMPILER-114
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Professional Version 5.1.2600 Service Pack 3
> Build 2600, Dell OptiPlex GX280, Total Physical Memory 4,096.00 MB
>Reporter: Grzegorz Solecki
> Attachments: TestApp.zip
>
>
> Given the following example:
> {code:title=Bar.java|borderStyle=solid}
> public class Main {
>public static void main(String[] args) {
> for (StackTraceElement stackTraceElement :
> Thread.currentThread().getStackTrace())
> System.out.println(stackTraceElement);
>}
> }
> {code}
> and pom.xml
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>4.0.0
>com.greg
>TestApp
>1
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>none
>1.5
>1.5
>
>
>
>
>
> {code}
> after compiling and running we get:
> {panel:title=cmd}
> {noformat}
> {TestApp}\target\classes>dir Main.class
> 05/02/2010 XX:XX 564 Main.class
> {TestApp}\target\classes>java -cp . Main
> java.lang.Thread.dumpThreads(Native Method)
> java.lang.Thread.getStackTrace(Thread.java:1383)
> Main.main(Main.java:3)
> {noformat}
> {panel}
> *NOTE !!!: the number of line (Main.java:3) has been shown*
> However when you compile the same java code using the javac we get:
> {panel:title=cmd}
> {noformat}
> {TestApp}\src\main\java>javac -g:none -source 1.5 -target 1.5 Main.java
> {TestApp}\src\main\java>dir Main.class
> 05/02/2010 XX:XX 477 Main.class
> {TestApp}\src\main\java>java -cp . Main
> java.lang.Thread.dumpThreads(Native Method)
> java.lang.Thread.getStackTrace(Thread.java:1383)
> Main.main(Unknown Source){noformat}
> {panel}
> *NOTE !!!: the number of line has not been shown*
> Please find the whole sample project in Eclipse that uses m2eclipse plugin,
> that is configured for using external maven 2.2.1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-587) Doesn't run tests if they don't end with Test
[ http://jira.codehaus.org/browse/SUREFIRE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243783#action_243783 ] Kristian Rosenvold commented on SUREFIRE-587: - I will be treating this as a documentation issue and update the FAQ wrt this issue, since it's already specified in the main documentation at http://maven.apache.org/plugins/maven-surefire-plugin/examples/inclusion-exclusion.html . You have to update the include/exclude pattern to include all your classes if you want surefire to scan all your project classes for annotations. I will close this issue when the faq is updated. > Doesn't run tests if they don't end with Test > - > > Key: SUREFIRE-587 > URL: http://jira.codehaus.org/browse/SUREFIRE-587 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.4.3 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Critical > > We have a mix of test - some purely junit4 (e.g. not extending anything and > annotating with @Test) - and some which extends TestCase. > I've discovered that the ones extending TestCase won't run if the classname > doesn't end with Test - so that the class CommonsAttributesParserTests won't > get included (notice the ending "s"). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-525) Generated html from apt is ignoring all paragraph lines
Generated html from apt is ignoring all paragraph lines --- Key: MSITE-525 URL: http://jira.codehaus.org/browse/MSITE-525 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.2 Environment: mac osx Reporter: Greg Mirabito I create a simple apt file with two lines in it. This is line1. This is line2. Run mvn site and look at the generated html. There is no line break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243786#action_243786 ] Greg Mirabito commented on MSITE-525: - Here is the html paragraph that gets generates This is line1. This is line2. > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- 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: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243786#action_243786 ] Greg Mirabito edited comment on MSITE-525 at 11/19/10 10:55 AM: Here is the html paragraph that gets generated This is line1. This is line2. was (Author: mirabg): Here is the html paragraph that gets generatesd This is line1. This is line2. > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- 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: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243786#action_243786 ] Greg Mirabito edited comment on MSITE-525 at 11/19/10 10:55 AM: Here is the html paragraph that gets generatesd This is line1. This is line2. was (Author: mirabg): Here is the html paragraph that gets generates This is line1. This is line2. > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- 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: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-525. - Resolution: Not A Bug This is the expected behavior. See the Doxia reference on the APT format: http://maven.apache.org/doxia/references/apt-format.html#Line_break > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-587) Doesn't run tests if they don't end with Test
[ http://jira.codehaus.org/browse/SUREFIRE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243787#action_243787 ] Gareth Clay commented on SUREFIRE-587: -- Apologies, so it is. I missed that. I would still argue that scanning all classes is a more useful default. JUnit imposes no restriction on test class naming, so it seems odd that surefire filters by name by default. Wouldn't a better default be to scan all classes, and let users impose their own restrictions if they're using a particular naming convention? It would avoid confusion and issues like this being raised, and I would have thought the performance hit is likely to be small on all but very large codebases. > Doesn't run tests if they don't end with Test > - > > Key: SUREFIRE-587 > URL: http://jira.codehaus.org/browse/SUREFIRE-587 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.4.3 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Critical > > We have a mix of test - some purely junit4 (e.g. not extending anything and > annotating with @Test) - and some which extends TestCase. > I've discovered that the ones extending TestCase won't run if the classname > doesn't end with Test - so that the class CommonsAttributesParserTests won't > get included (notice the ending "s"). -- 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-4907) Wrong error message when relativePath wrong
Wrong error message when relativePath wrong --- Key: MNG-4907 URL: http://jira.codehaus.org/browse/MNG-4907 Project: Maven 2 & 3 Issue Type: Improvement Components: Inheritance and Interpolation Affects Versions: 3.0 Environment: maven 3.0, windows XP Reporter: Marshall Schor Priority: Minor Attachments: mvn-parent-relative-path.zip I'll attach a zipped sample showing the issue; it has 3 folders, each having a small pom. They are named childFolder, parentFolder, and submodule. The child has the parent as its parent. The child has a section listing the parent and the submodule as things to be built. The submodule list "parent" as its parent, but fails (on purpose, to illustrate the issue) to include a element. If I do mvn clean on the "submodule", it says, correctly: [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project t:submodule:1-SNAPSHOT (D:\mavenAlign\trunk\mvn-parent-relative-path\submodule\pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact t:parent:pom:1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 8, column 11 -> [Help 2] Note: line 8, column 11 is right after the "" element in the source. But, if I run mvn clean on the "child", it says, incorrectly: [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project t:child:1-SNAPSHOT (D:\mavenAlign\trunk\mvn-parent-relative-path\childFolder\pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact t:parent:pom:1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 5, column 11 -> [Help 2] In fact, the ...\childFolder\pom.xml doesn't have an error, and the message that it points at the wrong local POM at line 5, column 11 is not correct. If you comment out the reference in this pom to the "submodule", it works fine. The error is actually in the submodule. The line 5, column 11 refers to a spot right after the "" element in the child module, where everything is OK. This of course, misleads the person trying to debug this, to look hard in the wrong place :-). -- 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: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mirabito reopened MSITE-525: - I am not talking about hard line breaks using the '\' character. I am talking about separate lines in a paragraph. Look at the 'Paragraph section' of same document you referenced. In the APT doc it states that "A paragraph is a sequence of consecutive lines" My problem is that the separate lines in my paragraphs all show up on the same line when the html is generated. If I copy the example paragraph from the apt doc into my own apt doc and run mvn site, the generated html puts the separate paragraph lines on the same line. (no line breaks) Here is what it says in the APT doc about paragraphs: A paragraph is simply a sequence of consecutive text lines. First line of first paragraph. Second line of first paragraph. Third line of first paragraph. Line 1 of paragraph 2 (separated from first paragraph by an open line). Line 2 of paragraph 2. > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- 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: (MCOMPILER-141) do not create generated-sources folder when proc = none
do not create generated-sources folder when proc = none --- Key: MCOMPILER-141 URL: http://jira.codehaus.org/browse/MCOMPILER-141 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.3.2 Reporter: Minas Manthos Currently generated-source folder (generatedSourcesDirectory/generatedTestSourcesDirectory) is always created, even if none is set. if proc is none, then folders should not be generated and also not added to javac command line... We have a lot of modules in our projects and only a few have annotationsProcesses. Our IDE adds all generated-source folder to Project but mostly of them are empty and overview suffers. -- 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-4908) source jars are not signed when releasing maven-indexer
source jars are not signed when releasing maven-indexer --- Key: MNG-4908 URL: http://jira.codehaus.org/browse/MNG-4908 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.1 Reporter: Brian Demers The sources plugin runs after the gpg plugin. They both run in the verify phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-4908) source jars are not signed when releasing maven-indexer
[ http://jira.codehaus.org/browse/MNG-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-4908 started by Brian Demers. > source jars are not signed when releasing maven-indexer > --- > > Key: MNG-4908 > URL: http://jira.codehaus.org/browse/MNG-4908 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Brian Demers >Assignee: Brian Demers > > The sources plugin runs after the gpg plugin. > They both run in the verify phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4908) source jars are not signed when releasing maven-indexer
[ http://jira.codehaus.org/browse/MNG-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Demers updated MNG-4908: -- Component/s: POM Affects Version/s: (was: 3.1) 3.0.1 This is not actually a bug, I was just trying to track the changes needed to the parent poms > source jars are not signed when releasing maven-indexer > --- > > Key: MNG-4908 > URL: http://jira.codehaus.org/browse/MNG-4908 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 3.0.1 >Reporter: Brian Demers >Assignee: Brian Demers > > The sources plugin runs after the gpg plugin. > They both run in the verify phase. -- 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-4908) source jars are not signed when releasing maven-indexer
[ http://jira.codehaus.org/browse/MNG-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243818#action_243818 ] Brian Demers commented on MNG-4908: --- Benjamin pointed out that the indexer pom was redefining the sources plugin config. ( I didn't notice this ) So the parent changes are fine, it changes the gpg version to 1.1. I will remove the extra sources plugin config from the indexer pom > source jars are not signed when releasing maven-indexer > --- > > Key: MNG-4908 > URL: http://jira.codehaus.org/browse/MNG-4908 > Project: Maven 2 & 3 > Issue Type: Bug > Components: POM >Affects Versions: 3.0.1 >Reporter: Brian Demers >Assignee: Brian Demers > > The sources plugin runs after the gpg plugin. > They both run in the verify phase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243822#action_243822 ] Dennis Lundberg commented on MSITE-525: --- Greg, This is the way it is supposed to be. If you want to separate the lines within a paragraph you need to use a forced line break using the \ character. If you don't put any forced line breaks inside the paragraph, the line will break when the window's width is reached, just like a in HTML does and just like a paragraph does in a word processor. Is there anything in the docs that you find is unclear? If so how could we make it more clear? > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-525) Generated html from apt is ignoring all paragraph lines
[ http://jira.codehaus.org/browse/MSITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243823#action_243823 ] Greg Mirabito commented on MSITE-525: - Dennis, Thanks for the response. The documentation does seem to indicate that a forced line break is not required on paragraphs. However, adding the \ at the end of each line works for me. Thanks, greg > Generated html from apt is ignoring all paragraph lines > --- > > Key: MSITE-525 > URL: http://jira.codehaus.org/browse/MSITE-525 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: mac osx >Reporter: Greg Mirabito > > I create a simple apt file with two lines in it. > This is line1. > This is line2. > Run mvn site and look at the generated html. There is no line break. -- 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: (MEV-673) Incorrect hashes in http://repo1.maven.org/maven2/org/apache/httpcomponents/project/4.1/
[ http://jira.codehaus.org/browse/MEV-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243824#action_243824 ] J. David Beutel commented on MEV-673: - Thank you! Now I can @Grab the latest Selenium. > Incorrect hashes in > http://repo1.maven.org/maven2/org/apache/httpcomponents/project/4.1/ > > > Key: MEV-673 > URL: http://jira.codehaus.org/browse/MEV-673 > Project: Maven Evangelism > Issue Type: Bug > Components: Checksum Failure >Reporter: SebbASF > > See: https://issues.apache.org/jira/browse/HTTPCLIENT-1017 > We have reset the hashes on Nexus, and the Maven metadata has been updated, > but the updated files have not been replicated. > Please could you resynch the hashes? -- 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
