Re: Multi-repo experience

[Tamás Cservenák]

Or, ultimately, just release a BOM with all the related versions. And tie
this BOM version release to the most frequent release, and adjust as needed.

T

On Thu, Aug 31, 2023 at 11:27 PM Tamás Cservenák 
wrote:

> Mostly what matters is the release cadence (that is somewhat in line with
> "what works with what').
>
> Rule of thumb: if you have an artifact that SHOULD be released when
> another is released, keep it together.
>
> Otherwise, no need to tie them together (disclaimer: yes, there is all the
> clien side pain, what works with what, etc, but a site could explain that
> just nicely, or, just provide a table of versions).
>
> My 5 cents,
> T
>
> On Thu, Aug 31, 2023 at 3:38 PM Volkan Yazıcı  wrote:
>
>> *[Sorry for the late response. I was busy with incorporating your input
>> into the attack plan document.]*
>>
>> Thanks so much for the pointers and the insight Hervé (and Romain!), much
>> appreciated!
>>
>> For those interested, Log4j's motivation and proposals are shared in this
>> `dev@logging` thread
>> . If
>> you
>> have any feedback, I would be more than happy to hear.
>>
>> On Sat, Aug 26, 2023 at 2:03 PM Hervé Boutemy 
>> wrote:
>>
>> > notice that you call it "multi-repo experience"
>> > it's in fact more about a topic of component-oriented structure, each
>> > component having its own release lifecycle. The fact that each component
>> > has
>> > his own Git repository is just an implementation detail (in the past,
>> each
>> > component had its own root directory in Subversion: see [1] for how we
>> > went
>> > from svn structure to Git one).
>> >
>> > > Would you still go the same route if Maven is founded today?
>> > yes: Maven is a core, with plugins (and extension) = something we would
>> > not
>> > change without loosing critical aspects of Maven
>> > and the fact that some plugins reuse some shared components is normal
>> >
>> > of course, the exact number of plugins and shared components could have
>> > been
>> > done with different granularity
>> >
>> > And on using Google repo tool and the precise directory organisation
>> when
>> > checking out everything, it's an implementation detail:
>> > https://github.com/apache/maven-sources/tree/master
>> > Changing anything here can be done, it's not critical: what is critical
>> is
>> > the
>> > component-oriented approach. Then the granularity chosen for these
>> > components.
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>> >
>> > Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit :
>> > > Hi Volkan,
>> > >
>> > > Yes, I worked a lot on this aspect fo Maven: the result is summarised
>> > here
>> > > https://maven.apache.org/scm.html
>> > >
>> > > As you can see, you can get "Maven Full Sources" in one command using
>> > Google
>> > > "repo" tool.
>> > >
>> > > Please have a llok and we can dive into more details if you need
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
>> > > > 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.
>> > >
>> > > -
>> > > 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: Multi-repo experience

[Tamás Cservenák]

Mostly what matters is the release cadence (that is somewhat in line with
"what works with what').

Rule of thumb: if you have an artifact that SHOULD be released when another
is released, keep it together.

Otherwise, no need to tie them together (disclaimer: yes, there is all the
clien side pain, what works with what, etc, but a site could explain that
just nicely, or, just provide a table of versions).

My 5 cents,
T

On Thu, Aug 31, 2023 at 3:38 PM Volkan Yazıcı  wrote:

> *[Sorry for the late response. I was busy with incorporating your input
> into the attack plan document.]*
>
> Thanks so much for the pointers and the insight Hervé (and Romain!), much
> appreciated!
>
> For those interested, Log4j's motivation and proposals are shared in this
> `dev@logging` thread
> . If you
> have any feedback, I would be more than happy to hear.
>
> On Sat, Aug 26, 2023 at 2:03 PM Hervé Boutemy 
> wrote:
>
> > notice that you call it "multi-repo experience"
> > it's in fact more about a topic of component-oriented structure, each
> > component having its own release lifecycle. The fact that each component
> > has
> > his own Git repository is just an implementation detail (in the past,
> each
> > component had its own root directory in Subversion: see [1] for how we
> > went
> > from svn structure to Git one).
> >
> > > Would you still go the same route if Maven is founded today?
> > yes: Maven is a core, with plugins (and extension) = something we would
> > not
> > change without loosing critical aspects of Maven
> > and the fact that some plugins reuse some shared components is normal
> >
> > of course, the exact number of plugins and shared components could have
> > been
> > done with different granularity
> >
> > And on using Google repo tool and the precise directory organisation when
> > checking out everything, it's an implementation detail:
> > https://github.com/apache/maven-sources/tree/master
> > Changing anything here can be done, it's not critical: what is critical
> is
> > the
> > component-oriented approach. Then the granularity chosen for these
> > components.
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
> >
> > Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit :
> > > Hi Volkan,
> > >
> > > Yes, I worked a lot on this aspect fo Maven: the result is summarised
> > here
> > > https://maven.apache.org/scm.html
> > >
> > > As you can see, you can get "Maven Full Sources" in one command using
> > Google
> > > "repo" tool.
> > >
> > > Please have a llok and we can dive into more details if you need
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> > > > 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.
> > >
> > > -
> > > 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: Multi-repo experience

[Volkan Yazıcı]

*[Sorry for the late response. I was busy with incorporating your input
into the attack plan document.]*

Thanks so much for the pointers and the insight Hervé (and Romain!), much
appreciated!

For those interested, Log4j's motivation and proposals are shared in this
`dev@logging` thread
. If you
have any feedback, I would be more than happy to hear.

On Sat, Aug 26, 2023 at 2:03 PM Hervé Boutemy  wrote:

> notice that you call it "multi-repo experience"
> it's in fact more about a topic of component-oriented structure, each
> component having its own release lifecycle. The fact that each component
> has
> his own Git repository is just an implementation detail (in the past, each
> component had its own root directory in Subversion: see [1] for how we
> went
> from svn structure to Git one).
>
> > Would you still go the same route if Maven is founded today?
> yes: Maven is a core, with plugins (and extension) = something we would
> not
> change without loosing critical aspects of Maven
> and the fact that some plugins reuse some shared components is normal
>
> of course, the exact number of plugins and shared components could have
> been
> done with different granularity
>
> And on using Google repo tool and the precise directory organisation when
> checking out everything, it's an implementation detail:
> https://github.com/apache/maven-sources/tree/master
> Changing anything here can be done, it's not critical: what is critical is
> the
> component-oriented approach. Then the granularity chosen for these
> components.
>
> Regards,
>
> Hervé
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>
> Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit :
> > Hi Volkan,
> >
> > Yes, I worked a lot on this aspect fo Maven: the result is summarised
> here
> > https://maven.apache.org/scm.html
> >
> > As you can see, you can get "Maven Full Sources" in one command using
> Google
> > "repo" tool.
> >
> > Please have a llok and we can dive into more details if you need
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit :
> > > 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.
> >
> > -
> > 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: CVE-2021-26291 for plugin writers

[Hervé Boutemy]

in fact, whatever you do in your plugin POM, they are provided by Maven core 
at runtime (ignoring the precise version the plugin asked for)

but marking them provided in your plugin pom.xml makes this fact more visible

Regards,

Hervé

Le jeudi 31 août 2023, 03:15:15 CEST Jeremy Landis a écrit :
> Make sure your maven artifacts are provided scope then your users can
> continue using old versions just fine to the 3.3.9 support level you have
> now.
> 
> Sent from my Verizon, Samsung Galaxy smartphone
> Get Outlook for Android
> 
> From: Anton Vodonosov 
> Sent: Monday, August 28, 2023 11:14:30 AM
> To: dev@maven.apache.org 
> Subject: CVE-2021-26291 for plugin writers
> 
> Maven 3.8.1 release notes describe CVE-2021-26291 fixed in that version:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apach
> e.org%2Fdocs%2F3.8.1%2Frelease-notes.html=05%7C01%7C%7Cfb1603297a0149d3
> 585e08dba7d986e8%7C84df9e7fe9f640afb435%7C1%7C0%7C63828832493462
> 1732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=EYAH%2FA7JWCBPcZ%2F4wNuUVHJCiNcrh0
> oB1C8cYeIDhu0%3D=0 s.html>
> 
> That's the best explanation of this CVE of all I saw online.
> 
> But it misses guide for plugin authors.
> 
> GitHub's security scanner created this alert for my plugin
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Favodonosov%2Fhashver-maven-plugin%2Fsecurity%2Fdependabot%2F3=05%7C01
> %7C%7Cfb1603297a0149d3585e08dba7d986e8%7C84df9e7fe9f640afb435%7C
> 1%7C0%7C638288324934621732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=rB3V4hX6%2Ba
> N9B8yhv7yrQolTXDL7USf0VkLn75fFvmU%3D=0 v/hashver-maven-plugin/security/dependabot/3> and a corresponding pull
> request, where it suggest to change
> dependency maven-core from 3.3.8 to 3.8.1:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Favodonosov%2Fhashver-maven-plugin%2Fpull%2F11=05%7C01%7C%7Cfb1603297a
> 0149d3585e08dba7d986e8%7C84df9e7fe9f640afb435%7C1%7C0%7C63828832
> 4934621732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=09QeFG3AtERkHZAQ0Wyd%2BjIJMa
> YQmYqf8qoNl20K%2FZ4%3D=0 n-plugin/pull/11>
> 
> I am reluctant to commit this change because
> I am afraid the plugin may stop working for users of older maven versions.
> I suppose this CVE is not relevant to plugin authors, my reasoning
> is in the pull request comments.
> 
> Am I right that the CVE does not affect the plugin?
> 
> It would be good if the 3.8.1 release notes were extended with explanations
> is it safe for plugins to depend on older versions of maven libs.
> 
> Best regards,
> - Anton
> 
> -
> 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