[VOTE] Release Apache Maven Artifact Plugin version 3.2.0

[Hervé BOUTEMY]

Hi,

We solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322=12350180=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1674/
https://repository.apache.org/content/repositories/maven-1674/org/apache/maven/plugins/maven-artifact-plugin/3.2.0/maven-artifact-plugin-3.2.0-source-release.zip

Source release checksum(s):
maven-artifact-plugin-3.2.0-source-release.zip sha512: 
1929f907732a9f78b49b06a14829d9ab0c56c57377e5ee8c6f823d6df16765a11752d49079c7f4f9dede368dda65288e2f09bcf6e08d55279cdd328f2297

Staging site:
https://maven.apache.org/plugins-archives/maven-artifact-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




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

[GitHub] [maven-wrapper-plugin] hboutemy commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980639933


   the issue you have is only with SNAPSHOTs or maven-wrapper, that are 
obvioulsy not published to central
   But with releases, there won't be any problem for normal users using default
   
   during development with SNAPSHOT maven-wrapper, see last section of 
https://maven.apache.org/wrapper-archives/wrapper-LATEST/


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] hboutemy edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980641749


   but for sure, there is the question: what should be the default? current 
`script`or `bin` as it was in Takari?
   I kept the `script` default value that Robert chose previously, changing is 
easy, it's really just a choice to do


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] hboutemy commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980641749


   but for sure, there is the question: what should be the default? current 
`script`or `bin`?
   I kept the `script` default value that Robert chose previously, changing is 
easy, it's really just a choice to do


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Maven Code Style and imports layouts

[Hervé BOUTEMY]

no objection, PR merged

for enforcing, it can be a future enhancement if someone contributes

Regards,

Hervé

Le samedi 13 novembre 2021, 19:49:09 CET Romain Manni-Bucau a écrit :
> While enforced at mvn package +1 from me
> 
> Le sam. 13 nov. 2021 à 15:04, Hervé BOUTEMY  a
> 
> écrit :
> > I had a look at https://github.com/apache/maven-site/pull/269
> > 
> > seems reasonable: we'll just need to have someone implement the same for
> > Eclipse format
> > 
> > if nobody objects, I'll merge in 1 week
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 17 septembre 2021, 23:19:25 CET Slawomir Jaranowski a écrit :
> > > Hi,
> > > 
> > > We have described many rules about code style on Maven Code Style And
> > 
> > Code
> > 
> > > Conventions [1].
> > > 
> > > One item missing for me is how java imports should be ordered and
> > > groped.
> > > I can setup it in IDE and it is very useful to use code formatting with
> > > tools.
> > > I think that all propositions in this case will be ok - the most
> > 
> > important
> > 
> > > is to have one standard.
> > > At the end we can even use checkstyle to verify it ... [2]
> > > 
> > > So first proposition:
> > > 
> > > - import javax.*
> > > - import java.*
> > > 
> > > - blank line
> > > 
> > > - all other imports
> > > 
> > > - blank line
> > > 
> > > - import static all other imports
> > > 
> > > 
> > > [1] https://maven.apache.org/developers/conventions/code.html
> > > [2] https://checkstyle.sourceforge.io/config_imports.html#ImportOrder
> > 
> > -
> > 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: Different parent/child configuration without child located customization?

[Falko Modler]

Hi,

what also works in many cases is a profile with file activation, e.g. if there 
is src/main/kotlin add the kotlin plugin.
You can even use flagfiles to control this, which isn't pretty but sometimes it 
makes sense

Cheers,

Falko

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

Re: Different parent/child configuration without child located customization?

[Romain Manni-Bucau]

Hi

Just to answer to the 2 proposals:

1. Profiles dont work by design since they must be activated and have the
same issue that plugin flag
2. Tiles plugin is not bad and relates to the issue i mentionned about
custom lifecycles in an old thread but it is not really related to this
particular issue which is aligned on default jar lifecycle even if it
builds frontend in the example I gave (it is more a structure issue, look
at server example which does not need any custom lifecycle - just jar).
Also something light not requiring way more than maven knowledge is always
10 times saner - when possible - than a very custom build for sharing in
teams. Corporate custom lifecycles or autoconfig always fail after a few
months from my XP (people moving, new coming etc) so I tend to only use it
when I can justify it by a multi outputs - fullstack - module or alike.

Hope it makes sense.

Le sam. 27 nov. 2021 à 19:52, Frederik Boster 
a écrit :

> For frontend development with Maven I found it to be easiest to define a
> custom lifecycle for a custom artifact type / packaging, e.g.
> "angular-app", "angular-lib", "webpack-app" etc.
> This way it is possible to specify a build flow which is more appropriate
> for frontend development than the default lifecycle by specifying a
> sensible set of plugin executions such as the frontend-maven-plugin.
> The generated frontend artifact can then be used as dependency in other
> maven modules and be unpacked with the maven-dependency-plugin to the
> desired location.
>
> On a more general note: in my opinion maven-tiles [1] is more appropriate
> for this kind of scenarios by utilizing composition-over-inheritance.
>
> I usually combine both approaches to specify a generalized build flow for
> the frontend first with the custom lifecycle / artifact type and
> maven-tiles to make customizations to this build flow.
>
>
> [1] https://github.com/repaint-io/maven-tiles
>
>
> On Sat, Nov 27, 2021, 18:08 Falko Modler  wrote:
>
> > Hi,
> >
> > what also works in many cases is a profile with file activation, e.g. if
> > there is src/main/kotlin add the kotlin plugin.
> > You can even use flagfiles to control this, which isn't pretty but
> > sometimes it makes sense
> >
> > Cheers,
> >
> > Falko
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Different parent/child configuration without child located customization?

[Falko Modler]

Am 27.11.2021 um 20:25 schrieb Romain Manni-Bucau:

1. Profiles dont work by design since they must be activated and have the
same issue that plugin flag


In what I proposed the activation happens automatically via
... activation, so I don't get your point.

Sure, if you don't have a suitable file or directory in each child
module to use for the activation then this approach is not an option.

Artificial flagfiles can be an option when you want to activate a
profile only for a subset of child modules, but I wouldn't use this
approach unless there is no other option.

I can show you (working) examples for both in the Quarkus codebase.

Cheers,

Falko


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

[GitHub] [maven-wrapper-plugin] hboutemy commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980644191


   thinking at default type more in depth, I think that I now understand the 
logic
   = making `script` the default is not sufficient, because if 
`.mvn/wrapper/maven-wrapper.jar` or `*.jar` is not in `.gitignore`, the jar 
will inevitably come into future Git commit
   then the logic is to have `bin` by default when installing maven-wrapper, 
and the `.gitignore` configuration will trigger if the jar is stored or not 
(and if not stored, the consequence in network access)
   
   thinking like this, I now feel that yes, `bin` should be default...


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Different parent/child configuration without child located customization?

[Romain Manni-Bucau]

Hi Sławomir,

Ok, finally got the trick, it is a good one actually and even if a bit more
verbose than mine it is more "buit-in", thanks a lot and probleme solved!

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 26 nov. 2021 à 18:27, Slawomir Jaranowski 
a écrit :

> Hi
> It can be for both cases.
>
> You want to configure everything in parent pom - right?
> Some executions for all child only and some for parent only.
>
> So everything can be done in one place, like:
>
> 
> 
> 
> frontend-maven-plugin
> 
> 
> npm-build
> 
> npm
> 
> 
> 
> 
>
> 
> frontend-maven-plugin
> 
> 
> 
> false
> 
> npm-build
> none
> 
> 
> 
> false
> install-node-npm
> 
> install-node-and-npm
> 
> 
> 
> 
> 
>
>
>
> pt., 26 lis 2021 o 17:38 Romain Manni-Bucau 
> napisał(a):
>
> > Hi Sławomir,
> >
> > It solves the parent case but not the child one (the exact opposite). So
> i
> > can install node only in parent but i can't run npm install && npm run in
> > all children. Do I miss anything?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 26 nov. 2021 à 16:20, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > a écrit :
> >
> > > Hi,
> > >
> > > Try something like in parent pom
> > >
> > > 
> > > 
> > > 
> > > 
> > > maven-failsafe-plugin
> > > 3.0.0-M5
> > > 
> > > 
> > > test-id
> > > 
> > > integration-test
> > > verify
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > 
> > > 
> > > maven-failsafe-plugin
> > > 
> > > 
> > > false
> > > test-id
> > > none
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > In build/pluginManagement I have executions and also can have
> > > configuration.
> > >
> > > In build/plugins I bind execution to magic phase none with inherited
> set
> > to
> > > false, so plugin will not execute in parent pom only.
> > >
> > >
> > > pt., 26 lis 2021 o 15:21 Romain Manni-Bucau 
> > > napisał(a):
> > >
> > > > Hi all,
> > > >
> > > > I regularly hit an issue with plugin definition: it is not possible
> to
> > > > define the plugin for children in a parent.
> > > > Let me detail a concrete case: i want a parent module to define the
> > > plugins
> > > > for children modules but I don't want the parent to have these
> plugins.
> > > > A common solution is to skip=true in the parent and skip=false in
> > > children
> > > > but it requires N (number of children) undesired flag (vs 1 for the
> > > > parent).
> > > > An example is when I do an ui/ parent (pom packaging) i want to
> define
> > > "npm
> > > > install && npm run build" using frontend-maven-plugin for all
> children
> > > > (spa1, spa2 etc) but I don't want ui/ module itself to run npm since
> it
> > > > does not contain any module.
> > > >
> > > > Side note: it is the same if you do an images/ subhierarchy or
> servers/
> > > > subhierarchy.
> > > >
> > > > Indeed a trivial trick for the plugin would be to avoid pom packaging
> > but
> > > > the author rejected the PR doing that saying it is a tool feature
> not a
> > > > plugin feature - a bit the same argument that skip should be handled
> by
> > > > mojo executor and not each plugin.
> > > >
> > > > I did a quick extension workaround (
> > > > https://github.com/rmannibucau/hierarchy-extension) to enable to
> > > configure
> > > > the skip toggle the plugin luckily has from the parent and not
> redefine
> > > the
> > > > chain/toggle in all children but I think we would need to solve it
> more
> > > > cleanly at some 

[GitHub] [maven-site] hboutemy merged pull request #269: [MNGSITE-465] Java Code Convention - import layouts

[GitBox]

hboutemy merged pull request #269:
URL: https://github.com/apache/maven-site/pull/269


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[VOTE] Release Apache Maven Fuildo Skin version 1.10.0

[Hervé BOUTEMY]

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317926=12348442=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1673]/
https://repository.apache.org/content/repositories/maven-1673/org/apache/maven/skins/maven-fluido-skin/1.10.0/maven-fluido-skin-1.10.0-source-release.zip

Source release checksum(s):
maven-fluido-skin-1.10.0-source-release.zip sha512: 
316f60827fe663e699f8a8f26e693ef305daeb90b617d64b2964a6e495056f57d723b6c3c7828e5e65648829924d65cc63bb463667af272eff029a6fc162b958

Staging site:
https://maven.apache.org/skins-archives/maven-fluido-skin-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

[VOTE] Release Maven Doxia version 1.11

[Michael Osipov]

Hi,

We solved 10 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12350341

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1672/
https://repository.apache.org/content/repositories/maven-1672/org/apache/maven/doxia/doxia/1.11/doxia-1.11-source-release.zip

Source release checksum(s):
doxia-1.11-source-release.zip
sha512: 
1f1698d44ef3d26b8910a051762f3b0ad425cfe27ad9a9d2cf1d8f6c776336873d95b20d182b69daaa520db8665277b91e222a2b2205fad0ebffb488991b21f4


Staging site:
http://maven.apache.org/doxia/doxia-archives/doxia-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

[GitHub] [maven-wrapper-plugin] hboutemy edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980639933


   the issue you have is only with SNAPSHOTs of maven-wrapper, that are 
obviously not published to central
   But with releases, there won't be any problem for normal users using default
   
   during development with SNAPSHOT maven-wrapper, see last section of 
https://maven.apache.org/wrapper-archives/wrapper-LATEST/


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Different parent/child configuration without child located customization?

[Frederik Boster]

For frontend development with Maven I found it to be easiest to define a
custom lifecycle for a custom artifact type / packaging, e.g.
"angular-app", "angular-lib", "webpack-app" etc.
This way it is possible to specify a build flow which is more appropriate
for frontend development than the default lifecycle by specifying a
sensible set of plugin executions such as the frontend-maven-plugin.
The generated frontend artifact can then be used as dependency in other
maven modules and be unpacked with the maven-dependency-plugin to the
desired location.

On a more general note: in my opinion maven-tiles [1] is more appropriate
for this kind of scenarios by utilizing composition-over-inheritance.

I usually combine both approaches to specify a generalized build flow for
the frontend first with the custom lifecycle / artifact type and
maven-tiles to make customizations to this build flow.


[1] https://github.com/repaint-io/maven-tiles


On Sat, Nov 27, 2021, 18:08 Falko Modler  wrote:

> Hi,
>
> what also works in many cases is a profile with file activation, e.g. if
> there is src/main/kotlin add the kotlin plugin.
> You can even use flagfiles to control this, which isn't pretty but
> sometimes it makes sense
>
> Cheers,
>
> Falko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[GitHub] [maven-wrapper-plugin] slawekjaranowski commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

slawekjaranowski commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980598578


   @hboutemy great job.
   
   I've tested by:
   - build project - unit and IT test are executed, plugin and artifacts are 
installed
   - use in another project with some of released maven version ... looks ok
   
   In this point of time I'm not looking deeper in code, simple build and use. 
   
   I think that push this code to public repo and release this version as is - 
will be the best approach. 
   It opens a way. to testing by other users as well.
   
   Next improvement can be done in small, easy to review changes. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] slawekjaranowski edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

slawekjaranowski edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980598578


   @hboutemy great job.
   
   I've tested by:
   - build project - unit and IT test are executed, plugin and artifacts are 
installed
   - use in another project with some of released maven version ... looks ok
   
   In this point of time I'm not looking deeper in code, simple build and use. 
   
   I think that push this code to public repo and release this version as is - 
will be the best approach. 
   It opens a way to testing by other users as well.
   
   Next improvement can be done in small, easy to review changes. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] jvanzyl commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

jvanzyl commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980613922


   I run the following in the clone repository itself:
   
   ```
   mvn clean install
   mvn org.apache.maven.plugins:maven-wrapper-plugin:3.0.3-SNAPSHOT:wrapper
   ./mvnw clean install
   ```
   
   Which yields:
   
   ```
 % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
Dload  Upload   Total   SpentLeft  Speed
 0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
   curl: (22) The requested URL returned error: 404 
   Error: Could not find or load main class 
org.apache.maven.wrapper.MavenWrapperMain
   ```
   
   All I have in the `.mvn` directory is the following:
   
   ```
   bash-3.2$ tree .mvn
   .mvn
   └── wrapper
   └── maven-wrapper.properties
   
   ```
   
   @slawekjaranowski how did you test it?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] jvanzyl edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

jvanzyl edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980613922


   I run the following in the cloned repository itself:
   
   ```
   mvn clean install
   mvn org.apache.maven.plugins:maven-wrapper-plugin:3.0.3-SNAPSHOT:wrapper
   ./mvnw clean install
   ```
   
   Which yields:
   
   ```
 % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
Dload  Upload   Total   SpentLeft  Speed
 0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
   curl: (22) The requested URL returned error: 404 
   Error: Could not find or load main class 
org.apache.maven.wrapper.MavenWrapperMain
   ```
   
   All I have in the `.mvn` directory is the following:
   
   ```
   bash-3.2$ tree .mvn
   .mvn
   └── wrapper
   └── maven-wrapper.properties
   
   ```
   
   @slawekjaranowski how did you test it?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] slawekjaranowski commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

slawekjaranowski commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980632912


   in `maven-wrapper` 
   
   ```
   mvn clean install -P run-its
   ``` 
   
   and in other project
   
   ```
   mvn org.apache.maven.plugins:maven-wrapper-plugin:3.0.3-SNAPSHOT:wrapper 
-Dtype=bin -Dmaven=3.6.2
   ```
   
   important is `type=bin`, so I have:
   
   ```
   tree .mvn/
   .mvn/
   └── wrapper
   ├── maven-wrapper.jar
   └── maven-wrapper.properties
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] jvanzyl commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

jvanzyl commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980633136


   I think that's a poor default behavior, and the `type=bin` should be the 
default. That's not how the current released wrapper work, no one will read the 
docs and the first experience from new users will be poor, and not what's 
expected. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] jvanzyl edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

jvanzyl edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980633136


   @hboutemy I think that's poor default behavior, the `type=bin` should be the 
default. That's not how the current released wrapper works. No one will read 
the docs, that's not what will be expected and the first experience from new 
users will be poor.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] jvanzyl edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

jvanzyl edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980633136


   @hboutemy I think that's poor default behavior, the `type=bin` should be the 
default. That's not how the current released wrapper works. No one will read 
the docs that's not what will be expected and the first experience from new 
users will be poor.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] slawekjaranowski commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

slawekjaranowski commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980633392


   Of course, `wrapperUrl` in properties is wrong, but release (even staging) 
should resolve it
   
   ```
   
wrapperUrl=https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.0.3-SNAPSHOT/maven-wrapper-3.0.3-SNAPSHOT.zip
   ```
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] jvanzyl commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

jvanzyl commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980635194


   I'm not sure why the slight change was made, but the latest published 
instructions put the JAR in there by default. Just a warning that it's asking 
for potential support issues. Maybe someone has one network setup and commits 
the wrapper change not noticing the JAR isn't there. Changes network setups and 
their network or corporate setup doesn't allow access.
   
   I think it's nicer not to have any JARs checked in but changing the way it 
works before it's released may not make for a great first release.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] hboutemy commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy commented on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980543639


   last try:
   - code = https://github.com/hboutemy/maven-wrapper = the initial wrapper 
donation with 4 commits to switch to Apache, replace provisio to assembly, add 
maven-wrapper-plugin and document
   - site: https://maven.apache.org/wrapper-archives/wrapper-LATEST/
   
   This approach of wrapper does not need any releases when new Maven versions 
are released, and can work with any version from the past (like the original 
donation), and any SNAPSHOT
   
   Getting identical features of installed mvnw in a project Git vs downloaded 
Maven distribution will be part of MWRAPPER-16 = stop trying to re-implement 
mvn logic to launch a JVM and Maven core, but call mvn = the only solution to 
get consistency
   
   all, please review: in the end, I expect to create a maven-wrapper.git 
repository containing my initial work (that contains initial donation), and 
we'll track future features an release normally in MWRAPPER Jira


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-wrapper-plugin] hboutemy edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build

[GitBox]

hboutemy edited a comment on pull request #1:
URL: 
https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-980543639


   last try:
   - code = https://github.com/hboutemy/maven-wrapper = the initial wrapper 
donation with 4 commits to switch to Apache, replace provisio to assembly, add 
maven-wrapper-plugin and document
   - site: https://maven.apache.org/wrapper-archives/wrapper-LATEST/
   
   This approach of wrapper does not need any releases when new Maven versions 
are released, and can work with any version from the past and any Maven 
SNAPSHOT (like the original donation)
   
   Getting identical features of installed `mvnw` in a project Git vs 
downloaded Maven distribution `mvn` will be part of MWRAPPER-16 = stop trying 
to re-implement `mvn` logic in `mvnw` to launch a JVM and Maven core, but call 
mvn = the only solution to get consistency
   
   all, please review: in the end, I expect to create a maven-wrapper.git 
repository containing my initial work (that contains initial donation), and 
we'll track future features an release normally in MWRAPPER Jira


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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