Re: [VOTE] Release Apache Maven Wrapper 3.3.2

[Manfred Moser]

Looks good!

+1

On 2024-05-21 8:17 a.m., Tamás Cservenák wrote:

Howdy,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354608

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MWRAPPER/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2124/

Source release checksum SHA512:
620d6945ad3a18cc80da52ad81af452524cf427b24adcff1a83ad77a0d0e72dd18825e2c5e4405e43babe8e6fd52e83cef58b10d39b55fa8a4bba9a7801d66a5

Staging site:
https://maven.apache.org/wrapper-archives/wrapper-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Quo Vadis Maven?

[Manfred Moser]

Awesome work everyone. It is great to see all the progress Maven and 
related tooling is making.


Manfred

On 2024-04-23 2:12 p.m., Tamás Cservenák wrote:

Howdy,

This is just a short newsflash about upcoming planned releases related to
Maven.

Recently we got a huge spike in plugin releases, with various fixes and
improvements. I will not enumerate all of them here, just use `mvn
versions:display-plugin-updates` to pick them up ;)
(and more plugins to come).

What I do want to share is about our upcoming Maven releases...

Maven 3.9.7 is nearing (read: coming soon), and will have an important
Resolver update and other important fixes. Most importantly, the file-locks
are getting nice improvement (feedback VERY welcome).

Maven 3.9.7 issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.7

Resolver 1.9.19 issues (mostly bug fixes):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19

At the same time, we plan to release Maven Daemon (m39) as well, to have it
aligned with Maven 3,9,7: with many bug fixes and improvements/alignments
to "how Maven 3 behave". Our goal is to make the two (mvn and mvnd)
interchangeable on workstations.

Next, Maven 4 is turning beta, so the next release will be beta1! And
again, same thing for Maven Damon (m40), we will have a release that will
include Maven 4 beta-1.

Maven 4 beta-1
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-beta-1

Resolver 2.0.0 (currently alpha-11, will become beta after Maven4 beta-1
release):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%202.0.0-alpha-11

Keep your eyes on our upcoming releases,
and have fun!
- The Apache Maven team



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Require Java 17 for Maven 4

[Manfred Moser]

+100 (committer)

For build and runtime and source code level.

Also +100 for later upgrade to 21 ;-)

On 2024-02-27 23:30, Benjamin Marwell wrote:

Hi Maven Devs/Users/Committers and PMC members!

After several discussions on the mailing lists, I would like to
start a vote in favour of setting the minimal Java bytecode target
of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.

This is a procedural majority vote [1*]:
You can also vote with fractions and negative votes are not vetoes.

Please also notice:
* Maven 3 will stay at Java 8 no matter what.
* We may raise Maven 4 to JDK 21 later if we feel like it (depending
on the release date).
   This is not part of this vote.
* The linked PR is not part of this vote (this is not a code vote).
   But you may take a look at it to understand the intended change.

PR: https://github.com/apache/maven/pull/1430

Maven-Parent will not be raised with this vote, the other PR is not
part of this vote.

Please refrain from starting discussions in this thread, but do
include a reasoning on downvotes and feel free to start a new
discussion on the mailing list, or comment on the existing ones.

---

Vote open for 72 hours:

[ ] +1 (set JDK17 min version for Maven 4.x)
[ ] +0
[ ] -1 (please include reasoning)

---

- Ben

[1*]: https://www.apache.org/foundation/voting.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version for Maven

[Manfred Moser]

Given that it will still be quite a while until Maven 4 comes out and we 
are probably going to stick to the same Java version for Maven 4 until 
we move to 5, I would strongly suggest to go with Java 21.


There are a lot of further performance and other improvements from 17 to 
21. Also from our experience with the upgrade in the Trino project the 
leap from 17 to 21 is relatively small.


Manfred

On 2024-02-22 14:40, Brian Fox wrote:

That feels right to me based on the data and all the discussion so far.

On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák  wrote:


I think this starts to make reasonable picture:

If you are on Java 8, use Maven 3
If you are on Java 9+ use Maven 4 (once out).

For start, Maven3 has no idea (notion) about "classpaths" vs "modulepaths"
(is not quite true stated like this, it has SOME heuristics, that is mostly
shoot-and-miss).

So, I think it makes sense to have Maven 4 as Java 17, as folks in "big
tech" with strict processes, policies and what not will not migrate anyway
to Maven4. They have Maven3.

T


On Thu, Feb 22, 2024 at 9:23 PM Benjamin Marwell 
wrote:


Brian, any Chance you could make a stacked 100% graph for every *week*
of the past two years?
We could then see where we are heading…
(or the raw numbers per week, so we could work with that).

That's probably a lot to ask, but I think it will show us how "fast"
the progression was (and will be).

@Tamas please consider the support times are different by vendor.
I have seen Java 8 support well beyond 2030 *shudder*.

Seeing all those numbers, I now feel a lot more confident that Maven 4
should be 17 (runtime), 21 (build)
and Java 8 users should stay with 3.x.x.
Elliotte gave a good reason for this: There are two camps now (read:
ALREADY).
There is no reason to not go with either of them.

Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox 
We dumped 30 days because that gives a good snapshot of what's

happening

right now. If we dumped for example the whole year, then it really

blurs

the lines all over the place and things newer will be less prominent

just

because they didn't have as much time. 30 days is how we typically

bucket

things when we want a form of relative popularity.

As far as toy projects skewing, Tamas is right, the scale of central

data

is so large that it's insignificant. Also remember we only counted each

IP

once per entry so even projects downloading over and over won't skew

the

results.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Manfred Moser]

I agree with observations ... in the Trino project we switched to 
require Java 17 ages ago and now switched to 21 for the project itself. 
The language improvements to 17 and then to 21 allow for a lot of code 
improvements on the source level.


As a build tool that supports building other versions and has a huge 
codebase the case for allowing as many improvements as possible can not 
the underappreciated. I vote for at least having 17 as requirement and 
would also be fine with 21. After all by the time Maven 4 really 
stabilizes and becomes commonly used we are probably close to the next LTS.


Manfred


On 2024-01-22 4:33 a.m., Benjamin Marwell wrote:

To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
compile, run and package on 21 is an *extreme* improvement in build
time.

As always, YMMV. But why waste time...

Since with Semeru and Temurin all major vendors have published their
JDK21 at last,
I see no reason to use a lower Java version to build maven with.
It is easily available for everyone who wants to contribute.

If I read the thread correctly, there were no objections to raising
the build time requirements.

It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
possibly build chains and module-info profiles),
in case any of those are present.

- Ben

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Manfred Moser]

I have to strongly disagree. If Maven wants to remain relevant it needs 
to be using a relatively modern JDK and language that is available to 
open source developers and interesting to work on.


Nobody wants to work on Java 8 code.

Ultimately the committers and project maintainers can vote and move on 
as desired. You can always use an old version of Maven or switch to some 
other build system that works with Java 8.


Personally I will certainly vote for the current LTS release of Java 
(17) .. and would in the future also vote for the next current LTS very 
soon. And I would vote against staying with an outdated version that 
reached EOL years ago.


Manfred

On 2023-06-05 15:31, Hunter C Payne wrote:

  Other projects have tried to do that (given they are different types of 
projects) and it turned out that keeping JVM8 support going when not compiling 
on JDK8 proved difficult and when push came to shove, it was JVM 8 support that 
was dropped.  I know that's not you or this project, but human nature is what 
it is and patterns tend to repeat.  So while I understand what you are saying, 
I have my doubts based upon past projects I have seen do this.

On the other hand, the reasons for the upgrade are always a bit weak and the 
upgrade really only created lots of support work for the devs and users (the 
security model is especially an issue) and yes they thought it would be 
seem-less too.  Writing code in any other JVM language would accomplish what 
you want far more effectively.  Instead you want to put lipstick on the pig and 
act like Java 21 is somehow like more modern languages (it isn't, it never will 
be).   Just because you can pass a function in Java, doesn't make it a FP 
language.  It has no currying, no function composition, it lacks a self-type, 
there are no concepts of co or contra variance in the types and that's just a 
short list off the top of my head.  That's the direction you are pushing with 
what you are asking about but Java 21 isn't the answer there as it has none of 
these things, while almost all of them would be useful in Maven itself.
So from my perspective, you are proposing a solution to a problem that doesn't 
exist while at the same time the solution you propose doesn't truly give you 
what you want.  Nobody wanting to a new language on their CV is going to need 
that language to be Java.  If they are joining the Maven project, it is likely 
because they want to contribute to Maven, not because Maven uses JDK 21.  And 
your users just don't want to be bothered and want their build system to work.  
It is hardly ideal and I have sympathy but it doesn't make dropping building of 
Maven by javac8 the right call.

Hunter
 On Monday, June 5, 2023 at 02:22:59 PM PDT, Delany 
 wrote:
  
  Your inclination to ignore points of the debate doesn't do your own

arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
- building with Maven 3

This is the main point of the debate, not the language.

On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
 wrote:


* Attract devsAbsolutely not.  If you want to attract devs, switch to a
language that is actually growing (no I'm advocating for this).  That isn't
Java.  If anything, this will lose you devs.  The company I work for will
be leaving Maven if you stop supporting Java8.  That's 300 users you lose
right there.  That's just 1 company.  You will lose users in droves if you
stop Java8 support.  Many companies don't have/put enough resources into
this type of upgrade.  Its hard to justify to the business and it makes
lots of work for devs (expensive).  If it is cheaper to switch build
systems that to upgrade the JVM, that's exactly what folks will do.  My
company certainly will (not my decision so don't try to convince me, I'm
not the one you have to convince).

* CDS for non-OpenJ9-usersI'm not sure this is something that is really
taken advantage of by Maven.  Perhaps I am wrong.

* Better clarity of code (yes, I mean that)That you say that you actually
mean this says it all.  Clearly this is something that isn't agreed upon
universally.  Your personal taste shouldn't decide the future of a project
used by so many others.
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)This is simply not true.  There
have been comments by devs on this very list, in this very discussion that
disprove this point.  It isn't OK to just ignore their input because you
really want to use lambdas.

* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
that backwards.  If you leave Java8, you leave behind everyone who can't
upgrade their source base.  It seems to me that the size of the group of
Java8 folks you will leave behind is quite large.  So your argument about
no drawbacks isn't credible.  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Manfred Moser]

+1

Totally also agree with upping to Java 17.

Working mostly on Trino these days and we have been on 17 for quite a 
while and are getting ready to go to 21 soon after it hits. In my 
opinion Maven should do the same. There should be no reason not to 
support and also default to the latest LTS.


Ultimately users who are good with using old JDK should also be good 
with using an old build tool and an old IDE and so on..


And of course they also want to use old dependencies with many nice 
security issues... so lets enable them to stop this by making the usage 
of old stuff even more painful.


Manfred

On 2023-05-31 03:00, Tamás Cservenák wrote:

+1 for the move to Java 17 with Maven 4 (am actually for "move to latest
current Java LTS")

As anyone can see, all the major (OSS) projects did or are in the middle of
pushing for Java 17.
In September we have Java 21. The Java release cadence has changed, and it
did not change yesterday, but a long time ago, so users should live with it.

T

On Wed, May 31, 2023 at 10:30 AM Guillaume Nodet  wrote:


I'd like to resume this discussion about switching master to require JDK
17.

These past days, I've been working on improving the usage of toolchains
(first inside maven, but now completely in the maven-toolchains-plugin)
with [1].  If we want to go further, we could simplify the selection by
modifying the POM somehow to add a specific section, but I suspect most
people will just use the release flag on the compiler to target bytecode.
The only downside I see, beyond the additional configuration (though the
goal is that users don't really have to generate/maintain the toolchains)
is that the selection of the toolchain is done during the build, so that
JDK profile based activation can not be used.  Note that the use of
environment variables is also another way to work around, for example in
github [2].

I think with those improvements, requiring JDK 17 for master should be
doable.  Any concerns of suggestions ?

Cheers,
Guillaume

[1] https://github.com/apache/maven-toolchains-plugin/pull/14
[2]

https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml

Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise  a
écrit :


Hi to all,

what do you think about using JDK17 as minimum requirement for running
the future Apache Maven 4.0.0 ?

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



--

Guillaume Nodet



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Release Apache Maven Surefire 3.0.0

[Manfred Moser]

Massive congratulations! I am so glad we got beyond the milestones finally.

Manfred

On 2023-03-14 03:11, Slawomir Jaranowski wrote:

Hi

The Apache Maven team is pleased to announce the availability of Maven
Surefire 3.0.0

Release Notes - Maven Surefire - Version 3.0.0

** Bug
 * [SUREFIRE-2119] - Inconsistent failIfNoSpecifiedTests parameter
prefixes
 * [SUREFIRE-2143] - Disabled @ParametrizedTest is not counted as
skipped one in M8 (worked in M7)
 * [SUREFIRE-2150] - Upgrade Maven parent 39

** Improvement
 * [SUREFIRE-2154] - Get rid of ${localRepository} from surefire mojo
parameter, use Resolver API

** Task
 * [SUREFIRE-2149] - Several ITs fail with Maven 3.9.0
 * [SUREFIRE-2156] - Refresh download page

Enjoy,
-The Apache Maven team



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Speed up release process?

[Manfred Moser]

+1

That sounds good to me. There is plenty of communication going on BEFORE 
the release is even kicked off.. from then on it really should be just 
process and minimal validation. If something goes wrong.. run another 
patch release.


I would even go for .. lazy consensus after 48 hours counts as well.

Manfred

On 2022-11-18 9:55 a.m., Tamás Cservenák wrote:

Howdy,

My pet peeve these days is our release process. IMHO, we should be able to
release ("move") much faster than today.

My proposal would be:
* vote is "done done" the moment quorum is reached
* change the wording in the vote email from "Vote open for at least 72
hours." to "Vote open for a maximum of 72 hours.".

Reasoning:
* vote cannot be vetoed by definition (only release mgr can cancel it).
* change would not conflict with ASF defined rules, the 72h is not
compulsory (document states "should" not "must").
* the release process is already wearisome, complex, and is easy to miss
(over-represented) manual steps. For example yesterday for some reason it
took almost 2 hours to sync release artifacts to Maven Central, during
which you are in a "busy loop" (the announcement and site depends on sync).
Leaving it "for tomorrow" may cause users to learn about a new release thru
Artifact Listener or whatever other service, causing confusion. Ideally,
site and announcement mail should be tied to sync, and that does lead to
"busy loop".
* current process causes (forced) context switching, and can likely lead to
human mistakes: when the release vote is announced, developer is FORCED to
stop for 72h and possibly switch. This is just a productivity killer.
* which part do you like: as a developer sitting on needles while being
blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
* we already agreed on one minor process improvement: we have quite long
"chains" of dependencies, so a bugfix that can span on long trails could
take weeks to be done serially, even if the bugfix itself is trivial. Hence
we did accept that we can do "batch votes" (release together) and can do
one vote for this case.
* on positive site this could lead to mindset change of bugfix releases, as
today, few wants to go thru painful release process for "single simple
change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
wrong: we all should release early and often. And be happy with it, not
feel it like chores :)

Finally some "canned responses":
* "time is needed for all interested parties to review": If someone cannot
get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
does not matter, as release is to happen anyway (unless release mgr cancels
it). One not getting to it, will be notified via mails anyway (vote,
result, announce). We can already observe that there are "areas of
interests", but also there is the customary habit of "review invitation"
which is a good thing IMHO, as usually one invites a colleague with whom
the topic was or is under discussion already, so both of them are
"contextualized". Those initiated developers will most probably join in
voting for release as well, as either they depend on the fix or they know
what the problem was.
* "this will lead to more bugs" or "we are too hasty making changes": no,
it will not and we are not. As in essence, this change would allow us, in
case of need, to release even multiple times per day (so release the
project carrying a bug in the morning, then have a patch release for it in
the afternoon). Really, as bugs are inevitable, they happen with or without
72 hours, still the current process just causes problems IMHO. As the new
release is sitting on Central, without immediate remediation possibility.
Or to put it another way, having this option open does not mean we will
make all releases like it, and we will not start competing by releasing all
the plugins several times a day :) You can see there are "hot spots'' (if
you look at maveniverse as whole, sometimes plugins, sometimes shared
stuff, sometime maven, etc), especially with closing releases of Maven, but
those hotspots come and go, move, and just like today, some components will
not be released for quite some time, as the hotspots move from here to
there.

Applying this process change, if accepted, would not alter anything
regarding "commit policy" of code changes (PRs, JIRA attached patches, etc).

Refs:
https://www.apache.org/foundation/voting.html
https://www.apache.org/legal/release-policy.html

Please comment, add your opinion. Ideally, if discussion closes with
"positive outcome", I would like to propose a vote for these changes.

Thanks
T



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Quo Vadis Maven Site

[Manfred Moser]

There are a couple of things I would like to mention:

* the current output format of HTML is immediately usable, which is great

* any other format (md, asciidoc) is NOT and requires more tools to make 
them consumable


* reporting into an additional format like asciidoc will require some 
post processing of the output in most cases, would be great to have 
tools for that (e.g. add header with metadata)


* there is quite a lot of value in the stack .. but I have a hard time 
knowning how widely it is used, it might be a lot of work for only a few 
users.. at a minimum the maven project itself and various plugins use 
this stuff a lot.. and various apache projects use it as well


manfred


On 2022-11-17 04:24, Tamás Cservenák wrote:

Howdy,

It's not about losing at all, on the contrary: my "proposal" would be to
keep reporting, but make them write in "intermediate" format, like for
example Markdown is (or Asciidoc).
Those formats are human readable, unlike APT/FML/XDOC etc.

To me it would look like a win-win:
- you can still read the reports (those rendered in "intermediate" format,
as Javadoc and some others may be fully rendered in HTML)
- but savvy site owners could use whatever flashy skin, design and site
generator they want.

That's all.
T
T

On Thu, Nov 17, 2022 at 1:20 PM Gary Gregory  wrote:


I really like that Maven provides the option to build a site, no matter
what technological relics it uses.

I do see two site use cases that are worth teasing out:

I want to build and publish a site for public consumption.

I want a local folder full of HTML reports for my review as a developer.
For example, JaCoCo, PMD, SpotBugs, Checkstyle. Yes, I could look at the
raw output from each plugin and I do that as well. If that raw output,
usually XML is human readable enough, I might not need the HTML.

All of this to say that there is still value in the whole stack IMO and it
would be a shame to lose it.

Gary

On Wed, Nov 16, 2022, 18:14 Tamás Cservenák  wrote:


Howdy,

So, here is "stage No1" that pretty much already delivers what existing
site had:
https://github.com/jaxen-xpath/jaxen/pull/145

Point is: before, it was two runs to build and site (and took a total of

2

minutes), while now it is 10 seconds more than "build artifacts" (35

sec).

To build it: mvn clean install -P site

Just to clear up: I am NOT promoting JBake nor any other static site
generator, this was just an exercise to see if we can do simple maven

sites

without site plugin.

HTH
T

On Wed, Nov 16, 2022 at 7:28 PM Tamás Cservenák 
wrote:


Howdy,

I am pretty much convinced it can do all that site is able to do.
Let's see the jaxen conversion result once done.

Also, this would not push anything, I always wrote (at least intended

to)

"static site tool is left at discretion of user", I just mentioned

JBake

as

something that can buy out functionality of the maven-site-plugin,

that's

all.

T

On Wed, Nov 16, 2022 at 7:25 PM Benjamin Marwell 
wrote:


Please do NOT consider jbake.
We (shiro team) ported the page to jbake, and it is really a mess.
Many things are not supported which can easily be done in other static
site generators.
There is absolutely no progress. No java.time support. JSON/YAML
support is broken and needs a lot of workarounds.

Look at the repo and build it yourself -- the amount of javadoc will
take very long to process.
https://github.com/apache/shiro-site


Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák
:

Howdy,

I am pretty much sure your site could be pretty much "transported"

to

use

jbake-maven-plugin instead of maven-site-plugin.

I am aware of the long history of the Maven project, being here

since

2006,

but still...
I don't think what I propose is "build a lamborghini instead of a

ford

pickup".

I see it more like "let's replace the ford battery, but given how

old

it

is, we have
only aftermarket parts for it".

Now that you have shown your site, let me try to de-site it, just as

an

experiment...
as I never tried this before

Will do it here
https://github.com/cstamas/jaxen

Thanks
T

On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold <

elh...@ibiblio.org>

wrote:


I like some parts of this. I don't agree with others. I agree that
maven site isn't competitive with other site builders, but that

was

never really its purpose. I think it's OK for generating  a site

for a

Maven project. I wouldn't expect it to be used for anything else.

As a

maintainer of one such site 

it

would be very inconvenient for me if this plugin disappeared or
changed in a major way.

The old site design just works. We don't need so-called modern,
responsive sites. For our purposes — documenting code — the 20

year

old classic HTML we use is just fine. In fact, I'd say it's

superior

to modern designs as implemented in practice.

I do wish Maven hadn't gone its own way with NIH components like
Plexus, APT, and Doxia that are all essentially 

Re: Maven search for a class or method on classpath - how?

[Manfred Moser]

This might not help .. but your IDE will allow you to do that.. 

On the command line you might have to do a dependency:tree or dependency:list 
and then dependency:list-classes ...

Or you could fork the plugin to create a new goal that basically does the two 
in one go on the code level.. and then send a pull request ;-) 

Manfred

Graham Leggett wrote on 2022-06-17 10:14 (GMT -04:00):

> Hi all,
> 
> I find myself with a large project, not knowing which dependency(ies) is
> transitively providing a given class.
> 
> Is there a plugin that will allow a search within a project like this?
> 
> I can sort of do something with dependency:list-classes, but this is limited 
> in
> that it will only list classes in one artefact at a time. I want to find a
> class in all artefacts in a project.
> 
> Regards,
> Graham
> —
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven Wrapper 3.1.1 Released

[Manfred Moser]

Awesome work everyone. I am glad this made it to the users from Apache now.

Manfred

Hervé Boutemy wrote on 2022-05-14 07:06 (GMT -07:00):

> The Apache Maven team is pleased to announce the release of the Apache Maven 
> Wrapper, version 3.1.1.
> 
> The Maven Wrapper is an easy way to ensure a user of your Maven build has 
> everything necessary to run your Maven build.
> 
> This is the first release of this project in its Apache Maven new home: it 
> was 
> previously maintained by community at https://github.com/takari/maven-wrapper 
> and was kindly donated to the Maven team. Thank you to all people who 
> permitted this.
> 
> See https://maven.apache.org/wrapper/ for instructions on how to use this 
> updated Maven Wrapper.
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/wrapper/download.cgi
> 
> 
> Release Notes - Maven Wrapper - Version 3.1.1
> 
> ** Bug
> * [MWRAPPER-21] - Arbitrary file write during archive extraction ("Zip 
> Slip") in wrapper
> * [MWRAPPER-38] - build from source-release has different result from Git
> * [MWRAPPER-40] - Wrapper Properties File License system dependant line 
> separator
> * [MWRAPPER-41] - Goals documentation missing from site
> * [MWRAPPER-42] - maven-wrapper fails to self-update maven-wrapper.jar
> * [MWRAPPER-44] - maven-wrapper may use outdated 
> MavenWrapperDownloader.class
> * [MWRAPPER-58] - curl cannot follow 302 code when downloading wrapper jar
> 
> ** Improvement
> * [MWRAPPER-39] - release as maven-wrapper instead of maven-wrapper-parent
> * [MWRAPPER-43] - Download of jar must be quiet by default
> * [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper files/
> scripts
> * [MWRAPPER-49] - add Wrapper version in mvnw/mvnw.cmd scripts
> * [MWRAPPER-51] - Refactor using Java Path API (NIO.2)
> * [MWRAPPER-53] - cygwin path tidy for java and class
> 
> ** Task
> * [MWRAPPER-56] - Remove M2_HOME from mvnw script
> 
> ** Dependency upgrade
> * [MWRAPPER-62] - Upgrade Parent to 35
> * [MWRAPPER-63] - Upgrade Parent to 36
> 
> 
> Enjoy,
> 
> -The Apache Maven team
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: We need to lay down strategy

[Manfred Moser]

I could not agree more. It is extremely important for users to understand that 
we 
are NOT a commercial entity providing support. And contrary to other open source
products there is large, well known commercial entity either.

I also second all the other points from Tamas.

Manfred

Tamás Cservenák wrote on 2022-04-11 03:02 (GMT -07:00):

> Howdy,
> 
> Personally, I'd NOT use the term "supported" at all, as it comes from the
> commercial realm (at least for me it sounds like it).
> We do not support anything :)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Wrapper version 3.1.0

[Manfred Moser]

You can build locally and test that way as well. I used to do that with local 
repository as well as a locally running repository manager (Sonatype Nexus).

Manfred

Dan Tran wrote on 2021-12-13 22:53 (GMT -08:00):

> Hi
> 
> Could you deploy a snapshot?  my company repository manager does not proxy
> staging repos.
> 
> Can build from tag, generate the wrapper files, and run mvnw on some other
> host, it will fail if I use the staging RC, but I can pull
> maven-wrapper.jar from snapshot
> 
> Thanks
> 
> -D
> 
> On Mon, Dec 13, 2021 at 1:12 PM Manfred Moser 
> wrote:
> 
>> Awesome. Thank you Herve.
>>
>> + 100
>>
>> Hervé BOUTEMY wrote on 2021-12-13 13:09 (GMT -08:00):
>>
>> > Hi,
>> >
>> > We solved 18 issues:
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068=Text
>> >
>> > Staging repo:
>> > https://repository.apache.org/content/repositories/maven-1679/
>> >
>> https://repository.apache.org/content/repositories/maven-1679/org/apache/maven/wrapper/maven-wrapper-parent/3.1.0/maven-wrapper-parent-3.1.0-source-release.zip
>> >
>> > Source release checksum(s):
>> > maven-wrapper-parent-3.1.0-source-release.zip sha512:
>> >
>> 9b7362c956cd24e21b46b290e154893ae35fd38431b6fe80f035cd17a97806e9221c71ac14975692f2a948ad25489f5b9d9bbb72441f9ab5eb541da0a86bdef9
>> >
>> > Staging site:
>> > https://maven.apache.org/wrapper-archives/wrapper-LATEST/
>> >
>> > Guide to testing staged releases:
>> > https://maven.apache.org/guides/development/guide-testing-releases.html
>> >
>> > Vote open for at least 72 hours.
>> >
>> > [ ] +1
>> > [ ] +0
>> > [ ] -1
>> >
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Wrapper version 3.1.0

[Manfred Moser]

Awesome. Thank you Herve.

+ 100

Hervé BOUTEMY wrote on 2021-12-13 13:09 (GMT -08:00):

> Hi,
> 
> We solved 18 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1679/
> https://repository.apache.org/content/repositories/maven-1679/org/apache/maven/wrapper/maven-wrapper-parent/3.1.0/maven-wrapper-parent-3.1.0-source-release.zip
> 
> Source release checksum(s):
> maven-wrapper-parent-3.1.0-source-release.zip sha512:
> 9b7362c956cd24e21b46b290e154893ae35fd38431b6fe80f035cd17a97806e9221c71ac14975692f2a948ad25489f5b9d9bbb72441f9ab5eb541da0a86bdef9
> 
> Staging site:
> https://maven.apache.org/wrapper-archives/wrapper-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: reviewing Maven Wrapper before releasing

[Manfred Moser]

The improvements can still be applied. My understanding was that it was planned 
for the next Maven release. And that was 4 at the time .. however that changed 
and we have had no released maintained wrapper for two years now. Lets just 
move on with the release of the wrapper in Apache and then improve however 
desired. 

Manfred

Robert Scholte wrote on 2021-12-11 04:43 (GMT -08:00):

> It was marked for Maven 4, and part of the improvements was test 
> automation, which was now possible because it became part of Maven Core.
> Even thought the code still exists in Maven Core, is has now become 
> useless.
> 
> There hasn't been a real need for new releases of Maven Wrapper Plugin 
> until a range of Maven 3.8 started.
> Maven Wrapper would have been another feature to attract developers to 
> Maven 4.
> 
> And finally, I see that the donated code has been used as base, ignoring 
> all the effort done to improve that codebase done afterwards.
> Hence my response that reliability is gone that was added after 
> donation.
> 
> Robert
> 
> -- Origineel bericht --
> Van: "Manfred Moser" 
> Aan: dev@maven.apache.org
> Verzonden: 10-12-2021 20:58:33
> Onderwerp: Re: reviewing Maven Wrapper before releasing
> 
>>I totally agree with finally just shipping this. We got this all donated about
>>two years ago now and there is still nothing shipping.
>>
>>I used to just manually do the testing and thousands of projects are happy. I
>>assume the new project is at least manually testing and works as before or
>>better. Let's not wait nay more and let perfection get into our way. It surely
>>is good enough for a release.
>>
>>The beauty is that if you find an issue.. you just ship again ... no reason to
>>wait.
>>
>>manfred
>>
>>Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):
>>
>>>  the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did not
>>>  test, I just did not change anything using the general approach "people 
>>> were
>>>  happy before, just continue step by step improvements" :)
>>>
>>>  reading the mvnw script (*nix), compiling+running the .java is executed 
>>> only
>>>  if
>>>  neither wget nor curl are available on your machine
>>>
>>>  reading the mvnw.cmd, it seems .java is not supported
>>>
>>>  looking at Git history confirms:
>>>https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337
>>>
>>>
>>>  Don't hesitate to create a Jira issue and corresponding fix to add .java
>>>  support for Windows: future 3.1.0 will have one more fix over previous 
>>> 0.5.6
>>>
>>>  Regards,
>>>
>>>  Hervé
>>>
>>>  Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :
>>>>  I need more time.
>>>>
>>>>  e.g. it looks like type=source doesn't use the Java sourcefile to
>>>>  download the wrapper.
>>>>  now that the plugin and wrapper are combined in one project, the ITs are
>>>>  incomplete.
>>>>  They should call both the wrapper-goal and something like 'mvnw
>>>>  --version' to ensure it is working (this used to be done in
>>>>  maven-integration-testing)
>>>>
>>>>  thanks,
>>>>  Robert
>>>>
>>>>  -- Origineel bericht --
>>>>  Van: "Hervé BOUTEMY" 
>>>>  Aan: "Maven Developers List" 
>>>>  Verzonden: 10-12-2021 08:08:57
>>>>  Onderwerp: Re: reviewing Maven Wrapper before releasing
>>>>
>>>>  >thank you to everybody who reviewed, discussed, contributed
>>>>  >
>>>>  >we now have 16 issues fixed, everything seems stable
>>>>  >
>>>>  >if nobody objects, I'll start a release over the week-end
>>>>  >
>>>>  >Regards,
>>>>  >
>>>>  >Hervé
>>>>  >
>>>>  >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit :
>>>>  >>  Hi,
>>>>  >>
>>>>  >>  Maven Wrapper has been donated to Apache Maven, imported to
>>>>  >>
>>>>  >>https://github.com/apache/maven-wrapper
>>>>  >>
>>>>  >>  Documentation published to https://maven.apache.org/wrapper/
>>>>  >>
>>>>  >>  Here is the list of fixes from previous 0.5.6 release:
>>>>  
>>>> >>https://issues.apache.org

Re: reviewing Maven Wrapper before releasing

[Manfred Moser]

I totally agree with finally just shipping this. We got this all donated about 
two years ago now and there is still nothing shipping. 

I used to just manually do the testing and thousands of projects are happy. I 
assume the new project is at least manually testing and works as before or 
better. Let's not wait nay more and let perfection get into our way. It surely 
is good enough for a release.

The beauty is that if you find an issue.. you just ship again ... no reason to 
wait.

manfred

Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):

> the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did not
> test, I just did not change anything using the general approach "people were
> happy before, just continue step by step improvements" :)
> 
> reading the mvnw script (*nix), compiling+running the .java is executed only 
> if
> neither wget nor curl are available on your machine
> 
> reading the mvnw.cmd, it seems .java is not supported
> 
> looking at Git history confirms:
> https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337
> 
> 
> Don't hesitate to create a Jira issue and corresponding fix to add .java
> support for Windows: future 3.1.0 will have one more fix over previous 0.5.6
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :
>> I need more time.
>> 
>> e.g. it looks like type=source doesn't use the Java sourcefile to
>> download the wrapper.
>> now that the plugin and wrapper are combined in one project, the ITs are
>> incomplete.
>> They should call both the wrapper-goal and something like 'mvnw
>> --version' to ensure it is working (this used to be done in
>> maven-integration-testing)
>> 
>> thanks,
>> Robert
>> 
>> -- Origineel bericht --
>> Van: "Hervé BOUTEMY" 
>> Aan: "Maven Developers List" 
>> Verzonden: 10-12-2021 08:08:57
>> Onderwerp: Re: reviewing Maven Wrapper before releasing
>> 
>> >thank you to everybody who reviewed, discussed, contributed
>> >
>> >we now have 16 issues fixed, everything seems stable
>> >
>> >if nobody objects, I'll start a release over the week-end
>> >
>> >Regards,
>> >
>> >Hervé
>> >
>> >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit :
>> >>  Hi,
>> >>  
>> >>  Maven Wrapper has been donated to Apache Maven, imported to
>> >>
>> >>https://github.com/apache/maven-wrapper
>> >>
>> >>  Documentation published to https://maven.apache.org/wrapper/
>> >>
>> >>  Here is the list of fixes from previous 0.5.6 release:
>> >>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721;
>> >>ve>>
>> >>  rsion=12350068
>> >>  
>> >>  
>> >>  Please test and review so we can do a release soon
>> >>  
>> >>  Regards,
>> >>  
>> >>  Hervé
>> >>  
>> >>  
>> >>  
>> >>  -
>> >>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >>  For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >-
>> >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Moving away from Modello

[Manfred Moser]

I agree with a lot of what has been said towards keeping modello in use. There 
is really no existing drop-in alternative. The benefits of moving off
 Modello are mostly unknown until we actually do the work.  And in the end it 
should be mostly internal refactoring.

However that work is a very large effort that is much better invested in the 
user facing improvements and new features.

Manfred

Robert Scholte wrote on 2021-06-02 11:54 (GMT -07:00):

> The title suggest it should me moved completely from the Maven codebase, but I
> think there's no alternative for Maven Core, as we need quite a huge set of
> features. I don't think there's another tool that can keep the model, reader,
> writers, mergers, validators and xsd in sync. If you want to replace it, start
> with Maven core. If you succeed we can have another discussion otherwise we
> will stick to Modello. We have enough committers that can maintain it.
>  
> To me consistency is just as important, so it makes sense to have a preferred
> library for reading/writing XML. As Maven Core already claims Modello, better
> mark this as the preferred solution.
> 
> Regarding Eclipse support, most likely Eclipse was the first IDE to support
> Modello and it still does. If you open the pom you should see there are m2
> plugins available, including one for modello. Once installed and restarted, it
> works as expected (just tested it). Like any IDE, in general you don't get all
> the options but often pluguins are available.
> 
> You rarely need to touch the mdo-files, but with the right documentation you
> should be able to extend it.
> But that is for any solution we would choose. We shouldn't maintain all Java
> files and XSDs by hand, but generate it. And any generating tool will require
> read that famous manual.
> 
> Robert
> On 2-6-2021 14:38:43, Gary Gregory  wrote:
> On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> wrote:
>>
>> On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold wrote:
>>
>> > What do folks think about slowly moving away from Modello where
>> > feasible to simplify the build? Does anyone find Modello a net
>> > positive, especially in longterm maintenance, not just in initial code
>> > generation?
>>
>> To me, it sounds feasible to replace Modello with a Sax parser
>> (reading), and a Sax
>> event generator (writing), that take as input a bean class (either
>> written manually,
>> or generated by Modello, and do the serialization/deserialization.
>>
>> Would, most likely, not be a drop-in-replacement, but definitely a 
>> medium-term
>> solution.
> 
> What about JAXB?
> 
> Gary
> 
>>
>> Jochen
>>
>>
>> --
>>
>> Look, that's why there's rules, understand? So that you think before
>> you break 'em.
>>
>> -- (Terry Pratchett, Thief of Time)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[Manfred Moser]

You can use polyglot-maven for a compatible approach for your own pom files 
right now.. 

https://github.com/takari/polyglot-maven/tree/master/polyglot-xml

Manfred

Will Iverson wrote on 2020-12-11 14:40 (GMT -08:00):

> One of the biggest complaints about Maven has long been the verbosity of
> the XML format. The verbosity is due in large part to the exclusive
> reliance on XML elements in Maven.
> 
> Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
> declaring configuration elements.
> 
> Example: One of the most verbose sections of the pom for most projects is
> dependencies. A typical example:
> 
> 
> commons-io
> commons-io
> 2.8.0
> 
> 
> Here is the same declaration expressed with attribute shortcuts:
> 
> 
> That's an 80% reduction in LoC, and would make Maven comparable with other
> popular build tools (e.g. compare and contrast with other build tools at
> https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
> 
> REQUEST: Feedback on if this is something to pursue. I've done some
> research, happy to submit patches, but don't want to pursue if there is
> either a) technical reason[s] not to proceed I'm not aware of or b) a lack
> of enthusiasm for the entire idea from the community.
> 
> Basically, I'm looking for some feedback along the lines of a) love it -
> please submit patches so we can check it out, b) huh, maybe, willing to
> look at it, or c) this is a terrible idea, because X. Effectively, a
> totally non-binding vote on if this is worth exploring.
> 
> I've discussed this with others online and done some research, so are a few
> answers to objections/Qs as I currently understand. I may be
> wrong/uninformed about certain aspects, which would be very helpful
> feedback.
> 
> Q: Won't this require a new Maven XSD to be generated?
> A: No. The current Maven XSD declares many elements, but is not actually
> involved in validation. While the current XSD is valuable for tools and
> documentation, it does not actually perform validation.
> 
> Q: Wait, so what actually does the validation?
> A: It's all done in Java code generated by Modello. The maven-model project
> (https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
> the Modello Maven Plugin (
> http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
> turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
> generate the Java code that processes the pom.xml
> 
> The proposal is to submit a patch for Modello that would allow the
> generated source to accept an attribute as an alias for input. If it's a
> valid element per the Maven maven.mdo file (
> https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
> it will now accept an attribute as a shortcut.
> 
> Q: Wouldn't this break, like, everything?
> A: It would only affect pom.xml files that are read at runtime. All emitted
> pom.xml files would remain exactly the same.
> 
> Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
> the thing that's making it hard to support alternative formats for pom.xml
> like polyglot poms, etc?
> A: Nope, the pom.xml on disk is still the pom.xml. A
> X.X.X would be the only flag
> recommended to declare that a pom.xml uses attributes for shorthand.
> 
> Q: How much work is this to actually implement?
> A: It starts with a few lines added to the Modello code generation to allow
> for attribute aliasing with a feature flag. Testing those changes through
> the rest of the dependency chain. Adding test cases throughout.
> Documentation. although as "now you can use attributes" is conceptually
> simple it's not too bad. Tools in the Maven ecosystem would be able to
> indicate they have been updated to support this by referring to the simple
> term, "attribute shortcuts". Because nothing else changes, the only real
> documentation change would be "things that were elements can also be
> declared as attributes." The trickiest part is probably sorting out how to
> manage the feature flag across the various components. I'm sure there's
> more with a huge ecosystem like this, but the actual changes to the Modello
> code gen appear to be surprisingly minor.
> 
> Q: What about tooling, like IDEs, publishing to Maven Central & Maven
> repositories, etc?
> A: Many IDEs appear to have implemented validation logic on top of Maven
> that currently will flag attributes as errors in a pom.xml. Those IDEs and
> other tools would require updates to this validation logic. Because the
> rendered pom.xml output remains the same publishing tool chains and Maven
> repositories should be completely unaffected.
> 
> Q: Any big issues you've identified?
> A: Many sub-elements are not actually processed by Modello or Maven Model,
> but are instead passed along to the plugin. For example, 
> elements. It would be up to each of these projects to eventually allow for
> attribute aliasing (or not). Maven projects that rely on Modello would have

Re: Speed of Maven build

[Manfred Moser]

Mickael Istria wrote on 2020-08-25 14:17 (GMT -07:00):

> I
> 
> On Tuesday, August 25, 2020, Manfred Moser  wrote:
>> And the VS code integration from Red Hat might also do something along
> those lines.
> 
> It embeds and uses m2eclipse.
> 

Haha.. thanks for confirming. I thought that to be the case but did not want to 
say it explicitly since I was only 80 or so percent sure.. 

manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Speed of Maven build

[Manfred Moser]

Also the M2Eclipse integration does basically embed maven and make the Maven 
build incremental.

The Takari plugin does that on the commandline with the eclipse compiler

And the VS code integration from Red Hat might also do something along those 
lines.

Others can chime in with more details.

Manfred

John Patrick wrote on 2020-08-25 13:29 (GMT -07:00):

> Are you planning to create a baseline project or selecting a range of
> projects to be used as a baseline, so that perceived improvements can
> be monitored? So that anyone wanting to help out or give feedback can
> submit their own build performance.
> 
> i.e.
> 1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
> 2. Java version
> 3. Maven version
> 4. Speedtest results
> 5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
> 6. Clean/Fresh Local Repo Execution Time
> 7. 2nd Execution Time, after everything downloaded
> 
> As using Maven since 2005, I've found each new release has gotten
> faster and faster, and most performance issues have been around what
> OS I'm using, SSD vs HDD and also do you have enough free RAM etc.
> 
> As I'm surprised how quickly my builds are running at the moment, the
> only issue is when I see maven perform internet connections
> downloading new dependencies or say the versions plugin to check. Any
> thoughts about adding a HTTP/2 Server Push support so if it's Maven
> Aware and you request the pom it can also push back the hashes and
> maybe the jar too.
> 
> Regarding a "zombie" maven instance, it should be opt in so i need to
> explicitly enable it as often i'm jumping around between lots of
> projects so don't want each having a "zombie" progress and i might not
> be building that project again for another week maybe.
> 
> John
> 
> On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
>  wrote:
>>
>> In case this helps, Jason Dillon has a "Maven Shell" that does what you
>> seek for CLI - launches a Maven instance and runs interactive commands with
>> it, saving the startup time.
>> https://github.com/jdillon/mvnsh
>>
>>
>> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach 
>> wrote:
>>
>> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
>> > > I suppose that community would be happy to get such contributions.
>> > >
>> > > -Bertrand
>> >
>> > You are right, Bertrand. Why not ask!
>> >
>> > Hello Maven guys,
>> > we had a discussion on the NetBeans mailing list recently and here is a
>> > summary:
>> > * Apache NetBeans IDE is delegating most of its work directly to Maven
>> > * Users however complain that the speed isn't great
>> > * One of the ideas was to launch a "zombie" instance of Maven in advance
>> > * then actions like build, exec or test would be faster
>> >
>> > Have you thought about something like this already? Any advices?
>> >
>> > Best regards.
>> > Jaroslav Tulach
>> > NetBeans Platform Architect
>> >
>> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
>> > jaroslav.tul...@gmail.com>
>> > napsal:
>> >
>> > > > I agree with others, Ant is much faster day to day. But the pom.xml has
>> > > > become the universal project file for Java,
>> > >
>> > > Thank you all for sharing your thoughts. I know Maven start is slower,
>> > but
>> > > I
>> > > learned to live with it. It is interesting to hear that some of you
>> > > maintain a
>> > > dual Ant based copy of your project metadata. Once we were trying a
>> > > different
>> > > approach:
>> > >
>> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
>> > > XML &
>> > > co. files and stop it. As soon as we need to build/run/test, wake up this
>> > > zombie Maven process, tell it what to do and let it continue. If the XML
>> > > files
>> > > are modified, throw the process away and initialize it again. Tomáš
>> > Stupka
>> > > implemented a prototype of this and there were no issues, as far as I
>> > know
>> > > (nobody tested it thoroughly however).
>> > >
>> > > Maybe the support is even in and there is a property to turn it on. If
>> > the
>> > > Maven startup is the biggest problem for you guys, we shall investigate
>> > > how to
>> > > turn Tomáš's work on...
>> > >
>> > > -jt
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Your project website

[Manfred Moser]

I guess we just need confirmation that the fact that CMS goes away does not 
include svnpubsub/subversion... 

Manfred


Hervé BOUTEMY wrote on 2020-08-20 12:21 (GMT -07:00):

> (forgot to cc infra)
> 
> sorry, I completely overlooked the discussion during PTO...
> 
> I worked with Gav in the past to go from rsync to CMS, then go out of CMS to 
> direct svnpubsub+maven-scm-publish-plugin [1]: we don't use CMS at all any 
> more for a few years
> 
> Regards,
> 
> Hervé
> 
> [1] https://maven.apache.org/developers/website/index.html
> 
> Le jeudi 20 août 2020, 11:21:56 CEST Gavin McDonald a écrit :
>> I think you guys are fine and there is nothing to do. We still have some
>> Maven configs in our CMS system but looks like you have not used it since
>> 2018.
>> 
>> I'll go ahead and remove your old CMS content and configs
>> 
>> Gav...
>> 
>> 
>> On Thu, Aug 20, 2020 at 6:23 AM Manfred Moser 
>> 
>> wrote:
>> > Also ... from a technical standpoint the Maven site is just a bunch of
>> > static html files and I think some server side includes. We might have to
>> > fix those to be different depending on whatever we migrate to .. with that
>> > in mind..
>> > 
>> > What are our options within the Apache infrastructure or outside?
>> > 
>> > Manfred
>> > 
>> > Olivier Lamy wrote on 2020-08-19 18:33 (GMT -07:00):
>> > > Hi Andrew & Infra
>> > > We (maven-dev) wonder what does it mean with using Apache CMS?
>> > > As far as we can see, we only generate content and commit it to a svn
>> > > directory.
>> > > Maybe not for the root part of the website (sources are here
>> > > https://gitbox.apache.org/repos/asf?p=maven-site.git) which is
>> > 
>> > triggered in
>> > 
>> > > buildbot?
>> > > Please let us know if it's part you refer as our usage of Apache CMS
>> > > Thanks
>> > > Olivier
>> > > 
>> > > 
>> > > On Tue, 18 Aug 2020 at 9:54 pm, Andrew Wetmore 
>> > 
>> > wrote:
>> > >> Hi:
>> > >> 
>> > >> I wrote to you two weeks ago about your project website, but have not
>> > 
>> > seen
>> > 
>> > >> a response. Whom should I contact directly? I am trying to see whether
>> > 
>> > your
>> > 
>> > >> project still uses the Apache CMS and, if so, what your plans are to
>> > >> migrate off it.
>> > >> 
>> > >> Thanks in advance for your help.
>> > >> 
>> > >> Andrew
>> > >> 
>> > >> On Wed, Aug 5, 2020 at 9:35 AM Andrew Wetmore 
>> > 
>> > wrote:
>> > >>> Hi:
>> > >>> 
>> > >>> I am part of the Infrastructure team, and am writing to ask whether
>> > 
>> > your
>> > 
>> > >>> project is still using the Apache CMS for your project website. As you
>> > >>> know, the CMS is reaching end-of-life, and we need projects to move
>> > 
>> > their
>> > 
>> > >>> websites onto a different option within the next few weeks.
>> > >>> 
>> > >>> There are several alternatives available, including those listed on
>> > 
>> > this
>> > 
>> > >>> page [1] on managing project websites. Infra is assembling a Wiki page
>> > 
>> > [2]
>> > 
>> > >>> on migrating a website from the CMS, and is looking forward to helping
>> > >>> projects with this transition.
>> > >>> 
>> > >>> Please let me know whether your site is still on the Apache CMS and,
>> > >>> if
>> > >>> so, who will be the project point-of-contact with Infra for the
>> > 
>> > migration.
>> > 
>> > >>> Thank you!
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> [1] https://infra.apache.org/project-site.html
>> > >>> 
>> > >>> [2]
>> > 
>> > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+web
>> > site+from+the+Apache+CMS> 
>> > >>> --
>> > >>> Andrew Wetmore
>> > >>> Technical Writer-Editor
>> > >>> Infra
>> > >>> *Apache Software Foundation*
>> > >>> andr...@apache.org
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> 
>> > >>> <
>> > 
>> > https://www.avast.com/sig-email?utm_medium=email_source=link_campa
>> > ign=sig-email_content=webmail> 
>> > >>> Virus-free. www.avast.com
>> > >>> <
>> > 
>> > https://www.avast.com/sig-email?utm_medium=email_source=link_campa
>> > ign=sig-email_content=webmail
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > <#m_7218770601526193449_m_2382004626366778703_m_1277653308293069744_DAB4FA
>> > D8-2DD7-40BB-A1B8-4E2AA1F9FDF2>> 
>> > >> --
>> > >> Andrew Wetmore
>> > >> Technical Writer-Editor
>> > >> Infra
>> > >> *Apache Software Foundation*
>> > >> andr...@apache.org
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Your project website

[Manfred Moser]

Also ... from a technical standpoint the Maven site is just a bunch of static 
html files and I think some server side includes. We might have to fix those to 
be different depending on whatever we migrate to .. with that in mind..

What are our options within the Apache infrastructure or outside? 

Manfred

Olivier Lamy wrote on 2020-08-19 18:33 (GMT -07:00):

> Hi Andrew & Infra
> We (maven-dev) wonder what does it mean with using Apache CMS?
> As far as we can see, we only generate content and commit it to a svn
> directory.
> Maybe not for the root part of the website (sources are here
> https://gitbox.apache.org/repos/asf?p=maven-site.git) which is triggered in
> buildbot?
> Please let us know if it's part you refer as our usage of Apache CMS
> Thanks
> Olivier
> 
> 
> On Tue, 18 Aug 2020 at 9:54 pm, Andrew Wetmore  wrote:
> 
>> Hi:
>>
>> I wrote to you two weeks ago about your project website, but have not seen
>> a response. Whom should I contact directly? I am trying to see whether your
>> project still uses the Apache CMS and, if so, what your plans are to
>> migrate off it.
>>
>> Thanks in advance for your help.
>>
>> Andrew
>>
>> On Wed, Aug 5, 2020 at 9:35 AM Andrew Wetmore  wrote:
>>
>>> Hi:
>>>
>>> I am part of the Infrastructure team, and am writing to ask whether your
>>> project is still using the Apache CMS for your project website. As you
>>> know, the CMS is reaching end-of-life, and we need projects to move their
>>> websites onto a different option within the next few weeks.
>>>
>>> There are several alternatives available, including those listed on this
>>> page [1] on managing project websites. Infra is assembling a Wiki page [2]
>>> on migrating a website from the CMS, and is looking forward to helping
>>> projects with this transition.
>>>
>>> Please let me know whether your site is still on the Apache CMS and, if
>>> so, who will be the project point-of-contact with Infra for the migration.
>>>
>>> Thank you!
>>>
>>>
>>>
>>>
>>> [1] https://infra.apache.org/project-site.html
>>>
>>> [2]
>>> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
>>>
>>>
>>> --
>>> Andrew Wetmore
>>> Technical Writer-Editor
>>> Infra
>>> *Apache Software Foundation*
>>> andr...@apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>> Virus-free. www.avast.com
>>> 
>>>
>>>
>>>
>>>
>>> <#m_7218770601526193449_m_2382004626366778703_m_1277653308293069744_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>>
>>>
>>
>> --
>> Andrew Wetmore
>> Technical Writer-Editor
>> Infra
>> *Apache Software Foundation*
>> andr...@apache.org
>>
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Fwd: Your project website

[Manfred Moser]

I am not sure but I think that SVN commit is a backend for the CMS .. 

Olivier Lamy wrote on 2020-08-19 00:06 (GMT -07:00):

> Hi
> I'm not sure if we use CMS.
> I don't think so AFAIK to publish website content we only commit to a svn
> repo.
> Am I missing something?
> 
> cheers
> Olivier
> 
> -- Forwarded message -
> From: Andrew Wetmore 
> Date: Tue, 18 Aug 2020 at 21:54
> Subject: Re: Your project website
> To: 
> 
> 
> Hi:
> 
> I wrote to you two weeks ago about your project website, but have not seen
> a response. Whom should I contact directly? I am trying to see whether your
> project still uses the Apache CMS and, if so, what your plans are to
> migrate off it.
> 
> Thanks in advance for your help.
> 
> Andrew
> 
> On Wed, Aug 5, 2020 at 9:35 AM Andrew Wetmore  wrote:
> 
>> Hi:
>>
>> I am part of the Infrastructure team, and am writing to ask whether your
>> project is still using the Apache CMS for your project website. As you
>> know, the CMS is reaching end-of-life, and we need projects to move their
>> websites onto a different option within the next few weeks.
>>
>> There are several alternatives available, including those listed on this
>> page [1] on managing project websites. Infra is assembling a Wiki page [2]
>> on migrating a website from the CMS, and is looking forward to helping
>> projects with this transition.
>>
>> Please let me know whether your site is still on the Apache CMS and, if
>> so, who will be the project point-of-contact with Infra for the migration.
>>
>> Thank you!
>>
>>
>>
>>
>> [1] https://infra.apache.org/project-site.html
>>
>> [2]
>> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
>>
>>
>> --
>> Andrew Wetmore
>> Technical Writer-Editor
>> Infra
>> *Apache Software Foundation*
>> andr...@apache.org
>>
>>
>> 
>> Virus-free.
>> www.avast.com
>> 
>> <#m_-7487477713971908370_m_1277653308293069744_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
> 
> 
> -- 
> Andrew Wetmore
> Technical Writer-Editor
> Infra
> *Apache Software Foundation*
> andr...@apache.org
> 
> 
> -- 
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: second apache-maven-wrapper

[Manfred Moser]

Awesome! +1 

Robert Scholte wrote on 2020-05-22 13:36 (GMT -07:00):

> I've reached the point where apache-maven-wrapper is ready to be merged into
> master.
> The code contains all original commits and a few from me to get them step by
> step into core.
> 
> Related tickets:
> https://issues.apache.org/jira/browse/MNG-5937
> 
> https://issues.apache.org/jira/browse/MNG-6914
> 
> 
> https://github.com/apache/maven/pull/349
> 
> https://github.com/apache/maven-integration-testing/pull/62
> 
> 
> thanks,
> Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: APIs for reading Maven repositories

[Manfred Moser]

Elliotte Rusty Harold wrote on 2020-05-04 07:02 (GMT -07:00):


> 2. Is it possible to boostrap the resolver without using the internal
> class MavenRepositorySystemUtils?
> 
> https://issues.apache.org/jira/browse/MNG-6579
> 

I am using the resolver in my Maven Repository Provisioner and bootstrap it 
without ..

https://github.com/simpligility/maven-repository-tools/tree/master/maven-repository-provisioner

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Proposal to deprecate Maven 3.0.x

[Manfred Moser]

t; > (that are all filtered by Maven core class loading, then not really
>> > an
>> > > > > issue), I'm not convinced this is absolutely necessary to go to that
>> > > > > extend
>> > > > >
>> > > > > what is really useful is to deprecate anything that is not in
>> > > > > org.eclipse.aether Java package, because it is a nightmare in terms
>> > of
>> > > > > Java
>> > > > > code compatibility: this means deprecating 3.0.x only [2], given the
>> > > > > switch to Eclipse Aether has been done in 3.1.0 [3]
>> > > > > And, for the record, the switch to Maven Artifact Resolver has been
>> > done
>> > > > > in
>> > > > > 3.5.0 [4]
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > Hervé
>> > > > >
>> > > > > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html
>> > > > >
>> > > > > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html
>> > > > >
>> > > > > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html
>> > > > >
>> > > > > [4]
>> > https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html
>> > > > >
>> > > > > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit :
>> > > > > > +100
>> > > > > >
>> > > > > > I would deprecate everything before the maven-resolver import back
>> > to
>> > > > > > the
>> > > > > > project while you are at it. Not sure exact version but 3.1x would
>> > > > > > definitely on that list as well. Maybe also 3.2x
>> > > > > >
>> > > > > > Manfred
>> > > > > >
>> > > > > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
>> > > > > > > Some users still use Maven 3.0.5 and they require a support for
>> > > > > > > compatibility reasons between nowadays Maven plugins and the
>> > Maven
>> > > > > > > 3.0.x.
>> > > > > > >
>> > > > > > > We have a couple of reasons to deprecate this version (JSR-330,
>> > > > > > > Components injection, Logger) and we have discussed this issue in
>> > > > > > > https://github.com/apache/maven-surefire/pull/274
>> > > > > > >
>> > > > > > > Let's discuss it.
>> > > > > > >
>> > > > > > > Cheers
>> > > > > > > Tibor17
>> > > > > > >
>> > > > > > >
>> > -
>> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > > > > >
>> > > > > >
>> > -
>> > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > > > >
>> > > > > -
>> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> >
>> >
>> > --
>> > Cheers
>> > Tibor
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >
> 
> 
> 
> -- 
> Cheers
> Tibor
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Proposal to deprecate Maven 3.0.x

[Manfred Moser]

All features are already in Maven Resolver .. 

We should deprecate  everything before 3.5.0 imho

Or if really necessary everything before 3.2.5

Gabriel Belingueres wrote on 2020-04-16 17:35 (GMT -07:00):

> +1 to deprecate 3.0.x to get rid of Sonatype Aether, which would
> considerably simplify the dependency handling code base.
> 
> Not my use case, but,just to put it over the table, we should check the
> Eclipse Aether New and Noteworthy page [1] to see if there is some
> particular requirement over aether library that we want to take for granted.
> 
> I've looked for each aether version used by maven and I came up with the
> following list:
> 
> "3.0.0" <-- Sonatype Aether 1.7
> "3.0.1" <-- Sonatype Aether 1.8
> "3.0.2" <-- Sonatype Aether 1.9
> "3.0.3" <-- Sonatype Aether 1.11
> "3.0.4" <-- Sonatype Aether 1.13.1
> "3.0.5" <-- Sonatype Aether 1.13.1
> 
> "3.1.0" <-- Eclipse Aether 0.9.0M2
> "3.1.1" <-- Eclipse Aether 0.9.0M2
> "3.2.1" <-- Eclipse Aether 0.9.0M2
> "3.2.2" <-- Eclipse Aether 0.9.0M2
> "3.2.3" <-- Eclipse Aether 0.9.0M2
> 
> "3.2.5" <-- Eclipse Aether 1.0.0.v20140518
> 
> "3.3.1" <-- Eclipse Aether 1.0.2.v20150114
> "3.3.3" <-- Eclipse Aether 1.0.2.v20150114
> "3.3.9" <-- Eclipse Aether 1.0.2.v20150114
> 
> "3.5.0" <-- Maven Resolver 1.0.3
> 
> "3.5.2" <-- Maven Resolver 1.1.0
> 
> "3.5.3" <-- Maven Resolver 1.1.1
> "3.5.4" <-- Maven Resolver 1.1.1
> 
> "3.6.0" <-- Maven Resolver 1.3.1
> 
> "3.6.1" <-- Maven Resolver 1.3.3
> 
> "3.6.2" <-- Maven Resolver 1.4.1
> "3.6.3" <-- Maven Resolver 1.4.1
> 
> 
> so for example, let's say if it is really important that the CollectResult
> class keeps the detected dependency cycles (0.0.9-M4) then we should think
> in deprecating until maven 3.2.3.
> 
> Again, not my use case. I'm fine with deprecating 3.0.x.
> 
> Best regards,
> Gabriel
> 
> [1] https://wiki.eclipse.org/Aether/New_and_Noteworthy
> 
> El mié., 15 de abr. de 2020 a la(s) 17:39, Tibor Digana (
> tibordig...@apache.org) escribió:
> 
>> Some users still use Maven 3.0.5 and they require a support for
>> compatibility reasons between nowadays Maven plugins and the Maven
>> 3.0.x.
>>
>> We have a couple of reasons to deprecate this version (JSR-330,
>> Components injection, Logger) and we have discussed this issue in
>> https://github.com/apache/maven-surefire/pull/274
>>
>> Let's discuss it.
>>
>> Cheers
>> Tibor17
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Proposal to deprecate Maven 3.0.x

[Manfred Moser]

+100

I would deprecate everything before the maven-resolver import back to the 
project while you are at it. Not sure exact version but 3.1x would definitely 
on that list as well. Maybe also 3.2x 

Manfred

Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):

> Some users still use Maven 3.0.5 and they require a support for
> compatibility reasons between nowadays Maven plugins and the Maven
> 3.0.x.
> 
> We have a couple of reasons to deprecate this version (JSR-330,
> Components injection, Logger) and we have discussed this issue in
> https://github.com/apache/maven-surefire/pull/274
> 
> Let's discuss it.
> 
> Cheers
> Tibor17
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: .checkstyle

[Manfred Moser]

I agree with adding it to .gitignore

Elliotte Rusty Harold wrote on 2020-03-03 04:07 (GMT -08:00):

> There's content in it but it's autogenerated as a consequence of
> building the project. It's not hand edited.
> 
> On Tue, Mar 3, 2020 at 3:24 AM Maarten Mulders  wrote:
>>
>> It depends a bit... Is it an empty file? Or is there any content in it,
>> perhaps meaningful to share within a development team?
>>
>> Cheers,
>>
>> Maarten
>>
>> On March 3, 2020 at 22:17, Elliotte Rusty Harold wrote:
>>
>> > Some versions ago the Maven Checkstyle plugin (or perhaps checkstyle
>> > itself) began writing a .checkstyle file into the directory. This
>> > shows up when you run `mvn verify` and is listed a new file in git.
>> >
>> > It's autogenerated and I think we can ignore it. I don't think we want
>> > to check it in, so I propose we simply add it to .gitignore wherever
>> > it appears. E.g.
>> >
>> > https://github.com/apache/maven-shared-utils/pull/9/files
>> >
>> > Does anyone want to argue that we should include it in the repo?
> 
> 
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Repository Security issues: any war stories?

[Manfred Moser]

The order of repositories in a pom, settings and repo manager is crucial. Some 
companies use their own repos on top since they trust them the most. I have 
seen internal teams deploying patched version into those which then essentially 
override the real dep from central.

This is a feature and is used quite often .. however it also opens the door for 
abuse on that level. 

With all sorts of repos out there you really have to check what you consume. If 
you consume repos that are not trustworthy or just badly maintained .. anything 
is possible including security attacks... however I have not seen it in 
practice.

Overall its important that you use Central and othter trusted repos first and 
foremost.. 

Manfred

Elliotte Rusty Harold wrote on 2020-02-28 11:01 (GMT -08:00):

> Folks,
> 
> A colleague is preparing a presentation on general dependency security
> issues. I'm not aware of any compromises of the Maven repo system such
> that a malicious actor was able to push malware to client systems, but
> I'm not sure it's never happened.
> 
> Does anyone know about anything like the attack on npm a couple of
> years ago
> 
> that happened in the Java space?
> 
> Even if something just went a little wonky in a way that could have
> been used to serve malware but wasn't, that would be almost as
> interesting.
> 
> Of course, I'd love for the answer to be, "No, that's never happened
> to Java, and it can't because..." I suspect we're a little more
> resistant to these classes of attacks than npm because version ranges
> are far less common. However, I can't think of anything that would
> prevent someone from buying and compromising future versions of any
> particular artifact. It's not like intelligence agencies haven't
> bought entire companies before,
> 
> and most open source projects could be had for a lot less.
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven GroupID authority

[Manfred Moser]

Anything that goes to Central is immutable .. so no edits or updates or 
whatever. Make sure you keep that in mind 

Manfred



Jonathan Valliere wrote on 2020-02-20 09:50 (GMT -08:00):

> Just indicate a date in the pom at which point the relocation warning turns
> into a relocation error. date. So you warn for a year then you
> keep it up on central for an additional year in which it throws errors but
> indicates to the redirection information.
> 
> On Thu, Feb 20, 2020 at 2:55 AM Hervé BOUTEMY  wrote:
> 
>> +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.apache.org/maven2/org/apache/ant/ant/1.7.0/
>>
>> AFAIK, there is no modification expected on existing artifacts, just
>> relocation
>> poms to create at old coordinates to point new coordinates = the new
>> canonical
>> coordinates
>>
>>
>> then perhaps the way it is implemented can be improved: one issue I can
>> see
>> (from a pure theoretical point of view, I didn't take time to make
>> extensive
>> tests) is to define when you stop publishing relocation poms at old
>> coordinates, ie. starting with which version?
>> and how to be sure that the relocation is detected when resolving both old
>> coordinates and new coordinates that are both canonical coordinates?
>>
>> for example ant:ant:1.6.5 (= canonical coordinates for this release) and
>> org.apache.ant:ant:1.8.0 (= canonical coordinates for this release), given
>> there is no relocation pom published for ant:ant:1.8.0, only for
>> ant:ant:1.7.0
>>
>> Regards,
>>
>> Hervé
>>
>> Le mercredi 19 février 2020, 16:48:38 CET Jonathan Valliere a écrit :
>> > 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
>> 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 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 true on Maven
>> central.
>> > > >
>> > > > On Mon, Feb 17, 2020 at 3:36 PM Hervé BOUTEMY > >
>> > > >
>> > > > wrote:
>> > > > > you can test with
>> > > > > https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ant-1.7.0.pom
>> > >
>> > >
>> https://repo.maven.apache.org/maven2/javax/xml/jaxrpc/1.1/jaxrpc-1.1.pom
>> > >
>> > >
>> > >
>> https://repo.maven.apache.org/maven2/javax/xml/jaxb-api/1.0.1/jaxb-api-1.0
>> > > .1.pom>
>> > > > > testing relocation was on my todo list for years, but I never
>> really
>> > >
>> > > test
>> > >
>> > > > > Regards,
>> > > > >
>> > > > > Hervé
>> > > > >
>> > > > > Le dimanche 16 février 2020, 15:18:17 CET Elliotte Rusty Harold a
>> > >
>> > > écrit :
>> > > > > > On Sun, Feb 16, 2020 at 2:35 AM  wrote:
>> > > > > > > see:
>> > > > > > > -
>> > >
>> > >
>> http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocation
>> > >
>> > > > > > > - https://maven.apache.org/guides/mini/guide-relocation.html
>> > > > > >
>> > > > > > The guide to relocation seems to assume a lot more access and
>> > > > > > control
>> > > > > > to the repo than is the case with public repositories like Maven
>> > > > > > Central. I'm not sure it's actually possible to follow these
>> steps
>> > > > > > today, though perhaps that could be changed.
>> > > > > >
>> > > > > > I'd still like to see the code in the repo that implements
>> support
>> > >
>> > > for
>> > >
>> > > > > > this or, better yet, a sample project that demonstrates
>> relocation
>> > > > > > is
>> > > > > > possible.
>> > > > > >
>> > > > > > If this does work, I can see a lot of use cases for it, but I'm
>> > > > > > currently working with the assumption it is not.
>> > > > >
>> > > > >
>> -
>> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > > >
>> > > > --
>> > > > Elliotte Rusty Harold
>> > > > elh...@ibiblio.org
>> > > >
>> > > > -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>>

Re: Maven Wrapper

[Manfred Moser]

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-maven-3.6.1
apache-maven-3.6.1/ apache-maven-3.6.1-bin.zip

So the used version is actually in a path that contains a hash id.. 


ls 
~/.m2/wrapper/dists/apache-maven-3.6.1-bin/18t1vjepdne9cv9t0hdcik0hp1/apache-maven-3.6.1/
LICENSE NOTICE  README.txt  bin boot
conflib

This is a result of the port of the wrapper from Gradle wrapper and for some 
reason uses the hash of the archive. On the one hand this is more exact and 
secure maybe.. but it sure also seems like a painful choice.

Why not just have them like so

ls ~/.m2/wrapper/dists/

apache-maven-3.6.1
apache-maven-3.6.3
apache-maven-3.7.0

and so on.. 

Manfred

Bernd Eckenfels wrote on 2020-02-19 13:43 (GMT -08:00):

> 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, but
> I figured I just don't care enough :) But a official infrastructure for having
> a local selection of Maven versions would be a nice side product (I.e.
> .m2/Maven- and /opt/maven/maven-<> standard search path (independent
> of wrapper?)
> --
> http://bernd.eckenfels.net
> 
> Von: Robert Scholte 
> Gesendet: Wednesday, February 19, 2020 9:50:14 PM
> An: dev@maven.apache.org 
> Betreff: Re: Maven Wrapper
> 
> 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 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.
> It needs to work behind proxies, repo managers...
> 
> The result is that whatever is added to the repo is committed to the source
> repo of the project. This might or might not include the wrapper jar.
> 
> 
> The other two use cases are largely driven off the mvnw and mvnw.cmd files so
> updating those will be critical when you want to maintain how it works on
> different shells and so on.
> 
> Usage with installation of Maven:
> 
> Here the stuff added from above detects the correct Maven is installed and if
> not downloads it and installs it in ~/.m2/wrapper and then uses it to run the
> desired command passed to it. Download and install of Maven is done via Java
> code in the maven-wrapper jar. If the jar is not use it can fall back to
> curl/wget and if that fails to the java class that is compiled and used.
> 
> Usage without installation of Maven:
> 
> Same as above but the desired Maven version is detected and used straight 
> away.
> 
> 
> Now what that in minds.. is there a risk in completely rewriting it and
> changing how it currently works. Very much so. You might miss a use case and
> end up rebuilding it all over time.
> 
> At the same time .. is the current system maybe overly complex and ugly.
> Probably yes. Could it be improved, certainly.
> 
> So in the end its a questions of approach and taste. Do you want to just port
> what we got and then improve. Or do you want to rebuild from scratch?
> 
> Personally I would just port and improve later but it seems to me that with 
> the
> decision to get it into core you are already largely redoing things so a
> reimplementation seems okay. I would just try to maintain the user facing
> config and behavior.
> 
> Manfred
> 
> 
> Robert Scholte wrote on 2020-02-19 11:40 (GMT -08:00):
> 
>> 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 ProjectPropertiesCommandLineConverter is weird, in Maven -P is for
>> activating profiles.
>>
>> I would like to understand the need for every class, otherwise remove it,
>> especially if we start over with a clean codebase.
>> Do you see a risk?
>>
>> Robert
>>
>> On 19-2-2020 06:19:54, Manfred Moser wrote:
>> All don

Re: Maven Wrapper

[Manfred Moser]

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 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.
> It needs to work behind proxies, repo managers...
> 
> The result is that whatever is added to the repo is committed to the source
> repo of the project. This might or might not include the wrapper jar.
> 
> 
> The other two use cases are largely driven off the mvnw and mvnw.cmd files so
> updating those will be critical when you want to maintain how it works on
> different shells and so on.
> 
> Usage with installation of Maven:
> 
> Here the stuff added from above detects the correct Maven is installed and if
> not downloads it and installs it in ~/.m2/wrapper and then uses it to run the
> desired command passed to it. Download and install of Maven is done via Java
> code in the maven-wrapper jar. If the jar is not use it can fall back to
> curl/wget and if that fails to the java class that is compiled and used.
> 
> Usage without installation of Maven:
> 
> Same as above but the desired Maven version is detected and used straight 
> away.
> 
> 
> Now what that in minds.. is there a risk in completely rewriting it and
> changing how it currently works. Very much so. You might miss a use case and
> end up rebuilding it all over time.
> 
> At the same time .. is the current system maybe overly complex and ugly.
> Probably yes. Could it be improved, certainly.
> 
> So in the end its a questions of approach and taste. Do you want to just port
> what we got and then improve. Or do you want to rebuild from scratch?
> 
> Personally I would just port and improve later but it seems to me that with 
> the
> decision to get it into core you are already largely redoing things so a
> reimplementation seems okay. I would just try to maintain the user facing
> config and behavior.
> 
> Manfred
> 
> 
> Robert Scholte wrote on 2020-02-19 11:40 (GMT -08:00):
> 
>> 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 ProjectPropertiesCommandLineConverter is weird, in Maven -P is for
>> activating profiles.
>>
>> I would like to understand the need for every class, otherwise remove it,
>> especially if we start over with a clean codebase.
>> Do you see a risk?
>>
>> Robert
>>
>> On 19-2-2020 06:19:54, Manfred Moser wrote:
>> All done. All note with pointers to both project readme files, closed all
>> issues and closed all PRs. Hopefully further input and help will show up here
>> now.
>>
>> Manfred
>>
>> Robert Scholte wrote on 2020-02-18 10:56 (GMT -08:00):
>>
>>> sure, go ahead
>>> On 18-2-2020 19:47:29, Manfred Moser wrote:
>>> Okay .. so then I think I should update the Takari repos with a note about
>>> that
>>> and send any contributors to the Maven dev list NOW. I think this has the
>>> potential to drive some more help in this effort.
>>>
>>> If you agree I can do that tonight ..
>>>
>>> manfred
>>>
>>> Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00):
>>>
>>>> This will be part of 3.7.0 together with other huge changes.
>>>> Having the wrapper makes it possible to start updating the defaults for our
>>>> Maven plugins.
>>>> I don't expect a release soon and I don't see a reason to hurry that.
>>>> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on
>>>> 3.7.0.
>>>>
>>>> Robert
>>>> On 18-2-2020 18:50:01, Manfred Moser wrote:
>>>> Agreed... if you think now is a good time, I am happy to update the Takari
>>>> repos with a redirect to the maven dev list and the sandbox repo for now.
>>>>
>>>> I plan to close all issues and all PR and declare the project inactive and
>>>> moved to Apache Maven upstream. Just not sure what the best timing for that
>>>> is.
>>>>
>>>> And in terms of getting the sc

Re: Maven Wrapper

[Manfred Moser]

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. 
It needs to work behind proxies, repo managers... 

The result is that whatever is added to the repo is committed to the source 
repo of the project. This might or might not include the wrapper jar.


The other two use cases are largely driven off the mvnw and mvnw.cmd files so 
updating those will be critical when you want to maintain how it works on 
different shells and so on.

Usage with installation of Maven:

Here the stuff added from above detects the correct Maven is installed and if 
not downloads it and installs it in ~/.m2/wrapper and then uses it to run the 
desired command passed to it. Download and install of Maven is done via Java 
code in the maven-wrapper jar. If the jar is not use it can fall back to 
curl/wget and if that fails to the java class that is compiled and used. 

Usage without installation of Maven:

Same as above but the desired Maven version is detected and used straight away.


Now what that in minds.. is there a risk in completely  rewriting it and 
changing how it currently works. Very much so. You might miss a use case and 
end up rebuilding it all over time. 

At the same time .. is the current system maybe overly complex and ugly. 
Probably yes. Could it be improved, certainly. 

So in the end its a questions of approach and taste. Do you want to just port 
what we got and then improve. Or do you want to rebuild from scratch?

Personally I would just port and improve later but it seems to me that with the 
decision to get it into core you are already largely redoing things so a 
reimplementation seems okay. I would just try to maintain the user facing 
config and behavior.

Manfred


Robert Scholte wrote on 2020-02-19 11:40 (GMT -08:00):

> 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 ProjectPropertiesCommandLineConverter is weird, in Maven -P is for
> activating profiles.
> 
> I would like to understand the need for every class, otherwise remove it,
> especially if we start over with a clean codebase.
> Do you see a risk?
> 
> Robert
> 
> On 19-2-2020 06:19:54, Manfred Moser  wrote:
> All done. All note with pointers to both project readme files, closed all
> issues and closed all PRs. Hopefully further input and help will show up here
> now.
> 
> Manfred
> 
> Robert Scholte wrote on 2020-02-18 10:56 (GMT -08:00):
> 
>> sure, go ahead
>> On 18-2-2020 19:47:29, Manfred Moser wrote:
>> Okay .. so then I think I should update the Takari repos with a note about
>> that
>> and send any contributors to the Maven dev list NOW. I think this has the
>> potential to drive some more help in this effort.
>>
>> If you agree I can do that tonight ..
>>
>> manfred
>>
>> Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00):
>>
>>> This will be part of 3.7.0 together with other huge changes.
>>> Having the wrapper makes it possible to start updating the defaults for our
>>> Maven plugins.
>>> I don't expect a release soon and I don't see a reason to hurry that.
>>> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on
>>> 3.7.0.
>>>
>>> Robert
>>> On 18-2-2020 18:50:01, Manfred Moser wrote:
>>> Agreed... if you think now is a good time, I am happy to update the Takari
>>> repos with a redirect to the maven dev list and the sandbox repo for now.
>>>
>>> I plan to close all issues and all PR and declare the project inactive and
>>> moved to Apache Maven upstream. Just not sure what the best timing for that
>>> is.
>>>
>>> And in terms of getting the scripts in a separate repo or Maven core ... I
>>> see
>>> good reasons for both and dont really have a preference. I just would love 
>>> to
>>> get it moved and into main Maven as soon as possible.
>>>
>>> Would we cut 3.6.4 when the wrapper is done in core?
>>>
>>> Manfred
>>>
>>> Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00):
>>>
>>>> I want to prevent legal issues, so I won't pick up PRs from that 
>>>> repository.
>>>> Once the Maven Wrapper has it's final location, one can provide new PRs on
>>>> our
>>>> codebase.
>>>

Re: Maven Wrapper

[Manfred Moser]

All done. All note with pointers to both project readme files, closed all 
issues and closed all PRs. Hopefully further input and help will show up here 
now. 

Manfred

Robert Scholte wrote on 2020-02-18 10:56 (GMT -08:00):

> sure, go ahead
> On 18-2-2020 19:47:29, Manfred Moser  wrote:
> Okay .. so then I think I should update the Takari repos with a note about 
> that
> and send any contributors to the Maven dev list NOW. I think this has the
> potential to drive some more help in this effort.
> 
> If you agree I can do that tonight ..
> 
> manfred
> 
> Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00):
> 
>> This will be part of 3.7.0 together with other huge changes.
>> Having the wrapper makes it possible to start updating the defaults for our
>> Maven plugins.
>> I don't expect a release soon and I don't see a reason to hurry that.
>> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on
>> 3.7.0.
>>
>> Robert
>> On 18-2-2020 18:50:01, Manfred Moser wrote:
>> Agreed... if you think now is a good time, I am happy to update the Takari
>> repos with a redirect to the maven dev list and the sandbox repo for now.
>>
>> I plan to close all issues and all PR and declare the project inactive and
>> moved to Apache Maven upstream. Just not sure what the best timing for that
>> is.
>>
>> And in terms of getting the scripts in a separate repo or Maven core ... I 
>> see
>> good reasons for both and dont really have a preference. I just would love to
>> get it moved and into main Maven as soon as possible.
>>
>> Would we cut 3.6.4 when the wrapper is done in core?
>>
>> Manfred
>>
>> Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00):
>>
>>> I want to prevent legal issues, so I won't pick up PRs from that repository.
>>> Once the Maven Wrapper has it's final location, one can provide new PRs on
>>> our
>>> codebase.
>>>
>>> Robert
>>> On 16-2-2020 12:56:55, James Gao wrote:
>>> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote:
>>>
>>>> I've found another reason to move it to core: the mvnw scripts are
>>>> extended versions of the mvn scripts.
>>>> If you do a diff, you'll recognize a block responsible for downloading the
>>>> wrapper jar.
>>>> But you also notice that all recent improvements on the mvn scripts have
>>>> not been adopted.
>>>> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of
>>>> Maven x.y.z, now it doesn't.
>>>>
>>>
>>> Hi Robert, there is a PR to
>>> integrate the new boot behavior from maven core to the original wrapper.
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Wrapper

[Manfred Moser]

Okay .. so then I think I should update the Takari repos with a note about that 
and send any contributors to the Maven dev list NOW. I think this has the 
potential to drive some more help in this effort. 

If you agree I can do that tonight .. 
 
manfred

Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00):

> This will be part of 3.7.0 together with other huge changes.
> Having the wrapper makes it possible to start updating the defaults for our
> Maven plugins.
> I don't expect a release soon and I don't see a reason to hurry that.
> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on
> 3.7.0.
> 
> Robert
> On 18-2-2020 18:50:01, Manfred Moser  wrote:
> Agreed... if you think now is a good time, I am happy to update the Takari
> repos with a redirect to the maven dev list and the sandbox repo for now.
> 
> I plan to close all issues and all PR and declare the project inactive and
> moved to Apache Maven upstream. Just not sure what the best timing for that 
> is.
> 
> And in terms of getting the scripts in a separate repo or Maven core ... I see
> good reasons for both and dont really have a preference. I just would love to
> get it moved and into main Maven as soon as possible.
> 
> Would we cut 3.6.4 when the wrapper is done in core?
> 
> Manfred
> 
> Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00):
> 
>> I want to prevent legal issues, so I won't pick up PRs from that repository.
>> Once the Maven Wrapper has it's final location, one can provide new PRs on 
>> our
>> codebase.
>>
>> Robert
>> On 16-2-2020 12:56:55, James Gao wrote:
>> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote:
>>
>>> I've found another reason to move it to core: the mvnw scripts are
>>> extended versions of the mvn scripts.
>>> If you do a diff, you'll recognize a block responsible for downloading the
>>> wrapper jar.
>>> But you also notice that all recent improvements on the mvn scripts have
>>> not been adopted.
>>> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of
>>> Maven x.y.z, now it doesn't.
>>>
>>
>> Hi Robert, there is a PR to
>> integrate the new boot behavior from maven core to the original wrapper.
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Wrapper

[Manfred Moser]

Agreed... if you think now is a good time, I am happy to update the Takari 
repos with a redirect to the maven dev list and the sandbox repo for now. 

I plan to close all issues and all PR and declare the project inactive and 
moved to Apache Maven upstream. Just not sure what the best timing for that is.

And in terms of getting the scripts in a separate repo or Maven core ... I see 
good reasons for both and dont really have a preference. I just would love to 
get it moved and into main Maven as soon as possible. 

Would we cut 3.6.4 when the wrapper is done in core?

Manfred

Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00):

> I want to prevent legal issues, so I won't pick up PRs from that repository.
> Once the Maven Wrapper has it's final location, one can provide new PRs on our
> codebase.
> 
> Robert
> On 16-2-2020 12:56:55, James Gao  wrote:
> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote:
> 
>> I've found another reason to move it to core: the mvnw scripts are
>> extended versions of the mvn scripts.
>> If you do a diff, you'll recognize a block responsible for downloading the
>> wrapper jar.
>> But you also notice that all recent improvements on the mvn scripts have
>> not been adopted.
>> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of
>> Maven x.y.z, now it doesn't.
>>
> 
> Hi Robert, there is a PR to
> integrate the new boot behavior from maven core to the original wrapper.
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven GroupID authority

[Manfred Moser]

>From what I know it is no taken into account by the resolver.


Elliotte Rusty Harold wrote on 2020-02-14 14:25 (GMT -08:00):

> On Fri, Feb 14, 2020 at 5:12 PM Hervé BOUTEMY  wrote:
>>
>> Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit :
>> > Changing group IDs of existing projects is a very bad idea.
>> there is relocation strategy:
>> https://maven.apache.org/guides/mini/guide-relocation.html
>> but AFAIK, it is under-tested...
>>
> 
> Interesting. How does that affect dependency mediation? That is, if an
> old artifact (pre relocation) and a newer artifact both appear in the
> dependency graph will both be added to the classpath? Or does Maven
> treat them as the same and pick the one it sees first?
> 
> 
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven GroupID authority

[Manfred Moser]

>From the very start of the work on the module system and throughout the work 
>people from the Maven project have been involved.

There was never a willingness to create any sort of enforcement.. only a 
request to the community to do the right thing

>From my point of view the Maven project can not do anything really.

With binary repositories all over the place that have very little to no 
enforcement what happens in Maven Central can at best be a good example. At 
worst a system that everyone avoids..

Things like github binaries, dockerhub, npmjs, bintray and many others have 
very little to no guidance or enforcement ... 

The burden lies with the user not to be cheated.

Manfred

PS: and the cynic in me says that there are plenty of "open source security" 
companies out there that want to "help" you and provide tooling to organize the 
mess, so they of course have very little to no interest to have clear ownership 
and rules in repositories... Maven Central is really the only place with some 
real rules. 

Jonathan Valliere wrote on 2020-02-13 20:28 (GMT -08:00):

> Java modules is going to compound this problem we already have.  If
> projects can't get on board with correctly structuring their
> GroupID/Artifacts then why would they use good naming conventions for the
> Modules?  Without good naming conventions, the risk of collisions
> increases.  Manfred's referenced problem, of having multiple versions of
> the same dependency in the same classpath, is only going to become
> impossible with Java Modules.
> 
> Maven is at an optimal position within the community to prevent module
> naming from going haywire and becoming useless.  I believe these two issues
> are intrinsically linked.
> 
> On Thu, Feb 13, 2020 at 10:38 PM Manfred Moser 
> wrote:
> 
>> Agreed ... which is why no one ever went down that road in the last
>> decade...
>>
>> Sander Verhagen wrote on 2020-02-13 19:35 (GMT -08:00):
>>
>> > Hi, y'all. (Disclaimer: I may not completely understand you're
>> proposing.) I
>> > wonder what problem you are really trying to solve. People by now have
>> lost the
>> > absolute expectation that the groupId is authoritative or certified in
>> any way.
>> > And the way that projects get moved between owners, without breaking
>> dependency
>> > resolution, would become a nightmare when it'd require a change to
>> groupIds.
>> > Also, please don't force projects to change their groupId/artifactId
>> combos. We
>> > are still struggling with dependency issues because of having multiple
>> versions
>> > of the (essentially) same dependency on our classpath, because a
>> > groupId/artifactId got changed (sometimes a decade ago). If you can drive
>> > better behavior going forward, all the better, but other than that, and
>> while I
>> > also like it when the world is nicely organized (groupId/artifactId),
>> there
>> > seems little to win here (and a lot to loose).
>> >
>> > Best regards, Sander.
>> >
>> >
>> >
>> > Sander Verhagen
>> > [  san...@sanderverhagen.net<mailto:san...@sanderverhagen.net>  ]
>> >
>> > On 13/02/2020 19.28, Jonathan Valliere wrote:
>> >
>> > Is there any kind of planned timeline to force compliance against old
>> > projects?
>> >
>> > For example:
>> >
>> >   - Force compliance
>> >   - Provide symlinks for backwards compatibility for a limited period of
>> >   time (1 year)
>> >   - Update Maven clients to provide warnings for symlinks during
>> >   builds/tests/etc
>> >
>> >
>> > On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser
>> > <mailto:manf...@simpligility.com>
>> > wrote:
>> >
>> >
>> >
>> > This is a left over from bad choices made decades ago. Now Maven Central
>> > has well documented criteria ... very contrary to nearly all other binary
>> > repos..
>> >
>> >
>> > https://central.sonatype.org/pages/ossrh-guide.html
>> >
>> > https://central.sonatype.org/pages/requirements.html#correct-coordinates
>> >
>> > And the videos linked on the site in which I explain more as well.
>> >
>> > Manfred
>> >
>> >
>> > Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
>> >
>> >
>> >
>> > I have been growing concerned about the process of allowing the creation
>> >
>> >
>> > of
>> >
>> >
>> > GroupIDs, within the Maven Central reposito

Re: Maven GroupID authority

[Manfred Moser]

Agreed ... which is why no one ever went down that road in the last decade... 

Sander Verhagen wrote on 2020-02-13 19:35 (GMT -08:00):

> Hi, y'all. (Disclaimer: I may not completely understand you're proposing.) I
> wonder what problem you are really trying to solve. People by now have lost 
> the
> absolute expectation that the groupId is authoritative or certified in any 
> way.
> And the way that projects get moved between owners, without breaking 
> dependency
> resolution, would become a nightmare when it'd require a change to groupIds.
> Also, please don't force projects to change their groupId/artifactId combos. 
> We
> are still struggling with dependency issues because of having multiple 
> versions
> of the (essentially) same dependency on our classpath, because a
> groupId/artifactId got changed (sometimes a decade ago). If you can drive
> better behavior going forward, all the better, but other than that, and while 
> I
> also like it when the world is nicely organized (groupId/artifactId), there
> seems little to win here (and a lot to loose).
> 
> Best regards, Sander.
> 
> 
> 
> Sander Verhagen
> [  san...@sanderverhagen.net<mailto:san...@sanderverhagen.net>  ]
> 
> On 13/02/2020 19.28, Jonathan Valliere wrote:
> 
> Is there any kind of planned timeline to force compliance against old
> projects?
> 
> For example:
> 
>   - Force compliance
>   - Provide symlinks for backwards compatibility for a limited period of
>   time (1 year)
>   - Update Maven clients to provide warnings for symlinks during
>   builds/tests/etc
> 
> 
> On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser
> <mailto:manf...@simpligility.com>
> wrote:
> 
> 
> 
> This is a left over from bad choices made decades ago. Now Maven Central
> has well documented criteria ... very contrary to nearly all other binary
> repos..
> 
> 
> https://central.sonatype.org/pages/ossrh-guide.html
> 
> https://central.sonatype.org/pages/requirements.html#correct-coordinates
> 
> And the videos linked on the site in which I explain more as well.
> 
> Manfred
> 
> 
> Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
> 
> 
> 
> I have been growing concerned about the process of allowing the creation
> 
> 
> of
> 
> 
> GroupIDs, within the Maven Central repository, which do not adhere to the
> naming guidelines. i.e. the GroupID must belong to a unique domain name
> controlled by the project owner.
> 
> Even within the Apache family, there is no consistent naming enforcement.
> The project I belong to, org.apache.mina adheres to the conventions but
> many others do not.  Apache Commons for example uses a different GroupID
> for almost every sub-project within its scope.  Many of them simply
> starting with the word "commons" instead of "org.apache.commons".  Does
> 
> 
> the
> 
> 
> PMC have any ideas on how to combat this?
> 
> Cheers,
> Jon
> 
> 
> 
> 
> -
> To unsubscribe, e-mail:
> dev-unsubscr...@maven.apache.org<mailto:dev-unsubscr...@maven.apache.org>
> For additional commands, e-mail:
> dev-h...@maven.apache.org<mailto:dev-h...@maven.apache.org>
> 
> 
> 
> 
> 
> 
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven GroupID authority

[Manfred Moser]

Ownership of established GAVs and assignment of new ones is all managed by 
Sonatype as part of the onboarding to OSSRH.

>From all I know there is no policy for changes.. its entirely up to the 
>projects. 

Maybe Brian or Joel or someone else who is still with Sonatype can chime in.

Also.. fyi there is a feature in Maven that allows migration and such but it is 
barely used. 

Manfred

Jonathan Valliere wrote on 2020-02-13 19:28 (GMT -08:00):

> Is there any kind of planned timeline to force compliance against old
> projects?
> 
> For example:
> 
>   - Force compliance
>   - Provide symlinks for backwards compatibility for a limited period of
>   time (1 year)
>   - Update Maven clients to provide warnings for symlinks during
>   builds/tests/etc
> 
> 
> On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser 
> wrote:
> 
>> This is a left over from bad choices made decades ago. Now Maven Central
>> has well documented criteria ... very contrary to nearly all other binary
>> repos..
>>
>>
>> https://central.sonatype.org/pages/ossrh-guide.html
>>
>> https://central.sonatype.org/pages/requirements.html#correct-coordinates
>>
>> And the videos linked on the site in which I explain more as well.
>>
>> Manfred
>>
>>
>> Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
>>
>> > I have been growing concerned about the process of allowing the creation
>> of
>> > GroupIDs, within the Maven Central repository, which do not adhere to the
>> > naming guidelines. i.e. the GroupID must belong to a unique domain name
>> > controlled by the project owner.
>> >
>> > Even within the Apache family, there is no consistent naming enforcement.
>> > The project I belong to, org.apache.mina adheres to the conventions but
>> > many others do not.  Apache Commons for example uses a different GroupID
>> > for almost every sub-project within its scope.  Many of them simply
>> > starting with the word "commons" instead of "org.apache.commons".  Does
>> the
>> > PMC have any ideas on how to combat this?
>> >
>> > Cheers,
>> > Jon
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven GroupID authority

[Manfred Moser]

This is a left over from bad choices made decades ago. Now Maven Central has 
well documented criteria ... very contrary to nearly all other binary repos.. 


https://central.sonatype.org/pages/ossrh-guide.html

https://central.sonatype.org/pages/requirements.html#correct-coordinates

And the videos linked on the site in which I explain more as well. 

Manfred


Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):

> I have been growing concerned about the process of allowing the creation of
> GroupIDs, within the Maven Central repository, which do not adhere to the
> naming guidelines. i.e. the GroupID must belong to a unique domain name
> controlled by the project owner.
> 
> Even within the Apache family, there is no consistent naming enforcement.
> The project I belong to, org.apache.mina adheres to the conventions but
> many others do not.  Apache Commons for example uses a different GroupID
> for almost every sub-project within its scope.  Many of them simply
> starting with the word "commons" instead of "org.apache.commons".  Does the
> PMC have any ideas on how to combat this?
> 
> Cheers,
> Jon
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Wrapper

[Manfred Moser]

Chris,

IANAL but I dont think we can make such a claim ... even though there is not 
much to the code and scripts ... its still an Apache project and code of it.. 

Manfred

Christofer Dutz wrote on 2020-02-12 22:29 (GMT -08:00):

> Hi all,
> 
> would it also be possible for some sort of official statement that when 
> copying
> the maven wrapper scripts (For Apache Projects), this doesn't explicitly have
> to be mentioned in the NOTICE or LICENSE file? I know that this could ease
> quite some +1/-1 discussions (especially on the incubator).
> 
> Chris
> 
> Am 13.02.20, 06:12 schrieb "James Gao" :
> 
>With maven wrapper, most maven project could be build out of box iff jdk is
>installed, and the maven version used for build is locked by the project
>owner. So in run time, each version of wrapper should be able to integrate
>with as many as versions of maven. And so does the wrapper plugin, but
>plugin is seldom used by by developers.
>
>What the wrapper depends on are two very stable things:
>  a) how maven is distributed (a zip/tgz archive and its internal file
>structures),
>  b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
>bin/mvn.cmd)
>
>No matter how wrapper is distributed (via plugin or just copy from another
>project), the deployed wrapper based on previous dependents, will deploy a
>configurable version of maven to a personal location on the fly if needed,
>then executed the previous deployed maven, but will not update the deployed
>script itself.
>
>So although wrapper will be released with maven core, it still better not
>to lock the runtime version of maven.
>
>On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte  
> wrote:
>
>> well, with every release of Maven, some versions needed to be updated, 
> see
>> the commit logs.
>> Also the release instructions show some relation with the Maven version.
>>
>> Based on that it looks like it should be part of core.
>> I've understood doing a release of is a bit problematic due to some
>> chicken-egg issue.
>>
>> However, I did start with the plugin and that one is now capable of
>> recognizing the runtime version of Maven, not hardcoded.
>>
>> So it depends, I just haven't figured it out yet.
>> On 12-2-2020 20:28:24, Enrico Olivelli  wrote:
>> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>>
>> > Hi,
>> >
>> > This month we've finished the incubator process to move to code from 
> the
>> > maven wrapper to our project.
>> >
>>
>> Cool
>>
>> >
>> > Initially the idea was to move both the maven-wrapper and the
>> > takari-maven-plugin (which contains a wrapper goal) to our codebase, 
> but
>> > due to conflicting licensing we only moved the maven-wrapper.
>> >
>> > Right now I've moved the code of the maven-wrapper to his own branch
>> under
>> > maven-studies.
>> > From here we can work on it. I think it makes sense to make it a module
>> of
>> > Maven core, but that's still a decision we need to make.
>> >
>>
>> Is it strictly dependent on a Maven version? I thought it was totally
>> independent.
>> Why not having a separate repository and release lifecycle?
>>
>> Enrico
>>
>>
>> > For the maven-wrapper-plugin a new repository has been created. And 
> I've
>> > started with a clean branch, trying to set the base of this plugin.
>> >
>> > Both are open for further development, not just by me.
>> >
>> > So here are the 2 new git repositories:
>> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
>> > (branch MWRAPPER-0_WIP)
>> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
>> > maven-wrapper)
>> >
>> >
>> > Enjoy,
>> > Robert
>>
>
> 
> 

Re: Maven Wrapper

[Manfred Moser]

I have maintained the wrapper in a separate repo the last couple of years. In 
my opinion the wrapper should 
automatically default to the latest release of Maven, but allow configuration 
to use older versions.

Of course that comes with the usual claim that there is no such thing as 
support for older versions. Fixes only make it
into latest release.

Having the wrapper in the main core repo would allow us to just have it 
automatically releases whenever we
release core, and hence that reduces work. 

On the other hand of course it prevents us from releasing it more often.

I can see advantages for both approaches to be honest.

And yes James... we should not lock the runtime version to the wrapper use. But 
we should default to latest release... 

Overall I think the pragmatic approach might be best.. 

- just leave it as it was for now in a separate repo
- refactor the GAV and such so that we are within the AFF and Maven project
- cut a release of the wrapper jar (and the scripts within)
- cut a release of the maven wrapper plugin that Robert started

Then we are ready to use it already and we have a base to improve upon.

We can always pull it into core later if we find we need to do that... or stick 
with what we have.

There are a whole bunch of issues and ideas piled up in the contributing repo 
and the sooner we can have a first release at ASF the sooner I can point people 
to the ASF and the Maven project to help there .. the Takari wrapper dev is 
essentially frozen until we continue at ASF.


Manfred


James Gao wrote on 2020-02-12 21:12 (GMT -08:00):

> With maven wrapper, most maven project could be build out of box iff jdk is
> installed, and the maven version used for build is locked by the project
> owner. So in run time, each version of wrapper should be able to integrate
> with as many as versions of maven. And so does the wrapper plugin, but
> plugin is seldom used by by developers.
> 
> What the wrapper depends on are two very stable things:
>  a) how maven is distributed (a zip/tgz archive and its internal file
> structures),
>  b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
> bin/mvn.cmd)
> 
> No matter how wrapper is distributed (via plugin or just copy from another
> project), the deployed wrapper based on previous dependents, will deploy a
> configurable version of maven to a personal location on the fly if needed,
> then executed the previous deployed maven, but will not update the deployed
> script itself.
> 
> So although wrapper will be released with maven core, it still better not
> to lock the runtime version of maven.
> 
> On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte  wrote:
> 
>> well, with every release of Maven, some versions needed to be updated, see
>> the commit logs.
>> Also the release instructions show some relation with the Maven version.
>>
>> Based on that it looks like it should be part of core.
>> I've understood doing a release of is a bit problematic due to some
>> chicken-egg issue.
>>
>> However, I did start with the plugin and that one is now capable of
>> recognizing the runtime version of Maven, not hardcoded.
>>
>> So it depends, I just haven't figured it out yet.
>> On 12-2-2020 20:28:24, Enrico Olivelli  wrote:
>> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>>
>> > Hi,
>> >
>> > This month we've finished the incubator process to move to code from the
>> > maven wrapper to our project.
>> >
>>
>> Cool
>>
>> >
>> > Initially the idea was to move both the maven-wrapper and the
>> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
>> > due to conflicting licensing we only moved the maven-wrapper.
>> >
>> > Right now I've moved the code of the maven-wrapper to his own branch
>> under
>> > maven-studies.
>> > From here we can work on it. I think it makes sense to make it a module
>> of
>> > Maven core, but that's still a decision we need to make.
>> >
>>
>> Is it strictly dependent on a Maven version? I thought it was totally
>> independent.
>> Why not having a separate repository and release lifecycle?
>>
>> Enrico
>>
>>
>> > For the maven-wrapper-plugin a new repository has been created. And I've
>> > started with a clean branch, trying to set the base of this plugin.
>> >
>> > Both are open for further development, not just by me.
>> >
>> > So here are the 2 new git repositories:
>> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
>> > (branch MWRAPPER-0_WIP)
>> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
>> > maven-wrapper)
>> >
>> >
>> > Enjoy,
>> > Robert
>>
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Version poll results

[Manfred Moser]

Its part of the spec.. sure.However only the Maven spec .. and different specs 
and tools might behave differently. The Maven repository format and related 
aspects are used by MANY more tools than just Maven.

Using the short version 2.1 causes issues such as mentioned earlier for no real 
benefit - so in the interest of making it more user friendly and explicit I 
advocate for just being explicit and using 2.1.0

Manfred

Matt Foley wrote on 2020-01-08 12:36 (GMT -08:00):

>>> So do NOT use a version like 2.1 .. instead use 2.1.0.
> 
> The fact that 2.1 is identical to 2.1.0 is part of the spec, unambiguous, and
> quite important for expected behavior IMHO.  See "Trimming Examples" in
> https://maven.apache.org/pom.html#Version_Order_Specification
> <https://maven.apache.org/pom.html#Version_Order_Specification>
> 
> Thanks,
> —Matt
> —
> Open Source Technologies @ 
> 
> 
> On Jan 7, 2020, at 1:29 PM, Manfred Moser  wrote:
> 
> To be honest I dont think this needs fixing on the Maven side. If we change
> behavior we just break other approaches.
> 
> Instead users that want to use semver with three digits and want logic 
> ordering
> should just do so.
> 
> So do NOT use a version like 2.1 .. instead use 2.1.0.
> 
> Problem solved.
> 
> Also .. beyond the three digit semver usage .. dont assume anything beyond
> purely alphanumeric sort to work. 
> 
> And of course dont ever do something like "latest", which is so popular in
> other ecosystems like Docker or npm since you are just introducing a quicksand
> scenario for your users.
> E.g. latest release by date for example could be a patch release of an lower
> version...
> 
> manfred
> 
> Elliotte Rusty Harold wrote on 2020-01-07 04:16 (GMT -08:00):
> 
>> I've been looking at Maven 's version comparison algorithm: what it
>> does, what it's documented to do, and what it should do. I ran a quick
>> poll on my twitter feed to see what developers expect how version
>> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
>> version? 2.1.q or 2.1?
>> 
>> https://twitter.com/elharo/status/1213457533358223361
>> 
>> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
>> Maven currently assumes. See
>> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
>> to understand how.
>> 
>> This has real world consequences. xpp3:xpp3 for example uses letters
>> with the expectation that 1.4.1.c comes after 1.4.1. There are
>> probably other artifacts that use letters with these semantics too.
>> 
>> I'm about 90% convinced this is something we should fix. It's a
>> breaking change but I expect the high majority of devs who encounter
>> this would classify the existing behavior as a bug.
>> 
>> My main question is what version of Maven should we fix this in?
>> 3.6.5? 3.7? 4.0? Thoughts?
>> 
>> -- 
>> Elliotte Rusty Harold
>> elh...@ibiblio.org
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Version poll results

[Manfred Moser]

Elliotte Rusty Harold wrote on 2020-01-07 13:38 (GMT -08:00):

> On Tue, Jan 7, 2020 at 4:00 PM Clemens Quoss  wrote:
>>
>> artifactId-version-classifier.jar
>>
>> How do i separate the classifier?
>>
> 
> If all you have is the name of the jar, I don't think you can. You
> need the repo metadata or the coordinates or the pom.xml  to tell
> whether google-cloud-firestore-0.41.0-beta.jar has the version
> 0.41.0-beta and no classifier or the version 0.41.0 and the classifier
> beta.

Correct.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Version poll results

[Manfred Moser]

To be honest I dont think this needs fixing on the Maven side. If we change 
behavior we just break other approaches.

Instead users that want to use semver with three digits and want logic ordering 
should just do so.

So do NOT use a version like 2.1 .. instead use 2.1.0.

Problem solved.

Also .. beyond the three digit semver usage .. dont assume anything beyond 
purely alphanumeric sort to work. 

And of course dont ever do something like "latest", which is so popular in 
other ecosystems like Docker or npm since you are just introducing a quicksand 
scenario for your users.
E.g. latest release by date for example could be a patch release of an lower 
version...

manfred

Elliotte Rusty Harold wrote on 2020-01-07 04:16 (GMT -08:00):

> I've been looking at Maven 's version comparison algorithm: what it
> does, what it's documented to do, and what it should do. I ran a quick
> poll on my twitter feed to see what developers expect how version
> strings such as 2.1.q and 2.1 are compared. That is, what's the higher
> version? 2.1.q or 2.1?
> 
> https://twitter.com/elharo/status/1213457533358223361
> 
> 2.1.q won in a landslide. This is, unfortunately, the opposite of what
> Maven currently assumes. See
> https://issues.apache.org/jira/browse/MNG-6420?focusedCommentId=17008025=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008025
> to understand how.
> 
> This has real world consequences. xpp3:xpp3 for example uses letters
> with the expectation that 1.4.1.c comes after 1.4.1. There are
> probably other artifacts that use letters with these semantics too.
> 
> I'm about 90% convinced this is something we should fix. It's a
> breaking change but I expect the high majority of devs who encounter
> this would classify the existing behavior as a bug.
> 
> My main question is what version of Maven should we fix this in?
> 3.6.5? 3.7? 4.0? Thoughts?
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Defining EoL for Older Maven Versions

[Manfred Moser]

Chiming in late since I remember we discussed this before. 

Here is my view.

All releases beyond the most recent one are essentially end of lifed. We never 
backport, we have no explicit support and whenever we fix something it goes 
into the next release.

That is what we concluded last time and that is the reason why the download 
page only offers the latest version.

Anything else is misleading our users with some sort of support or guarantee 
that things continue to work and are tested when really they are not. 

Of course we make a best effort to keep things smooth ... but thats really 
where it ends.

Manfred

Karl Heinz Marbaise wrote on 2019-12-16 12:57 (GMT -08:00):

> On 15.12.19 12:14, Elliotte Rusty Harold wrote:
>> Tentative +1.
>>
>> Is there any reason we would ever backport a fix to 3.0 or 3.2? E.g.
>> this was the last release to support Java 1.6.
> 
> Unfortunately my crystal ball is under repair...I can't see into the
> future...
> 
> I would say if we a really bad security issue would could decide to do a
> backport for older releases...But based on the history I know and can
> read through the mailing archives it has not happened yet...
> 
> 
> 
>>
>> Or would we simply tell users to upgrade to 3.6.3?
>>
>>
>> On Sat, Dec 14, 2019 at 6:31 AM Karl Heinz Marbaise  
>> wrote:
>>>
>>> Hi,
>>>
>>> based on the history we have defined Maven 2.X EoL five years after the
>>> last release...[1]
>>>
>>> Based on that I would suggest to define End Of Life for the following
>>> Maven versions cause their release date is also five years ago...
>>>
>>>
>>> Maven 3.0.5...3.2.5 included.
>>>
>>> We have never backported some things in the last five year...
>>>
>>> WDYT?
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>
>>> [1]: https://maven.apache.org/docs/history.html#Maven_2
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

New Maven wrapper release

[Manfred Moser]

I just release a new version which now default to use Maven 3.6.3.

Update your projects with 

mvn -N io.takari:maven:0.7.7:wrapper

and enjoy.

More info at https://github.com/takari/maven-wrapper

Manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven version 3.6.3

[Manfred Moser]

+1

works for polyglot-maven, maven-wrapper and a whole bunch of other projects of 
various sizes and complexity.

Manfred

Robert Scholte wrote on 2019-11-21 12:06 (GMT -08:00):

> Hi,
> 
> This will be a regression release based on some critical issues discovered in
> Maven 3.6.2
> 
> We solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12346152=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1542/
> 
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.zip
> 
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/source/apache-maven-3.6.3-src.tar.gz
> 
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/source/apache-maven-3.6.3-src.zip
> 
> 
> Source release checksum(s):
> apache-maven-3.6.3-bin.tar.gz sha512: 
> c35a1803a6e70a126e80b2b3ae33eed961f83ed74d18fcd16909b2d44d7dada3203f1ffe726c17ef8dcca2dcaa9fca676987befeadc9b9f759967a8cb77181c0
> apache-maven-3.6.3-bin.zip sha512: 
> 1c095ed556eda06c6d82fdf52200bc4f3437a1bab42387e801d6f4c56e833fb82b16e8bf0aab95c9708de7bfb55ec27f653a7cf0f491acebc541af234eded94d
> 
> apache-maven-3.6.3-src.tar.gz sha512: 
> 14eef64ad13c1f689f2ab0d2b2b66c9273bf336e557d81d5c22ddb001c47cf51f03bb1465d6059ce9fdc2e43180ceb0638ce914af1f53af9c2398f5d429f114c
> 
> apache-maven-3.6.3-src.zip sha512: 
> b23b7ae7392eca28ec124cf8ad24bb27405aea5d252d9305bb37a6e317947cc7dc15a564958a113ab75e2010e16c293d6e7c44f7d41d7bad7635d2d76eb4d1ac
> 
> Staging site:
> http://maven.apache.org/ref/3-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Wagon version 3.3.4

[Manfred Moser]

Why? jsoup is MIT licensed which is compatible with Apache V2. 

Manfred

Vladimir Sitnikov wrote on 2019-11-05 11:10 (GMT -08:00):

>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1535/
> 
> -1 since
> https://repository.apache.org/content/repositories/maven-1535/org/apache/maven/wagon/wagon-http/3.3.4/wagon-http-3.3.4-shaded.jar
> violates licensing terms for the third-party code.
> One of the violations is org.jsoup:jsoup.
> 
> I know releases may not be vetoed (
> https://www.apache.org/foundation/voting.html#ReleaseVotes )
> However, there's
> 
>> http://www.apache.org/legal/release-policy.html#licensing
>>Every ASF release MUST comply with ASF licensing policy. This requirement
> is of utmost importance
> 
> Vladimir
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Manfred Moser]

+1

or more ... haha

Manfred

Stephen Connolly wrote on 2019-10-29 16:23 (GMT -07:00):

> +1
> 
> On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise  wrote:
> 
>> Hi to all,
>>
>> based on the discusion this is the formal VOTE to lift the minimum of
>> Maven Core with version 3.7.0 to JDK 8 minimum.
>>
>> Vote open for at least 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> --
> Sent from my phone
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Kotlin pom

[Manfred Moser]

The polyglot support is implemented as a project extension as you can see from 
the docs.

So if your project has the extension configured and a pom.kts .. nothing 
changes for you on the command line.. 

mvn install

will do the job just fine. No need for -f and so on.. 

Manfred

Tibor Digana wrote on 2019-06-08 07:52:

> If polyglot was included directly in Maven dist, we could run the build
> with something like this:
> $ mvn -f pom.kts install
> 
> Any thoughts?
> 
> On Sat, Jun 8, 2019 at 1:55 AM Manfred Moser 
> wrote:
> 
>> Shipped 0.4.1 of polyglot-maven with more kotlin goodness ;-)
>>
>>
>> https://www.simpligility.com/2019/06/kotlin-improvements-for-polyglot-maven/
>>
>> Enjoy
>>
>> Manfred
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Kotlin pom

[Manfred Moser]

Shipped 0.4.1 of polyglot-maven with more kotlin goodness ;-) 

https://www.simpligility.com/2019/06/kotlin-improvements-for-polyglot-maven/

Enjoy

Manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Retire Maven Ant Plugin

[Manfred Moser]

Somewhere between +5 and +10 ;-)

Robert Scholte wrote on 2019-05-28 11:54:

> Hi,
> 
> The Apache Maven project consist of about 100 (sub)projects. Due to the small
> number of volunteers and the huge amount of code to maintain we're missing
> enough space to make real progress on all these projects, including our
> ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
> 
> The goal of the Apache Maven Ant Plugin it to generate Ant build files based 
> on
> a pom.xml and was released for the last time in December 2014. Due to the
> different ways that Ant and Maven work I don't think it makes
> sense anymore to maintain a plugin to transform Maven files to Ant.
> See https://maven.apache.org/plugins/maven-ant-plugin/
> [https://maven.apache.org/plugins/maven-ant-plugin/]
> 
> To be clear, this is NOT the plugin you can use to run Ant within Maven; 
> that's
> the maven-antrun-plugin.
> 
> I therefore propose that we retire the maven-ant-plugin.
> 
> I don't think it makes sense to do a final release. Instead we should update
> the documentation and freeze the codebase.
> 
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html 
> 
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Retire Maven Runtime library

[Manfred Moser]

+1 .. definitely about time ;-) 

Robert Scholte wrote on 2019-05-15 13:33:

> Hi,
>  
> The Apache Maven project consist of about 100 (sub)projects. Due to the small
> number of volunteers and the huge amount of code to maintain we're missing
> enough space to make real progress on all these projects, including our
> ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
>  
> The Maven Runtime library has been released 3 times, the last time was May 
> 2012
> for version 1.0-alpha-3. According
> to https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime
> [https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] 
> this
> library is only used in 4 projects.
> The main purpose of the library is reading the pom.properties or pom.xml from
> an artifact to get the version. This functionality works so the library can be
> considered finished.
> See https://maven.apache.org/shared/maven-runtime/
> [https://maven.apache.org/shared/maven-runtime/]
>  
> I therefore propose that we retire the maven-runtime.
>  
> I don't think it makes sense to do a final release. Instead we should update
> the documentation and the freeze the codebase.
>  
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html 
>  
> The vote is open for 72 hours.
>  
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Retire Maven Repository Plugin

[Manfred Moser]

+1

Robert Scholte wrote on 2019-04-23 12:43:

> Hi,
> 
> The Apache Maven project consist of about 100 (sub)projects. Due to the small
> number of volunteers and the huge amount of code to maintain we're missing
> enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
> 
> One of those subprojects is the maven-repository-plugin, last released on
> February 22, 2015. It's main purpose: a plugin that can be used to create
> bundles of artifacts that can be uploaded to the central repository.
> Based on that it seems that the maven-assembly-plugin is a better fit for 
> that.
> 
> I therefore propose that we retire the maven-repository-plugin.
> 
> I don't think it makes sense to do a final release. Instead we should update
> the documentation and the freeze the codebase.
> 
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> 
> The vote is open for 72 hours.
> 
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven Wrapper updated to Apache Maven Version 3.6.1

[Manfred Moser]

I just cut a new release of maven wrapper and the plugin for installing it. It 
now defaults to the shiny new 3.6.1

Enjoy

manfred

Karl Heinz Marbaise wrote on 2019-04-13 03:03:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven 3.6.1.
> 
> Apache Maven is a software project management and comprehension tool.
> Based on the concept of a project object model (POM), Maven can manage a
> project's build, reporting and documentation from a central piece of
> information.
> 
> You can find out more about Apache Maven at https://maven.apache.org
> 
> You can download the appropriate sources etc. from the download page:
> https://maven.apache.org/download.cgi
> 
> Release Notes - Apache Maven Version 3.6.1
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344378=12316922
> 
> Code Contributors of this release:
> 
>  * Gabriel Belingueres (indirectly via plexus-utils PR)
>  * Michael Istria
>  * Michael Istria
>  * Guy Brand
>  * Fabiano C. de Oliveira
>  * Michael Istria
> 
> Issue Reporters of this release:
> 
>  * Ondra Žižka
>  * Matthias Scmalz
>  * Andreas Sewe
>  * Christian Aistleitner
>  * Jin Kwon
>  * Christoph Etzel
>  * Dawid Weiss
>  * Gene Smith
>  * Patrik Jetzer
>  * Rohan Padhye
>  * Elliotte Rusty Harold
>  * Andreas Veithen
>  * Olaf Otto
>  * Michael Istria
>  * Michael Istria
>  * Michael Istria
>  * Romain Manni-Bucau
>  * Guy Brand
>  * Rohan Padhye
>  * Olaf Otto
>  * Gunnar Wagenknecht
>  * Viacheslav Yakunin
> 
> Many thanks to contributors and reporters for the support and time.
> 
> Participants to the VOTE of the Maven 3.6.1 Release:
> 
>  * Gabriel Belingueres
>  * Francois Papon
>  * Eric Lilja
> 
> 
> Many thanks to those who tested the Maven releases
> and thanks for their support as well.
> 
> (Please send an email to the dev list if we missed one to mention).
> 
> Release Notes for Apache Maven 3.6.1
> 
> 
> https://maven.apache.org/docs/3.6.1/release-notes.html
> 
> Bugs:
>  * [MNG-5705] - NPE on parallel build in
> BuilderCommon.handleBuildError(BuilderCommon.java:147)
>  * [MNG-5965] - Parallel build multiplies work if multiple goals are given
>  * [MNG-5995] - Maven itself cannot run without maven-compat
>  * [MNG-6256] - Maven script can break if “-f” path contains special
> characters
>  * [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with
> complex multimodule builds
>  * [MNG-6262] - getCanonicalFile() is not used consistently during
> project resolution
>  * [MNG-6346] - … was unexpected at this time when using -f option and
> path contains brackets
>  * [MNG-6374] - ModelBuilder hangs with malformed pom.xml
>  * [MNG-6429] - Integration Test site publishing requires Java 7 (or
> javadoc errors ignored)
>  * [MNG-6495] - ModelResolver cannot be null
>  * [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
>  * [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
>  * [MNG-6529] - ProjectBuilder.build(List projects, boolean,
> ProjectBuildingRequest) doesn’t honor
> ProjectBuildingRequest.isResolveDependencies()
>  * [MNG-6530] - Regression in ProjectBuilder when file change between
> invocations (introduced by MNG-6311)
>  * [MNG-6533] - ProjectBuilder.build(list_of_projects,...) does not
> contain MavenProject in exception report
>  * [MNG-6543] - Upgrade plexus classworld to support java 9+
> ClassLoader.findClass(String moduleName, String name) in Mojos
>  * [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
>  * [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing
> unicode entity ref
>  * [MNG-6590] - DefaultProjectArtifactsCache
> java.lang.IllegalStateException: Duplicate artifact resolution result
>  * [MNG-6599] - unknown version in model id when version is defined
> from parent
> 
> Improvements:
> 
>  * [MNG-6059] - Important use cases not covered, as
> child.inherit.append.path affects all children
>  * [MNG-6159] - Child path adjustments break git scm urls
>  * [MNG-6213] - Maven doesn’t check the validity of scope value
>  * [MNG-6481] - Allow to compile and test Maven with Java 11
>  * [MNG-6513] - Replace depreated Plexus javadoc tags with annotations
> in ITs
>  * [MNG-6515] - Fix javadoc build errors under Java 8 and 11
>  * [MNG-6520] - Update assembly descriptors to 2.0.0
>  * [MNG-6522] - Prepare Maven’s Core Integration Test Suite to test
> with Java 12 and 13-ea
>  * [MNG-6572] - use int or long instead of BigIntegers for little
> numbers in ComparableVersion
>  * [MNG-6593] - track input location for super-pom
>  * [MNG-6597] - add input location tracking for plugins configuration
>  * [MNG-6600] - add input location tracking for default lifecycle
> bindings executions
>  * [MNG-6601] - add input location tracking for site’s reportPlugins
> injected by reports conversion
>  * [MNG-6605] - Allow to suppress download messages in interactive mode
>  * [MNG-6611] - Update 

Re: Accessing a maven repository programatically (in 2019)

[Manfred Moser]

Michael,

Have a look at my Maven Repository Provisioner codebase. It does exactly what 
you want and also includes dependencies and upload to a repo manager.

It now uses the Maven Resolver in the latest version so its up to date.. 

https://github.com/simpligility/maven-repository-tools

Specifically look at 

https://github.com/simpligility/maven-repository-tools/blob/master/maven-repository-provisioner/src/main/java/com/simpligility/maven/provisioner/ArtifactRetriever.java

Manfred

simpligility.com

Michael Lipp wrote on 2019-04-06 06:07:

> Hi,
> 
> I've spent considerable time on researching this, but to no avail. The
> closest answer that I have found was on Stackoverflow
> (https://stackoverflow.com/questions/11674537/retrieving-maven-artifact-from-repository-using-maven-java-api).
> But it points me to Eclipse Aether, which has been archived, so it seems
> out-dated and not the way to go.
> 
> I also found the "Aether re-integration page"
> (http://maven.apache.org/aether.html) and had a look at "Maven Resolver
> Provider"
> (https://maven.apache.org/ref/3.6.0/maven-resolver-provider/apidocs/index.html?org/apache/maven/repository/internal/MavenRepositorySystemUtils.html),
> the "resurrected Aether". What irritates me, however, is that there
> doesn't seem to be any connection between the "Maven Resolver Provider"
> and the main part of the API. So I wonder if this is just some "left-over".
> 
> Considering the "main parts" of the Maven API, I think I should be able
> to start things by creating a LocalArtifactRepository
> (https://maven.apache.org/ref/3.6.0/apidocs/index.html), but this is, of
> course, not possible, it's abstract. The concrete subclass
> UserLocalArtifactRepository isn't of much help, it requires a repository
> as constructor argument.
> 
> All other classes that implement "ArtifactRepository" are deprecated.
> Which is a pity, because something like "DefaultArtifactRepository"
> looks exactly like what I need. But I'm hesitant to start a new project
> centering around a deprecated class.
> 
> So, I'm at loss. All I want to do is retrieve some artifacts and their
> POMs from a remote repository, using the ~/.m2/repository as cache, as
> usual. The ArtifactRepository interface
> (https://maven.apache.org/ref/3.6.0/apidocs/index.html) seems perfect
> for this. How can I get an object that implements it?
> 
> Thanks!
> 
>  - Michael
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Kotlin for your pom

[Manfred Moser]

Hi all,

Just a quick heads up that the new polyglot-maven release I cut recently 
features a MUCH improved support for Kotlin. So with the help of polyglot-maven 
you can write your pom in yaml, ruby, scala, kotlin and a bunch of other 
formats now. 

Check it out and send us any feedback ...

https://www.simpligility.com/2019/03/kotlin-for-polyglot-maven/

https://github.com/takari/polyglot-maven

Manfred






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Recent Maven Wrapper releases

[Manfred Moser]

Hi all,

Just wanted to give you a heads up about the recent Maven wrapper and plugin 
releases. 

https://www.simpligility.com/2019/03/recent-maven-wrapper-updates/

Some pretty nice features worth checking out imho.

Go update your projects to this latest version!

Manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Enable Travis on Maven Scripting Plugin

[Manfred Moser]

Fair enough. If its just for outside contributor PRs I am agree with not owning 
the risk ;-) 

Stephen Connolly wrote on 2019-01-04 16:06:

> On Fri 4 Jan 2019 at 22:00, Tibor Digana  wrote:
> 
>> @Stephen Connolly 
>>  After such a big investment, especially made on your side, in Jenkins
>> plugin you developed you do not want to support the GitHub PRs and you just
>> let be to go with TravisCI just like that? I do not think so!
> 
> 
> I want to add GitHub support to ASF Jenkins too, but PR verification should
> be layers. No harm in having one layer provided by Travis/Codeship/etc and
> the second layer by Jenkins.
> 
> The other point is even if I add PR support to the ASF Jenkins, it’s not
> going to be automatic build for non-committers (which is the group of PRs
> that need the CI feedback most, and with least delay... ie before they walk
> away) as we simply do not have throw-away infra for building PRs that could
> contain bitcoin miners triggered by a unit test, etc.
> 
> Now if infra wants to set up a dedicated “safe space” for untrusted PRs to
> be built... super... but until that happens, we’ll need something like
> Travis to take that risk for us.
> 
> 
>> T
>>
>>
>> On Fri, Jan 4, 2019 at 7:22 PM Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > +1 from me
>> >
>> > On Fri 4 Jan 2019 at 18:21, Enrico Olivelli  wrote:
>> >
>> > > Hi,
>> > > I would like to try out Travis on this small plugin:
>> > > https://github.com/apache/maven-scripting-plugin
>> > >
>> > > I have pushed a minimal configuration file
>> > > I need to ask to Infra, but I need approval from the community and
>> > PMCs...
>> > >
>> > > Can I proceed ?
>> > >
>> > > Enrico
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > > --
>> > Sent from my phone
>> >
>>
> -- 
> Sent from my phone
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Enable Travis on Maven Scripting Plugin

[Manfred Moser]

I agree with Tibor. I would rather not have to deal with two different CI 
systems...

Manfred

Tibor Digana wrote on 2019-01-04 14:00:

> @Stephen Connolly 
> After such a big investment, especially made on your side, in Jenkins
> plugin you developed you do not want to support the GitHub PRs and you just
> let be to go with TravisCI just like that? I do not think so!
> T
> 
> 
> On Fri, Jan 4, 2019 at 7:22 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>> +1 from me
>>
>> On Fri 4 Jan 2019 at 18:21, Enrico Olivelli  wrote:
>>
>> > Hi,
>> > I would like to try out Travis on this small plugin:
>> > https://github.com/apache/maven-scripting-plugin
>> >
>> > I have pushed a minimal configuration file
>> > I need to ask to Infra, but I need approval from the community and
>> PMCs...
>> >
>> > Can I proceed ?
>> >
>> > Enrico
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> > --
>> Sent from my phone
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven 3.6.0

[Manfred Moser]

Used it every day since this email for a bunch of different projects of varying 
complexity and everything is working fine.

+1

Manfred

Karl Heinz Marbaise wrote on 2018-10-24 12:50:

> Hi,
> 
> We have solved 26 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12338966
> 
> There are issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1459
> 
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/
> 
> Specifically the zip, tarball and source archives can be found here:
> 
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.tar.gz
> 
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.tar.gz
> 
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.4
> 
> Source release checksum(s):
> apache-maven-3.6.0-src.tar.gz
> 
>   sha1: 255d8057b7f014222e96137001d4f4aa05d4a7cb
> sha512: 
> 5b4b5ca569d5476f9d6a2b8080927f58da9ca10a04c593df3d8c012e60fdcf7dcf70c4bc5db0d068b3a36785ede62a55fd1778b22ecadcf787485681ddc758a8
> 
> apache-maven-3.6.0-src.zip:
> 
>   sha1: 6149f259489acf36e2c04ec0dd713f99336b3346
> sha512: 
> c5794a6723d8d0fc8ff447b42e5a8c13524a44f8508a305d463f811c8039c7e9166d709077c8373d3cf980ce24feaebb2431cb50fb274933ab3bc2a90355
> 
> Git tag:
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=97c98ec64a1fdfee7767ce5ffb20918da4f719f3
> 
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven 3.5.4

[Manfred Moser]

Tried on a bunch of small to largish projects. All good 

+1


Stephen Connolly wrote on 2018-06-17 13:44:

> Hi,
> 
> We solved 16 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342826=Text=12316922
> 
> There are 356 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1438/
> 
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-1438/org/apache/maven/apache-maven/3.5.4/
> 
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1438/org/apache/maven/apache-maven/3.5.4/apache-maven-3.5.4-bin.zip
> https://repository.apache.org/content/repositories/maven-1438/org/apache/maven/apache-maven/3.5.4/apache-maven-3.5.4-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1438/org/apache/maven/apache-maven/3.5.4/apache-maven-3.5.4-src.zip
> https://repository.apache.org/content/repositories/maven-1438/org/apache/maven/apache-maven/3.5.4/apache-maven-3.5.4-src.tar.gz
> 
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.4
> 
> Source release checksum(s):
> apache-maven-3.5.4-src.tar.gz sha1:
> 04aefb9462af8cf7ca93808cd246f4c28b8ae4a1 sha256:
> f3ba1f1b24bbd4c345174ac616d40e26e72dad6022d56317d3ff6f7dd003e2f5
> apache-maven-3.5.4-src.zip: sha1: 1ee9850a046860d71267a043a29e0aa9acc13bcd
> sha256: ddcddecc8048d24edd3fa98fe50ae7f6a753389367d24593bf39e37427f643f5
> 
> Git tag:
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=1edded0938998edf8bf061f1ceb3cfdeccf443fe
> 
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Stephen.
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Welcome Christian Stein to the Apache Maven Team

[Manfred Moser]

Great to have you on the team Christian. Looking forward to see your 
contributions. 

Manfred

Robert Scholte wrote on 2018-05-07 15:01:

> Hi,
> 
> On behalf of the Apache Maven PMC I am pleased to announce that Christian  
> Stein (sor) has been voted in as a new Apache Maven committer.
> 
> Christian, welcome on board and have a lot of fun!
> 
> thanks,
> Robert
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven 3.5.3

[Manfred Moser]

agreed

+1 again ;-)

Olivier Lamy wrote on 2018-03-02 18:14:

> +1 to release as is
> 
> On 3 March 2018 at 05:55,  wrote:
> 
>> the issue is a multi-threading issue on Windows Jansi, then this affects
>> people on Windows who try to use parallel build.
>>
>> I can commit on Jansi but not do a release: I can see this if a quick
>> 1.17.1 is feasible...
>>
>> Regards,
>>
>> Hervé
>>
>> - Mail original -
>> De: "Stephen Connolly" 
>> À: "Maven Developers List" 
>> Envoyé: Vendredi 2 Mars 2018 09:12:09
>> Objet: Re: [VOTE] Release Apache Maven 3.5.3
>>
>> On Fri 2 Mar 2018 at 07:57, Sylwester Lachiewicz 
>> wrote:
>>
>> > Hi,
>> > yes i was able to reproduce both errors (Dan and Guillaume) and fixes are
>> > commited to JAnsi.
>> > If someone one to retest - please build JAnsi from master.
>> >
>> > Fix #107 also shoud help with reseting colors after Ctrl-C.
>> >
>> > https://github.com/fusesource/jansi/issues/110
>> > https://github.com/fusesource/jansi/issues/107
>> >
>>
>> @Hervé wdyt should we release as is and we can 3.5.4 when jansi has a new
>> release or shall we drop, wait and respin?
>>
>>
>> > Regards,
>> > Sylwester
>> >
>> > czw., 1 mar 2018 o 19:45 użytkownik Dan Tran 
>> napisał:
>> >
>> > > Hi all
>> > >
>> > > Sylwester Lachiewicz provided a fix for jansi 1.18-SNAPSHOT  which
>> > resolves
>> > > my issue.  I am not able to reproduce antrun issue
>> > >
>> > >
>> > > -Dan
>> > >
>> > > On Thu, Mar 1, 2018 at 5:00 AM, Stephane Nicoll <
>> > stephane.nic...@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > +1
>> > > >
>> > > > Thanks,
>> > > > S.
>> > > >
>> > > > On Sat, Feb 24, 2018 at 11:01 PM, Stephen Connolly <
>> > > > stephen.alan.conno...@gmail.com> wrote:
>> > > >
>> > > > > On 24 February 2018 at 22:00, Stephen Connolly <
>> > > > > stephen.alan.conno...@gmail.com> wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > We solved 22 issues:
>> > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > > > > > version=12341428=Text=12316922
>> > > > > >
>> > > > > > There are 381 issues left in JIRA for Maven core:
>> > > > > > https://issues.apache.org/jira/issues/?jql=project%20%
>> > > > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>> > > > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>> > > > > >
>> > > > > > Staging repo:
>> > > > > > https://repository.apache.org/content/repositories/maven-1401/
>> > > > > >
>> > > > > > The distributable binaries and sources can be found here:
>> > > > > > https://repository.apache.org/content/repositories/maven-
>> > > > > > 1401/org/apache/maven/apache-maven/3.5.3/
>> > > > > >
>> > > > > > Specifically the zip, tarball and source archives can be found
>> > here:
>> > > > > > https://repository.apache.org/content/repositories/maven-
>> > > > > > 1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.
>> 3-bin.zip
>> > > > > > https://repository.apache.org/content/repositories/maven-
>> > > > > >
>> > > 1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-bin.tar.gz
>> > > > > > https://repository.apache.org/content/repositories/maven-
>> > > > > > 1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.
>> 3-src.zip
>> > > > > > https://repository.apache.org/content/repositories/maven-
>> > > > > >
>> > > 1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-src.tar.gz
>> > > > > >
>> > > > > > The release artifacts are staged for distribution in:
>> > > > > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.3
>> > > > > >
>> > > > > > Source release checksum(s):
>> > > > > > apache-maven-3.5.3-src.tar.gz sha1:
>> 60905d8b8b025b091f456ec25ad60d
>> > > > > da56c26ad5
>> > > > > > sha256:
>> > 471748340cdc7f78b0b0c7bdf9e5399738e6721c08e166f59ef400f1dd10
>> > > > 7e19
>> > > > > > apache-maven-3.5.3-src.zip: sha1: a9be51d571165261dfb2e0c8ecc6b4
>> > > > > f1c4c96766
>> > > > > > sha256:
>> > 109ac07fa337e582b8e6741f179e9f09166cae0fc9b3f44d4a35a2a2c7cc
>> > > > bd57
>> > > > > >
>> > > > > > Git tag:
>> > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>> > > > > > 3383c37e1f9e9b3bc3df5050c29c8aff9f295297
>> > > > > >
>> > > > > > Staging site:
>> > > > > > https://maven.apache.org/components/ref/3-LATEST/
>> > > > > >
>> > > > > > Vote open for 72 hours.
>> > > > > >
>> > > > > > [ ] +1
>> > > > > > [ ] +0
>> > > > > > [ ] -1
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > > > Stephen.
>> > > > > >
>> > > > >
>> > > > >
>> > > > > $ sra https://repository.apache.org/content/repositories/maven-
>> 1401
>> > > > 3.5.3
>> > > > > Analyzer...
>> > > > >
>> > > > > stagingUrl:
>> > https://repository.apache.org/content/repositories/maven-
>> > > > 1401
>> > > > > groupId: org.apache.maven
>> > > > > artifactId: apache-maven
>> > > > > version: 3.5.3
>> > > > >
>> > > > > Source ZIP url exists.
>> > > > > 

Re: [VOTE] Release Apache Maven 3.5.3

[Manfred Moser]

Used on a bunch of project for a couple of days now without problems. 

+1

Manfred

Stephen Connolly wrote on 2018-02-24 16:00:

> Hi,
> 
> We solved 22 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341428=Text=12316922
> 
> There are 381 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1401/
> 
> The distributable binaries and sources can be found here:
> https://repository.apache.org/content/repositories/maven-1401/org/apache/maven/apache-maven/3.5.3/
> 
> Specifically the zip, tarball and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-bin.zip
> https://repository.apache.org/content/repositories/maven-1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-src.zip
> https://repository.apache.org/content/repositories/maven-1401/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-src.tar.gz
> 
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.3
> 
> Source release checksum(s):
> apache-maven-3.5.3-src.tar.gz sha1:
> 60905d8b8b025b091f456ec25ad60dda56c26ad5
> sha256: 471748340cdc7f78b0b0c7bdf9e5399738e6721c08e166f59ef400f1dd107e19
> apache-maven-3.5.3-src.zip: sha1: a9be51d571165261dfb2e0c8ecc6b4f1c4c96766
> sha256: 109ac07fa337e582b8e6741f179e9f09166cae0fc9b3f44d4a35a2a2c7ccbd57
> 
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=3383c37e1f9e9b3bc3df5050c29c8aff9f295297
> 
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Stephen.
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: seconders for Maven 3.5.x

[Manfred Moser]

Seconding with 

+2 

;-) 


Olivier Lamy wrote on 2018-02-07 17:18:

> +1
> 
> On 8 February 2018 at 00:09, Hervé BOUTEMY  wrote:
> 
>> Hi,
>>
>> I need seconders for:
>>
>> http://git-wip-us.apache.org/repos/asf/maven/commit/7fed4792
>> [MNG-5992] Upgrade default version of maven-release-plugin to 2.5.3
>> avoids exposing Git password during release
>> https://issues.apache.org/jira/browse/MNG-5992
>>
>> Anybody?
>>
>> Regards,
>>
>> Hervé
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 
> 
> -- 
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plan for releasing Maven core

[Manfred Moser]

As a team we are not actively maintaining a presence on Facebook or G+ as far 
as I know so I vote for removing them... 

Manfred

Hervé BOUTEMY wrote on 2018-01-31 09:40:

> I must confess that I don't understand G+ nor Facebook buttons result
> 
> any reason not to remove them?
> 
> Regards,
> 
> Hervé
> 
> Le mercredi 31 janvier 2018, 10:07:06 CET Stephen Connolly a écrit :
>> I like the twitter one, it's not too obtrusive. The facebook one looks
>> "meh" and the G+ is similar, i.e. I do not know what the call to action is
>> (what am I liking)... but "Follow @ASFMavenProject" is clear (once you see
>> it)
>> 
>> Perhaps that is an expected thing for the facebook and G+ networks and
>> explains why I do not engage strongly with them. I know what I am doing
>> when I "Follow @ASFMavenProject"... but are the Facebook and G+ buttons
>> liking some group on those networks or publishing a link to this page?
>> 
>> On 31 January 2018 at 06:06, Hervé BOUTEMY  wrote:
>> > thank you Andreas: this was exactly the type of feedback I needed
>> > 
>> > upgrade done: now need to have a look at maven-checkstyle-plugin
>> > 
>> > I also added Twitter and Facebook buttons to the G+ as test: you can see
>> > the
>> > result on the LATEST page [1]
>> > feedback welcome: keep or remove some from parent POM?
>> > 
>> > Regards,
>> > 
>> > Hervé
>> > 
>> > [1] http://maven.apache.org/pom-archives/maven-LATEST/
>> > 
>> > Le mardi 30 janvier 2018, 09:16:55 CET Andreas Dangel a écrit :
>> > > Since yesterday, m-pmd-p 3.9.0 is available - however, this includes a
>> > > major upgrade of PMD to 6.0.1. While all custom rulesets keep working,
>> > > the users will see a couple of deprecation warnings (the rules have been
>> > > reorganized).
>> > > 
>> > > I'd recommend to upgrade m-pmd-p from 3.7 -> 3.8 only.
>> > > 
>> > > Regards,
>> > > 
>> > > Andreas
>> > > 
>> > > Am 30.01.2018 um 07:29 schrieb Hervé BOUTEMY:
>> > > > there are 2 additional plugins updates available:
>> > > > [INFO]   maven-checkstyle-plugin . 2.17 ->
>> > > > 3.0.0 [INFO]   maven-pmd-plugin ..
>> > 
>> > .
>> > 
>> > > > 3.7 -> 3.8
>> > > > 
>> > > > do we upgrade or not? and is this only changing the version, or does
>> > > > it
>> > > > require more config (IIRC, m-checkstyle-p has some big changes in
>> > 
>> > 3.0.0)
>> > 
>> > > > This is the last question before Maven Parent 31 release
>> > > > 
>> > > > Regards,
>> > > > 
>> > > > Hervé
>> > > > 
>> > > > Le dimanche 28 janvier 2018, 10:46:06 CET Hervé BOUTEMY a écrit :
>> > > >> one little additional opportunity:
>> > > >> I'll launch maven-parent POM 31 soon, so perhaps update parents
>> > > >> before
>> > > >> releases. If not, please tell me and I'll upgrade Fuido skin to
>> > 
>> > version
>> > 
>> > > >> 1.7
>> > > >> with the edit button
>> > > >> 
>> > > >> BTW, if anybody wants to see something in Maven parent POM 31, it's
>> > 
>> > time
>> > 
>> > > >> to
>> > > >> do it
>> > > >> 
>> > > >> Regards,
>> > > >> 
>> > > >> Hervé
>> > > >> 
>> > > >> Le samedi 27 janvier 2018, 18:52:17 CET Stephen Connolly a écrit :
>> > > >>> Robert and I discussed on IRC...
>> > > >>> 
>> > > >>> Our plan is as follows:
>> > > >>> 
>> > > >>> 1. Fix https://issues.apache.org/jira/browse/MRESOLVER-38
>> > > >>> 2. Check status on git-wip to gitbox migration, if maven-resolver
>> > 
>> > will
>> > 
>> > > >>> be
>> > > >>> migrated during the vote, we will hold off releasing until after the
>> > > >>> migration (so that the release artifacts point to the gitbox
>> > 
>> > location)
>> > 
>> > > >>> 3. Release maven resolver
>> > > >>> 4. Upgrade Maven core
>> > > >>> 5. Check status on git-wip to gitbox migration for maven-core and
>> > > >>> maven-integration tests
>> > > >>> 6. Release.
>> > > >>> 
>> > > >>> I will be release manager for maven core, Robert will be release
>> > 
>> > manager
>> > 
>> > > >>> for resolver.
>> > > >>> 
>> > > >>> Share and enjoy
>> > > >>> 
>> > > >>> -Stephen
>> > > >> 
>> > > >> -
>> > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > >> For additional commands, e-mail: dev-h...@maven.apache.org
>> > > > 
>> > > > -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > > 
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > 
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
> 

Re: Plan for releasing Maven core

[Manfred Moser]

Sounds good. 

Robert Scholte wrote on 2018-01-27 11:51:

> Sure, I can release a 1.1.1 for the ant-tasks as well.
> 
> MRESOLVER-38 is a critical/blocking issue, you probably don't want to use  
> it, so my suggestions is to forget the 1.1.0 ant-tasks
> 
> thanks,
> Robert
> 
> On Sat, 27 Jan 2018 19:56:49 +0100, Manfred Moser  
> <manf...@simpligility.com> wrote:
> 
>> Awesome. On the resolver release can we make sure we release the ant  
>> task as well (maybe even the current version first since that has never  
>> been released yet..)
>>
>> Manfred
>>
>> Stephen Connolly wrote on 2018-01-27 09:52:
>>
>>> Robert and I discussed on IRC...
>>>
>>> Our plan is as follows:
>>>
>>> 1. Fix https://issues.apache.org/jira/browse/MRESOLVER-38
>>> 2. Check status on git-wip to gitbox migration, if maven-resolver will  
>>> be
>>> migrated during the vote, we will hold off releasing until after the
>>> migration (so that the release artifacts point to the gitbox location)
>>> 3. Release maven resolver
>>> 4. Upgrade Maven core
>>> 5. Check status on git-wip to gitbox migration for maven-core and
>>> maven-integration tests
>>> 6. Release.
>>>
>>> I will be release manager for maven core, Robert will be release manager
>>> for resolver.
>>>
>>> Share and enjoy
>>>
>>> -Stephen
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plan for releasing Maven core

[Manfred Moser]

Awesome. On the resolver release can we make sure we release the ant task as 
well (maybe even the current version first since that has never been released 
yet..)

Manfred

Stephen Connolly wrote on 2018-01-27 09:52:

> Robert and I discussed on IRC...
> 
> Our plan is as follows:
> 
> 1. Fix https://issues.apache.org/jira/browse/MRESOLVER-38
> 2. Check status on git-wip to gitbox migration, if maven-resolver will be
> migrated during the vote, we will hold off releasing until after the
> migration (so that the release artifacts point to the gitbox location)
> 3. Release maven resolver
> 4. Upgrade Maven core
> 5. Check status on git-wip to gitbox migration for maven-core and
> maven-integration tests
> 6. Release.
> 
> I will be release manager for maven core, Robert will be release manager
> for resolver.
> 
> Share and enjoy
> 
> -Stephen
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

All done on the ant-tasks migration now as well. 

Next would be a release of the ant-tasks for which I filed 
https://issues.apache.org/jira/browse/MRESOLVER-37

Imho we should do that but I don't know what is involved and wont be able to 
work on it until some time in January. 

manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Indexer 6.0.0

[Manfred Moser]

Awesome! +1 

Tamás Cservenák wrote on 2017-11-28 02:20:

> [VOTE] Release Maven Indexer 6.0.0
> 
> Hi,
> 
> We solved 25 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12330802
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MINDEXER/issues/MINDEXER-81?filter=allopenissues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1379
> https://repository.apache.org/service/local/repositories/maven-1379/content/org/apache/maven/indexer/maven-indexer/6.0.0/maven-indexer-6.0.0-source-release.zip
> 
> Source release checksum(s):
> maven-indexer-6.0.0-source-release.zip sha1:
> 279939f8deff0f5518364c06da847b32ab6108ed
> 
> Staging site:
> http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -- 
> Thanks,
> ~t~
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: beam leaving maven, anything doable?

[Manfred Moser]

Just my 2c as a long terms Maven user and committer.. 

People have been moving from one build tool the other for years. That includes 
to Gradle, to Maven and to all sorts of others stuff and back. If the Beam 
project thinks they will get significant improvements for their build times and 
they want to migrate.. let them. They will have to learn a whole bunch of 
different things and see some advantages as well as lot of disadvantages. 

>From my perspective the build time is NOT significantly faster with Gradle and 
>depends a LOT on what your build actually does. More importantly the 
>integration with IDEs and other tools is a lot worse in many aspects. 

As long as they can make sure that their binaries are published so that any 
user can easily consume them (e.a. they publish proper binaries and pom files 
to the Central Repository) I have no objection. 

Of course if they would step up and help us with Maven and make it better that 
would certainly be better than putting effort into migrating... but thats a 
different story.

And another one of course is that Gradle is open source project mostly 
sponsored by a single company and hence under a very different control compared 
to Maven.. 

Manfred

Romain Manni-Bucau wrote on 2017-11-27 13:43:

> Doesnt change anything significative - this is my setup.
> 
> Le 27 nov. 2017 22:01, "Igor Fedorenko"  a écrit :
> 
>> I wouldn't bother with Takari local repository, it's broken broken, see
>> [1] and [2]. Default Aether local repository impl is thread-safe enough,
>> at least when local repository is used from single-process
>> multi-threaded build.
>>
>> [1] https://github.com/takari/takari-local-repository/issues/4
>> [2] https://github.com/takari/takari-local-repository/issues/5
>>
>> --
>> Regards,
>> Igor
>>
>> On Mon, Nov 27, 2017, at 03:28 PM, Michael Osipov wrote:
>> > I really would like to see the same numbers with Takari Smart Builder
>> > and thread-safe local repo module.
>> >
>> > Am 2017-11-27 um 20:52 schrieb Romain Manni-Bucau:
>> > > Even doing it the difference is significative. The parallelism and
>> > > graph computation (linked to the local repo thread safety) is the main
>> > > drawback of maven it seems.
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>> > >
>> > >
>> > > 2017-11-27 20:47 GMT+01:00 Michael Osipov :
>> > >> Am 2017-11-27 um 20:24 schrieb Romain Manni-Bucau:
>> > >>>
>> > >>> Hi guys,
>> > >>>
>> > >>> anything doable on maven side (either tuning or code changes) to be
>> as
>> > >>> good as gradle on beam project. The project is goind to leave maven
>> as
>> > >>> build tool ([1]) and I think it is very bad for 1. the community and
>> > >>> 2. ASF as an ecosystem.
>> > >>>
>> > >>> [1]
>> > >>> https://lists.apache.org/thread.html/6d6f7ffc66622db1dd459e1704c3a5
>> d8a4bc29c2d9c0b60354fd3b6a@%3Cdev.beam.apache.org%3E
>> > >>
>> > >>
>> > >> Did they disable the build daemon? If not, it is not a fair
>> comparsion.
>> > >>
>> > >> Michael
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

All done on demos including cleanup and closing the issue.

For the ant tasks everything is ready in the new repo. If someone could set up 
the CI jenkins build that would be good.

Once we are happy I can delete the branch in the old repo.

And I think we also have to cut a release of the ant tasks. Not sure what it 
takes to do that.. the codebase seems ready from my point of view.. 

Manfred


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

Awesome ... setting up my github account and such now. In terms of pom.xml .. 
should the scm info just point to github then? 

Manfred

Hervé BOUTEMY wrote on 2017-11-25 14:00:

> ok, done: https://github.com/apache/maven-resolver-ant-tasks
> 
> Regards,
> 
> Hervé
> 
> Le samedi 25 novembre 2017, 22:07:12 CET Manfred Moser a écrit :
>> So .. I tried this now. Seems like something on gitbox is not configured
>> correctly for me because the Your PMCs drop down contains no entries apart
>> from Your PMCs.
>> 
>> Can someone either fix this for me or create maven-resolver-ant-tasks
>> repository? Then I can do the rest.
>> 
>> thx
>> 
>> manfred
>> 
>> Hervé BOUTEMY wrote on 2017-11-23 15:06:
>> > yes, that's GitBox self service [1], easy to use, just:
>> > 1. start by choosing your PMC before doing any other change (or you may
>> > create a "maven-maven-something.git" like I did)
>> > 2. change "GitHub notification list" to iss...@maven.apache.org
>> > 
>> > the only issue I see is the mix of Artifact Resolver on git-wip and
>> > Artifact Resolver Ant Tasks on gitbox: but one day, INFRA-15436 will
>> > probably be done
>> > 
>> > Regards,
>> > 
>> > Hervé
>> > 
>> > [1] https://gitbox.apache.org/
>> > 
>> > Le jeudi 23 novembre 2017, 19:27:06 CET Stephen Connolly a écrit :
>> >> Hervé might know... could be self-service on gitbox!
>> >> 
>> >> I have two repos to create after the Jenkins Server is upgraded on
>> >> Sunday,
>> >> so let me know the process
>> >> 
>> >> On Thu 23 Nov 2017 at 16:13, Manfred Moser <manf...@simpligility.com> 
> wrote:
>> >> > So how do I make this repo copy happen? An infra ticket or something
>> >> > like
>> >> > that?
>> >> > 
>> >> > Stephen Connolly wrote on 2017-11-22 23:53:
>> >> > > On Thu 23 Nov 2017 at 04:20, Manfred Moser <manf...@simpligility.com>
>> >> > 
>> >> > wrote:
>> >> > >> Status update and questions:
>> >> > >> 
>> >> > >> - demos are all now in master and part of the multi module build
>> >> > >> - no changes on the ant tasks for now
>> >> > >> 
>> >> > >> Questions:
>> >> > >> 
>> >> > >> 1. Can I delete the demos branch now or do we wait until next
>> >> > >> release?
>> >> > >> I
>> >> > >> would prefer to delete the branch and close the ticket to be honest.
>> >> > >> 
>> >> > >> 2. I like the idea of promoting the ant task from being hidden in
>> >> > >> the
>> >> > >> branch into their own repo. All we would have to do is to copy the
>> >> > 
>> >> > existing
>> >> > 
>> >> > >> repo somehow into a new repo in apache git. Then we can dDelete all
>> >> > >> the
>> >> > >> branches apart from the ant-task branch and make that the master.
>> >> > >> Done.
>> >> > 
>> >> > I
>> >> > 
>> >> > >> am happy to do that in terms of the branches and so on but how do I
>> >> > >> go
>> >> > >> about getting the repo copied into a new repo named
>> >> > >> maven-resolver-ant-tasks?
>> >> > > 
>> >> > > I like that solution too
>> >> > > 
>> >> > >> Thanks
>> >> > >> 
>> >> > >> Manfred
>> >> > >> 
>> >> > >> 
>> >> > >> -
>> >> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> > >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >> > >> 
>> >> > >> --
>> >> > > 
>> >> > > Sent from my phone
>> >> > 
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >> > 
>> >> > --
>> >> 
>> >> Sent from my phone
>> > 
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

So .. I tried this now. Seems like something on gitbox is not configured 
correctly for me because the Your PMCs drop down contains no entries apart from 
Your PMCs.

Can someone either fix this for me or create maven-resolver-ant-tasks 
repository? Then I can do the rest.

thx

manfred

Hervé BOUTEMY wrote on 2017-11-23 15:06:

> yes, that's GitBox self service [1], easy to use, just:
> 1. start by choosing your PMC before doing any other change (or you may 
> create 
> a "maven-maven-something.git" like I did)
> 2. change "GitHub notification list" to iss...@maven.apache.org
> 
> the only issue I see is the mix of Artifact Resolver on git-wip and Artifact 
> Resolver Ant Tasks on gitbox: but one day, INFRA-15436 will probably be done
> 
> Regards,
> 
> Hervé
> 
> [1] https://gitbox.apache.org/
> 
> Le jeudi 23 novembre 2017, 19:27:06 CET Stephen Connolly a écrit :
>> Hervé might know... could be self-service on gitbox!
>> 
>> I have two repos to create after the Jenkins Server is upgraded on Sunday,
>> so let me know the process
>> 
>> On Thu 23 Nov 2017 at 16:13, Manfred Moser <manf...@simpligility.com> wrote:
>> > So how do I make this repo copy happen? An infra ticket or something like
>> > that?
>> > 
>> > Stephen Connolly wrote on 2017-11-22 23:53:
>> > > On Thu 23 Nov 2017 at 04:20, Manfred Moser <manf...@simpligility.com>
>> > 
>> > wrote:
>> > >> Status update and questions:
>> > >> 
>> > >> - demos are all now in master and part of the multi module build
>> > >> - no changes on the ant tasks for now
>> > >> 
>> > >> Questions:
>> > >> 
>> > >> 1. Can I delete the demos branch now or do we wait until next release?
>> > >> I
>> > >> would prefer to delete the branch and close the ticket to be honest.
>> > >> 
>> > >> 2. I like the idea of promoting the ant task from being hidden in the
>> > >> branch into their own repo. All we would have to do is to copy the
>> > 
>> > existing
>> > 
>> > >> repo somehow into a new repo in apache git. Then we can dDelete all the
>> > >> branches apart from the ant-task branch and make that the master. Done.
>> > 
>> > I
>> > 
>> > >> am happy to do that in terms of the branches and so on but how do I go
>> > >> about getting the repo copied into a new repo named
>> > >> maven-resolver-ant-tasks?
>> > > 
>> > > I like that solution too
>> > > 
>> > >> Thanks
>> > >> 
>> > >> Manfred
>> > >> 
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > >> For additional commands, e-mail: dev-h...@maven.apache.org
>> > >> 
>> > >> --
>> > > 
>> > > Sent from my phone
>> > 
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> > 
>> > --
>> 
>> Sent from my phone
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

So how do I make this repo copy happen? An infra ticket or something like that? 

Stephen Connolly wrote on 2017-11-22 23:53:

> On Thu 23 Nov 2017 at 04:20, Manfred Moser <manf...@simpligility.com> wrote:
> 
>> Status update and questions:
>>
>> - demos are all now in master and part of the multi module build
>> - no changes on the ant tasks for now
>>
>> Questions:
>>
>> 1. Can I delete the demos branch now or do we wait until next release? I
>> would prefer to delete the branch and close the ticket to be honest.
>>
>> 2. I like the idea of promoting the ant task from being hidden in the
>> branch into their own repo. All we would have to do is to copy the existing
>> repo somehow into a new repo in apache git. Then we can dDelete all the
>> branches apart from the ant-task branch and make that the master. Done. I
>> am happy to do that in terms of the branches and so on but how do I go
>> about getting the repo copied into a new repo named
>> maven-resolver-ant-tasks?
> 
> 
> I like that solution too
> 
>>
>>
>> Thanks
>>
>> Manfred
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> --
> Sent from my phone
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

Status update and questions:

- demos are all now in master and part of the multi module build
- no changes on the ant tasks for now

Questions:

1. Can I delete the demos branch now or do we wait until next release? I would 
prefer to delete the branch and close the ticket to be honest. 

2. I like the idea of promoting the ant task from being hidden in the branch 
into their own repo. All we would have to do is to copy the existing repo 
somehow into a new repo in apache git. Then we can dDelete all the branches 
apart from the ant-task branch and make that the master. Done. I am happy to do 
that in terms of the branches and so on but how do I go about getting the repo 
copied into a new repo named maven-resolver-ant-tasks? 

Thanks

Manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

Hahah ... what a pain. Since so at this stage I think I will move the demos 
into the master and leave the ant tasks as they stand and 
close the relevant tickets with remarks that details this situation.

Manfred

Robert Scholte wrote on 2017-11-17 03:10:

> "We can solve any problem by introducing an extra level of indirection."  
> [1]
> 
> Looking at this new image[1] it is weird to me that ant-tasks has a direct  
> dependency on maven-resolver-provider. I would have expected some provider  
> abstraction where you can choose to use the maven-resolver-provider.
> 
> Merging it into one project is an interesting option, but I think the  
> maven-artifact-resolver is isolated enough to deserve its own project.
> 
> thanks,
> Robert
> 
> [1]  
> https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
> [2]  
> https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=blob_plain;f=src/site/resources/images/maven-resolver-deps.png;hb=f5439fde
> 
> On Thu, 16 Nov 2017 18:13:15 +0100, Manfred Moser  
> <manf...@simpligility.com> wrote:
> 
>> Thanks for the explanation and details Herve. Seems to be that to do  
>> this cleanly we have to break the circle. From my limited knowledge  
>> there are two ways to do that.
>>
>> 1. As stephen suggested.. get the resolver into maven core tree. That  
>> makes core bigger again and ties the two projects into one release  
>> cycle. Feasible but I am not a fan.
>>
>> 2. I am not sure if possible but .. could we get the maven resolver  
>> provider out of maven core and into the resolver project and have it all  
>> together in there?
>>
>> In either case .. both of those seem rather large tasks so I will  
>> definitely go ahead with demo branch merge first. I just have to redo  
>> the work I did without the ant tasks in the tree. Stay tuned on that..
>>
>> Manfred
>>
>> Hervé BOUTEMY wrote on 2017-11-16 05:49:
>>
>>> feasible, but I really don't like it: separation is good.
>>>
>>> seriously, just merge demos and let ant-tasks separate, and we have a  
>>> pretty
>>> good compromise on every aspect
>>> (or even drop ant tasks if really this is causing us too much  
>>> headache...)
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le jeudi 16 novembre 2017, 10:03:07 CET Stephen Connolly a écrit :
>>>> On Thu 16 Nov 2017 at 07:51, Hervé BOUTEMY <herve.bout...@free.fr>  
>>>> wrote:
>>>> > I just pushed an update of dependencies image that shows the external
>>>> > maven-
>>>> > resolver-provider (in yellow) inside the reactor dependency graph (in
>>>> > blue)
>>>> >
>>>> > That shows the chicken and egg issue on releasing we'll have on API
>>>> > breaking
>>>> > change. People always building from source (like Debian) will have  
>>>> the
>>>> > issue
>>>> > also.
>>>> >
>>>> > For demos, which are not really published during the release (just as
>>>> > documentation), disabling the module in the build when necessary is
>>>> > sufficient,
>>>> > won't change many things. For ant tasks, disabling the module will  
>>>> not
>>>> > publish
>>>> > the artifact: this will have a visible impact.
>>>>
>>>> Should we just bite the bullet and bring resolver in-tree as modules in
>>>> maven core... leaving demos and ant tasks here?
>>>>
>>>> > Regards,
>>>> >
>>>> > Hervé
>>>> >
>>>> > Le mercredi 15 novembre 2017, 23:05:14 CET Hervé BOUTEMY a écrit :
>>>> > > it seems I have not been clear: I'll try to explain better
>>>> > >
>>>> > > 1. maven-resolver-ant-tasks depends on maven-resolver-provider  
>>>> (from
>>>> >
>>>> > Maven
>>>> >
>>>> > > core)
>>>> > > 2. maven-resolver-provider (then Maven core) depends on  
>>>> maven-resolver
>>>> > >
>>>> > > if we put maven-resolver-ant-tasks in the same reactor than
>>>> >
>>>> > maven-resolver,
>>>> >
>>>> > > we can't release any maven-resolver API change that breaks
>>>> >
>>>> > maven-resolver-
>>>> >
>>>> > > provider
>>>> > >
>>>>

Re: Maven resolver branch consolidation

[Manfred Moser]

Thanks for the explanation and details Herve. Seems to be that to do this 
cleanly we have to break the circle. From my limited knowledge there are two 
ways to do that.

1. As stephen suggested.. get the resolver into maven core tree. That makes 
core bigger again and ties the two projects into one release cycle. Feasible 
but I am not a fan.

2. I am not sure if possible but .. could we get the maven resolver provider 
out of maven core and into the resolver project and have it all together in 
there?

In either case .. both of those seem rather large tasks so I will definitely go 
ahead with demo branch merge first. I just have to redo the work I did without 
the ant tasks in the tree. Stay tuned on that.. 

Manfred

Hervé BOUTEMY wrote on 2017-11-16 05:49:

> feasible, but I really don't like it: separation is good.
> 
> seriously, just merge demos and let ant-tasks separate, and we have a pretty 
> good compromise on every aspect
> (or even drop ant tasks if really this is causing us too much headache...)
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 16 novembre 2017, 10:03:07 CET Stephen Connolly a écrit :
>> On Thu 16 Nov 2017 at 07:51, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>> > I just pushed an update of dependencies image that shows the external
>> > maven-
>> > resolver-provider (in yellow) inside the reactor dependency graph (in
>> > blue)
>> > 
>> > That shows the chicken and egg issue on releasing we'll have on API
>> > breaking
>> > change. People always building from source (like Debian) will have the
>> > issue
>> > also.
>> > 
>> > For demos, which are not really published during the release (just as
>> > documentation), disabling the module in the build when necessary is
>> > sufficient,
>> > won't change many things. For ant tasks, disabling the module will not
>> > publish
>> > the artifact: this will have a visible impact.
>> 
>> Should we just bite the bullet and bring resolver in-tree as modules in
>> maven core... leaving demos and ant tasks here?
>> 
>> > Regards,
>> > 
>> > Hervé
>> > 
>> > Le mercredi 15 novembre 2017, 23:05:14 CET Hervé BOUTEMY a écrit :
>> > > it seems I have not been clear: I'll try to explain better
>> > > 
>> > > 1. maven-resolver-ant-tasks depends on maven-resolver-provider (from
>> > 
>> > Maven
>> > 
>> > > core)
>> > > 2. maven-resolver-provider (then Maven core) depends on maven-resolver
>> > > 
>> > > if we put maven-resolver-ant-tasks in the same reactor than
>> > 
>> > maven-resolver,
>> > 
>> > > we can't release any maven-resolver API change that breaks
>> > 
>> > maven-resolver-
>> > 
>> > > provider
>> > > 
>> > > example: if we move maven-resolver code to org.apache.maven java package
>> > 
>> > in
>> > 
>> > > maven-resolver 2.0.0-SNAPSHOT, we need maven-resolver-provider
>> > > 4.0.0-SNAPSHOT that uses maven-resolver 2.0.0-SNAPSHOT with this new
>> > > java
>> > > package. Then try to release anything: you can't, unless you don't try
>> > > to
>> > > release maven- resolver-ant-tasks
>> > > 
>> > > (the consequence on version consistency is another way to describe the
>> > > issue, but that is more subtle, then I chose to describe the most
>> > > visible
>> > > issue, with API breaking change)
>> > > 
>> > > IMHO, another consequence could be: maven-resolver-ant-tasks would
>> > 
>> > perhaps
>> > 
>> > > better be versionned like maven-resolver-provider
>> > > 
>> > > 
>> > > Merging resolver-demos is really the great big idea: with that merge,
>> > > modifying maven-rresolver can immediately be tested with demos: that'll
>> > 
>> > be
>> > 
>> > > so much easier to make changes to maven-resolver code!
>> > > 
>> > > Regards,
>> > > 
>> > > Hervé
>> > > 
>> > > Le mercredi 15 novembre 2017, 09:02:12 CET Michael Osipov a écrit :
>> > > > Why -1 on the Ant tasks?
>> > > > 
>> > > > Am 2017-11-15 um 00:50 schrieb Hervé BOUTEMY:
>> > > > > I answered on the mailing list and on the 2 Jira issues
>> > > > > In summary, +1 to merge demos, -1 to merge ant-tasks
>> > > > > 
>> > &

Re: Maven resolver branch consolidation

[Manfred Moser]

Sorry herve. For some reason I totally missed those. I commented on the issues. 

In summary I would like to get the ant-tasks merged as well since that makes a 
lot more sense to me than keeping it separate. 

Manfred

Hervé BOUTEMY wrote on 2017-11-14 15:50:

> I answered on the mailing list and on the 2 Jira issues
> In summary, +1 to merge demos, -1 to merge ant-tasks
> 
> Regards,
> 
> Hervé
> 
> Le mardi 14 novembre 2017, 18:19:40 CET Manfred Moser a écrit :
>> Any feedback or should I just go ahead with the cleanup?
>> 
>> Manfred
>> 
>> Manfred Moser wrote on 2017-11-08 21:35:
>> > Hi all,
>> > 
>> > I have started and made good progress on getting Maven resolver all into
>> > the master branch instead of having master, demos and ant-tasks in
>> > separate branches.
>> > 
>> > Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28
>> > 
>> > All of it is now in a new branch called master-all for you to see.
>> > 
>> > I am now wondering what the next steps are. I added what I think should
>> > happen next in the issue in a comment and would appreciate any input on
>> > the current setup and next steps.
>> > 
>> > Any help would be appreciated.
>> > 
>> > manfred
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven resolver branch consolidation

[Manfred Moser]

Any feedback or should I just go ahead with the cleanup?

Manfred

Manfred Moser wrote on 2017-11-08 21:35:

> Hi all,
> 
> I have started and made good progress on getting Maven resolver all into the
> master branch instead of having master, demos and ant-tasks in separate
> branches.
> 
> Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28
> 
> All of it is now in a new branch called master-all for you to see.
> 
> I am now wondering what the next steps are. I added what I think should happen
> next in the issue in a comment and would appreciate any input on the current
> setup and next steps. 
> 
> Any help would be appreciated.
> 
> manfred


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven resolver branch consolidation

[Manfred Moser]

Hi all,

I have started and made good progress on getting Maven resolver all into the 
master branch instead of having master, demos and ant-tasks in separate 
branches.

Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28

All of it is now in a new branch called master-all for you to see.

I am now wondering what the next steps are. I added what I think should happen 
next in the issue in a comment and would appreciate any input on the current 
setup and next steps. 

Any help would be appreciated.

manfred





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Docker Images

[Manfred Moser]

Following up on that remark and my earlier remark that we should NOT make this 
official .. here are my remarks:

- so far the only binaries we assemble and call official are the tar.gz and zip 
archives (and even that is a gray line since official there are only sources 
from Apache)
- we do NOT support (by calling them official) any other binaries such as
  - linux distro versions
  - osx package versions (brews, ports)
  - windows packages
  - sdkman
  - and many others
- the complexity of the docker images is greater than any of the above since it 
includes those factors.. 

Here are a few issues why I would object to this being the official images

- only openjdk and ibm java, no oracle java, no others such as Zulu or whatever
- limited os selection (only alpine and debian and windows from what I can 
tell), no centos, no ubuntu
- binaries are download from a mirror rather than the actual apache servers 
(alternatively maybe could use Central)

These above factors imho show that there is a selection that has been made and 
I do not think we as the Apache Maven project should make this selection.

As such I would suggest to keep it as is. 

An open source project from an individual that provides Maven binaries on 
Docker images. Just happens to be the case that the same person is also a Maven 
PMC (great btw!).

If we make this part of the officially supplied binaries we could also think 
about

- making binaries for various Linux distros in the first place (then we wouldnt 
even need docker images since it could be a one line to install an official 
Maven distro on them)
- supplying binaries to SDKMan, ports, brew, chocolatey and so on
- pull all mojohaus plugins into Apache (they are mostly the same committers..)
- pull other Maven projects in as desired 

You see where this leads... a LOT of work. In my opinion as the Apache Maven 
project we should focus on just that. Maven itself, our current plugins and 
related projects. We all know thats already more work than we can reasonably 
shoulder.. I see no reason to add more.

Manfred



Carlos Sanchez wrote on 2017-10-21 03:59:

> BTW there are possibly more than one image build for each maven version.
> For a variety of reasons, like security issues in OS or to upgrade JDK or
> because docker rebuilds it, so it is not feasible to vote each of them.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Docker Images

[Manfred Moser]

>From my perspective it is just like sdkman including the conclusion. We have 
>other tasks at our hands, maintaining a docker images is not something we 
>should bother with. However needs one can easily create one and there will be 
>thousands of variations different users want. 

Let them create it on their own.

Manfred

Hervé BOUTEMY wrote on 2017-10-20 18:46:

> true, from a general perspective, it's like sdkman
> 
> we need to discuss then decide if we want to maintain Maven Docker 
> integration 
> (contrary to our current decision to not maintain Maven sdkman integration 
> but 
> let sdkman community do it)
> 
> can we think about a general solution? perhaps not really a solution, but a 
> decision process, yes
> 
> to me, on each tool integration, there are key decision drivers:
> - importance of the tool on the market
> - interest of Maven devs to actually do integration maintenance
> - complexity of integration, technical prerequisites (with IDEs, for example, 
> a dedicated independant project like m2e is necessary)
> - time factor: things evolve over time (e.g. 2 years ago, Docker was not what 
> it is nowadays)
> 
> any other key driver to document?
> 
> once done, we'll discuss more precisely about the Docker integration case
> 
> and probably finish with a vote :)
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 20 octobre 2017, 11:30:49 CEST Robert Scholte a écrit :
>> Isn't this actually the same case as sdkman[1]?
>> Just wondering if we need to think about a general solution instead of
>> pulling everything into our project when possible.
>> 
>> thanks,
>> Robert
>> 
>> [1] http://markmail.org/message/oofvszmf56tbr7et
>> 
>> On Thu, 19 Oct 2017 19:30:57 +0200, Hervé BOUTEMY <herve.bout...@free.fr>
>> 
>> wrote:
>> > great idea
>> > 
>> > ok, we need a git repo at ASF
>> > 
>> > what else?
>> > Is there some sort of release process? some sort of source to release?
>> > 
>> > Regards,
>> > 
>> > Hervé
>> > 
>> > Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit :
>> >> Thanks for the pointer, Carlos! I had searched the archives, but maybe I
>> >> didn't go back far enough.
>> >> 
>> >> I think moving these Dockerfiles into an ASF repo would be great for
>> >> their
>> >> maintainability.
>> >> 
>> >> Thanks,
>> >> 
>> >> Mike
>> >> 
>> >> On 2017-10-19 03:50, Carlos Sanchez <c...@apache.org> wrote:
>> >> > Arnaud is correct, I sent an email to users@ back on Fri, Nov 7,
>> >> 
>> >> 2014,>
>> >> 
>> >> > 00:23 when I created the image>
>> >> > 
>> >> > 
>> >> > On Thu, Oct 19, 2017, 11:12 Arnaud H�ritier <ah...@gmail.com> wrote:>
>> >> > 
>> >> > > These images are kindly managed by a PMC member of our project
>> >> 
>> >> (Carlos)
>> >> 
>> >> but>
>> >> 
>> >> > > yes they aren't managed directly by the project>
>> >> > > 
>> >> > > We can easily see with him to improve this IMO.>
>> >> > > 
>> >> > > When he started that (several years ago) Docker wasn't what it is
>> >> 
>> >> nowadays.>
>> >> 
>> >> > > With docker being mainstream I agree that we can reconsider this.>
>> >> > > 
>> >> > > The docker image build/distribution could perhaps be part of our
>> >> 
>> >> release>
>> >> 
>> >> > > process.>
>> >> > > 
>> >> > > WDYT Carlos ?>
>> >> > > 
>> >> > > On Thu, Oct 19, 2017 at 4:16 AM, Mike Drob <md...@apache.org>
>> >> 
>> >> wrote:>
>> >> 
>> >> > > > I guess the natural follow-on question is whether the Maven
>> >> 
>> >> community>
>> >> 
>> >> > > > would consider publishing an official set of images? Or
>> >> 
>> >> alternatively>
>> >> 
>> >> > > > whether they should send a takedown notice to protect their brand
>> >> 
>> >> and>
>> >> 
>> >> > > > trademarks...>
>> >> > > > 
>> >> > > > On 2017-10-18 18:36, &q

Re: Maven Plugin that provides alternative repository

[Manfred Moser]

I think this would modify the overall Maven behaviour and you would therefore 
have to implement this as an extension rather than as a plugin. Fyi. we have 
such an extension that modifies usage of the local repository already within 
Takari.

Use it as inspiration.. 

https://github.com/takari/takari-local-repository

Manfred

Paul Hammant wrote on 2017-10-16 03:39:

>>
>> This should be possible by providing WorkspaceReader implementation -
>> @Component( role = WorkspaceReader.class, hint = "ide" )
>>
>> Note that Maven tries resolution from workspace *before* repositories -
>> workspace reader has priority lower than reactor, but higher than remote
>> repos known to Maven.
> 
> WorkspaceReader functionality is or is not a thing that can be set in
> pom.xml files?
> 
> Are there any examples in public that use WorkspaceReader in use to
> source a dep from outside of maven central (or the projects sibling
> modules)?
> 
> - Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven JMod Plugin version 3.0.0-alpha-1 (First Public Release)

[Manfred Moser]

+1 

Ship it. 

Karl Heinz Marbaise wrote on 2017-09-09 06:52:

> Hi,
> 
> this is the VOTE for the first public release for Maven JMod Plugin...
> 
> We solved 1 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321433=12341363
> 
> There are currently no issues left in JIRA.
> 
> If you have any issue to report please open an issue in JIRA
> https://issues.apache.org/jira/projects/MJMOD
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1361/
> 
> https://repository.apache.org/content/repositories/maven-1361/org/apache/maven/plugins/maven-jmod-plugin/3.0.0-alpha-1/maven-jmod-plugin-3.0.0-alpha-1-source-release.zip
> 
> Source release checksum(s):
> [NAME-OF]-source-release.zip sha1: 8002767f6cffc7bbbcf76a8e7f0c1799a42caf93
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-jmod-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Enforcer Plugin version 3.0.0-M1

[Manfred Moser]

Wow Karl! Very nice testing effort.

+1 from me (with less testing but still some ubuntu and osx based runs..) 

Manfred

Karl Heinz Marbaise wrote on 2017-07-28 14:44:

> Hi,
> 
> +1 from me.
> 
> 
> Tested with JDK 9+180 the following Maven versions:
>  o Maven 3.5.0, Maven 3.3.9, Maven 3.2.5, Maven 3.1.1, Maven 3.0.5
> 
> Tested with JDK 1.8.0_144 the following Maven versions:
>  o Maven 3.5.0, Maven 3.3.9, Maven 3.2.5, Maven 3.1.1, Maven 3.0.5
> Tested with JDK 1.8.0_131, Maven 3.5.0, Maven 3.3.9
> 
> Only got a warnings with JDK 9: Should be addressed for final 3.0.0...
> 
> Running org.apache.maven.plugins.enforcer.TestDefaultEnforcementRuleHelper
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.mockito.cglib.core.ReflectUtils$2 
> (file:/Users/kama/.m2/repository/org/mockito/mockito-core/1.9.5/mockito-core-1.9.5.jar)
> 
> to method 
> java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
> WARNING: Please consider reporting this to the maintainers of 
> org.mockito.cglib.core.ReflectUtils$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> 
> Second:
> [INFO] --- maven-invoker-plugin:2.0.0:run (integration-test) @ 
> maven-enforcer-plugin ---
> [INFO] Building: always-fail/pom.xml
> [INFO] ..SUCCESS (2.7 s)
> [INFO] Building: always-fail-warn/pom.xml
> [INFO] run script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.codehaus.groovy.reflection.CachedClass$3$1 
> (file:/Users/kama/.m2/repository/org/codehaus/groovy/groovy/2.0.1/groovy-2.0.1.jar)
> 
> to method java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of 
> org.codehaus.groovy.reflection.CachedClass$3$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [INFO] ..SUCCESS (3.0 s)
> 
> which is based on Maven Invoker Plugin 2.0.0 should be fine with Maven 
> Invoker Plugin 3.0.0...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 26/07/17 22:58, Robert Scholte wrote:
>> Hi,
>> 
>> We solved 14 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12330768=Text
>> 
>> 
>> 
>> There are still a couple of issues left in JIRA:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317520%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>> 
>> 
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1349
>> https://repository.apache.org/service/local/repositories/maven-1349/content/org/apache/maven/enforcer/enforcer/3.0.0-M1/enforcer-3.0.0-M1-source-release.zip
>> 
>> 
>> 
>> Source release checksum(s):
>> enforcer-3.0.0-M1-source-release.zip sha1: 
>> 20b6e4800bb6357a25db6da3bdacc45675b9b5c8
>> 
>> Staging site:
>> https://maven.apache.org/enforcer-archives/enforcer-LATEST/
>> 
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>> 
>> NOTE: this is a milestone release, because there are still some open 
>> issues which need to be fixed before the official 3.0.0.
>> This release is mainly there to provide a Java9 compatible plugin 
>> (previous versions fail the build).
>> 
>> Vote open for at least 72 hours.
>> 
>> [ ] +1
>> [ ] +0
>> [ ] -1
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> -- 
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen   http://www.soebes.de
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Resolver

[Manfred Moser]

Great.

https://issues.apache.org/jira/browse/MRESOLVER-28
https://issues.apache.org/jira/browse/MRESOLVER-29

Let me know if you want me to work on them.

Manfred

Michael Osipov wrote on 2017-07-19 14:44:

> Am 2017-07-19 um 23:39 schrieb Manfred Moser:
>> Hi all,
>>
>> I found out that maven-resolver has main codebase, demos and ant
>> tasks as separate branches in the same repository. Anybody know why
>> this is the case instead of having three separate repositories? I
>> must have missed that in the discussions about pulling Aether in..
>>
>> Related to that the demos and ant tasks still use 1.0.3 .. any
>> objections if I upgrade this to the latest 1.1.0 release?
>>
>> Or should we even look at pulling the two branches into master as
>> additional modules? Or separate them out into different repositories?
> 
> Hi Manfred,
> 
> this is simply a time issue. I wasn't able to make it into 1.1.0. I my 
> opinion, I see no reason to have it as three repos, but simply as 
> modules of the regular reactor. The burden two release two more 
> components is too huge which I won't do.
> You should simply file two JIRA issues to merge them into master as modules.
> 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven Resolver

[Manfred Moser]

Hi all,

I found out that maven-resolver has main codebase, demos and ant tasks as 
separate branches in the same repository. Anybody know why this is the case 
instead of having three separate repositories? I must have missed that in the 
discussions about pulling Aether in.. 

Related to that the demos and ant tasks still use 1.0.3 .. any objections if I 
upgrade this to the latest 1.1.0 release? 

Or should we even look at pulling the two branches into master as additional 
modules? Or separate them out into different repositories? 

manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven Resolver Provider, Repo Provisioner and 3.5.1

[Manfred Moser]

Hi all,

I moved my Maven Repository Provisioner to using Maven Resolver and 3.5.0 from 
Aether and 3.3.9 and have to say.. nice work on the migration. It essentially 
compiled after just changing a few dependencies!

I did run into an issue in the Maven Resolver Provider where a missing setter 
causes an NPE and found that Igor already fixed that in master.
Details are at https://github.com/simpligility/maven-repository-tools/pull/31

So now my questions is ... when is 3.5.1 planned for?

Manfred



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Resolver version 1.1.0

[Manfred Moser]

Excellent. Looking forward to using this. 

+1

manfred

Michael Osipov wrote on 2017-06-30 13:12:

> Hi,
> 
> We solved 15 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12339212
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1344/
> https://repository.apache.org/content/repositories/maven-1344/org/apache/maven/resolver/maven-resolver/1.1.0/maven-resolver-1.1.0-source-release.zip
> 
> Source release checksum(s):
> maven-resolver-1.1.0-source-release.zip sha1: 
> d36df9ee315cbd4b0016a04c1716b121160c9c11
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Anyone object if I release Maven Enforcer?

[Manfred Moser]

A release is always welcome ;-) 

+1

Stephen Connolly wrote on 2017-06-15 04:13:

> Jesse Glick needs this release for some downstream fixes in the Jenkins
> project.
> 
> If nobody objects I'll cut the release on Monday.
> 
> -Stephen
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: convert maven-resolver-provider to jsr330

[Manfred Moser]

Lgtm +1

Igor Fedorenko wrote on 2017-05-24 14:38:

> I'd like to ask for somebody to second my change described in
> [MNG-6233]. The change cleans up mixture of jsr330 and plexus
> annotations used in maven-resolver-provider, leaving only jsr330. The
> change is small and I believe safe, does not change any user-observable
> behaviour during normal maven build and all ITs pass.
> 
> [MNG-6233] https://issues.apache.org/jira/browse/MNG-6233
> 
> -- 
> Regards,
> Igor
> 
> PS: Unfortunately I already submitted the change to master (by bad,
> sorry about that) but will revert the change if I don't get +1s or get
> any -1s within usual 72h.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Manfred Moser]

If you would run Central on git like that in a centralized manner you would 
have to find someone that does that hosting for you and you would have to get 
buy in from the community to use that - both extremely hard or impossible.

And if you dont do that but instead go with the distributed system you end up 
with the registry model that I think just doesnt really work in the real world.

manfred

Paul Hammant wrote on 2017-05-17 13:39:

> Actually I'm proposing a predictable structure on 'central :
> 
> g...@central.maven.org:
> maven2/<group-name-with-slashes-for-dots.git
> 
> (one minor fix versus previous description of the git:// location)
> 
> Or for the three separate variant:
> 
> g...@central.maven.org:
> maven2/<group-name-with-slashes-for-dots-classes.git
> g...@central.maven.org:
> maven2/<group-name-with-slashes-for-dots-javadocs.git
> g...@central.maven.org:
> maven2/<group-name-with-slashes-for-dots-sources.git
> 
> More likely though (as you mentioned in your opening line) is the way
> homebrew works - you point at repos elsewhere, but control poms/shas etc on
> 'central.
> 
> 
> 
> 
> On Wed, May 17, 2017 at 3:59 PM, Manfred Moser <manf...@simpligility.com>
> wrote:
> 
>> Having worked with repository managers and the implementation for various
>> formats on Nexus for years I think such a format is a bit like Bower. It is
>> a registry format that in turn points to git repositories that have the
>> content.
>>
>> From a corporate usage and implementation point of view this is a utter
>> nightmare since you would have to open up your systems to all those
>> different repositories and sites hosting them instead of just one.
>>
>> You also cant simply make a copy of the content or analyze it in the way
>> it manifests as binaries.
>>
>> I am not sure what you are looking for as benefits but from my point of
>> view this is maybe a fun experiment but not something that will ever take
>> off..
>>
>> Manfred
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Manfred Moser]

Having worked with repository managers and the implementation for various 
formats on Nexus for years I think such a format is a bit like Bower. It is a 
registry format that in turn points to git repositories that have the content.

>From a corporate usage and implementation point of view this is a utter 
>nightmare since you would have to open up your systems to all those different 
>repositories and sites hosting them instead of just one. 

You also cant simply make a copy of the content or analyze it in the way it 
manifests as binaries. 

I am not sure what you are looking for as benefits but from my point of view 
this is maybe a fun experiment but not something that will ever take off.. 

Manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: The maven-archetype-plugin paradox

[Manfred Moser]

I think you have done the right thing even if some users are not necessarily 
happy. The documentation about the new behavior is clear enough, but maybe it 
needs to be more explicit.

In either I would just keep the plugin at ASF and do minimal maintenance like 
you have been doing. If someone wants to step up and do more they can right 
here easily enough or via pull requests.

Donating the plugin does not really solve anything imho. If someone really 
wants to use the old setup they have many options (use old version, fork, help 
us). 

Reverting seems the wrong choice given that the new behavior is more in line 
with common Maven idioms.. 

In a nutshell.. dont fret. Keep up the good work ;-) 

Manfred

Robert Scholte wrote on 2017-05-08 10:38:

> So we have this plugin, which has been released lately as requested by the  
> community.
> It has been released as a 3.x, so it now requires Maven3 and with this  
> major release[1] we used this opportunity to break compatibility in case  
> there are parameters we don't want to use anymore.
> 
> One of the things changed is the usage of the reference to the archetype  
> repository. The original implementation was based on Maven2 and wasn't  
> using all security features as available in Maven3. This also made it hard  
> to maintain.
> So for example, now it is picking up the artifact repository manager by  
> default, it'll use its credentials when required, etc.
> By removing these parameters is should also be easier to use this plugin  
> (less parameters = less chance of mistakes)
> 
> So I think we made quite some people happy now that things are working  
> much more according to Maven default behavior. However, other have issues  
> to use the archetype. Sometimes it is because they are using deprecated  
> parameters (or use parameters which should have been removed as well),  
> others have a local setup which now requires to add the repository to  
> their settings.xml.
> 
> I still think that ARCHETYPE-439[2] is valid, so I'd prefer not to revert.  
> Instead I hope we can find a solution which will fit better for the most.
> 
> I can think of the following solutions:
> 1. Continue with taken decision and further improve usage without extra  
> parameters
> 2. Find somebody willing to maintain the plugin at ASF
> 3. Donate the plugin
> 4. Revert
> 
> #3 is a serious option, because it seems that within the team there's  
> nobody willing to maintain the plugin, probably due to other Maven  
> sub-projects which have a higher priority.
> 
> Any thoughts on this topic?
> 
> Robert
> 
> [1] http://semver.org/
> [2] https://issues.apache.org/jira/browse/ARCHETYPE-439
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org