Developing Maven within an IDE
Having trouble running Maven Core with in an IDE. I've tried all the pages under https://maven.apache.org/guides/development/guide-maven-development.html but nothing specific about running within an IDE. I'm trying to use IntelliJ and get the following output. /Library/Java/JavaVirtualMachines/jdk1.8.0_341.jdk/Contents/Home/bin/java ... org.apache.maven.cli.MavenCli -ep -Dmaven.multiModuleProjectDirectory system property is not set. Process finished with exit code 1 I'm trying to launch org.apache.maven.cli.MavenCli I'm setting the working directory to where my test pom is. Any useful pages that might be good to look at? John
Re: [DISCUSS] Change maven code style
The only way this makes sense if it's fully automatic: all code is
formatted on merge, period, without extra commits or human thought.
Anything less is a big -1 from me.
On Wed, Oct 12, 2022 at 4:24 PM Guillaume Nodet wrote:
>
> Related to the discussion about automatically formatting and sorting
> imports, I think it would be nice, given the big reformat commits if those
> PRs are to be merged, to eventually discuss some changes to those code
> style. In particular, I found out that the code is very sparse and my
> screen is more wide than height, which means I can usually only see 30-40
> lines of code, where sometime half of them do not really carry any semantic
> (open braces, or things like close brace + else + open brace on 3 lines).
> This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual java coding style) :
> * move open braces to the end of the previous line on all places
> * allow the else keyword to be directly following a closing brace to
> allow "} else {" to be on the same line
> * eventually relax a bit the checkstyle line length as described in
> https://github.com/gnodet/maven-shared-resources/pull/2. This has not much
> effect, as the formatter will automatically format the lines and wrap them
> at 120. However, in certain cases, the formatter can find in difficult to
> wrap the line (for example with a variable declaration and cast with a
> fully qualified name) and there is either a need to manually force the wrap
> (using an end of line comment for example) or disabling the check with a
> @SuppressWarning( "checkstyle:LineLength" ) annotation. This change only
> removes the checks so that in those rare cases, the formatter can be left
> without any need to force things.
>
> If this is to be accepted, I'd amend the PRs from the other thread to
> follow those changes.
>
> Cheers,
> Guillaume
--
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: [DISCUSS] Release Maven 4.0.0-alpha-1 this week
+1 to push manually once the vote suceeded, forks can be used during the vote time. Several asf projects do it with quite some success. Le sam. 15 oct. 2022 à 14:19, Slawomir Jaranowski a écrit : > For failed release I would prefer > - revert commits if needed - we will have history > - remove tag > try again :-) > > If we bump versions only caused by technical problems during release we > need to change / create labels in jira, move labeled issues and so on > And we can have questions why some versions are missing. > > > > sob., 15 paź 2022 o 13:31 Benjamin Marwell > napisał(a): > > > Unpopular opinion: > > Deactivate automatic push. If release:perform went well, push main and > the > > tags. > > > > Besides, push --delete works for tags, too (if PMC agrees). > > I doubt there are already forks from the tag active anywhere. > > But yes, bumping the version is what we used to do in this case. > > > > - Ben > > > > > > Am Sa., 15. Okt. 2022 um 00:31 Uhr schrieb Guillaume Nodet < > > gno...@apache.org>: > > > > > > The release:prepare has succeeded but the release:perform failed. > > > Hence, the tag has been created on github and can't be deleted. > > > > > > Le sam. 15 oct. 2022 à 00:26, Gary Gregory a > > > écrit : > > > > > > > Why are you bumping the version if it failed? > > > > > > > > Gary > > > > > > > > On Fri, Oct 14, 2022, 18:13 Guillaume Nodet > wrote: > > > > > > > > > Just FYI, I've attempted to release 4.0.0-alpha-1, but it failed. > > I'll > > > > try > > > > > to cut another version once the problems are resolved. So > > 4.0.0-alpha-1 > > > > is > > > > > a burnt version and next attempt will be 4.0.0-alpha-2. Stay > tuned ! > > > > > > > > > > Le lun. 10 oct. 2022 à 22:32, Guillaume Nodet > a > > > > écrit > > > > > : > > > > > > > > > > > The master branch contains a lot of things and has not been > > released > > > > for > > > > > a > > > > > > long time. With the new addition of the v4 api, I think it would > be > > > > good > > > > > to > > > > > > get something out of the door to gather some feedback from users > > and > > > > also > > > > > > allow migrating some components and plugins to the new API. > > > > > > > > > > > > So unless there's an objection, I'd like to start a release > process > > > > later > > > > > > this week after [1] and [2] are merged. > > > > > > > > > > > > Thoughts ? > > > > > > > > > > > > Cheers, > > > > > > Guillaume Nodet > > > > > > > > > > > > [1] https://github.com/apache/maven/pull/806 > > > > > > [2] https://github.com/apache/maven/pull/819 > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Guillaume Nodet > > > > > > > > > > > > > > > > > > -- > > > > > > Guillaume Nodet > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > Sławomir Jaranowski >
Re: [DISCUSS] Release Maven 4.0.0-alpha-1 this week
For failed release I would prefer - revert commits if needed - we will have history - remove tag try again :-) If we bump versions only caused by technical problems during release we need to change / create labels in jira, move labeled issues and so on And we can have questions why some versions are missing. sob., 15 paź 2022 o 13:31 Benjamin Marwell napisał(a): > Unpopular opinion: > Deactivate automatic push. If release:perform went well, push main and the > tags. > > Besides, push --delete works for tags, too (if PMC agrees). > I doubt there are already forks from the tag active anywhere. > But yes, bumping the version is what we used to do in this case. > > - Ben > > > Am Sa., 15. Okt. 2022 um 00:31 Uhr schrieb Guillaume Nodet < > gno...@apache.org>: > > > > The release:prepare has succeeded but the release:perform failed. > > Hence, the tag has been created on github and can't be deleted. > > > > Le sam. 15 oct. 2022 à 00:26, Gary Gregory a > > écrit : > > > > > Why are you bumping the version if it failed? > > > > > > Gary > > > > > > On Fri, Oct 14, 2022, 18:13 Guillaume Nodet wrote: > > > > > > > Just FYI, I've attempted to release 4.0.0-alpha-1, but it failed. > I'll > > > try > > > > to cut another version once the problems are resolved. So > 4.0.0-alpha-1 > > > is > > > > a burnt version and next attempt will be 4.0.0-alpha-2. Stay tuned ! > > > > > > > > Le lun. 10 oct. 2022 à 22:32, Guillaume Nodet a > > > écrit > > > > : > > > > > > > > > The master branch contains a lot of things and has not been > released > > > for > > > > a > > > > > long time. With the new addition of the v4 api, I think it would be > > > good > > > > to > > > > > get something out of the door to gather some feedback from users > and > > > also > > > > > allow migrating some components and plugins to the new API. > > > > > > > > > > So unless there's an objection, I'd like to start a release process > > > later > > > > > this week after [1] and [2] are merged. > > > > > > > > > > Thoughts ? > > > > > > > > > > Cheers, > > > > > Guillaume Nodet > > > > > > > > > > [1] https://github.com/apache/maven/pull/806 > > > > > [2] https://github.com/apache/maven/pull/819 > > > > > > > > > > > > > > > > > > -- > > > > > > > > Guillaume Nodet > > > > > > > > > > > > > -- > > > > Guillaume Nodet > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sławomir Jaranowski
Re: [DISCUSS] Release Maven 4.0.0-alpha-1 this week
Unpopular opinion: Deactivate automatic push. If release:perform went well, push main and the tags. Besides, push --delete works for tags, too (if PMC agrees). I doubt there are already forks from the tag active anywhere. But yes, bumping the version is what we used to do in this case. - Ben Am Sa., 15. Okt. 2022 um 00:31 Uhr schrieb Guillaume Nodet : > > The release:prepare has succeeded but the release:perform failed. > Hence, the tag has been created on github and can't be deleted. > > Le sam. 15 oct. 2022 à 00:26, Gary Gregory a > écrit : > > > Why are you bumping the version if it failed? > > > > Gary > > > > On Fri, Oct 14, 2022, 18:13 Guillaume Nodet wrote: > > > > > Just FYI, I've attempted to release 4.0.0-alpha-1, but it failed. I'll > > try > > > to cut another version once the problems are resolved. So 4.0.0-alpha-1 > > is > > > a burnt version and next attempt will be 4.0.0-alpha-2. Stay tuned ! > > > > > > Le lun. 10 oct. 2022 à 22:32, Guillaume Nodet a > > écrit > > > : > > > > > > > The master branch contains a lot of things and has not been released > > for > > > a > > > > long time. With the new addition of the v4 api, I think it would be > > good > > > to > > > > get something out of the door to gather some feedback from users and > > also > > > > allow migrating some components and plugins to the new API. > > > > > > > > So unless there's an objection, I'd like to start a release process > > later > > > > this week after [1] and [2] are merged. > > > > > > > > Thoughts ? > > > > > > > > Cheers, > > > > Guillaume Nodet > > > > > > > > [1] https://github.com/apache/maven/pull/806 > > > > [2] https://github.com/apache/maven/pull/819 > > > > > > > > > > > > > > -- > > > > > > Guillaume Nodet > > > > > > > > -- > > Guillaume Nodet - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 4.0.0-alpha-2
Why alpha-2, we didn't release alpha-1. Even if some technical problems occur during release we should reuse the final tag. In jira we have a label for alpha-1. sob., 15 paź 2022 o 02:19 Guillaume Nodet napisał(a): > I've staged a release candidate at > https://repository.apache.org/content/repositories/maven-1811 > > The binaries are available at: > > > https://repository.apache.org/service/local/repositories/maven-1811/content/org/apache/maven/apache-maven/4.0.0-alpha-2/ > > The tag is available at: > https://github.com/apache/maven/tree/maven-4.0.0-alpha-2 > > Please review and vote ! > > Cheers, > Guillaume Nodet > -- Sławomir Jaranowski
Re: [VOTE] Release Apache Maven 4.0.0-alpha-2
Hi, Link for biaries is: https://repository.apache.org/content/repositories/maven-1811/org/apache/maven/apache-maven/4.0.0-alpha-2/ By the way binaries should be available at distribution area also ... https://dist.apache.org/repos/dist/dev/maven/ Did you publish a staging Maven site somewhere? sob., 15 paź 2022 o 02:19 Guillaume Nodet napisał(a): > I've staged a release candidate at > https://repository.apache.org/content/repositories/maven-1811 > > The binaries are available at: > > > https://repository.apache.org/service/local/repositories/maven-1811/content/org/apache/maven/apache-maven/4.0.0-alpha-2/ > > The tag is available at: > https://github.com/apache/maven/tree/maven-4.0.0-alpha-2 > > Please review and vote ! > > Cheers, > Guillaume Nodet > -- Sławomir Jaranowski
Re: [DISCUSS] Change maven code style
Le ven. 14 oct. 2022 à 22:14, Jochen Wiedmann a
écrit :
> Hi, Guillaume,
>
> rather than suggesting (and, what's worse: discussing) code change
> details: Is there, by any change, an existing code style, that we
> might adopt? In particular.could we reuse tools, like an Eclipse
> fornatter, and the like?
>
Definitely, see the other discussion about automatic formatting [1].
My idea is to do both at the same time. I.e. set up what is needed to have
a way to easily reformat files (either always, as by enabling a profile).
Once that's done on a given project, there is a need to reformat the files
so that the formatting check can pass. The idea is to do a single pass:
first agree that we want to enforce formatting, then agree on the format we
want. Once that's settled, It should be easy to set up when a project
migrates.
Currently, my proposal is to leverage the existing eclipse configuration
file (that can be downloaded from the web site at [2]) and to apply that
config using spotless plugin (it uses the eclipse formatter underneath,
pointing to those very files) to reformat. This could be done very easily
using a modification in the maven parent, see [3]. So the tools are there
and they are easy to use on the command line and the settings can be
imported in Eclipse and IDEA. It's mostly a matter of upgrading the parent
pom to this new version and reformatting everything. After that,
formatting will be enforced and applied easily using the -Pformat profile.
The above is mainly discussed in the other discussion I mentioned. This
one was more about changing the style, but it definitely needs to be
understood in the context of the other discussion about how to enforce it,
else it's really not interesting imho.
The question is then which code style configuration do we want. I
personally would love to have a middle ground between the current code
style and the usual java code style. I.e. keep spaces the way they are, but
do not enforce line breaks for each opening / closing braces. I've just
raised a draft PR at [4] as an early proposal. Here's an example of
reformatted code [5].
The problem I see is mainly that people kinda fear the automatic formatting
step. Imho, working on maven projects will be easier with an automatic
reformatting during the first phase of the build, rather than trying to
rely on the IDE formatting, just to find out that it does not completely
match the enforced one, trying to fix it manually, then fail again, and
last use the formatter in the build to actually format it correctly. This
could happen if you changed a bit your IDE settings (which can happen if
you switch from a project to another), or if you use an IDE which is not
Eclipse : as close as the format results can be, the only way to have the
exact result is to use the same formatter. I know IDEA has a plugin to use
the eclipse formatter, so that would be a deal saver imho, as there will
always be some discrepancies between the formatters on some tricky code
(mostly very long statements spanning multiple lines, where formatters can
decide to break/indent slightly differently). I very well suspect that
people will just switch to use the automatic format step which is really
fast and just works. As indicated on other threads, some IDE can also
support format-on-save, which would avoid having the source code
reformatted outside the IDE.
[1] https://lists.apache.org/thread/ok9qdl1w92f9fhdkz3tmc5f65ytpppqp
[2] https://maven.apache.org/developers/committer-environment.html
[3] https://github.com/apache/maven-parent/pull/80
[4] https://github.com/apache/maven-shared-resources/pull/3
[5]
https://github.com/gnodet/maven-resolver/blob/reformat/maven-resolver-impl/src/main/java/org/eclipse/aether/impl/DefaultServiceLocator.java
> Apart from that, I'd be more than happy about the changes, that you
> are suggesting.
>
> Jochen
>
>
> On Wed, Oct 12, 2022 at 6:23 PM Guillaume Nodet wrote:
> >
> > Related to the discussion about automatically formatting and sorting
> > imports, I think it would be nice, given the big reformat commits if
> those
> > PRs are to be merged, to eventually discuss some changes to those code
> > style. In particular, I found out that the code is very sparse and my
> > screen is more wide than height, which means I can usually only see 30-40
> > lines of code, where sometime half of them do not really carry any
> semantic
> > (open braces, or things like close brace + else + open brace on 3 lines).
> > This makes me scroll a lot even on quite small methods to be able to read
> > the full code, and that's a pain imho.
> > So I'd like to propose the following changes that would make maven code
> > more readable imho (and also closer to the usual java coding style) :
> > * move open braces to the end of the previous line on all places
> > * allow the else keyword to be directly following a closing brace to
> > allow "} else {" to be on the same line
> > * eventually relax a bit the checkstyle
