Re: APT vs Markdown formats for site docs

[Paul Hammant]

https://github.com/asciidoctor/jekyll-asciidoc-quickstart .. find “GitHub
pages” in page.

My blog used to be in textile - overnight GHP dropped support so I had to
batch convert hundreds to markdown. That was years back. I might have
preferred asciidoc, and if it is supported that’s great, but I don’t think
it is.



> Asciidoc might be a sane choice here. It was specially designed for
> technical documentation and
> has neat features which are handy for exactly those cases.
> Besides, it is also supported on GitHub.
>
> ---
>

Re: Maven artifacts SHA256 | SHA512 checksums

[Paul Hammant]

I don't think so - it's tied to SHA1 presently and would require updates to
multiple plugins. I mean for your own DAV-style repository you could ALSO
publish SHA256s, but there's no verification cycle as deps are pulled into
a build client-side that'd use them.

Re: JSR330 in extensions and plugins, Singleton or not Singleton

[Paul Hammant]

CDI came after JSR330 I think. I was on the JSR330 experts group. I could
be wrong there.

Back history of dependency injection - it was an antidote to classic GoF
service-locator being used everywhere in Javaland. When we co-created
PicoContainer we were careful to avoid Singleton as a term or idiom for
good within the classbase and documentation. GoF singleton being a sibling
of service locator.  Spring used the term in XML, then later as an
annotation (after Guice used Singleton as an annotation when Java5 kicked
off).  Then JSR330 gets to include it in the set of annotations.

Anyway, I always told readers "single managed instance" was the thing you
were trying to do. That could be one per JVM for a flat classloader design.
Or in a hierarchy of classloaders (Tomcat, Intellij, a stupid Jesktop
 thing I worked on) it would be one per
meaningful separate part of a tree of classloaders in a JVM.

These days, twice a year I get to give an opinion of a technology in a
language that purports to be DI, but is actually
Container.getInstance().getComponent() by various obfuscations
(service locator *not* DI at all).

- Paul

Re: JSR330 in extensions and plugins, Singleton or not Singleton

[Paul Hammant]

>
> JSR 330 has a TCK that defines a lot. A system that purports to facilitate
> injection into contained components (plugins or lesser) doesn’t have to
> implement all facets of that TCK but could do so out of the box by just
> using (say) guice or dagger in a class loader tree implementation.

Re: JSR330 in extensions and plugins, Singleton or not Singleton

[Paul Hammant]

OK, my bad, I thought we were talking about Maven's internals for itself.

Classloader trees, hidden implementations, security policies for the JVM
are stand out features that they nailed in 1995/6/7.

I once drew a pretty pic of Tomcat's classloader setup -
https://paulhammant.com/images/tomcat_classloader.jpg - not from
actually knowledge, but from "that's how I would do it"

On Fri, Feb 5, 2021 at 1:32 PM Romain Manni-Bucau 
wrote:

> @Paul: not really, none define any behavior (note that the class loader
> tree implementation is a vendor choice, several certified EE servers do
> handle singleton per tree or per loader of the tree and it is compliant).
> Only @inject tests are
>
> https://github.com/eclipse-ee4j/injection-tck/blob/2ef97bfc0439f28730d4d1793f1ef9ff21309450/src/main/java/org/atinject/tck/auto/Convertible.java#L176
> which are mainly smoke tests to let vendors handle instances as they want
> (proxy or not, eager vs lazy, scope/context definition etc). All that still
> leads to the fact that the Maven IoC is not obvious on our doc, no?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 5 févr. 2021 à 13:55, Paul Hammant  a
> écrit :
>
> > >
> > > JSR 330 has a TCK that defines a lot. A system that purports to
> > facilitate
> > > injection into contained components (plugins or lesser) doesn’t have to
> > > implement all facets of that TCK but could do so out of the box by just
> > > using (say) guice or dagger in a class loader tree implementation.
> >
>

Re: Running maven from inside JVM.

[Paul Hammant]

Google for "embedding Maven". Articles like
https://techblog.bozho.net/embedding-maven/ talk about that.

Re: Incremental Maven - push the feature

[Paul Hammant]

Sounds great. Quick check - this is a fork of Maven somehow?  Or additional
plugins that are configurable into standard Maven?

I too published something on quicker Maven builds that's lower tech -
https://paulhammant.com/2021/01/28/dagging-on-maven

- Paul

Re: Feature proposal: Dependency deprecation indicators

[Paul Hammant]

https://github.com/hboutemy/mcmm-yaml could gain some additional
post-publication meta info :)

Re: Eat our own dogfood

[Paul Hammant]

Apache used to operate Gump for this purpose, back on the days of Ant and
Maven 1.x.

Re: Empty jars in local .m2/repository

[Paul Hammant]

Corporations that do anti-virus content filtering of incoming GETs, have
occasionally seen corrupt jars in ~/.m2 and their shared
Nexus/Artifactory.  In that case there was text content for the jar (insead
of a zip) and if you looked at it, you saw a HTML page talking of the A-V
transgression but with the .jar suffix.  Plot twist: none were actual
malware - just bad A-V configuration.

On Wed, Dec 1, 2021 at 11:58 AM Slawomir Jaranowski 
wrote:

> With Maven 3.6.2 I had similar issues ... so last week I upgrade on my CI
> system to 3.8.4 ... not fix
>
> śr., 1 gru 2021 o 12:27 Romain Manni-Bucau 
> napisał(a):
>
> > Hi,
> >
> > I have a few coming from p2 plugins and .lock/.part files (missing
> cleanup
> > but no big deal I guess). All other 0 sized artifacts are related to data
> > exploded in .m2 by plugins but unrelated to maven (like graal distro
> > exploded, npm tar.gz exploded etc).
> >
> > Side note: I mainly use 3.6.3 on projects so can be in a luck case too.
> >
> > 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 mer. 1 déc. 2021 à 12:23, Slawomir Jaranowski  >
> > a
> > écrit :
> >
> > > Hi,
> > >
> > > From time to time I have jars in .m2/repository of size 0.
> > >
> > > Probably some network issues are the reason for this situation.
> > >
> > > I can't reproduce this today.
> > > I need some hints which component is responsible for storing artifacts
> in
> > > .m2
> > > Or some other hints which can help to reproduce, debug such a
> situation.
> > >
> > > Does anybody else have a similar problem?
> > >
> > > Please try on your system:
> > > find ~/.m2/repository -type f -size 0
> > >
> > > I use Maven 3.8.4
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> > > https://twitter.com/SlawekJaran
> > > https://github.com/slawekjaranowski
> > > https://linkedin.com/in/slawomirjaranowski
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: Multi-repo experience

[Paul Hammant]

OK, ignore me, you're talking about the other way.

On Thu, Aug 24, 2023 at 1:27 PM Paul Hammant  wrote:

> A classic pom.xml at root in a single repo, then multiple levels of child
> directory each with its own pom.xml (and its own src/main/java &
> src.test/java) ?
>
> Branching model would be trunk based development (and branch for release),
> possibly as short-lived feature branches in the GitHub Pull-Request style?
> Or GitFlow, or some other branching model?
>
> - Paul
> (I maintain https://trunkbaseddevelopment.com)
>
> On Thu, Aug 24, 2023 at 11:31 AM Volkan Yazıcı  wrote:
>
>> Hello,
>>
>> Log4j crew is considering moving to a multi-repo structure. If I am not
>> mistaken, there are 125 `github.com/apache/maven-*`
>> <http://github.com/apache/maven-*>
>> <http://github.com/apache/maven-*> repos, which makes me believe that you
>> have quite a bit of experience with such a construct. I am curious to hear
>> your thoughts on the matter.
>>
>> How does it work for you?
>> What are its advantages?
>> What are its disadvantages?
>> What are the things we should be extra cautious about?
>> Are there any major pillars we need to erect for such a construct to work?
>> Would you still go the same route if Maven is founded today?
>>
>> I deliberately don't share in this post our goals with such a migration to
>> avoid manipulating your line of thinking. I can do that later to give the
>> conversation a little bit more context.
>>
>> Kind regards.
>>
>

Re: Multi-repo experience

[Paul Hammant]

A classic pom.xml at root in a single repo, then multiple levels of child
directory each with its own pom.xml (and its own src/main/java &
src.test/java) ?

Branching model would be trunk based development (and branch for release),
possibly as short-lived feature branches in the GitHub Pull-Request style?
Or GitFlow, or some other branching model?

- Paul
(I maintain https://trunkbaseddevelopment.com)

On Thu, Aug 24, 2023 at 11:31 AM Volkan Yazıcı  wrote:

> Hello,
>
> Log4j crew is considering moving to a multi-repo structure. If I am not
> mistaken, there are 125 `github.com/apache/maven-*`
> 
>  repos, which makes me believe that you
> have quite a bit of experience with such a construct. I am curious to hear
> your thoughts on the matter.
>
> How does it work for you?
> What are its advantages?
> What are its disadvantages?
> What are the things we should be extra cautious about?
> Are there any major pillars we need to erect for such a construct to work?
> Would you still go the same route if Maven is founded today?
>
> I deliberately don't share in this post our goals with such a migration to
> avoid manipulating your line of thinking. I can do that later to give the
> conversation a little bit more context.
>
> Kind regards.
>

Re: And while I'm on the subject of logging

[Paul Hammant]

I wrote much of
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
20 years back, and still stand by the basic message.

Maven is a build tool though, and aims and reproducibility. Minimal output
should be the default (console and log files). If someone wants more, they
can run the build again with another —argument. Cough, I mean -Dargument

Re: My first expierence trying to contribute code

[Paul Hammant]

Eclipse can't open a pom.xml file from the command line?  For Intellij-idea
on Mac, Windows or Linux, I'd just do `idea pom.xml`

- Paul

On Sat, Feb 3, 2024 at 11:44 AM Matthias Bünger 
wrote:

> Hey all,
> in this mail I want to share my experiences / thouhgts I had on my way
> from the decision to contribute some code to the Maven project, because
> I think there are some things which may be improved. But before creating
> issues about that I wanted to write here, as it's heavly opinion based
> (obviously ;) ).
>
> To my background: At my work I don't code that much as some years ago,
> but do a lot of team lead, mentoring and (not only as part of the first
> two things) documentation (funny enough one of the documentation I
> currectly overhaul is the one for onboarind new team members and get
> them to work). I'm also one of the maintainers of the JUnit extension
> library "Pioneer" where I primely care about issues and documentation.
> ---
>
> IDE setup and code style:
>
> When I decided trying to contribute some small code fragements as a
> first step I first tried to setup my IDE. So I checked the coding rules
> on the Code style page
> (https://maven.apache.org/developers/conventions/code.html)
>
>
> As I'm more used to Eclipse and it's workspace concept I tried to set up
> this first. Imported the "import order"-file and all except coding
> style. I read the instructions to compile the palantir Java plugin
> (never heart about palantir before) which worked (I think, needed to
> switch to an older JDK for it) but I noticed nothing in Eclipse of it.
> So I tried IntelliJ as I read on the plugin page that it is available in
> the plugin store there. As not that familiar it took quite a long time
> for me to set up a project (workspace) with multiple maven modules, but
> finally I got it. And also got the palantir plugin to worked.
>
> To finish the story of coding style: After I coded somthing the build
> failed as the Spotless plugin said my code does not match the style.
> That confused me quite a lot as that should be done by the planatir
> plugin. But in some places it did not what the spotless check wanted to
> have. I then decided so give a  about palantir and only use
> spotless. I think a statement on the website that the spotless plugin is
> configured and can/should be used would make it easier I think
>
>
> Mojo docs:
> After I've set up my IDE I wanted to know how plugins work so I took the
> Mojo docs and tried to understand by using a quite simple plugin (clean
> plugin)
>
>
> When I read the "Common Bugs and Pitfalls" page
> (https://maven.apache.org/plugin-developers/common-bugs.html) I was very
> confused by the code examples. First I wondered why they are all labeld
> with fixme and therefore not up to date? I then realized that all code
> examples are the "don't do it that way" examples, but the "how you do it
> right" is only written in text (or not at all, e.g. the Logging example)
> - without any code examples. From my experience with juniors at my work
> and from how (many) people in the internet people mostly only look at
> the code examples without further reading the sentences around the
> examples.
>
> I think Benjamin agrees me about that, do you? ;)
> (https://x.com/bmarwell/status/1751539018389475558?s=20)
>
> Logging:
> Information about loggin are wide spreaded and I think that's not good.
>
> - At "Maven 3.1.x loggin" what framework Maven uses, but there is not
> shown how to get the correct logger or logging example
> - At the pitfalls page only the bad one is shown, but not the correct one
> - At the "Maven loggin" page it shows that you should you use
> "Logger.getLogger" but in mosts Mojo codes of plugins (let's take a
> SNAPSHOT of the maven site plugin) always "getLog()" is used and it took
> me some time to understand the difference to the pitfalls page bad example
>
> I suggest to bring that in line and connect it more or centralize it.
>
>
> Integration tests:
> I find it hard to find a good documentation about how to write and
> execute integration tests. On the "testing a plugin" page there is a
> link to a wiki article from 2018. Doesn't make me feel compfortable.
>
>
> Other:
> - There's a "TODO creating and using custom packaging" at the plugin
> developer centre start page.
> - There's a formatting error on the pitfalls page
> - I opend my first PR about three weeks ago and didn't get any response
> yet. I know all do this in their spare time and I wouldn't expect
> responses when opening issues (and I didn't get one since months on my
> first JIRA issue), but from my expierence it's always good  to show at
> least some reaction (esp. to new contributes) - even if it's only to
> thank him and to tell him that a review may be delayed.
>
> I know I'm not yet deep into Maven, but I wanted to share my thoughts of
> my first steps.
>
> Have a good weekend
> Matthias
>
>
> -
> To