Maven with Hocon and Json

[Hunter C Payne]

Hi Maven devs,
I emailed you about a month ago about an idea to allow Maven to use Hocon and 
Json formatted POMs which I called Unbound.
Just wanted to let you know that Unbound is beta now and ready to be used by 
others.

https://hunterpayne.github.io/maven-unbound-site/
Hunter

PS I'm interested in donating this project to Apache and integrating it 
directly into Maven.

Re: Naming of ITs in maven-release

[Tibor Digana]

Clemens, why the issues cannot use Jira ID only?
If somebody wants to know more, she/he can still open Jira and see.
Another position is when you develop a new feature and then human readable
name should be used.
This way we know that we have more ITs for bug than originally TDD
features, or oposite ;-)

On Wed, Jul 17, 2019 at 11:24 PM Clemens Quoss  wrote:

> Hi,
> I wrote unit tests with scm mocked away [0].
> But IT: I do not know how and what.
> Cheers, Clemens
> [0]
>
> https://github.com/apache/maven-release/pull/29/files#diff-bd93f43863e2917722a94ccc46af95a8
>
> Am 17.07.2019 um 08:22 schrieb Olivier Lamy:
> > Hi
> > I understand it can be complicated to write such it which need some scm..
> > Maybe write a unit at least?
> >
> > On Tue, 16 Jul 2019 at 05:20, Clemens Quoss  wrote:
> >
> >> Hi Olivier,
> >> yeah, could do that.  Would be a great idea.  But i am stuck on what to
> >> put into this IT:
> >> RemoveScmTag does what the name suggests:  it uses maven-scm to remove
> >> the tag during release:rollback.
> >> In the unit tests maven-scm is mocked away and i think in the ITs of
> >> maven-release maven-scm is out of scope, too.
> >> Then there is not really much left to test there.
> >> Maybe someone out there has a different opinion?  And we can discuss
> >> this further in private mail?
> >> TIA
> >> Clemens
> >>
> >> Am 15.07.2019 um 02:12 schrieb Olivier Lamy:
> >>> Hi
> >>> I agree the name is a bit confusing...
> >>> maybe name the IT: MRELEASE-229-RemoveScmTagPhase?
> >>>
> >>>
> >>> On Sun, 14 Jul 2019 at 20:06, Clemens Quoss  wrote:
> >>>
>  Hello everyone,
> 
>  one more question regarding the name of the ITs in maven-release (or
>  maybe generally):
> 
>  Seeing that the tests are named after the jira issues i am wondering
> if
>  that would be the right thing to do.
> 
>  Shouldn't they be named after the functionality they are testing?
> 
>  I for my part, being new to the whole thing, have provided a PR for
>  MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests)
> [1].
> 
>  Now i would like to see if there are IT for ScmTagPhase to help me in
> my
>  orientation.
> 
>  For goal prepare there seem to exist the following:
> 
>  ...
> 
>  10.07.2019  08:16  completion-goals
>  17.02.2019  23:40  flat-multi-module
>  10.07.2019  08:16  forked-basic
>  10.07.2019  08:16  invoker-basic
>  10.07.2019  08:16   833 invoker.properties
>  10.07.2019  08:15  MRELEASE-128
>  10.07.2019  08:15  MRELEASE-156
>  10.07.2019  08:15  MRELEASE-161
>  10.07.2019  08:15 MRELEASE-161-dependencyManagement
>  10.07.2019  08:15  MRELEASE-420
>  10.07.2019  08:15  MRELEASE-483
>  10.07.2019  08:15  MRELEASE-533
>  10.07.2019  08:15  MRELEASE-571_M3
>  10.07.2019  08:16  MRELEASE-618
>  10.07.2019  08:16  MRELEASE-667
>  17.02.2019  23:40  MRELEASE-834
>  10.07.2019  08:16  MRELEASE-966
>  10.07.2019  08:16  MRELEASE-976
>  10.07.2019  08:16  regular-multi-module
> 
>  ...
> 
>  Maybe one of the MRELEASE-... ITs does something with ScmTagPhase,
> maybe
>  not.  I will have to look into everyone of them to decide.
> 
>  Would there be a test or tests named 'scm-tag-phase' or
>  'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.
> 
>  Or have I misunderstood some fundamental concept here?
> 
>  Regards,
> 
>  Clemens
> 
>  [1] https://github.com/apache/maven-release/pull/29
> 
> 
>  -
>  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: Naming of ITs in maven-release

[Clemens Quoss]

Hi,
I wrote unit tests with scm mocked away [0].
But IT: I do not know how and what.
Cheers, Clemens
[0] 
https://github.com/apache/maven-release/pull/29/files#diff-bd93f43863e2917722a94ccc46af95a8


Am 17.07.2019 um 08:22 schrieb Olivier Lamy:

Hi
I understand it can be complicated to write such it which need some scm..
Maybe write a unit at least?

On Tue, 16 Jul 2019 at 05:20, Clemens Quoss  wrote:


Hi Olivier,
yeah, could do that.  Would be a great idea.  But i am stuck on what to
put into this IT:
RemoveScmTag does what the name suggests:  it uses maven-scm to remove
the tag during release:rollback.
In the unit tests maven-scm is mocked away and i think in the ITs of
maven-release maven-scm is out of scope, too.
Then there is not really much left to test there.
Maybe someone out there has a different opinion?  And we can discuss
this further in private mail?
TIA
Clemens

Am 15.07.2019 um 02:12 schrieb Olivier Lamy:

Hi
I agree the name is a bit confusing...
maybe name the IT: MRELEASE-229-RemoveScmTagPhase?


On Sun, 14 Jul 2019 at 20:06, Clemens Quoss  wrote:


Hello everyone,

one more question regarding the name of the ITs in maven-release (or
maybe generally):

Seeing that the tests are named after the jira issues i am wondering if
that would be the right thing to do.

Shouldn't they be named after the functionality they are testing?

I for my part, being new to the whole thing, have provided a PR for
MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1].

Now i would like to see if there are IT for ScmTagPhase to help me in my
orientation.

For goal prepare there seem to exist the following:

...

10.07.2019  08:16  completion-goals
17.02.2019  23:40  flat-multi-module
10.07.2019  08:16  forked-basic
10.07.2019  08:16  invoker-basic
10.07.2019  08:16   833 invoker.properties
10.07.2019  08:15  MRELEASE-128
10.07.2019  08:15  MRELEASE-156
10.07.2019  08:15  MRELEASE-161
10.07.2019  08:15 MRELEASE-161-dependencyManagement
10.07.2019  08:15  MRELEASE-420
10.07.2019  08:15  MRELEASE-483
10.07.2019  08:15  MRELEASE-533
10.07.2019  08:15  MRELEASE-571_M3
10.07.2019  08:16  MRELEASE-618
10.07.2019  08:16  MRELEASE-667
17.02.2019  23:40  MRELEASE-834
10.07.2019  08:16  MRELEASE-966
10.07.2019  08:16  MRELEASE-976
10.07.2019  08:16  regular-multi-module

...

Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe
not.  I will have to look into everyone of them to decide.

Would there be a test or tests named 'scm-tag-phase' or
'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.

Or have I misunderstood some fundamental concept here?

Regards,

Clemens

[1] https://github.com/apache/maven-release/pull/29


-
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 Build Fix and Reverting MRESOLVER-7

[Enrico Olivelli]

+1

Enrico

Il mer 17 lug 2019, 19:49 Tibor Digana  ha scritto:

> For these purpose of build stability, see Jira issue
> https://issues.apache.org/jira/browse/MNG-6712
> "Revert maven-resolver:1.4.0 to 1.3.3"
>
>
>
> On Tue, Jul 16, 2019 at 12:48 PM Tibor Digana 
> wrote:
>
> > Hello devs,
> >
> > You may have noticed that Maven build fails over one month.
> > We cann't cut a new release version of Maven.
> > Additionally, another Maven builds still fail too.
> >
> > Not speaking too long, I want to inform you that I want to revert the
> > commit of MRESOLVER-7 in Maven Core and make the build passing. I will
> try
> > to do so in an outstanding branch and confirm successful build.
> >
> > The reasoning about this activity is explained in
> >
> >
> https://issues.apache.org/jira/browse/MRESOLVER-7?focusedCommentId=16885618=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885618
> >
> > Have a nice day!
> > Tibor17
> >
> >
>

Re: Maven Build Fix and Reverting MRESOLVER-7

[Tibor Digana]

For these purpose of build stability, see Jira issue
https://issues.apache.org/jira/browse/MNG-6712
"Revert maven-resolver:1.4.0 to 1.3.3"



On Tue, Jul 16, 2019 at 12:48 PM Tibor Digana 
wrote:

> Hello devs,
>
> You may have noticed that Maven build fails over one month.
> We cann't cut a new release version of Maven.
> Additionally, another Maven builds still fail too.
>
> Not speaking too long, I want to inform you that I want to revert the
> commit of MRESOLVER-7 in Maven Core and make the build passing. I will try
> to do so in an outstanding branch and confirm successful build.
>
> The reasoning about this activity is explained in
>
> https://issues.apache.org/jira/browse/MRESOLVER-7?focusedCommentId=16885618=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885618
>
> Have a nice day!
> Tibor17
>
>

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Vladimir Sitnikov]

Just in case: I see you seem to be battling against CRLF
For instance: https://github.com/apache/maven-checkstyle-plugin/pull/16
Did you consider to add the relevant .gitattributes file to ensure Git
converts the files automatically?
With a proper .gitattributes file, it is just impossible to commit a file
with "a wrong EOL".

PS. I've came across this thread when Apache JMeter project noticed that
Window-based builds were broken by
https://issues.apache.org/jira/browse/INFRA-18383

Vladimir

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Enrico Olivelli]

Il mer 17 lug 2019, 13:28 Eric Lilja  ha scritto:

> I believe, if we instead upgrade to Checkstyle 8.21 or later, we don't need
> to do any of those alternative approaches.
>
> https://github.com/checkstyle/checkstyle/issues/4073


Eric
I think it is the best idea
Do you have cycles to give it a try?

Enrico



>
> - Eric L
>
>
> On Wed, Jul 17, 2019 at 1:20 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > Robert>A clone from Git succeeds, but the sources.zip fails.
> > Robert>The files in the zip are generated on a unix system, so all EOLs
> in
> > text files are LF
> > Robert>...
> > Robert>The fix: add a setup.groovy to the IT and rewrite the java files
> > with OS specific EOLs
> >
> > Alternative approaches:
> > A) Provide both Linux (LF) and Windows (CRLF) source distributions (e.g.
> > *.zip and *.tgz).
> > B) Specify "lineSeparator" explicitly. Then you could have both CRLF and
> LF
> > files at the same time and verify if those work
> > C) Generate file at the build stage. If you generate it into target/
> > directory, then you could generate the file with appropriate for the
> > platform enconding
> > D) Ensure the file is always in LF or CRLF by adding a relevant
> > .gitattributes entry
> >
> > Vladimir
> >
>

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Eric Lilja]

I believe, if we instead upgrade to Checkstyle 8.21 or later, we don't need
to do any of those alternative approaches.

https://github.com/checkstyle/checkstyle/issues/4073

- Eric L


On Wed, Jul 17, 2019 at 1:20 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Robert>A clone from Git succeeds, but the sources.zip fails.
> Robert>The files in the zip are generated on a unix system, so all EOLs in
> text files are LF
> Robert>...
> Robert>The fix: add a setup.groovy to the IT and rewrite the java files
> with OS specific EOLs
>
> Alternative approaches:
> A) Provide both Linux (LF) and Windows (CRLF) source distributions (e.g.
> *.zip and *.tgz).
> B) Specify "lineSeparator" explicitly. Then you could have both CRLF and LF
> files at the same time and verify if those work
> C) Generate file at the build stage. If you generate it into target/
> directory, then you could generate the file with appropriate for the
> platform enconding
> D) Ensure the file is always in LF or CRLF by adding a relevant
> .gitattributes entry
>
> Vladimir
>

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Vladimir Sitnikov]

Robert>A clone from Git succeeds, but the sources.zip fails.
Robert>The files in the zip are generated on a unix system, so all EOLs in
text files are LF
Robert>...
Robert>The fix: add a setup.groovy to the IT and rewrite the java files
with OS specific EOLs

Alternative approaches:
A) Provide both Linux (LF) and Windows (CRLF) source distributions (e.g.
*.zip and *.tgz).
B) Specify "lineSeparator" explicitly. Then you could have both CRLF and LF
files at the same time and verify if those work
C) Generate file at the build stage. If you generate it into target/
directory, then you could generate the file with appropriate for the
platform enconding
D) Ensure the file is always in LF or CRLF by adding a relevant
.gitattributes entry

Vladimir

Re: [shade plugin] common code with gradle shadow plugin?

[Romain Manni-Bucau]

A PoC being always better than a mail, here is the demo of what I am
talking about: https://github.com/rmannibucau/portable-transformer

Both integrations have an IT with should help to see how it works if the
readme is not enough

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



Le mar. 16 juil. 2019 à 01:03, Lennart Jörelid 
a écrit :

> It could make a lot of sense, Romain - and fine in terms of Shadow/Shade
> reuse.
>
> On Mon, Jul 15, 2019 at 8:09 PM Romain Manni-Bucau 
> wrote:
>
> > It is simpler actually, in pseudo code it is:
> >
> > 
> >shade plugin gav...
> >   
> > 
> >   
> > 
> >   
> > 
> >
> > And exactly the same MyPortableTfr in shadow gradle plugin.
> > Maven just wraps orgportable.Transformer implementations in native
> mvn
> > shade Transformers forwarding attributes through a factory in guice or
> > equivalent.
> >
> > Topic is not about bridging mvn and gradle but maven shade and shadow
> > plugins together only.
> >
> > Does it make more sense?
> >
> > Le lun. 15 juil. 2019 à 17:08, Tibor Digana  a
> > écrit :
> >
> > > Hi Lenant,
> > >
> > > The plugin looks like this in POM:
> > >
> > > 
> > > ... implements="pkg.ResolverImpl"...
> > > ~~~ plugin dependencies ~~~
> > > 
> > > groupId,artifactId,version ~~~ for ~~~ artifact ~~~ having ~~~
> > > pkg.ResolverImpl.class ~~~
> > > 
> > > 
> > >
> > > So " implements" is already the extention style.
> > > The class ResolverImpl should inherit the API from a separate API
> > artifact.
> > >
> > > So the separation concern (plugin implementation and API) means that
> the
> > > SPI is not need and the patch is directly applied to the particular
> > plugin
> > > (and plugin execution), not the whole JVM as in case of SPIs.
> > >
> > > If somebody does not want to use POM, still the API is the keypoint.
> > > Somebody who deploys the artifact in dependency has to write facade or
> > > adapter between this API in Maven and Gradle or whatever else.
> > >
> > > I thik this is meant by Romain.
> > >
> > > Honestly, i am not a fan or embedding these Gradle adapters in Maven,
> and
> > > quite pessimistic, because doing such things would mean that the API
> > > (whatever it means) is a "beton". One endpoint wins and second will
> loose
> > > because any change breaks the world. So therefore a 3rd party (equal
> devs
> > > from Maven + Gradle project) should be the adapter artifact/project,
> and
> > > his speed of development and release matters how fast he reacts on
> > changes
> > > from both.
> > >
> > > Cheers
> > > Tibor
> > >
> > > On Mon, Jul 15, 2019 at 3:13 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hello Lennart,
> > > >
> > > > Do you have an example where transformer abstraction can be messing
> for
> > > > existing transformers?
> > > > Goal here is not to abstract the build system but the user extensions
> > for
> > > > two particular plugins.
> > > >
> > > > 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 lun. 15 juil. 2019 à 14:58, Lennart Jörelid <
> > > lennart.jore...@gmail.com>
> > > > a écrit :
> > > >
> > > > > I'd say it would - nowadays - always be a good idea to split the
> > > plugins
> > > > > into an API-or-SPI part where the meat of the functionality is
> > located
> > > -
> > > > > and an Implementation-Per-Build-System part (i.e. an *x-spi*,
> > > > > *x-maven-plugin* and *x-gradle-plugin* type of structure).
> > > > >
> > > > > However, the underpinnings of most known build systems would be in
> > need
> > > > of
> > > > > an abstraction layer themselves for those kinds of operation to
> work
> > > > > smoothly... and at the moment they are not exactly harmonized to a
> > > level
> > > > > where cross-buildsystem development is necessarily trivial. As an
> > > > example,
> > > > > compare the semantics for transitive dependencies between Maven and
> > > > Gradle.
> > > > > It is currently not trivial to - say - modify the execution
> > environment
> > > > for
> > > > > a plugin in a consistent manner across build systems.
> > > > >
> > > > > That being said, I guess there is quite a bit of simplification to
> be
> > > > > gained in terms of reusing implemented algorithms, even if adapting
> > > said
> > > > > implementation to Maven or Gradle or SBT or ... 

Re: Naming of ITs in maven-release

[Olivier Lamy]

Hi
I understand it can be complicated to write such it which need some scm..
Maybe write a unit at least?

On Tue, 16 Jul 2019 at 05:20, Clemens Quoss  wrote:

> Hi Olivier,
> yeah, could do that.  Would be a great idea.  But i am stuck on what to
> put into this IT:
> RemoveScmTag does what the name suggests:  it uses maven-scm to remove
> the tag during release:rollback.
> In the unit tests maven-scm is mocked away and i think in the ITs of
> maven-release maven-scm is out of scope, too.
> Then there is not really much left to test there.
> Maybe someone out there has a different opinion?  And we can discuss
> this further in private mail?
> TIA
> Clemens
>
> Am 15.07.2019 um 02:12 schrieb Olivier Lamy:
> > Hi
> > I agree the name is a bit confusing...
> > maybe name the IT: MRELEASE-229-RemoveScmTagPhase?
> >
> >
> > On Sun, 14 Jul 2019 at 20:06, Clemens Quoss  wrote:
> >
> >> Hello everyone,
> >>
> >> one more question regarding the name of the ITs in maven-release (or
> >> maybe generally):
> >>
> >> Seeing that the tests are named after the jira issues i am wondering if
> >> that would be the right thing to do.
> >>
> >> Shouldn't they be named after the functionality they are testing?
> >>
> >> I for my part, being new to the whole thing, have provided a PR for
> >> MRELEASE-229 (implementing RemoveScmTagPhase with some unit tests) [1].
> >>
> >> Now i would like to see if there are IT for ScmTagPhase to help me in my
> >> orientation.
> >>
> >> For goal prepare there seem to exist the following:
> >>
> >> ...
> >>
> >> 10.07.2019  08:16  completion-goals
> >> 17.02.2019  23:40  flat-multi-module
> >> 10.07.2019  08:16  forked-basic
> >> 10.07.2019  08:16  invoker-basic
> >> 10.07.2019  08:16   833 invoker.properties
> >> 10.07.2019  08:15  MRELEASE-128
> >> 10.07.2019  08:15  MRELEASE-156
> >> 10.07.2019  08:15  MRELEASE-161
> >> 10.07.2019  08:15 MRELEASE-161-dependencyManagement
> >> 10.07.2019  08:15  MRELEASE-420
> >> 10.07.2019  08:15  MRELEASE-483
> >> 10.07.2019  08:15  MRELEASE-533
> >> 10.07.2019  08:15  MRELEASE-571_M3
> >> 10.07.2019  08:16  MRELEASE-618
> >> 10.07.2019  08:16  MRELEASE-667
> >> 17.02.2019  23:40  MRELEASE-834
> >> 10.07.2019  08:16  MRELEASE-966
> >> 10.07.2019  08:16  MRELEASE-976
> >> 10.07.2019  08:16  regular-multi-module
> >>
> >> ...
> >>
> >> Maybe one of the MRELEASE-... ITs does something with ScmTagPhase, maybe
> >> not.  I will have to look into everyone of them to decide.
> >>
> >> Would there be a test or tests named 'scm-tag-phase' or
> >> 'scm-tag-phase-MRELEASE-...' this would be of help, at least to me.
> >>
> >> Or have I misunderstood some fundamental concept here?
> >>
> >> Regards,
> >>
> >> Clemens
> >>
> >> [1] https://github.com/apache/maven-release/pull/29
> >>
> >>
> >> -
> >> 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
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy