Re: maven.repo.local cf. localRepository

2024-07-14 Thread Timothy Stone

On 7/14/24 10:04 AM, Romain Manni-Bucau wrote:

Hi

Agree it should be absolute but there is no technical constraint -
ultimately it must be known how it resolves.

I know on ci it is common to use a relative path to avoid ci specific
internal path issues accross os/workers.


I concur. But as I note below, I think most CI environments can address 
this.




Le dim. 14 juil. 2024 à 09:52, Tamás Cservenák  a
écrit :



... snip ...


As it is evaluated at maven boot and relative would be calculated against
CWD based on invocation (plus, -f modifies it).



As Manni-Bucau noted above, CI workers/runners add some context to 
consider.


In the case of GitLab, the CI context is populated with many variables 
that can aid in easily resolving or creating an absolute path. For 
example, GitLab's CI_* variables are populated and include the 
CI_PROJECT_DIR variable that can be used to "pin" the absolute path.



I think this is enough to provide the team more information as we drive 
a path forward.


Thanks for the detailed answer Tamás, and the additional context clarity 
Manni-Bacau.




Hth
T

On Sun, Jul 14, 2024, 03:10 Timothy Stone  wrote:


I help maintain Maven tooling for To Be Continuous, a GitLab CI/CD
catalog of pluggable pipeline configurations.

There is some discussion on the use of the JVM property,
`-Dmaven.repo.local=path' and the note on "Configuring your Local
Repository" (see [1]). Initially I was going to post to the user list,
but being a development question against the internals of Maven, I
thought this a better forum.

There is an admonition on the referenced page:

/Note: The local repository _must_ be an absolute path./ (emphasis mine)

Is this specifically noted for the use of the settings.localRepository
only or does the note extend to the use of the JVM property? I searched
the GitHub repo for a examples and found numerous uses of relative
paths, e.g., `../.repository` and others.

Seeking clarification as I could not immediately determine the internal
use of `maven.repo.local' property when set.

Thanks!
Tim


[1]



https://maven.apache.org/guides/mini/guide-configuring-maven.html#configuring-your-local-repository

--
Timothy Stone
=
Some call me ... Tim.
Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
Find me on GitLab | GitHub | Linked In | MeWe | GnuPG







--
Timothy Stone
=
Some call me ... Tim.
Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
Find me on GitLab | GitHub | Linked In | MeWe | GnuPG


OpenPGP_signature.asc
Description: OpenPGP digital signature


maven.repo.local cf. localRepository

2024-07-13 Thread Timothy Stone

I help maintain Maven tooling for To Be Continuous, a GitLab CI/CD
catalog of pluggable pipeline configurations.

There is some discussion on the use of the JVM property,
`-Dmaven.repo.local=path' and the note on "Configuring your Local
Repository" (see [1]). Initially I was going to post to the user list,
but being a development question against the internals of Maven, I
thought this a better forum.

There is an admonition on the referenced page:

/Note: The local repository _must_ be an absolute path./ (emphasis mine)

Is this specifically noted for the use of the settings.localRepository
only or does the note extend to the use of the JVM property? I searched
the GitHub repo for a examples and found numerous uses of relative
paths, e.g., `../.repository` and others.

Seeking clarification as I could not immediately determine the internal
use of `maven.repo.local' property when set.

Thanks!
Tim


[1] 
https://maven.apache.org/guides/mini/guide-configuring-maven.html#configuring-your-local-repository

--
Timothy Stone
=
Some call me ... Tim.
Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
Find me on GitLab | GitHub | Linked In | MeWe | GnuPG


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: User friendly release notes

2024-03-24 Thread Timothy Stone

On 3/13/24 7:05 PM, Andres Almiray wrote:

First, I’d suggest following a commit message convention. You may define your 
own or follow an existing one such as 
https://www.conventionalcommits.org/en/v1.0.0/


+1


Next, use a tool that can read, parse, and format commit messages. You’ll find 
plenty of options out there. I can pitch https://jreleaser.org/ 


Not familiar with jreleaser. I will say that mixed technology pipelines 
have worked well for us, with Node managing many aspects of versioning 
and providing previous/next versions to the Maven Release Plugin via the 
pipeline environment.



Cheers
Andres

Sent from my primitive tricorder


On 13 Mar 2024, at 23:58, Slawomir Jaranowski  wrote:

Hi,

Today's facts:

- We manage our issues in jira and all officala release notes are also in
jira.
- We sent an email in text  format to announce mailing list.
- In project documentation we don't have a release notes

But as we see in:
https://lists.apache.org/thread/pzd36lo6rtfn7c5s0x60xbj296xt1mvf
today it is not a user-friendly way.



... snip



Any other propositions, ideas ?

--
Sławomir Jaranowski




--
Timothy Stone
=
Some call me ... Tim.
Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
Find me on GitLab | GitHub | Linked In | MeWe | GnuPG


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Using .git-blame-ignore-revs with reordered lines

2024-02-18 Thread Timothy Stone



On 1/24/24 6:31 AM, Konrad Windszus wrote:

Ping, does anyone have any input on this? Would be much appreciated,
Thanks,
Konrad


On 8. Jan 2024, at 19:16, Konrad Windszus  wrote:

Hi,

According to https://maven.apache.org/pom/maven/#the-format-profile the git 
commits created through applying the spotless formatting should be ignored via 
a .git-blame-ignore-revs file. This file is automatically evaluated by GitHub 
blame view. This doesn’t work well if the formatting also does some reordering 
of lines (most prominently through 
https://github.com/diffplug/spotless/tree/main/plugin-maven#sortpom). An 
example can be found in 
https://github.com/apache/sling-parent/blame/master/sling-parent/pom.xml#L270 
which obviously shows a non-related commit in line 270 due to the ignored 
reordering commit (this is a different ASF projects but follows the same 
approach as Maven).

The same may happen with reordering of lines  in Java.
I am wondering if there is a better approach, or we should rather not generally 
recommend to add those reformatting commits to .git-blame-ignore-revs. WDYT?
Konrad




Konrad,

I don't think I ever paid attention to this Maven workflow and tooling, 
deferring mostly to Checkstyle and pipeline tooling for Java.


Editing a file with SHAs adds friction: Who edits it? If it's not 
edited, what is the need/requirement to edit it after the fact? I see a 
separate file that needs manual action as process friction subject to 
all sorts of user issues. IMHO.


I'm aware that 'git blame' has "detect copy-move" switches, for example:


-C[]
  In addition to -M, detect lines moved or copied from other files that
  were modified in the same commit. This is useful when you reorganize
  your program and move code around across files. When this option is
  given twice, the command additionally looks for copies from other
  files in the commit that creates the file. When this option is given
  three times, the command additionally looks for copies from other
  files in any commit.

   is optional but it is the lower bound on the number of
  alphanumeric characters that Git must detect as moving/copying between
  files for it to associate those lines with the parent commit. And the
  default value is 40. If there are more than one -C options given, the
   argument of the last -C will take effect.


Is it possible that this could be leveraged somehow? Certainly, 
pipelines could be scripted to use these features of Git.


--
Timothy Stone
=
Some call me ... Tim.
Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
Find me on GitLab | GitHub | Linked In | MeWe | GnuPG


OpenPGP_signature.asc
Description: OpenPGP digital signature


Checkstyle 10.0, Java 11, Maven Checkstyle Plugin, and toolchain support

2022-03-07 Thread Timothy Stone
Devs,

I'm researching the possibility of committing a patch to the Maven
Checkstyle Plugn to support toolchains.

This support would be critical with Checkstyle 10.0 now requiring Java 11.

I did not see any work pending on this in the JIRA board, yet. I'm not
aware of any pending work from the Checkstyle team.

Any awareness of work would be appreciated, before I begin.

Thanks!
Tim

-- 
Timothy Stone
=
Some call me ... Tim.
Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
Find me on GitHub | Linked In | MeWe | PGP


OpenPGP_signature
Description: OpenPGP digital signature