Hello,
I don't think it's expected that those properties are replaced as it is not
documented. But I think it's specific to some known suffixes (GoupId). If you
can add a "Custom" or similar keyword it might help.
I think the expansion can be avoided with ${dollar}{someGroupID} but it might
For the declaration element we took the easy route and use the single line
element as it gets regenerated by the release.
This is actually a good thing it contains absolutely nothing of value, so
wasting only one line is ok (you just must get over the need of printing it on
paper ,)
--
Hi list,
I send this e-mail last week to the userlist, but haven't heard back yet.
Do you think this is a bug or a user error?
With regards,
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any
It is quite likely that it was fixed/changed and we never fixed the broken
indentions in existing poms, that's why I am still reminded of it :) I will
test later.
--
http://bernd.eckenfels.net
Von: Eric Lilja
Gesendet: Tuesday, February 4, 2020 8:41:03 PM
An:
Ah, yes, I do remember the changed indentation of the tag element in the
past, put I don't recall seeing that lately. Have to check tomorrow when I
get to the office.
Bernd: Which version of the maven-release-plugin did you use?
- Eric L
On Tue, Feb 4, 2020 at 8:30 PM Bernd Eckenfels
wrote:
>
Hm, for me it keeps the line breaks, it does however change the intention for
the tag element. I thought this was configurable, but can't find it at the
moment.
Anyway this is an open (and rejected) issue:
https://issues.apache.org/jira/browse/MRELEASE-1008
Gruss
Bernd
--
The transformation is triggered by one of the subclasses of
AbstractRewritePomsPhase[1]
In 2.5.3[2] the plugin was relying on JDOM with quite some hacks to make it
work. This is now extracted so it is possible to switch to a different parser
(JDom is not an active project anymore).
Here's where
Sure! Today I did a release in a single module project. The unwanted diff
was that the release plugin changed
http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
can you provide an example of reformatting, please?
in every case I saw until now, there is no reformatting, so I suppose you're
in a case I did not expect
Regards,
Hervé
Le mardi 4 février 2020, 16:24:54 CET Eric Lilja a écrit :
> > I see.
> > I am not aware of any such feature.
> > If you
>
> I see.
> I am not aware of any such feature.
> If you have some tool that pretty prints XML according to your
> comporate rules you could invoke it in completionGoals [1]
>
That could be a workaround for now. Thanks!
- Eric L
>
> Enrico
>
> [1]
>
Il giorno mar 4 feb 2020 alle ore 16:17 Eric Lilja
ha scritto:
>
> I didn't say the generated xml was invalid. It's a nuisance for us since
> the formatting conflicts with our corporate settings, so we are seeing
> unwelcome noise git diffs after releases.
I see.
I am not aware of any such
I didn't say the generated xml was invalid. It's a nuisance for us since
the formatting conflicts with our corporate settings, so we are seeing
unwelcome noise git diffs after releases.
- Eric L
On Tue, Feb 4, 2020 at 4:08 PM Enrico Olivelli wrote:
> Eric
> What's your use case?
> As far as it
Eric
What's your use case?
As far as it creates a valid XML with the same meaning this should not be a
problem
Enrico
Il Mar 4 Feb 2020, 15:22 Eric Lilja ha scritto:
> Hi, we noticed that maven-release-plugin changes formatting of the project
> element, it writes the element as a single line,
Hi, we noticed that maven-release-plugin changes formatting of the project
element, it writes the element as a single line, removing existing line
breaks on attributes. Is it possible to make it preserve original
formatting?
We're using maven-release-plugin version 3.0.0-M1
- Eric L
14 matches
Mail list logo
