+1
probably will start by improving the documentation, because this is really the
current intent from what I can understand: a relocation pom only provides
relocation info only, no jar, no build info
like https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ that points to
https://repo.maven.apa
I agree about the standard look up path for maven installations. That would be
nice. One of the problems I always had with the wrapper is the weird storage of
the binaries in .m2/wrapper
E.g. check this path out
ls
~/.m2/wrapper/dists/apache-maven-3.6.1-bin/18t1vjepdne9cv9t0hdcik0hp1/apache-ma
I don't know how you get this error, I can't reproduce and ASF Jenkins can't
reproduce either:
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-doxia-sitetools/job/master/
Regards,
Hervé
Le mercredi 19 février 2020, 21:21:22 CET Elliotte Rusty Harold a écrit :
> There' at l
How about adding a system property or environment variable stating the type of
starter script and it's version, so this can be logged by Maven runs for better
troubleshooting and potentially warnings from enforcer plugin?
BTW: I wrote a longish argument for maintainability and binaries in Repos,
That sounds good.
Robert Scholte wrote on 2020-02-19 12:50 (GMT -08:00):
> I will write several integration tests matching these use cases.
> Based on that we can decide what to do.
>
> Robert
>
> On 19-2-2020 21:04:51, Manfred Moser wrote:
> There are kinda three main use cases that need to w
I will write several integration tests matching these use cases.
Based on that we can decide what to do.
Robert
On 19-2-2020 21:04:51, Manfred Moser wrote:
There are kinda three main use cases that need to work:
Install:
Installing the wrapper in a project by adding the .mvn/wrapper folder con
There' at least one failing test at HEAD:
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] DefaultSiteRendererTest.testRender:175->verifyHeadPage:328
Unexpected value found for generator meta entry in generated resource
target/output/head.html expected:<... Doxia Site Renderer[]> but
was:<... Do
Am 2020-02-19 um 08:12 schrieb Hervé BOUTEMY:
Hi,
We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320&version=12345961&styleName=Text
Staging repo:
https://repository.apache.org/content/repositories/maven-1552/
https://repository.apache.org/conten
There are kinda three main use cases that need to work:
Install:
Installing the wrapper in a project by adding the .mvn/wrapper folder contents
and the mvnw and mvnw.cmd files. This is done by the plugin by taking the
maven-wrapper jar and extracting it in to project after downloading and so on
Manfred, I don't understand the need for the org.apache.maven.wrapper.cli
package.
I would expect that all arguments after mvnw are passed as is to Maven.
The wrapper itself doesn't have any arguments to change the behavior, only
environment variables.
And the ProjectPropertiesCommandLineConverte
plexus-java is a multi-release jar, Java 7 compatible. So there's no issue.
Robert
On 19-2-2020 13:36:46, Romain Manni-Bucau wrote:
Should we rediscuss moving to j8 as baseline?
Le mer. 19 févr. 2020 à 13:01, Elliotte Rusty Harold a
écrit :
> Java 7 is the version for most (all?) of the Maven
Maybe we need to rework how this functionality works. It should be
essentially a symlink with a warning message within the resolver so they
both resolve to the same artifact.
On Wed, Feb 19, 2020 at 8:58 AM Anders Hammar wrote:
> In real practice it doesn't work well though, as someone already
In real practice it doesn't work well though, as someone already brought
up. It can result in duplication of libraries on the class path (the same
library under different groupId).
/Anders (mobile)
Den ons 19 feb. 2020 14:52Elliotte Rusty Harold skrev:
> I set up some simple projects and tested
I set up some simple projects and tested this manually. As best I can
determine, relocation does work as one would hope, at least in Maven
and M2E. (No idea about Gradle or Ivy.)
The documentation should probably be rewritten because it assumes you
can change published pom.xml files, which isn't t
Should we rediscuss moving to j8 as baseline?
Le mer. 19 févr. 2020 à 13:01, Elliotte Rusty Harold a
écrit :
> Java 7 is the version for most (all?) of the Maven project. It would
> be a bit confusing to have a special exception for this. I'm also a
> bit worried compiling this plugin for Java
Java 7 is the version for most (all?) of the Maven project. It would
be a bit confusing to have a special exception for this. I'm also a
bit worried compiling this plugin for Java 9 might cause problems when
it's included in a pom.xml that also supports Java 7. E.g. some weird
scenario where a bui
16 matches
Mail list logo
