Re: [VOTE] Release Apache Maven Wrapper 3.3.0

[James Gao]

pr of MWRAPPER-124  is
not ported to only-script type. see pr
https://github.com/apache/maven-wrapper/pull/133

On Thu, Apr 18, 2024 at 3:36 AM Tamás Cservenák  wrote:

> Howdy,
>
> We solved 21 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12352995
>
> 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-2093
>
> Source release checksum SHA512:
>
> 4c495321f25d7001ba76a0cb4fd207b59905c4fef9066df8ca6f37eb645a74e55234710222d46df297bfd6ca17138630778ffa27c026a23e4b1045e0e98d9a04
>
> 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
>

Re: Maven 3 API, backwards compatibility

[James Gao]

Hi, after following the discussion, i still have no idea how to maintain a
core-extension that needs to run on both maven 3 and 4. Could anyone plz
give some suggestions?

On Fri, Nov 18, 2022 at 4:20 PM Guillaume Nodet  wrote:

> Le mer. 16 nov. 2022, 10:20, Konrad Windszus  a écrit :
>
> > Hi,
> > Unfortunately Maven 3 didn’t define a proper API. In effect everything
> > somehow exposed through class loaders was considered API by
> > plugin/extension developers.
> > For Maven 4 a completely separate API was established in package
> > “org.apache.maven.api”, but what about the old packages used and exported
> > in Maven 3?
> >
> > For example in the context of
> > https://issues.apache.org/jira/browse/MNG-7588 <
> > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> > package “org.apache.maven.plugin.descriptor”.
> > We already figured out that this particular package (although not part of
> > the Maven 4 API) is used from both Maven Core as well as Maven Plugin
> > Tools, therefore this probably needs to stay backwards compatible.
> > What about others like
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> ?
> > <
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > ?>
> > This interface should IMHO never been implemented outside Maven Core but
> > in fact it was exposed to all plugins/extensions (via
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > <
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >).
> >
> > There are three options coming to my mind:
> >
> > 1. Deprecate the interfaces we don’t consider API and create new ones for
> > Maven 4 which are not exported!
> >
>
> I think that's the way to go.
> We'd also need to deprecate a bunch of jars and in maven-shared like
> m-artifact-transfer, maven-dependency-tree etc...
> One of the goal is also to completely hide the resolver.
>
> 2. Modify the existing interfaces in a backwards compatible way (but
> > somehow add a marker that they should not be implemented outside core)
> >
>
>
>
> 3. Modify the existing  interfaces in a backwards compatible way (but
> > somehow add a marker that they should not be implemented outside core)
> >
> > For all three options we somehow need to come up with a list of
> > classes/interfaces currently being exported through the API class loader,
> > which should be considered private and agree on an Annotation/Javadoc for
> > that (something like
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > <
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >
> > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >
> > WDYT?
> >
> > Konrad
> >
> >
>

Re: [VOTE] Release Apache Maven Wrapper version 3.1.1

[James Gao]

If mvnd always bundles a fixed version of Maven, from the wapper, maven
daemon could be seen as a maven distribution, and if detected, the `mvnd`
entry script is invoked instead of `mvn`.

On Mon, May 9, 2022 at 2:59 AM Hervé BOUTEMY  wrote:

> currently mvnd does not support variable Maven versions
> then having wrapper for mvnd does not yet make sense
>
> Le dimanche 8 mai 2022, 14:12:31 CEST Slawomir Jaranowski a écrit :
> > HI
> > Delany what kind of integration do you think ...? Is there an issue
> created
> > for it?
> >
> > niedz., 8 maj 2022 o 11:49 Delany 
> napisał(a):
> > > Hi. Is there integration between the wrapper and the upcoming mvnd?
> > >
> > > Thanks,
> > > Delany
> > >
> > > On Sun, 8 May 2022 at 11:29, Hervé BOUTEMY 
> wrote:
> > > > Hi,
> > >
> > > > We solved 14 issues:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350929
> > > yleName=Text=12323721>
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1750/
> > >
> > >
> https://repository.apache.org/content/repositories/maven-1750/org/apache/m
> > >
> aven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1-source-release.zip>
> > > > Source release checksum(s):
> > >
> > > > maven-wrapper-3.1.1-source-release.zip:
> > >
> b110aef3a123c5f1ab77669c53baee3b1a71471ad672af4812d39ef302234f64789edd89f7
> > > 0f20c169eb5d4cc45fb4a94a24f64f98adbf863d0e5013a762aea0>
> > > > 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: Maven Wrapper

[James Gao]

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.

Re: Maven Wrapper

[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
>

[MNG-6392] Add Project Settings .mvn/settings.xml

[James Gao]

Hi.

Here is a proposal to improve the maven settings model in order to make
projects management easier. We need some opinion and discussion on it. If
everything is OK, we will work on it.


1. new settings merge order:

   - project level (${maven.multiModuleProjectDirectory}/.mvn/settings.xml)
   - user level
   - global



2. ignored fields in project level settings:

   - localRepository
   - interactiveMode
   - offline
   - usePluginRegistry


3. Do not need a new cli option to specify another project settings.