[jira] Commented: (MRESOURCES-152) The dependency of JUnit 3.8.1 may override the depended JUnit version of the project

[Haixing Hu (JIRA)]

[ 
https://jira.codehaus.org/browse/MRESOURCES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275448#comment-275448
 ] 

Haixing Hu commented on MRESOURCES-152:
---

Oh my god!
It's so strange. I just recompiled the porject again and was surprised to found 
that the porject passed the compilation! But I swear it was not got compiled 
yeasterday.

I remember that the only thing I have done is to remove all my "~/.m2" 
directory and force the maven to downloads all dependency again.

Maybe some conflicts of dependency caused that problem.

Anyway, the good news is that my project got compiled, and the bad news is that 
the protential bug may still exist and I can't reproduce it.

So I close this issue.

> The dependency of JUnit 3.8.1 may override the depended JUnit version of the 
> project
> 
>
> Key: MRESOURCES-152
> URL: https://jira.codehaus.org/browse/MRESOURCES-152
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Haixing Hu
>Priority: Blocker
>
> As the following pages state:
> http://maven.apache.org/plugins/maven-resources-plugin/dependencies.html
> The maven resources plugin itself depends on the JUnit 3.8.1, and any project 
> using this plugin will be introduced a transitive dependency of JUnit 3.8.1. 
> This will cause the projects which use JUnit 4.x in their unit test fail to 
> pass the compilation under the command line (i.e., via "mvn install"), but 
> they could be compiled under eclipse.
> I can't understand why this plugin has to introduce the dependency of Junit. 
> Is it really necessary? If it is, could you please upgrade the JUnit to 
> version 4 or above? Since JUnit 4.x provides a lot of assertArrayEquals(...) 
> functions, which are really widely used.
> Thank you in advance.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MRESOURCES-152) The dependency of JUnit 3.8.1 may override the depended JUnit version of the project

[Haixing Hu (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRESOURCES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Haixing Hu closed MRESOURCES-152.
-

Resolution: Cannot Reproduce

Just remove the directory "~/.m2", the bug dispeared.

> The dependency of JUnit 3.8.1 may override the depended JUnit version of the 
> project
> 
>
> Key: MRESOURCES-152
> URL: https://jira.codehaus.org/browse/MRESOURCES-152
> Project: Maven 2.x Resources Plugin
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Haixing Hu
>Priority: Blocker
>
> As the following pages state:
> http://maven.apache.org/plugins/maven-resources-plugin/dependencies.html
> The maven resources plugin itself depends on the JUnit 3.8.1, and any project 
> using this plugin will be introduced a transitive dependency of JUnit 3.8.1. 
> This will cause the projects which use JUnit 4.x in their unit test fail to 
> pass the compilation under the command line (i.e., via "mvn install"), but 
> they could be compiled under eclipse.
> I can't understand why this plugin has to introduce the dependency of Junit. 
> Is it really necessary? If it is, could you please upgrade the JUnit to 
> version 4 or above? Since JUnit 4.x provides a lot of assertArrayEquals(...) 
> functions, which are really widely used.
> Thank you in advance.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-1378) Make dependencies of test-jars transitive

[William Ghelfi (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275451#comment-275451
 ] 

William Ghelfi commented on MNG-1378:
-

I have a (not so) slightly different use case and really would like to see this 
issue fixed...

> Make dependencies of test-jars transitive
> -
>
> Key: MNG-1378
> URL: https://jira.codehaus.org/browse/MNG-1378
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 2.0
>Reporter: Mark Hobson
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: mng1378.tar.gz
>
>
> test-jar transitive dependencies are calculated as per compile scope rather 
> than test scope.
> The situation is demonstrated nicely in it0077:
> * module sub1 has a test-scoped dependency of commons-lang
> * module sub2 has a test-scoped dependency of sub1 test-jar
> sub2 tests should inherit the commons-lang transitive dependency.  For 
> example:
> Index: 
> maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
> ===
> --- 
> maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
>   (revision
> 328307)
> +++ 
> maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
>   (working
> copy)
> @@ -1,6 +1,7 @@
>  package org.apache.maven.it0077;
>  import junit.framework.TestCase;
> +import org.apache.commons.lang.BooleanUtils;
>  public class PersonTwoTest
> extends PersonTest
> Results in:
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Compilation failure
> c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31]
> package org.apache.commons.lang does not exist

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-240) archiveClasses and attachClasses in 2.1

[Sergiy Shyrkov (JIRA)]

[ 
https://jira.codehaus.org/browse/MWAR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275452#comment-275452
 ] 

Sergiy Shyrkov commented on MWAR-240:
-

Confirm, same issue with Maven 3 and maven-war-plugin 2.1.1 on Windows.

Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

> archiveClasses and attachClasses in 2.1
> ---
>
> Key: MWAR-240
> URL: https://jira.codehaus.org/browse/MWAR-240
> Project: Maven 2.x WAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_18
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergiy Shyrkov
> Attachments: effective-pom.out, mwar-240-test-case.zip
>
>
> There seems to be a regression between 2.1-beta-1 and 2.1 with regard to 
> archiveClasses and attachClasses options.
> My use case:
> I have a WAR project with Java classes and I am setting both archiveClasses 
> and attachClasses to true.
> With 2.1-beta-1 it was working correctly (mvn clean install) --> I got 
> classes packaged into a JAR and placed into WEB-INF/lib and I got that JAR 
> artifact deployed to my Maven repository.
> Just upgraded to 2.1 and I got the following with the same use case: I got 
> classes packaged into a JAR and placed into WEB-INF/lib (correct) and I got 
> an empty JAR artifact (only META-INF/ present) deployed to my Maven 
> repository (incorrect).
> Looking at the code in 2.1 of WarMojo (line 230) I am seeing that the classes 
> folder (for classes to be included into attached artifact) is empty, because 
> it was cleared before due to archiveClasses=true
> Trying to debug both code branches I am seeing a difference between 
> 2.1-beta-1 and 2.1 in that the
> getJarArchiver().getDirs() before the call to packager.packageClasses() 
> method (line 233/234)
> is empty in the 2.1:
>(java.util.HashMap) {}
> whereas it is not in 2.1-beta-1. It contains a list of all my classes, 
> perhaps because the same archiver instance was used to package them into JAR 
> for WEB-INF/lib.
> That is why I am getting all my classes in the attached artifact with 
> 2.1-beta-1
> I would really need your help in understanding the "correct" behaviour.
> Is this a regression bug for 2.1 or I am completely wrong in my expectations 
> about archiveClasses and attachClasses used together?
> Kind regards
> Sergiy Shyrkov

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MINDEXER-35) Make Indexer index classes in WAR too

[JIRA]

Make Indexer index classes in WAR too
-

 Key: MINDEXER-35
 URL: https://jira.codehaus.org/browse/MINDEXER-35
 Project: Maven Indexer
  Issue Type: Improvement
Reporter: Tamás Cservenák


Make Indexer index classes in WAR too.

Currently, Indexer "cranks up and index" JARs only, while WARs may contain 
classes too

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SUREFIRE-329) Support for JUNIT extensions

[Roy Truelove (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275459#comment-275459
 ] 

Roy Truelove commented on SUREFIRE-329:
---

This would be huge.  No more having to have hacky package names to 
differentiate between unit/integration or small/medium/large tests.

> Support for JUNIT extensions
> 
>
> Key: SUREFIRE-329
> URL: https://jira.codehaus.org/browse/SUREFIRE-329
> Project: Maven Surefire
>  Issue Type: Wish
>  Components: Junit 4.x support
>Reporter: Anuj Kathuria
> Fix For: Backlog
>
>
> Is there any plan to support using JUNIT extensions such as 
> @Category,@PreRequisite with Maven2 SureFire plugin?
> The JUNIT EXTENSION URL:
> http://www.junitext.org/
> We would like to specify the categories to run via a configurable option in 
> the maven surefire plugin that supports JUNIT extensions
> See example Java Code: The following runs only tests with Category - Z.
>  //In JUnit4
> JUnitCore core = new JUnitCore();
> // use for categories special listener, give some statistics
> core.addListener(new CategoryTextListener(System.out));
> Request req = Request.aClass(SpcfTest.class);
> core.run(req.filterWith(new CategoryFilter("Z")));

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-582) Make it possible to remove breadcrumbs in child projects again

[Herve Boutemy (JIRA)]

[ 
https://jira.codehaus.org/browse/MSITE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275460#comment-275460
 ] 

Herve Boutemy commented on MSITE-582:
-

ok, here is a proposal that should be easy to understand (and I hope it will be 
easy to implement):
suppose a project, with its all parents, has following breacrumbs:
A > B > C > D > E > F

I want a child to remove D > E > F and replace with M > N > O
If that child defines C > M > N > O, C is found in actual breadcrumbs, then we 
can delete the following items and replace with the suite

I think it is natural.
If you find it convenient, I'll look at the way to implement this logic...

> Make it possible to remove breadcrumbs in child projects again
> --
>
> Key: MSITE-582
> URL: https://jira.codehaus.org/browse/MSITE-582
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: New Feature
>  Components: inheritance
>Affects Versions: 3.0
>Reporter: Andreas Sewe
> Attachments: example.tar.gz
>
>
> Currently a child can only add more breadcrumbs. There are situations, 
> however, where it is desirable to remove some or all of the breadcrumbs 
> defined by the parent, in particular when the Maven project hierarchy doesn't 
> match the _natural_ hierarchy of the site. See 
>  for an 
> example (also attached).
> One way to do this, without requiring changes to the {{site.xml}} format and 
> with only minimal breakage of compatibility, would be to simply use the 
> child's breadcrumbs wholesale whenever they are a prefix to the parents.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSITE-582) Make it possible to remove breadcrumbs in child projects again

[Andreas Sewe (JIRA)]

[ 
https://jira.codehaus.org/browse/MSITE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275461#comment-275461
 ] 

Andreas Sewe commented on MSITE-582:


Sounds good to me _if_ the following boundary case is supported as well:

bq. I want a child to remove D > E > F. The child thus defines C, which results 
in A > B > C being picked for its breadcrumbs.

That being said, I don't want to be the only one who has a say in this issue. 
Maybe you should take this conversation to {{d...@maven.apache.org}}.

> Make it possible to remove breadcrumbs in child projects again
> --
>
> Key: MSITE-582
> URL: https://jira.codehaus.org/browse/MSITE-582
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: New Feature
>  Components: inheritance
>Affects Versions: 3.0
>Reporter: Andreas Sewe
> Attachments: example.tar.gz
>
>
> Currently a child can only add more breadcrumbs. There are situations, 
> however, where it is desirable to remove some or all of the breadcrumbs 
> defined by the parent, in particular when the Maven project hierarchy doesn't 
> match the _natural_ hierarchy of the site. See 
>  for an 
> example (also attached).
> One way to do this, without requiring changes to the {{site.xml}} format and 
> with only minimal breakage of compatibility, would be to simply use the 
> child's breadcrumbs wholesale whenever they are a prefix to the parents.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MNG-4680) Please fix license distribution model

[Mark Struberg (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-4680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg closed MNG-4680.
--

Resolution: Not A Bug

Bruno, what Benjamin tried to express is that Maven itself is _NOT_ responsible 
for adding any LICENSE.txt file to the artifacts!

There are mechanisms which are perfectly supporting this use case, but this 
options also must get used by the maintainers of the respective OSS projects. 

As you can see in all ASF maintained projects it _is_ certainly possible as we 
contain a LICENSE.txt in all of our jars.

If you think that there could be an improvement done to the 
maven-repository-plugin then please feel free to report an issue over there.

> Please fix license distribution model
> -
>
> Key: MNG-4680
> URL: https://jira.codehaus.org/browse/MNG-4680
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Reporter: Bruno Harbulot
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
>
> Most OSS licences mandate the redistribution of the licence with the software 
> as a condition in the licence. A large number of projects, more particularly 
> in the central repository, are redistributed without any mechanism to 
> redistribute the licence correctly, thereby making the central repository be 
> in breach of those licences.
> While there is a guideline in the "Introduction to the Standard Directory 
> Layout" [1] to put the LICENSE.txt and NOTICE.txt file in the root directory, 
> nothing seems to be done with them.
> In addition:
>   - Since version 2.1 of the maven-repository-plugin, LICENSE.txt is no 
> longer included in the bundle created with repository:bundle-create.
>   - LICENSE.txt files in bundles uploaded via the JIRA/MAVENUPLOAD mechanism 
> don't seem to appear in the central repository.
> Having BSD or GPL in the POM is not 
> enough.
> (See related thread [2].)
> [1] 
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
> [2] 
> http://markmail.org/thread/s5jsvatxbsynwajc#query:+page:1+mid:whtbsnnejszyad2h+state:results

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MANTRUN-167) Maven Plugin Doesn't allow me to SETUP JDK 1.4.2 Version

[daivish shah (JIRA)]

Maven Plugin Doesn't allow me to SETUP JDK 1.4.2 Version


 Key: MANTRUN-167
 URL: https://jira.codehaus.org/browse/MANTRUN-167
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.6
 Environment: Windows
Reporter: daivish shah


Hi,

I am using MAVEN 2.2.1 version and trying to compile my classes from ANT 
script. 

I want to compile my classes with JDK 1.4.2 version. How can i do it ?

Following one is my entry which i am using EVEN i am setting up rt.jar and 
tools.jar with JDK 1.4.2 in my build.xml file still my Eclipse is referring JDK 
1.5 version only.



org.apache.maven.plugins
maven-antrun-plugin
1.6


install
install

run



${java-version}

${java-version}







   
 sun.jdk
 tools
 1.4.2
 system
 
${java.home}/lib/tools.jar






Please advice me which property is available in maven-antrun-plugin so i can 
set that and my compiler use JDK 1.4.2 version ?

I am really stuck here. I am looking for your reply.

Thanks,
daivish..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MSANDBOX-51) Rewrite Plexus Utils classes at the ASF from scratch

[Mark Struberg (JIRA)]

[ 
https://jira.codehaus.org/browse/MSANDBOX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275495#comment-275495
 ] 

Mark Struberg commented on MSANDBOX-51:
---

It seems that a big part of the plexus code is actually coming from the Apache 
Avalon project and only got copied over.
Some classes, like Os.java are almost 1:1 copies of ASF originated sources!.

To reduce the amount of work, it is suggested to take the ASF original code, 
copy it over to our new sandbox project and apply the maven codestyle.

The code needs proper testing of course to ensure that there has no 
incompatibility been introduced.

> Rewrite Plexus Utils classes at the ASF from scratch
> 
>
> Key: MSANDBOX-51
> URL: https://jira.codehaus.org/browse/MSANDBOX-51
> Project: Maven 2.x Sandbox
>  Issue Type: New Feature
>Reporter: Mark Struberg
>
> plexus-utils are 85% written by ASF committers, but we still don't have a IP 
> cleared history.
> For cleaning this up we aim to rewrite those classes from scratch in ASF 
> maven sandbox.
> The strategy is the following:
> 1. create unit tests for the existing plexus classes
> 2. create a new implementation from scratch
> 3. the new implementation must be a binary API compatible drop-in replacement

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira