[jira] [Commented] (MSITE-802) Support more than one directory

[Allen Wittenauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254725#comment-16254725
 ] 

Allen Wittenauer commented on MSITE-802:


Here's a slightly modified example that uses Apache Yetus. This might be too 
complex for an example though.

{code}
  
org.codehaus.mojo
exec-maven-plugin


shelldocs
pre-site

exec


shelldocs

${project.build.directory}/generated-site/site/markdown

--skipprnorep
--output

${project.build.directory}/generated-site/markdown/UnixShellAPI.md
--input

${basedir}/src/main/bin/hadoop-functions.sh




  
{code}

This example runs Apache Yetus' shelldocs command on the hadoop-functions.sh 
script to generate markdown-formatted documentation.

> Support more than one directory
> ---
>
> Key: MSITE-802
> URL: https://issues.apache.org/jira/browse/MSITE-802
> Project: Maven Site Plugin
>  Issue Type: Task
>Reporter: Allen Wittenauer
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.7
>
>
> It would be great if maven-site-plugin could support more than one site 
> directory per module.  Specifically, I'm looking for a way to process 
> generated content without copying all of src/site into target where my 
> generated content is sitting or using a separate module that only handles 
> generated content to get aggregated later.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MJAVADOC-499) Ignore module-info.java on earlier Java versions

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254203#comment-16254203
 ] 

Robert Scholte commented on MJAVADOC-499:
-

If I add a {{module-info.java}} to my project, I expect it to be compiled and 
added to my classes. If somebody uses an older version of Java, I would like to 
see the build break to make that developer aware that must use Java 9 to 
compile this project. The module descriptor contains to much important info to 
be simply ignored. 
Even though javadoc is about reporting, I prefer to let it behave as strict as 
the maven-compiler-plugin.

I can only imagine that if the module descriptor was NOT compiled, then this 
file can be ignored as well for javadoc. In fact: all compiled classes should 
match all javadoc sourcefiles.

> Ignore module-info.java on earlier Java versions
> 
>
> Key: MJAVADOC-499
> URL: https://issues.apache.org/jira/browse/MJAVADOC-499
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Stephen Colebourne
>Assignee: Robert Scholte
> Fix For: 3.0.0
>
>
> Versions of the javadoc tool prior to Java 9 cannot process 
> `module-info.java`. The plugin should automatically detect and exclude 
> `module-info.java` if the javadoc tool is Java 8 or earlier. The alternative 
> (Java version specific profiles) does work, but is very verbose for something 
> that can never work (thus the plugin should deal with it)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MNG-6306) Replace use of Guava in maven-resolver-provider with a lighter weight alternative

[Andy Wilkinson (JIRA)]

Andy Wilkinson created MNG-6306:
---

 Summary: Replace use of Guava in maven-resolver-provider with a 
lighter weight alternative
 Key: MNG-6306
 URL: https://issues.apache.org/jira/browse/MNG-6306
 Project: Maven
  Issue Type: Improvement
Affects Versions: 3.5.2
Reporter: Andy Wilkinson


Spring Boot's CLI currently embeds Aether and uses Maven's Aether Provider 
3.2.1. We'd [like to switch to Maven Resolver and Maven Resolver 
Provider|https://github.com/spring-projects/spring-boot/issues/7627] but the 
use of Guava adds 2.4MB to a < 10MB binary. We'd like to avoid that 25% 
increase if we can.

Given that Aether and Maven Resolver are intended to be embedded, would it be 
possible to remove the use of Guava from Maven Resolver Provider? Its use 
appears to have been added in [this 
commit|https://github.com/apache/maven/commit/61c374042560b2dc21c294886615931a888df597#diff-b275596b2058bcd469e4c45288cef7b4].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MRESOLVER-29) Move ant tasks into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253841#comment-16253841
 ] 

Manfred Moser edited comment on MRESOLVER-29 at 11/15/17 5:48 PM:
--

The ant tasks are published (installed and deployed) as normal so there is no 
issue.

The second issue indicated seems more a code and dependency problem than a 
reason to keep it in a separate branch. Looking at the pom the shade plugin is 
used to create an uber jar and there is all sorts of funky relocation and stuff 
happening. I have a feeling we should merge this all into one branch and then 
work on cleaning this uber jar up more. mavenVersion is already set at 3.5.0 
and we should therefore be able to get rid of a lot of this magic since all the 
relocation work is no longer needed with 3.5.2 and in the ant runtime context 
it can all be just consistently with newer versions instead of trying be 
compatible with old maven versions and dealing with the funky moves of resolver 
to sonatype, to eclipse and back to apache.

I think if the ant tasks are not releasable at any time the resolver should not 
be released either and having them all in one multi module project expresses 
that idea better. 

The main reason I did the change is so that it is easier to see the code all in 
one place and work with it as well as cleaner for the user and to maintain as 
an overall project. Wdyt? 

Also if there are specific changes for the ant task I can do to fix the 
dependency version issues I can attack them after the merge and prior to the 
next release. 


was (Author: simpligility):
The ant tasks are published (installed and deployed) as normal so there is no 
issue.

The second issue indicated seems more a code and dependency problem than a 
reason to keep it in a separate branch. Looking at the pom the shade plugin is 
used to create an uber jar and there is all sorts of funky relocation and stuff 
happening. I have a feeling we should merge this all into one branch and then 
work on cleaning this uber jar up more. mavenVersion is already set at 3.5.0 
and we should therefore be able to get rid of a lot of this magic since all the 
relocation work is no longer needed with 3.5.2 and in the ant runtime context 
it can all be just consistently with newer versions instead of trying be 
compatible with old maven versions. 

I think if the ant tasks are not releasable at any time the resolver should not 
be released either and having them all in one multi module project expresses 
that idea better. 

The main reason I did the change is so that it is easier to see the code all in 
one place and work with it as well as cleaner for the user and to maintain as 
an overall project. Wdyt? 

Also if there are specific changes for the ant task I can do to fix the 
dependency version issues I can attack them after the merge and prior to the 
next release. 

> Move ant tasks into master as new module
> 
>
> Key: MRESOLVER-29
> URL: https://issues.apache.org/jira/browse/MRESOLVER-29
> Project: Maven Resolver
>  Issue Type: Task
>  Components: ant tasks
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The ant tasks of Maven Resolver are currently in a separate branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MRESOLVER-29) Move ant tasks into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253841#comment-16253841
 ] 

Manfred Moser edited comment on MRESOLVER-29 at 11/15/17 5:47 PM:
--

The ant tasks are published (installed and deployed) as normal so there is no 
issue.

The second issue indicated seems more a code and dependency problem than a 
reason to keep it in a separate branch. Looking at the pom the shade plugin is 
used to create an uber jar and there is all sorts of funky relocation and stuff 
happening. I have a feeling we should merge this all into one branch and then 
work on cleaning this uber jar up more. mavenVersion is already set at 3.5.0 
and we should therefore be able to get rid of a lot of this magic since all the 
relocation work is no longer needed with 3.5.2 and in the ant runtime context 
it can all be just consistently with newer versions instead of trying be 
compatible with old maven versions. 

I think if the ant tasks are not releasable at any time the resolver should not 
be released either and having them all in one multi module project expresses 
that idea better. 

The main reason I did the change is so that it is easier to see the code all in 
one place and work with it as well as cleaner for the user and to maintain as 
an overall project. Wdyt? 

Also if there are specific changes for the ant task I can do to fix the 
dependency version issues I can attack them after the merge and prior to the 
next release. 


was (Author: simpligility):
The ant tasks are published (installed and deployed) as normal so there is no 
issue.

The second issue indicated more a code and dependency problem than a reason to 
keep it in a separate branch. Looking at the pom the shade plugin is used to 
create an uber jar and there is all sorts of funky relocation and stuff 
happening. I have a feeling we should merge this all into one branch and then 
work on cleaning this uber jar up more. mavenVersion is already set at 3.5.0 
and we should therefore be able to get rid of a lot of this magic since all the 
relocation work is no longer needed with 3.5.2 and in the ant runtime context 
it can all be just consistently with newer versions instead of trying be 
compatible with old maven versions. 

I think if the ant tasks are not releasable at any time the resolver should not 
be released either and having them all in one multi module project expresses 
that idea better. 

The main reason I did the change is so that it is easier to see the code all in 
one place and work with it as well as cleaner for the user and to maintain as 
an overall project. Wdyt? 

Also if there are specific changes for the ant task I can do to fix the 
dependency version issues I can attack them after the merge and prior to the 
next release. 

> Move ant tasks into master as new module
> 
>
> Key: MRESOLVER-29
> URL: https://issues.apache.org/jira/browse/MRESOLVER-29
> Project: Maven Resolver
>  Issue Type: Task
>  Components: ant tasks
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The ant tasks of Maven Resolver are currently in a separate branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-29) Move ant tasks into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253841#comment-16253841
 ] 

Manfred Moser commented on MRESOLVER-29:


The ant tasks are published (installed and deployed) as normal so there is no 
issue.

The second issue indicated more a code and dependency problem than a reason to 
keep it in a separate branch. Looking at the pom the shade plugin is used to 
create an uber jar and there is all sorts of funky relocation and stuff 
happening. I have a feeling we should merge this all into one branch and then 
work on cleaning this uber jar up more. mavenVersion is already set at 3.5.0 
and we should therefore be able to get rid of a lot of this magic since all the 
relocation work is no longer needed with 3.5.2 and in the ant runtime context 
it can all be just consistently with newer versions instead of trying be 
compatible with old maven versions. 

I think if the ant tasks are not releasable at any time the resolver should not 
be released either and having them all in one multi module project expresses 
that idea better. 

The main reason I did the change is so that it is easier to see the code all in 
one place and work with it as well as cleaner for the user and to maintain as 
an overall project. Wdyt? 

Also if there are specific changes for the ant task I can do to fix the 
dependency version issues I can attack them after the merge and prior to the 
next release. 

> Move ant tasks into master as new module
> 
>
> Key: MRESOLVER-29
> URL: https://issues.apache.org/jira/browse/MRESOLVER-29
> Project: Maven Resolver
>  Issue Type: Task
>  Components: ant tasks
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The ant tasks of Maven Resolver are currently in a separate branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253785#comment-16253785
 ] 

Manfred Moser commented on MRESOLVER-28:


Demos are not deployed as the plugin is skipped. This is the same as it is in 
the current branch.

> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MDEP-584) Upgrade plexus-utils to version 3.1.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253633#comment-16253633
 ] 

ASF GitHub Bot commented on MDEP-584:
-

GitHub user io7m opened a pull request:

https://github.com/apache/maven-plugins/pull/135

[MDEP-584] Update plexus-utils to 3.1.0

This updates the plexus-utils dependency to 3.1.0. It corrects four
unit tests that were failing due to new behaviour in 3.1.0: It appears
that the new plexus-utils copies the lastModified attributes of files,
and the old tests were implicitly depending on the attributes not
being copied.

Fixes: MDEP-584

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/io7m/maven-plugins trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/135.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #135


commit 59c0f89db6e69e8c4287c9dee07b831b26fcbca3
Author: Mark Raynsford 
Date:   2017-11-15T15:28:27Z

[MDEP-584] Update plexus-utils to 3.1.0

This updates the plexus-utils dependency to 3.1.0. It corrects four
unit tests that were failing due to new behaviour in 3.1.0: It appears
that the new plexus-utils copies the lastModified attributes of files,
and the old tests were implicitly depending on the attributes not
being copied.

Fixes: MDEP-584




> Upgrade plexus-utils to version 3.1.0
> -
>
> Key: MDEP-584
> URL: https://issues.apache.org/jira/browse/MDEP-584
> Project: Maven Dependency Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.0
>
>
> Currently an upgrade will fail the following unit tests in maven-dependency 
> plugin:
> {code}
> Results :
> Failed tests:
>   TestCopyMojo.testCopyOverWriteReleases:694
>   TestCopyMojo.testCopyOverWriteSnapshot:723
>   TestCopyDependenciesMojo.testOverWriteRelease:592 time = 1504955654000 
> should be < to 1504955652000
>   TestCopyDependenciesMojo.testOverWriteSnap:661
> Tests run: 244, Failures: 4, Errors: 0, Skipped: 0
> {code}
> I need to investigate those tests...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MDEP-584) Upgrade plexus-utils to version 3.1.0

[Mark Raynsford (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253429#comment-16253429
 ] 

Mark Raynsford edited comment on MDEP-584 at 11/15/17 1:28 PM:
---

I've had look at this, and it seems to me like the new version of plexus-utils 
copies the last modified time of files, whereas the old version evidently 
didn't. Those tests above seem to depend upon the old behaviour.

Here's a patch to demonstrate what I mean:

{code:java}
diff --git 
a/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
 
b/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
index 7cc11e286..fdb7280bf 100644
--- 
a/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
+++ 
b/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
@@ -666,12 +666,20 @@ public class TestCopyMojo
 assertEquals( time, copiedFile.lastModified() );
 }
 
+/**
+ * Test that the given release artifact is copied, and the copy is 
overwritten if the Mojo is executed again.
+ *
+ * @throws Exception On errors
+ */
+
 public void testCopyOverWriteReleases()
 throws Exception
 {
 stubFactory.setCreateFiles( true );
 Artifact release = stubFactory.getReleaseArtifact();
-assertTrue( release.getFile().setLastModified( 
System.currentTimeMillis() - 2000 ) );
+
+assertTrue( release.getFile().setLastModified( 1000L ) );
+assertEquals( 1000L, release.getFile().lastModified() );
 
 ArtifactItem item = new ArtifactItem( release );
 
@@ -685,13 +693,13 @@ public class TestCopyMojo
 
 File copiedFile = new File( item.getOutputDirectory(), 
item.getDestFileName() );
 
-// round up to the next second
-long time = System.currentTimeMillis() - 2000;
-assertTrue( copiedFile.setLastModified( time ) );
+assertTrue( copiedFile.setLastModified( 2000L ) );
+assertEquals( 2000L, copiedFile.lastModified() );
 
 mojo.execute();
 
-assertTrue( time < copiedFile.lastModified() );
+long timeCopyNow = copiedFile.lastModified();
+assertTrue( "Artifact time " + 2000L + " must be < " + timeCopyNow, 
2000L < timeCopyNow );
 }
 
 public void testCopyOverWriteSnapshot()
{code}

Try the above patch with 3.0.24 and 3.1.0. You can see that the final value of 
copiedFile.lastModified() is 1000L when using 3.1.0, but is roughly equal to 
the current time on 3.0.24.

I'm a little hesitant to submit actual fixes until someone else has assured me 
that I've actually understood what the tests are trying to test. If my 
understanding is correct though, I think I can have all of these done by the 
end of the day.



was (Author: io7m):
I've had look at this, and it seems to me like the new version of plexus-utils 
copies the last modified time of files, whereas the old version evidently 
didn't. Those tests above seem to depend upon the old behaviour.

Here's a patch to demonstrate what I mean:

{code:java}
diff --git 
a/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
 
b/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
index 7cc11e286..fdb7280bf 100644
--- 
a/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
+++ 
b/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
@@ -666,12 +666,20 @@ public class TestCopyMojo
 assertEquals( time, copiedFile.lastModified() );
 }
 
+/**
+ * Test that the given release artifact is copied, and the copy is 
overwritten if the Mojo is executed again.
+ *
+ * @throws Exception On errors
+ */
+
 public void testCopyOverWriteReleases()
 throws Exception
 {
 stubFactory.setCreateFiles( true );
 Artifact release = stubFactory.getReleaseArtifact();
-assertTrue( release.getFile().setLastModified( 
System.currentTimeMillis() - 2000 ) );
+
+assertTrue( release.getFile().setLastModified( 1000L ) );
+assertEquals( 1000L, release.getFile().lastModified() );
 
 ArtifactItem item = new ArtifactItem( release );
 
@@ -685,13 +693,13 @@ public class TestCopyMojo
 
 File copiedFile = new File( item.getOutputDirectory(), 
item.getDestFileName() );
 
-// round up to the next second
-long time = System.currentTimeMillis() - 2000;
-assertTrue( copiedFile.setLastModified( time ) );
+assertTrue( copiedFile.setLastModified( 2000L ) );
+assertEquals( 2000L, copiedFile.lastModified() );
 
   

[jira] [Commented] (MDEP-584) Upgrade plexus-utils to version 3.1.0

[Mark Raynsford (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253429#comment-16253429
 ] 

Mark Raynsford commented on MDEP-584:
-

I've had look at this, and it seems to me like the new version of plexus-utils 
copies the last modified time of files, whereas the old version evidently 
didn't. Those tests above seem to depend upon the old behaviour.

Here's a patch to demonstrate what I mean:

{code:java}
diff --git 
a/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
 
b/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
index 7cc11e286..fdb7280bf 100644
--- 
a/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
+++ 
b/maven-dependency-plugin/src/test/java/org/apache/maven/plugins/dependency/fromConfiguration/TestCopyMojo.java
@@ -666,12 +666,20 @@ public class TestCopyMojo
 assertEquals( time, copiedFile.lastModified() );
 }
 
+/**
+ * Test that the given release artifact is copied, and the copy is 
overwritten if the Mojo is executed again.
+ *
+ * @throws Exception On errors
+ */
+
 public void testCopyOverWriteReleases()
 throws Exception
 {
 stubFactory.setCreateFiles( true );
 Artifact release = stubFactory.getReleaseArtifact();
-assertTrue( release.getFile().setLastModified( 
System.currentTimeMillis() - 2000 ) );
+
+assertTrue( release.getFile().setLastModified( 1000L ) );
+assertEquals( 1000L, release.getFile().lastModified() );
 
 ArtifactItem item = new ArtifactItem( release );
 
@@ -685,13 +693,13 @@ public class TestCopyMojo
 
 File copiedFile = new File( item.getOutputDirectory(), 
item.getDestFileName() );
 
-// round up to the next second
-long time = System.currentTimeMillis() - 2000;
-assertTrue( copiedFile.setLastModified( time ) );
+assertTrue( copiedFile.setLastModified( 2000L ) );
+assertEquals( 2000L, copiedFile.lastModified() );
 
 mojo.execute();
 
-assertTrue( time < copiedFile.lastModified() );
+long timeCopyNow = copiedFile.lastModified();
+assertTrue( "Artifact time " + 2000L + " must be < " + timeCopyNow, 
2000L < timeCopyNow );
 }
 
 public void testCopyOverWriteSnapshot()
{code}

Try the above patch with 3.0.24 and 3.1.0. You can see that the final value of 
copiedFile.lastModified() is 1000L when using 3.1.0, but is roughly equal to 
the current time on 3.0.24.


> Upgrade plexus-utils to version 3.1.0
> -
>
> Key: MDEP-584
> URL: https://issues.apache.org/jira/browse/MDEP-584
> Project: Maven Dependency Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.0
>
>
> Currently an upgrade will fail the following unit tests in maven-dependency 
> plugin:
> {code}
> Results :
> Failed tests:
>   TestCopyMojo.testCopyOverWriteReleases:694
>   TestCopyMojo.testCopyOverWriteSnapshot:723
>   TestCopyDependenciesMojo.testOverWriteRelease:592 time = 1504955654000 
> should be < to 1504955652000
>   TestCopyDependenciesMojo.testOverWriteSnap:661
> Tests run: 244, Failures: 4, Errors: 0, Skipped: 0
> {code}
> I need to investigate those tests...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MINDEXER-107) Shaded-lucene indexer-core should have its own POM

[Andreas Sewe (JIRA)]

Andreas Sewe created MINDEXER-107:
-

 Summary: Shaded-lucene indexer-core should have its own POM
 Key: MINDEXER-107
 URL: https://issues.apache.org/jira/browse/MINDEXER-107
 Project: Maven Indexer
  Issue Type: Improvement
Affects Versions: 6.0
Reporter: Andreas Sewe
Priority: Minor


While I like the idea that {{indexer-core}} is also available with a 
{{shaded-lucene}} classifier (given the likelihood of clashes with another, 
incompatible Lucene already on the classpath), the current, classifier-based 
implementation is not ideal:

The {{shaded-lucene}} JAR shares its POM with the primary {{indexer-core}} JAR, 
i.e., there is no *dependency-reduced* POM available for easy consumption by 
clients. Thus, every user of the {{shaded-lucene}} JAR needs a lengthy 
{{}} list – which needs to be kept in-sync with {{lucene-core}}’s 
{{maven-shade-plugin}} configuration:

{noformat}

org.apache.maven.indexer
indexer-core
shaded-lucene
6.0-SNAPSHOT


org.apache.lucene
lucene-core


org.apache.lucene
lucene-queryparser


org.apache.lucene
lucene-queries


org.apache.lucene
lucene-sandbox


org.apache.lucene
lucene-analyzers-common


org.apache.lucene
lucene-backward-codecs


org.apache.lucene
lucene-highlighter


org.apache.lucene
lucene-join


org.apache.lucene
lucene-memory


org.apache.commons
commons-compress


org.bouncycastle
bcprov-jdk16



{noformat}

IMHO, it would be better to have a separate {{indexer-core-standalone}} project 
whose dependency-reduced POM is deployed and thus available for easy 
consumption by clients



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6302) Provide some "progress" hints

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253194#comment-16253194
 ] 

ASF GitHub Bot commented on MNG-6302:
-

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/136
  
@hboutemy Tested your branch. Great improvement to the PR! +1


> Provide some "progress" hints
> -
>
> Key: MNG-6302
> URL: https://issues.apache.org/jira/browse/MNG-6302
> Project: Maven
>  Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> High level need is to know when you launched a "long"/"big" build where you 
> are without having to scroll for days. Some progress information would be 
> neat.
> A proposal is to add the info in term of module number of total number of 
> modules after the artifact logging like:
> {code}
> [INFO] 
> 
> [INFO] Building Foo 1.0.0-SNAPSHOT
> [INFO] 
> 
> [INFO] Module 10 / 100
> {code}
> If it can be more fancy it would be appreciated but this simple solution 
> looks good enough to fulfill the original requirement.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)