You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2021/12/07 08:47:12 UTC
[DISCUSS] Move maven caching to an external repository
Following the recent work done to integrate the maven caching / incremental
build system into maven, I think it's now time to discuss where we want its
long-term location to be.
This extension was donated a few months ago and provides local and remote
caching of maven project's output, based on computed hashes of the inputs.
It's defined as a maven extension and can be used as a core or build
extension. This avoids building the project and speeds up builds a lot !
The current status of this work resides in 3 branches:
* MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
* MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
* https://github.com/apache/maven/tree/MNG-7129-maven-caching
The two first PRs include the required changes to integrate the extension
in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the one
that should be moved to a separate repository and contain the code for the
extension. The goal is to agree on the location and the final name for the
repository (it can't be changed easily).
I propose maven-caching as the repository / subproject name, but any better
name is welcomed of course.
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 7 décembre 2021, 10:21:47 CET Arnaud Héritier a écrit :
> I agree that having a set of official extensions might be ideal.
see https://maven.apache.org/extensions/
We can publish maven-caching-extension to
https://maven.apache.org/extensions/maven-caching-extension
I can publish the site tonight
it's really like plugins
> Today the most popular are still the Takari ones AFAIK but they aren't
> officially supported by our team and thus probably less used than they
> could/should.
> Due to the git organization @ASF I don't know what is easier between having
> 1 repo or several ones.
> In general I prefer to have 1 repo = 1 lifecycle (the opposite of monorepo)
> but maybe it could have some sense in the long term and some shared code
> ... not sure.
creating one Git repository per project is easy, no problem: once we have the
name, creating the Git repository is just self-service for PMC done in 1
minute
Regards,
Hervé
>
> On Tue, Dec 7, 2021 at 9:53 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> > Howdy,
> >
> > I'd rather group ASF extensions (are there any existing ones aside of
> > caching?),
> > to be clear... so GH repo could be something like
> > apache/maven-caching-extension
> > apache/maven-foobar-extension
> > etc?
> >
> > T
> >
> > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org> wrote:
> > > Following the recent work done to integrate the maven caching /
> >
> > incremental
> >
> > > build system into maven, I think it's now time to discuss where we want
> >
> > its
> >
> > > long-term location to be.
> > >
> > > This extension was donated a few months ago and provides local and
> > > remote
> > > caching of maven project's output, based on computed hashes of the
> >
> > inputs.
> >
> > > It's defined as a maven extension and can be used as a core or build
> > > extension. This avoids building the project and speeds up builds a lot
> > > !
> > >
> > > The current status of this work resides in 3 branches:
> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > >
> > > The two first PRs include the required changes to integrate the
> > > extension
> > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> >
> > one
> >
> > > that should be moved to a separate repository and contain the code for
> >
> > the
> >
> > > extension. The goal is to agree on the location and the final name for
> >
> > the
> >
> > > repository (it can't be changed easily).
> > >
> > > I propose maven-caching as the repository / subproject name, but any
> >
> > better
> >
> > > name is welcomed of course.
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Arnaud Héritier <ah...@gmail.com>.
I agree that having a set of official extensions might be ideal.
Today the most popular are still the Takari ones AFAIK but they aren't
officially supported by our team and thus probably less used than they
could/should.
Due to the git organization @ASF I don't know what is easier between having
1 repo or several ones.
In general I prefer to have 1 repo = 1 lifecycle (the opposite of monorepo)
but maybe it could have some sense in the long term and some shared code
... not sure.
On Tue, Dec 7, 2021 at 9:53 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> I'd rather group ASF extensions (are there any existing ones aside of
> caching?),
> to be clear... so GH repo could be something like
> apache/maven-caching-extension
> apache/maven-foobar-extension
> etc?
>
> T
>
> On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> > Following the recent work done to integrate the maven caching /
> incremental
> > build system into maven, I think it's now time to discuss where we want
> its
> > long-term location to be.
> >
> > This extension was donated a few months ago and provides local and remote
> > caching of maven project's output, based on computed hashes of the
> inputs.
> > It's defined as a maven extension and can be used as a core or build
> > extension. This avoids building the project and speeds up builds a lot !
> >
> > The current status of this work resides in 3 branches:
> > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > The two first PRs include the required changes to integrate the extension
> > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> one
> > that should be moved to a separate repository and contain the code for
> the
> > extension. The goal is to agree on the location and the final name for
> the
> > repository (it can't be changed easily).
> >
> > I propose maven-caching as the repository / subproject name, but any
> better
> > name is welcomed of course.
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
Arnaud Héritier
Twitter/GitHub/... : aheritier
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
perhaps we should create a Jira project?
MBUILDCACHE?
Le mardi 4 janvier 2022, 13:07:09 CET Herve Boutemy a écrit :
> done: https://github.com/apache/maven-build-cache-extension
>
> On 2022/01/04 07:30:40 Guillaume Nodet wrote:
> > I'd go for #2 ...
> >
> > Le mar. 4 janv. 2022 à 00:14, Hervé BOUTEMY <he...@free.fr> a
> >
> > écrit :
> > > yes, I was happy to learn about that shallow + filter approach :)
> > >
> > > now, we have one choice to do:
> > > 1. keep the shallow repository
> > > or
> > > 2. keep a strongly filtered repository done from the shallow
> > >
> > > option 2 gives a smaller Git repository (0.8 MB vs 3.77 MB), but old
> > > commits
> > > cannot be built (because filtering removed many files)
> > > option 1 maintains every commit as buildable as when it was in maven.git
> > >
> > > Which option do you choose?
> > >
> > > nce you choose, if nobody objects, I'll create
> > > maven-build-cache-extension.git
> > > with the content...
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le lundi 3 janvier 2022, 15:15:02 CET Guillaume Nodet a écrit :
> > > > Awesome ! I didn't know about the shallow options during clone.
> > > > This looks good to me !
> > > >
> > > > Guillaume
> > > >
> > > > Le ven. 24 déc. 2021 à 00:14, Hervé BOUTEMY <he...@free.fr> a
> > > >
> > > > écrit :
> > > > > short version:
> > >
> > > > > I think I managed to extract exactly what we wanted:
> > > https://github.com/hboutemy/maven-build-cache-extension-shallow-filtered
> > >
> > > > > please review and confirm the result is ok
> > > > >
> > > > >
> > > > > longer version: how was it done?
> > > > > the first recipe I found is to drop old history:
> > > > >
> > > > > git clone
> > > > > https://github.com/hboutemy/maven-build-cache-extension.git
> > > > > shallow --shallow-since=2021-10-18
> > > > > cd shallow
> > > > > git filter-branch -- --all
> > > > >
> > > > > you can see the intermediate result in
> > > > > https://github.com/hboutemy/maven-build-cache-extension-shallow
> > > > >
> > > > > then I just filtered with "git filter-repo" to remove globally many
> > >
> > > files
> > >
> > > > > that were removed in
> > >
> > > https://github.com/hboutemy/maven-build-cache-extension-shallow/commit/a
> > > 32
> > >
> > > > > 3d9859f091cdd8a2b946c71d12228ec29b70c
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le dimanche 19 décembre 2021, 22:56:56 CET Hervé BOUTEMY a écrit :
> > > > > > I've tried to use git filter-repo, excluding unwanted directories
> > > > > > or
> > > > > > extensions
> > > > > >
> > > > > > here is a sample result:
> > > > > > https://github.com/hboutemy/maven-build-cache-extension-filtered
> > > > > > = 4200 commits
> > > > > >
> > > > > > instead of initial 11700
> > > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > > >
> > > > > > we can still improve the list of directories to exclude
> > > > > >
> > > > > > before taking time for that, I need feedback: what do you think
> > > > > > about
> > > > >
> > > > > this
> > > > >
> > > > > > approach?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit
:
> > > > > > > I've tried various things without any good results.
> > > > > > > Given there's not much history to preserve here, I'd go ahead
> > > > > > > and
> > >
> > > just
> > >
> > > > > > > create a new repo with the current contents of the branch.
> > > > > > > Any objections?
> > > > > > >
> > > > > > > Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> > > > > > > <je...@upstairstechnology.com>
> > > > > > >
> > > > > > > a écrit :
> > > > > > > > I've split git repos before and using filter-branch is the key
> > > > > > > > to
> > > > >
> > > > > keep
> > > > >
> > > > > > > > the
> > > > > > > > desired and purge the rest.
> > > > > > > >
> > > > > > > > From my notes, these two posts helped me:
> > > > > > > > *
> > >
> > > https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-o
> > >
> > > > > > > > ut
> > > > > > > > -into-a-new-repository *
> > >
> > > https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in
> > >
> > > > > > > > -t
> > > > > > > > wo/
> > > > > > > >
> > > > > > > > These are my shortcut notes for doing so, hope they are clear
> > >
> > > enough
> > >
> > > > > for
> > > > >
> > > > > > > > you and help. In a new repo, locally convert a current source
> > > > > > > > subdirectory
> > > > > > > > to the root directory and purge everything else; then push to
> > >
> > > remote
> > >
> > > > > and
> > > > >
> > > > > > > > locally cleanup:
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Make directory for new repo from current repo:
> > > > > > > > git clone current-repo to-new-directory
> > > > > > > >
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Disconnect from current remote immediately to prevent
> > >
> > > catastrophe
> > >
> > > > > and
> > > > >
> > > > > > > > verify none set
> > > > > > > >
> > > > > > > > git remote rm origin
> > > > > > > >
> > > > > > > > git remote -v
> > > > > > > >
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Keep desired dir and move it to top level, remove the rest
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > FOLDER-NAME: which one to keep and move to top level
> > > > > > > > 2.
> > > > > > > >
> > > > > > > > BRANCH-NAME: which branch to do this on (must exist,
> > > > > > > > e.g.
> > > > >
> > > > > master)
> > > > >
> > > > > > > > git filter-branch --prune-empty --subdirectory-filter
> > > > > > > > FOLDER-NAME
> > > > > > > > BRANCH-NAME
> > > > > > > >
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Setup remote repo and verify set
> > > > > > > >
> > > > > > > > git remote add origin
> > >
> > > https://githost.com/NEW-REPOSITORY-NAME.git
> > >
> > > > > > > > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> > > > > > > >
> > > > > > > > git remote -v
> > > > > > > >
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Push to new repo
> > > > > > > >
> > > > > > > > git push -u origin BRANCH-NAME
> > > > > > > >
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Further cleanup: delete all tags (locally only
> > > > > > > > (Powershell))
> > > > > > > >
> > > > > > > > git tag | foreach-object -process { git tag -d $_ }
> > > > > > > >
> > > > > > > > 1.
> > > > > > > >
> > > > > > > > Further cleanup: remove local unreachable/recyclable
> > > > > > > > commits
> > > > > > > > (remnants
> > > > > > > > of prior)
> > > > > > > >
> > > > > > > > git reflog expire --expire-unreachable=now --all
> > > > > > > >
> > > > > > > > git gc --prune=now
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <
> > >
> > > herve.boutemy@free.fr
> > >
> > > > > > > > wrote:
> > > > > > > > > nice work done
> > > > > > > > > I published the result to
> > > > >
> > > > > https://maven.apache.org/ref/caching-LATEST/
> > > > >
> > > > > > > > > now, on moving source to a separate Git repository, I did a
> > >
> > > basic
> > >
> > > > > test
> > > > >
> > > > > > > > > pushing
> > > > > > > > > to a new repository:
> > > > > > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > > > > > >
> > > > > > > > > this leads to getting quite a lot of Maven history
> > > > > > > > >
> > > > > > > > > I'm not a Git wizard: is there a way to cut down the history
> > > > > > > > > to
> > > > >
> > > > > keep
> > > > >
> > > > > > > > > only
> > > > > > > > > the
> > > > > > > > > interesting part when the build cache code donation was
> > > > > > > > > done?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Hervé
> > > > > > > > >
> > > > > > > > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a
> > > > > > > > > écrit
> > > > > > > > >
> > > > > > > > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <
> > > > >
> > > > > herve.boutemy@free.fr> a
> > > > >
> > > > > > > > > écrit :
> > > > > > > > > > > we have most plugins that are simple with only 1
> > >
> > > mono-module
> > >
> > > > > build
> > > > >
> > > > > > > > > > > This makes documentation easy in
> > > > > > > > > > > /plugins/maven-*-plugin/:
> > > > > > > > > > > see https://maven.apache.org/components/plugins/ for
> > > > > > > > > > > full
> > >
> > > list
> > >
> > > > > > > > > > > we have a few components that have a plugin as part of a
> > > > > > > > > > > larger
> > > > > > > > > > > multi-module
> > > > > > > > > > > build, like surefire, jxr, archetype, scm, plugin-tools,
> > > > >
> > > > > enforcer,
> > > > >
> > > > > > > > > > > release, and
> > > > > > > > > > > soon wrapper
> > > > > > > > > > >
> > > > > > > > > > > And from experience, it makes documentation harder
> > > > > > > > > > > because
> > > > >
> > > > > there
> > > > >
> > > > > > > > > > > is
> > > > > > > > >
> > > > > > > > > always
> > > > > > > > >
> > > > > > > > > > > the
> > > > > > > > > > > question of what to write in the plugin pages and what
> > > > > > > > > > > to
> > > > >
> > > > > write in
> > > > >
> > > > > > > > > other
> > > > > > > > >
> > > > > > > > > > > modules. Not talking of navigation from
> > > > >
> > > > > /plugins/maven-xxx-plugin
> > > > >
> > > > > > > > > > > to
> > > > > > > > >
> > > > > > > > > /xxx/
> > > > > > > > >
> > > > > > > > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > > > > > > > >
> > > > > > > > > > > In caching case, I see that there is only one submodule,
> > >
> > > that
> > >
> > > > > is
> > > > >
> > > > > > > > > > > done
> > > > > > > > >
> > > > > > > > > for
> > > > > > > > >
> > > > > > > > > > > ITs
> > > > > > > > > > > with Surefire: is it necessary? isn't
> > > > > > > > > > > maven-invoker-plugin
> > > > >
> > > > > usable,
> > > > >
> > > > > > > > like
> > > > > > > >
> > > > > > > > > > > for
> > > > > > > > > > > plugins?
> > > > > > > > > >
> > > > > > > > > > Yes, that's actually a good point. I thought about that
> > >
> > > when I
> > >
> > > > > read
> > > > >
> > > > > > > > > Tamás
> > > > > > > > >
> > > > > > > > > > answer. I'll double check if the integration tests can be
> > > > > > > > > > merged
> > > > > > > > > > into
> > > > > > > >
> > > > > > > > a
> > > > > > > >
> > > > > > > > > > single module.
> > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > >
> > > > > > > > > > > Hervé
> > > > > > > > > > >
> > > > > > > > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a
> > >
> > > écrit
> > >
> > > > > > > > > > > > I think the repository name should not contain
> > >
> > > 'extension',
> > >
> > > > > > > > > > > > similar
> > > > > > > > >
> > > > > > > > > to
> > > > > > > > >
> > > > > > > > > > > > surefire which provides a plugin, but it a bit more
> > >
> > > complex
> > >
> > > > > > > > > > > > The fact that it is provided as an extension is a
> > > > >
> > > > > technicality
> > > > >
> > > > > > > > > > > > in
> > > > > > > > >
> > > > > > > > > this
> > > > > > > > >
> > > > > > > > > > > case
> > > > > > > > > > >
> > > > > > > > > > > > imho.
> > > > > > > > > > > > No big deal though...
> > > > > > > > > > > >
> > > > > > > > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák
> > > > > > > > > > > > <ta...@cservenak.net>
> > > > > > > >
> > > > > > > > a
> > > > > > > >
> > > > > > > > > > > écrit :
> > > > > > > > > > > > > Howdy,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'd rather group ASF extensions (are there any
> > > > > > > > > > > > > existing
> > > > >
> > > > > ones
> > > > >
> > > > > > > > aside
> > > > > > > >
> > > > > > > > > of
> > > > > > > > >
> > > > > > > > > > > > > caching?),
> > > > > > > > > > > > > to be clear... so GH repo could be something like
> > > > > > > > > > > > > apache/maven-caching-extension
> > > > > > > > > > > > > apache/maven-foobar-extension
> > > > > > > > > > > > > etc?
> > > > > > > > > > > > >
> > > > > > > > > > > > > T
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > > > > > > >
> > > > > > > > gnodet@apache.org>
> > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Following the recent work done to integrate the
> > > > > > > > > > > > > > maven
> > > > > > > > > > > > > > caching
> > > > > > > > > > > > > > /
> > > > > > > > > > > > >
> > > > > > > > > > > > > incremental
> > > > > > > > > > > > >
> > > > > > > > > > > > > > build system into maven, I think it's now time to
> > > > > > > > > > > > > > discuss
> > > > > > > > > > > > > > where
> > > > > > > > >
> > > > > > > > > we
> > > > > > > > >
> > > > > > > > > > > want
> > > > > > > > > > >
> > > > > > > > > > > > > its
> > > > > > > > > > > > >
> > > > > > > > > > > > > > long-term location to be.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This extension was donated a few months ago and
> > >
> > > provides
> > >
> > > > > > > > > > > > > > local
> > > > > > > > >
> > > > > > > > > and
> > > > > > > > >
> > > > > > > > > > > > > > remote
> > > > > > > > > > > > > > caching of maven project's output, based on
> > > > > > > > > > > > > > computed
> > > > >
> > > > > hashes
> > > > >
> > > > > > > > > > > > > > of
> > > > > > > > >
> > > > > > > > > the
> > > > > > > > >
> > > > > > > > > > > > > inputs.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > It's defined as a maven extension and can be used
> > > > > > > > > > > > > > as
> > >
> > > a
> > >
> > > > > core
> > > > >
> > > > > > > > > > > > > > or
> > > > > > > > >
> > > > > > > > > build
> > > > > > > > >
> > > > > > > > > > > > > > extension. This avoids building the project and
> > >
> > > speeds
> > >
> > > > > up
> > > > >
> > > > > > > > > builds a
> > > > > > > > >
> > > > > > > > > > > lot
> > > > > > > > > > >
> > > > > > > > > > > > > > !
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The current status of this work resides in 3
> > >
> > > branches:
> > > > > > > > > > > > > > * MNG-7129-3.8.x (PR at
> > > > > > > > >
> > > > > > > > > https://github.com/apache/maven/pull/622)
> > > > > > > > >
> > > > > > > > > > > > > > * MNG-7129-master (PR at
> > > > > > > > >
> > > > > > > > > https://github.com/apache/maven/pull/607)
> > > > > > > > >
> > > > > > > > > > > > > > *
> > > > > > > >
> > > > > > > > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > > > >
> > > > > > > > > > > > > > The two first PRs include the required changes to
> > > > >
> > > > > integrate
> > > > >
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > extension
> > > > > > > > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master.
> > > > > > > > > > > > > > The
> > >
> > > last
> > >
> > > > > > > > > > > > > > branch
> > > > > > > > >
> > > > > > > > > is
> > > > > > > > >
> > > > > > > > > > > the
> > > > > > > > > > >
> > > > > > > > > > > > > one
> > > > > > > > > > > > >
> > > > > > > > > > > > > > that should be moved to a separate repository and
> > > > > > > > > > > > > > contain
> > > > > > > > > > > > > > the
> > > > > > > > >
> > > > > > > > > code
> > > > > > > > >
> > > > > > > > > > > for
> > > > > > > > > > >
> > > > > > > > > > > > > the
> > > > > > > > > > > > >
> > > > > > > > > > > > > > extension. The goal is to agree on the location
> > > > > > > > > > > > > > and
> > >
> > > the
> > >
> > > > > > > > > > > > > > final
> > > > > > > > >
> > > > > > > > > name
> > > > > > > > >
> > > > > > > > > > > for
> > > > > > > > > > >
> > > > > > > > > > > > > the
> > > > > > > > > > > > >
> > > > > > > > > > > > > > repository (it can't be changed easily).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I propose maven-caching as the repository /
> > >
> > > subproject
> > >
> > > > > name,
> > > > >
> > > > > > > > but
> > > > > > > >
> > > > > > > > > any
> > > > > > > > >
> > > > > > > > > > > > > better
> > > > > > > > > > > > >
> > > > > > > > > > > > > > name is welcomed of course.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > ------------------------
> > > > > > > > > > > > > > Guillaume Nodet
> > > > >
> > > > > ------------------------------------------------------------------
> > > > >
> > > > > > > > > > > --
> > > > > > > > > > > -
> > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > > > > > > > dev-help@maven.apache.org
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > >
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > > ------------------------------------------------------------------
> > > > > > ---
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Herve Boutemy <hb...@apache.org>.
done: https://github.com/apache/maven-build-cache-extension
On 2022/01/04 07:30:40 Guillaume Nodet wrote:
> I'd go for #2 ...
>
> Le mar. 4 janv. 2022 à 00:14, Hervé BOUTEMY <he...@free.fr> a
> écrit :
>
> > yes, I was happy to learn about that shallow + filter approach :)
> >
> > now, we have one choice to do:
> > 1. keep the shallow repository
> > or
> > 2. keep a strongly filtered repository done from the shallow
> >
> > option 2 gives a smaller Git repository (0.8 MB vs 3.77 MB), but old
> > commits
> > cannot be built (because filtering removed many files)
> > option 1 maintains every commit as buildable as when it was in maven.git
> >
> > Which option do you choose?
> >
> > nce you choose, if nobody objects, I'll create
> > maven-build-cache-extension.git
> > with the content...
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 3 janvier 2022, 15:15:02 CET Guillaume Nodet a écrit :
> > > Awesome ! I didn't know about the shallow options during clone.
> > > This looks good to me !
> > >
> > > Guillaume
> > >
> > > Le ven. 24 déc. 2021 à 00:14, Hervé BOUTEMY <he...@free.fr> a
> > >
> > > écrit :
> > > > short version:
> > > > I think I managed to extract exactly what we wanted:
> > > >
> > https://github.com/hboutemy/maven-build-cache-extension-shallow-filtered
> > > > please review and confirm the result is ok
> > > >
> > > >
> > > > longer version: how was it done?
> > > > the first recipe I found is to drop old history:
> > > >
> > > > git clone https://github.com/hboutemy/maven-build-cache-extension.git
> > > > shallow --shallow-since=2021-10-18
> > > > cd shallow
> > > > git filter-branch -- --all
> > > >
> > > > you can see the intermediate result in
> > > > https://github.com/hboutemy/maven-build-cache-extension-shallow
> > > >
> > > > then I just filtered with "git filter-repo" to remove globally many
> > files
> > > > that were removed in
> > > >
> > https://github.com/hboutemy/maven-build-cache-extension-shallow/commit/a32
> > > > 3d9859f091cdd8a2b946c71d12228ec29b70c
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le dimanche 19 décembre 2021, 22:56:56 CET Hervé BOUTEMY a écrit :
> > > > > I've tried to use git filter-repo, excluding unwanted directories or
> > > > > extensions
> > > > >
> > > > > here is a sample result:
> > > > > https://github.com/hboutemy/maven-build-cache-extension-filtered
> > > > > = 4200 commits
> > > > >
> > > > > instead of initial 11700
> > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > >
> > > > > we can still improve the list of directories to exclude
> > > > >
> > > > > before taking time for that, I need feedback: what do you think about
> > > >
> > > > this
> > > >
> > > > > approach?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit :
> > > > > > I've tried various things without any good results.
> > > > > > Given there's not much history to preserve here, I'd go ahead and
> > just
> > > > > > create a new repo with the current contents of the branch.
> > > > > > Any objections?
> > > > > >
> > > > > > Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> > > > > > <je...@upstairstechnology.com>
> > > > > >
> > > > > > a écrit :
> > > > > > > I've split git repos before and using filter-branch is the key to
> > > >
> > > > keep
> > > >
> > > > > > > the
> > > > > > > desired and purge the rest.
> > > > > > >
> > > > > > > From my notes, these two posts helped me:
> > > > > > > *
> > > >
> > > >
> > https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-o
> > > >
> > > > > > > ut
> > > > > > > -into-a-new-repository *
> > > >
> > > >
> > https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in
> > > >
> > > > > > > -t
> > > > > > > wo/
> > > > > > >
> > > > > > > These are my shortcut notes for doing so, hope they are clear
> > enough
> > > >
> > > > for
> > > >
> > > > > > > you and help. In a new repo, locally convert a current source
> > > > > > > subdirectory
> > > > > > > to the root directory and purge everything else; then push to
> > remote
> > > >
> > > > and
> > > >
> > > > > > > locally cleanup:
> > > > > > > 1.
> > > > > > >
> > > > > > > Make directory for new repo from current repo:
> > > > > > > git clone current-repo to-new-directory
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > > Disconnect from current remote immediately to prevent
> > catastrophe
> > > >
> > > > and
> > > >
> > > > > > > verify none set
> > > > > > >
> > > > > > > git remote rm origin
> > > > > > >
> > > > > > > git remote -v
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > > Keep desired dir and move it to top level, remove the rest
> > > > > > > 1.
> > > > > > >
> > > > > > > FOLDER-NAME: which one to keep and move to top level
> > > > > > > 2.
> > > > > > >
> > > > > > > BRANCH-NAME: which branch to do this on (must exist, e.g.
> > > >
> > > > master)
> > > >
> > > > > > > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > > > > > > BRANCH-NAME
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > > Setup remote repo and verify set
> > > > > > >
> > > > > > > git remote add origin
> > https://githost.com/NEW-REPOSITORY-NAME.git
> > > > > > > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> > > > > > >
> > > > > > > git remote -v
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > > Push to new repo
> > > > > > >
> > > > > > > git push -u origin BRANCH-NAME
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > > Further cleanup: delete all tags (locally only (Powershell))
> > > > > > >
> > > > > > > git tag | foreach-object -process { git tag -d $_ }
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > > Further cleanup: remove local unreachable/recyclable commits
> > > > > > > (remnants
> > > > > > > of prior)
> > > > > > >
> > > > > > > git reflog expire --expire-unreachable=now --all
> > > > > > >
> > > > > > > git gc --prune=now
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <
> > herve.boutemy@free.fr
> > > > > > >
> > > > > > > wrote:
> > > > > > > > nice work done
> > > > > > > > I published the result to
> > > >
> > > > https://maven.apache.org/ref/caching-LATEST/
> > > >
> > > > > > > > now, on moving source to a separate Git repository, I did a
> > basic
> > > >
> > > > test
> > > >
> > > > > > > > pushing
> > > > > > > > to a new repository:
> > > > > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > > > > >
> > > > > > > > this leads to getting quite a lot of Maven history
> > > > > > > >
> > > > > > > > I'm not a Git wizard: is there a way to cut down the history to
> > > >
> > > > keep
> > > >
> > > > > > > > only
> > > > > > > > the
> > > > > > > > interesting part when the build cache code donation was done?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Hervé
> > > > > > > >
> > > > > > > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit
> > :
> > > > > > > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <
> > > >
> > > > herve.boutemy@free.fr> a
> > > >
> > > > > > > > écrit :
> > > > > > > > > > we have most plugins that are simple with only 1
> > mono-module
> > > >
> > > > build
> > > >
> > > > > > > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > > > > > > see https://maven.apache.org/components/plugins/ for full
> > list
> > > > > > > > > >
> > > > > > > > > > we have a few components that have a plugin as part of a
> > > > > > > > > > larger
> > > > > > > > > > multi-module
> > > > > > > > > > build, like surefire, jxr, archetype, scm, plugin-tools,
> > > >
> > > > enforcer,
> > > >
> > > > > > > > > > release, and
> > > > > > > > > > soon wrapper
> > > > > > > > > >
> > > > > > > > > > And from experience, it makes documentation harder because
> > > >
> > > > there
> > > >
> > > > > > > > > > is
> > > > > > > >
> > > > > > > > always
> > > > > > > >
> > > > > > > > > > the
> > > > > > > > > > question of what to write in the plugin pages and what to
> > > >
> > > > write in
> > > >
> > > > > > > > other
> > > > > > > >
> > > > > > > > > > modules. Not talking of navigation from
> > > >
> > > > /plugins/maven-xxx-plugin
> > > >
> > > > > > > > > > to
> > > > > > > >
> > > > > > > > /xxx/
> > > > > > > >
> > > > > > > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > > > > > > >
> > > > > > > > > > In caching case, I see that there is only one submodule,
> > that
> > > >
> > > > is
> > > >
> > > > > > > > > > done
> > > > > > > >
> > > > > > > > for
> > > > > > > >
> > > > > > > > > > ITs
> > > > > > > > > > with Surefire: is it necessary? isn't maven-invoker-plugin
> > > >
> > > > usable,
> > > >
> > > > > > > like
> > > > > > >
> > > > > > > > > > for
> > > > > > > > > > plugins?
> > > > > > > > >
> > > > > > > > > Yes, that's actually a good point. I thought about that
> > when I
> > > >
> > > > read
> > > >
> > > > > > > > Tamás
> > > > > > > >
> > > > > > > > > answer. I'll double check if the integration tests can be
> > > > > > > > > merged
> > > > > > > > > into
> > > > > > >
> > > > > > > a
> > > > > > >
> > > > > > > > > single module.
> > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hervé
> > > > > > > > > >
> > > > > > > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a
> > écrit
> > > > > > > > > >
> > > > > > > > > > > I think the repository name should not contain
> > 'extension',
> > > > > > > > > > > similar
> > > > > > > >
> > > > > > > > to
> > > > > > > >
> > > > > > > > > > > surefire which provides a plugin, but it a bit more
> > complex
> > > > > > > > > > > The fact that it is provided as an extension is a
> > > >
> > > > technicality
> > > >
> > > > > > > > > > > in
> > > > > > > >
> > > > > > > > this
> > > > > > > >
> > > > > > > > > > case
> > > > > > > > > >
> > > > > > > > > > > imho.
> > > > > > > > > > > No big deal though...
> > > > > > > > > > >
> > > > > > > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák
> > > > > > > > > > > <ta...@cservenak.net>
> > > > > > >
> > > > > > > a
> > > > > > >
> > > > > > > > > > écrit :
> > > > > > > > > > > > Howdy,
> > > > > > > > > > > >
> > > > > > > > > > > > I'd rather group ASF extensions (are there any existing
> > > >
> > > > ones
> > > >
> > > > > > > aside
> > > > > > >
> > > > > > > > of
> > > > > > > >
> > > > > > > > > > > > caching?),
> > > > > > > > > > > > to be clear... so GH repo could be something like
> > > > > > > > > > > > apache/maven-caching-extension
> > > > > > > > > > > > apache/maven-foobar-extension
> > > > > > > > > > > > etc?
> > > > > > > > > > > >
> > > > > > > > > > > > T
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > > > > > >
> > > > > > > gnodet@apache.org>
> > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > > Following the recent work done to integrate the maven
> > > > > > > > > > > > > caching
> > > > > > > > > > > > > /
> > > > > > > > > > > >
> > > > > > > > > > > > incremental
> > > > > > > > > > > >
> > > > > > > > > > > > > build system into maven, I think it's now time to
> > > > > > > > > > > > > discuss
> > > > > > > > > > > > > where
> > > > > > > >
> > > > > > > > we
> > > > > > > >
> > > > > > > > > > want
> > > > > > > > > >
> > > > > > > > > > > > its
> > > > > > > > > > > >
> > > > > > > > > > > > > long-term location to be.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This extension was donated a few months ago and
> > provides
> > > > > > > > > > > > > local
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > > > > > > > remote
> > > > > > > > > > > > > caching of maven project's output, based on computed
> > > >
> > > > hashes
> > > >
> > > > > > > > > > > > > of
> > > > > > > >
> > > > > > > > the
> > > > > > > >
> > > > > > > > > > > > inputs.
> > > > > > > > > > > >
> > > > > > > > > > > > > It's defined as a maven extension and can be used as
> > a
> > > >
> > > > core
> > > >
> > > > > > > > > > > > > or
> > > > > > > >
> > > > > > > > build
> > > > > > > >
> > > > > > > > > > > > > extension. This avoids building the project and
> > speeds
> > > >
> > > > up
> > > >
> > > > > > > > builds a
> > > > > > > >
> > > > > > > > > > lot
> > > > > > > > > >
> > > > > > > > > > > > > !
> > > > > > > > > > > > >
> > > > > > > > > > > > > The current status of this work resides in 3
> > branches:
> > > > > > > > > > > > > * MNG-7129-3.8.x (PR at
> > > > > > > >
> > > > > > > > https://github.com/apache/maven/pull/622)
> > > > > > > >
> > > > > > > > > > > > > * MNG-7129-master (PR at
> > > > > > > >
> > > > > > > > https://github.com/apache/maven/pull/607)
> > > > > > > >
> > > > > > > > > > > > > *
> > > > > > >
> > > > > > > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > > >
> > > > > > > > > > > > > The two first PRs include the required changes to
> > > >
> > > > integrate
> > > >
> > > > > > > > > > > > > the
> > > > > > > > > > > > > extension
> > > > > > > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The
> > last
> > > > > > > > > > > > > branch
> > > > > > > >
> > > > > > > > is
> > > > > > > >
> > > > > > > > > > the
> > > > > > > > > >
> > > > > > > > > > > > one
> > > > > > > > > > > >
> > > > > > > > > > > > > that should be moved to a separate repository and
> > > > > > > > > > > > > contain
> > > > > > > > > > > > > the
> > > > > > > >
> > > > > > > > code
> > > > > > > >
> > > > > > > > > > for
> > > > > > > > > >
> > > > > > > > > > > > the
> > > > > > > > > > > >
> > > > > > > > > > > > > extension. The goal is to agree on the location and
> > the
> > > > > > > > > > > > > final
> > > > > > > >
> > > > > > > > name
> > > > > > > >
> > > > > > > > > > for
> > > > > > > > > >
> > > > > > > > > > > > the
> > > > > > > > > > > >
> > > > > > > > > > > > > repository (it can't be changed easily).
> > > > > > > > > > > > >
> > > > > > > > > > > > > I propose maven-caching as the repository /
> > subproject
> > > >
> > > > name,
> > > >
> > > > > > > but
> > > > > > >
> > > > > > > > any
> > > > > > > >
> > > > > > > > > > > > better
> > > > > > > > > > > >
> > > > > > > > > > > > > name is welcomed of course.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > ------------------------
> > > > > > > > > > > > > Guillaume Nodet
> > > >
> > > > ------------------------------------------------------------------
> > > >
> > > > > > > > > > --
> > > > > > > > > > -
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > >
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
I'd go for #2 ...
Le mar. 4 janv. 2022 à 00:14, Hervé BOUTEMY <he...@free.fr> a
écrit :
> yes, I was happy to learn about that shallow + filter approach :)
>
> now, we have one choice to do:
> 1. keep the shallow repository
> or
> 2. keep a strongly filtered repository done from the shallow
>
> option 2 gives a smaller Git repository (0.8 MB vs 3.77 MB), but old
> commits
> cannot be built (because filtering removed many files)
> option 1 maintains every commit as buildable as when it was in maven.git
>
> Which option do you choose?
>
> nce you choose, if nobody objects, I'll create
> maven-build-cache-extension.git
> with the content...
>
> Regards,
>
> Hervé
>
> Le lundi 3 janvier 2022, 15:15:02 CET Guillaume Nodet a écrit :
> > Awesome ! I didn't know about the shallow options during clone.
> > This looks good to me !
> >
> > Guillaume
> >
> > Le ven. 24 déc. 2021 à 00:14, Hervé BOUTEMY <he...@free.fr> a
> >
> > écrit :
> > > short version:
> > > I think I managed to extract exactly what we wanted:
> > >
> https://github.com/hboutemy/maven-build-cache-extension-shallow-filtered
> > > please review and confirm the result is ok
> > >
> > >
> > > longer version: how was it done?
> > > the first recipe I found is to drop old history:
> > >
> > > git clone https://github.com/hboutemy/maven-build-cache-extension.git
> > > shallow --shallow-since=2021-10-18
> > > cd shallow
> > > git filter-branch -- --all
> > >
> > > you can see the intermediate result in
> > > https://github.com/hboutemy/maven-build-cache-extension-shallow
> > >
> > > then I just filtered with "git filter-repo" to remove globally many
> files
> > > that were removed in
> > >
> https://github.com/hboutemy/maven-build-cache-extension-shallow/commit/a32
> > > 3d9859f091cdd8a2b946c71d12228ec29b70c
> > >
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 19 décembre 2021, 22:56:56 CET Hervé BOUTEMY a écrit :
> > > > I've tried to use git filter-repo, excluding unwanted directories or
> > > > extensions
> > > >
> > > > here is a sample result:
> > > > https://github.com/hboutemy/maven-build-cache-extension-filtered
> > > > = 4200 commits
> > > >
> > > > instead of initial 11700
> > > > https://github.com/hboutemy/maven-build-cache-extension
> > > >
> > > > we can still improve the list of directories to exclude
> > > >
> > > > before taking time for that, I need feedback: what do you think about
> > >
> > > this
> > >
> > > > approach?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit :
> > > > > I've tried various things without any good results.
> > > > > Given there's not much history to preserve here, I'd go ahead and
> just
> > > > > create a new repo with the current contents of the branch.
> > > > > Any objections?
> > > > >
> > > > > Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> > > > > <je...@upstairstechnology.com>
> > > > >
> > > > > a écrit :
> > > > > > I've split git repos before and using filter-branch is the key to
> > >
> > > keep
> > >
> > > > > > the
> > > > > > desired and purge the rest.
> > > > > >
> > > > > > From my notes, these two posts helped me:
> > > > > > *
> > >
> > >
> https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-o
> > >
> > > > > > ut
> > > > > > -into-a-new-repository *
> > >
> > >
> https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in
> > >
> > > > > > -t
> > > > > > wo/
> > > > > >
> > > > > > These are my shortcut notes for doing so, hope they are clear
> enough
> > >
> > > for
> > >
> > > > > > you and help. In a new repo, locally convert a current source
> > > > > > subdirectory
> > > > > > to the root directory and purge everything else; then push to
> remote
> > >
> > > and
> > >
> > > > > > locally cleanup:
> > > > > > 1.
> > > > > >
> > > > > > Make directory for new repo from current repo:
> > > > > > git clone current-repo to-new-directory
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Disconnect from current remote immediately to prevent
> catastrophe
> > >
> > > and
> > >
> > > > > > verify none set
> > > > > >
> > > > > > git remote rm origin
> > > > > >
> > > > > > git remote -v
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Keep desired dir and move it to top level, remove the rest
> > > > > > 1.
> > > > > >
> > > > > > FOLDER-NAME: which one to keep and move to top level
> > > > > > 2.
> > > > > >
> > > > > > BRANCH-NAME: which branch to do this on (must exist, e.g.
> > >
> > > master)
> > >
> > > > > > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > > > > > BRANCH-NAME
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Setup remote repo and verify set
> > > > > >
> > > > > > git remote add origin
> https://githost.com/NEW-REPOSITORY-NAME.git
> > > > > > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> > > > > >
> > > > > > git remote -v
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Push to new repo
> > > > > >
> > > > > > git push -u origin BRANCH-NAME
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Further cleanup: delete all tags (locally only (Powershell))
> > > > > >
> > > > > > git tag | foreach-object -process { git tag -d $_ }
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Further cleanup: remove local unreachable/recyclable commits
> > > > > > (remnants
> > > > > > of prior)
> > > > > >
> > > > > > git reflog expire --expire-unreachable=now --all
> > > > > >
> > > > > > git gc --prune=now
> > > > > >
> > > > > >
> > > > > > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <
> herve.boutemy@free.fr
> > > > > >
> > > > > > wrote:
> > > > > > > nice work done
> > > > > > > I published the result to
> > >
> > > https://maven.apache.org/ref/caching-LATEST/
> > >
> > > > > > > now, on moving source to a separate Git repository, I did a
> basic
> > >
> > > test
> > >
> > > > > > > pushing
> > > > > > > to a new repository:
> > > > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > > > >
> > > > > > > this leads to getting quite a lot of Maven history
> > > > > > >
> > > > > > > I'm not a Git wizard: is there a way to cut down the history to
> > >
> > > keep
> > >
> > > > > > > only
> > > > > > > the
> > > > > > > interesting part when the build cache code donation was done?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Hervé
> > > > > > >
> > > > > > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit
> :
> > > > > > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <
> > >
> > > herve.boutemy@free.fr> a
> > >
> > > > > > > écrit :
> > > > > > > > > we have most plugins that are simple with only 1
> mono-module
> > >
> > > build
> > >
> > > > > > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > > > > > see https://maven.apache.org/components/plugins/ for full
> list
> > > > > > > > >
> > > > > > > > > we have a few components that have a plugin as part of a
> > > > > > > > > larger
> > > > > > > > > multi-module
> > > > > > > > > build, like surefire, jxr, archetype, scm, plugin-tools,
> > >
> > > enforcer,
> > >
> > > > > > > > > release, and
> > > > > > > > > soon wrapper
> > > > > > > > >
> > > > > > > > > And from experience, it makes documentation harder because
> > >
> > > there
> > >
> > > > > > > > > is
> > > > > > >
> > > > > > > always
> > > > > > >
> > > > > > > > > the
> > > > > > > > > question of what to write in the plugin pages and what to
> > >
> > > write in
> > >
> > > > > > > other
> > > > > > >
> > > > > > > > > modules. Not talking of navigation from
> > >
> > > /plugins/maven-xxx-plugin
> > >
> > > > > > > > > to
> > > > > > >
> > > > > > > /xxx/
> > > > > > >
> > > > > > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > > > > > >
> > > > > > > > > In caching case, I see that there is only one submodule,
> that
> > >
> > > is
> > >
> > > > > > > > > done
> > > > > > >
> > > > > > > for
> > > > > > >
> > > > > > > > > ITs
> > > > > > > > > with Surefire: is it necessary? isn't maven-invoker-plugin
> > >
> > > usable,
> > >
> > > > > > like
> > > > > >
> > > > > > > > > for
> > > > > > > > > plugins?
> > > > > > > >
> > > > > > > > Yes, that's actually a good point. I thought about that
> when I
> > >
> > > read
> > >
> > > > > > > Tamás
> > > > > > >
> > > > > > > > answer. I'll double check if the integration tests can be
> > > > > > > > merged
> > > > > > > > into
> > > > > >
> > > > > > a
> > > > > >
> > > > > > > > single module.
> > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Hervé
> > > > > > > > >
> > > > > > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a
> écrit
> > > > > > > > >
> > > > > > > > > > I think the repository name should not contain
> 'extension',
> > > > > > > > > > similar
> > > > > > >
> > > > > > > to
> > > > > > >
> > > > > > > > > > surefire which provides a plugin, but it a bit more
> complex
> > > > > > > > > > The fact that it is provided as an extension is a
> > >
> > > technicality
> > >
> > > > > > > > > > in
> > > > > > >
> > > > > > > this
> > > > > > >
> > > > > > > > > case
> > > > > > > > >
> > > > > > > > > > imho.
> > > > > > > > > > No big deal though...
> > > > > > > > > >
> > > > > > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák
> > > > > > > > > > <ta...@cservenak.net>
> > > > > >
> > > > > > a
> > > > > >
> > > > > > > > > écrit :
> > > > > > > > > > > Howdy,
> > > > > > > > > > >
> > > > > > > > > > > I'd rather group ASF extensions (are there any existing
> > >
> > > ones
> > >
> > > > > > aside
> > > > > >
> > > > > > > of
> > > > > > >
> > > > > > > > > > > caching?),
> > > > > > > > > > > to be clear... so GH repo could be something like
> > > > > > > > > > > apache/maven-caching-extension
> > > > > > > > > > > apache/maven-foobar-extension
> > > > > > > > > > > etc?
> > > > > > > > > > >
> > > > > > > > > > > T
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > > > > >
> > > > > > gnodet@apache.org>
> > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > Following the recent work done to integrate the maven
> > > > > > > > > > > > caching
> > > > > > > > > > > > /
> > > > > > > > > > >
> > > > > > > > > > > incremental
> > > > > > > > > > >
> > > > > > > > > > > > build system into maven, I think it's now time to
> > > > > > > > > > > > discuss
> > > > > > > > > > > > where
> > > > > > >
> > > > > > > we
> > > > > > >
> > > > > > > > > want
> > > > > > > > >
> > > > > > > > > > > its
> > > > > > > > > > >
> > > > > > > > > > > > long-term location to be.
> > > > > > > > > > > >
> > > > > > > > > > > > This extension was donated a few months ago and
> provides
> > > > > > > > > > > > local
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > > > > > > > remote
> > > > > > > > > > > > caching of maven project's output, based on computed
> > >
> > > hashes
> > >
> > > > > > > > > > > > of
> > > > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > > > > inputs.
> > > > > > > > > > >
> > > > > > > > > > > > It's defined as a maven extension and can be used as
> a
> > >
> > > core
> > >
> > > > > > > > > > > > or
> > > > > > >
> > > > > > > build
> > > > > > >
> > > > > > > > > > > > extension. This avoids building the project and
> speeds
> > >
> > > up
> > >
> > > > > > > builds a
> > > > > > >
> > > > > > > > > lot
> > > > > > > > >
> > > > > > > > > > > > !
> > > > > > > > > > > >
> > > > > > > > > > > > The current status of this work resides in 3
> branches:
> > > > > > > > > > > > * MNG-7129-3.8.x (PR at
> > > > > > >
> > > > > > > https://github.com/apache/maven/pull/622)
> > > > > > >
> > > > > > > > > > > > * MNG-7129-master (PR at
> > > > > > >
> > > > > > > https://github.com/apache/maven/pull/607)
> > > > > > >
> > > > > > > > > > > > *
> > > > > >
> > > > > > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > >
> > > > > > > > > > > > The two first PRs include the required changes to
> > >
> > > integrate
> > >
> > > > > > > > > > > > the
> > > > > > > > > > > > extension
> > > > > > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The
> last
> > > > > > > > > > > > branch
> > > > > > >
> > > > > > > is
> > > > > > >
> > > > > > > > > the
> > > > > > > > >
> > > > > > > > > > > one
> > > > > > > > > > >
> > > > > > > > > > > > that should be moved to a separate repository and
> > > > > > > > > > > > contain
> > > > > > > > > > > > the
> > > > > > >
> > > > > > > code
> > > > > > >
> > > > > > > > > for
> > > > > > > > >
> > > > > > > > > > > the
> > > > > > > > > > >
> > > > > > > > > > > > extension. The goal is to agree on the location and
> the
> > > > > > > > > > > > final
> > > > > > >
> > > > > > > name
> > > > > > >
> > > > > > > > > for
> > > > > > > > >
> > > > > > > > > > > the
> > > > > > > > > > >
> > > > > > > > > > > > repository (it can't be changed easily).
> > > > > > > > > > > >
> > > > > > > > > > > > I propose maven-caching as the repository /
> subproject
> > >
> > > name,
> > >
> > > > > > but
> > > > > >
> > > > > > > any
> > > > > > >
> > > > > > > > > > > better
> > > > > > > > > > >
> > > > > > > > > > > > name is welcomed of course.
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > ------------------------
> > > > > > > > > > > > Guillaume Nodet
> > >
> > > ------------------------------------------------------------------
> > >
> > > > > > > > > --
> > > > > > > > > -
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > >
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
yes, I was happy to learn about that shallow + filter approach :)
now, we have one choice to do:
1. keep the shallow repository
or
2. keep a strongly filtered repository done from the shallow
option 2 gives a smaller Git repository (0.8 MB vs 3.77 MB), but old commits
cannot be built (because filtering removed many files)
option 1 maintains every commit as buildable as when it was in maven.git
Which option do you choose?
nce you choose, if nobody objects, I'll create maven-build-cache-extension.git
with the content...
Regards,
Hervé
Le lundi 3 janvier 2022, 15:15:02 CET Guillaume Nodet a écrit :
> Awesome ! I didn't know about the shallow options during clone.
> This looks good to me !
>
> Guillaume
>
> Le ven. 24 déc. 2021 à 00:14, Hervé BOUTEMY <he...@free.fr> a
>
> écrit :
> > short version:
> > I think I managed to extract exactly what we wanted:
> > https://github.com/hboutemy/maven-build-cache-extension-shallow-filtered
> > please review and confirm the result is ok
> >
> >
> > longer version: how was it done?
> > the first recipe I found is to drop old history:
> >
> > git clone https://github.com/hboutemy/maven-build-cache-extension.git
> > shallow --shallow-since=2021-10-18
> > cd shallow
> > git filter-branch -- --all
> >
> > you can see the intermediate result in
> > https://github.com/hboutemy/maven-build-cache-extension-shallow
> >
> > then I just filtered with "git filter-repo" to remove globally many files
> > that were removed in
> > https://github.com/hboutemy/maven-build-cache-extension-shallow/commit/a32
> > 3d9859f091cdd8a2b946c71d12228ec29b70c
> >
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 19 décembre 2021, 22:56:56 CET Hervé BOUTEMY a écrit :
> > > I've tried to use git filter-repo, excluding unwanted directories or
> > > extensions
> > >
> > > here is a sample result:
> > > https://github.com/hboutemy/maven-build-cache-extension-filtered
> > > = 4200 commits
> > >
> > > instead of initial 11700
> > > https://github.com/hboutemy/maven-build-cache-extension
> > >
> > > we can still improve the list of directories to exclude
> > >
> > > before taking time for that, I need feedback: what do you think about
> >
> > this
> >
> > > approach?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit :
> > > > I've tried various things without any good results.
> > > > Given there's not much history to preserve here, I'd go ahead and just
> > > > create a new repo with the current contents of the branch.
> > > > Any objections?
> > > >
> > > > Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> > > > <je...@upstairstechnology.com>
> > > >
> > > > a écrit :
> > > > > I've split git repos before and using filter-branch is the key to
> >
> > keep
> >
> > > > > the
> > > > > desired and purge the rest.
> > > > >
> > > > > From my notes, these two posts helped me:
> > > > > *
> >
> > https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-o
> >
> > > > > ut
> > > > > -into-a-new-repository *
> >
> > https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in
> >
> > > > > -t
> > > > > wo/
> > > > >
> > > > > These are my shortcut notes for doing so, hope they are clear enough
> >
> > for
> >
> > > > > you and help. In a new repo, locally convert a current source
> > > > > subdirectory
> > > > > to the root directory and purge everything else; then push to remote
> >
> > and
> >
> > > > > locally cleanup:
> > > > > 1.
> > > > >
> > > > > Make directory for new repo from current repo:
> > > > > git clone current-repo to-new-directory
> > > > >
> > > > > 1.
> > > > >
> > > > > Disconnect from current remote immediately to prevent catastrophe
> >
> > and
> >
> > > > > verify none set
> > > > >
> > > > > git remote rm origin
> > > > >
> > > > > git remote -v
> > > > >
> > > > > 1.
> > > > >
> > > > > Keep desired dir and move it to top level, remove the rest
> > > > > 1.
> > > > >
> > > > > FOLDER-NAME: which one to keep and move to top level
> > > > > 2.
> > > > >
> > > > > BRANCH-NAME: which branch to do this on (must exist, e.g.
> >
> > master)
> >
> > > > > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > > > > BRANCH-NAME
> > > > >
> > > > > 1.
> > > > >
> > > > > Setup remote repo and verify set
> > > > >
> > > > > git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> > > > > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> > > > >
> > > > > git remote -v
> > > > >
> > > > > 1.
> > > > >
> > > > > Push to new repo
> > > > >
> > > > > git push -u origin BRANCH-NAME
> > > > >
> > > > > 1.
> > > > >
> > > > > Further cleanup: delete all tags (locally only (Powershell))
> > > > >
> > > > > git tag | foreach-object -process { git tag -d $_ }
> > > > >
> > > > > 1.
> > > > >
> > > > > Further cleanup: remove local unreachable/recyclable commits
> > > > > (remnants
> > > > > of prior)
> > > > >
> > > > > git reflog expire --expire-unreachable=now --all
> > > > >
> > > > > git gc --prune=now
> > > > >
> > > > >
> > > > > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <herve.boutemy@free.fr
> > > > >
> > > > > wrote:
> > > > > > nice work done
> > > > > > I published the result to
> >
> > https://maven.apache.org/ref/caching-LATEST/
> >
> > > > > > now, on moving source to a separate Git repository, I did a basic
> >
> > test
> >
> > > > > > pushing
> > > > > > to a new repository:
> > > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > > >
> > > > > > this leads to getting quite a lot of Maven history
> > > > > >
> > > > > > I'm not a Git wizard: is there a way to cut down the history to
> >
> > keep
> >
> > > > > > only
> > > > > > the
> > > > > > interesting part when the build cache code donation was done?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > > > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <
> >
> > herve.boutemy@free.fr> a
> >
> > > > > > écrit :
> > > > > > > > we have most plugins that are simple with only 1 mono-module
> >
> > build
> >
> > > > > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > > > > see https://maven.apache.org/components/plugins/ for full list
> > > > > > > >
> > > > > > > > we have a few components that have a plugin as part of a
> > > > > > > > larger
> > > > > > > > multi-module
> > > > > > > > build, like surefire, jxr, archetype, scm, plugin-tools,
> >
> > enforcer,
> >
> > > > > > > > release, and
> > > > > > > > soon wrapper
> > > > > > > >
> > > > > > > > And from experience, it makes documentation harder because
> >
> > there
> >
> > > > > > > > is
> > > > > >
> > > > > > always
> > > > > >
> > > > > > > > the
> > > > > > > > question of what to write in the plugin pages and what to
> >
> > write in
> >
> > > > > > other
> > > > > >
> > > > > > > > modules. Not talking of navigation from
> >
> > /plugins/maven-xxx-plugin
> >
> > > > > > > > to
> > > > > >
> > > > > > /xxx/
> > > > > >
> > > > > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > > > > >
> > > > > > > > In caching case, I see that there is only one submodule, that
> >
> > is
> >
> > > > > > > > done
> > > > > >
> > > > > > for
> > > > > >
> > > > > > > > ITs
> > > > > > > > with Surefire: is it necessary? isn't maven-invoker-plugin
> >
> > usable,
> >
> > > > > like
> > > > >
> > > > > > > > for
> > > > > > > > plugins?
> > > > > > >
> > > > > > > Yes, that's actually a good point. I thought about that when I
> >
> > read
> >
> > > > > > Tamás
> > > > > >
> > > > > > > answer. I'll double check if the integration tests can be
> > > > > > > merged
> > > > > > > into
> > > > >
> > > > > a
> > > > >
> > > > > > > single module.
> > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Hervé
> > > > > > > >
> > > > > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit
> > > > > > > >
> > > > > > > > > I think the repository name should not contain 'extension',
> > > > > > > > > similar
> > > > > >
> > > > > > to
> > > > > >
> > > > > > > > > surefire which provides a plugin, but it a bit more complex
> > > > > > > > > The fact that it is provided as an extension is a
> >
> > technicality
> >
> > > > > > > > > in
> > > > > >
> > > > > > this
> > > > > >
> > > > > > > > case
> > > > > > > >
> > > > > > > > > imho.
> > > > > > > > > No big deal though...
> > > > > > > > >
> > > > > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák
> > > > > > > > > <ta...@cservenak.net>
> > > > >
> > > > > a
> > > > >
> > > > > > > > écrit :
> > > > > > > > > > Howdy,
> > > > > > > > > >
> > > > > > > > > > I'd rather group ASF extensions (are there any existing
> >
> > ones
> >
> > > > > aside
> > > > >
> > > > > > of
> > > > > >
> > > > > > > > > > caching?),
> > > > > > > > > > to be clear... so GH repo could be something like
> > > > > > > > > > apache/maven-caching-extension
> > > > > > > > > > apache/maven-foobar-extension
> > > > > > > > > > etc?
> > > > > > > > > >
> > > > > > > > > > T
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > > > >
> > > > > gnodet@apache.org>
> > > > >
> > > > > > > > wrote:
> > > > > > > > > > > Following the recent work done to integrate the maven
> > > > > > > > > > > caching
> > > > > > > > > > > /
> > > > > > > > > >
> > > > > > > > > > incremental
> > > > > > > > > >
> > > > > > > > > > > build system into maven, I think it's now time to
> > > > > > > > > > > discuss
> > > > > > > > > > > where
> > > > > >
> > > > > > we
> > > > > >
> > > > > > > > want
> > > > > > > >
> > > > > > > > > > its
> > > > > > > > > >
> > > > > > > > > > > long-term location to be.
> > > > > > > > > > >
> > > > > > > > > > > This extension was donated a few months ago and provides
> > > > > > > > > > > local
> > > > > >
> > > > > > and
> > > > > >
> > > > > > > > > > > remote
> > > > > > > > > > > caching of maven project's output, based on computed
> >
> > hashes
> >
> > > > > > > > > > > of
> > > > > >
> > > > > > the
> > > > > >
> > > > > > > > > > inputs.
> > > > > > > > > >
> > > > > > > > > > > It's defined as a maven extension and can be used as a
> >
> > core
> >
> > > > > > > > > > > or
> > > > > >
> > > > > > build
> > > > > >
> > > > > > > > > > > extension. This avoids building the project and speeds
> >
> > up
> >
> > > > > > builds a
> > > > > >
> > > > > > > > lot
> > > > > > > >
> > > > > > > > > > > !
> > > > > > > > > > >
> > > > > > > > > > > The current status of this work resides in 3 branches:
> > > > > > > > > > > * MNG-7129-3.8.x (PR at
> > > > > >
> > > > > > https://github.com/apache/maven/pull/622)
> > > > > >
> > > > > > > > > > > * MNG-7129-master (PR at
> > > > > >
> > > > > > https://github.com/apache/maven/pull/607)
> > > > > >
> > > > > > > > > > > *
> > > > >
> > > > > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > >
> > > > > > > > > > > The two first PRs include the required changes to
> >
> > integrate
> >
> > > > > > > > > > > the
> > > > > > > > > > > extension
> > > > > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last
> > > > > > > > > > > branch
> > > > > >
> > > > > > is
> > > > > >
> > > > > > > > the
> > > > > > > >
> > > > > > > > > > one
> > > > > > > > > >
> > > > > > > > > > > that should be moved to a separate repository and
> > > > > > > > > > > contain
> > > > > > > > > > > the
> > > > > >
> > > > > > code
> > > > > >
> > > > > > > > for
> > > > > > > >
> > > > > > > > > > the
> > > > > > > > > >
> > > > > > > > > > > extension. The goal is to agree on the location and the
> > > > > > > > > > > final
> > > > > >
> > > > > > name
> > > > > >
> > > > > > > > for
> > > > > > > >
> > > > > > > > > > the
> > > > > > > > > >
> > > > > > > > > > > repository (it can't be changed easily).
> > > > > > > > > > >
> > > > > > > > > > > I propose maven-caching as the repository / subproject
> >
> > name,
> >
> > > > > but
> > > > >
> > > > > > any
> > > > > >
> > > > > > > > > > better
> > > > > > > > > >
> > > > > > > > > > > name is welcomed of course.
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > ------------------------
> > > > > > > > > > > Guillaume Nodet
> >
> > ------------------------------------------------------------------
> >
> > > > > > > > --
> > > > > > > > -
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
Awesome ! I didn't know about the shallow options during clone.
This looks good to me !
Guillaume
Le ven. 24 déc. 2021 à 00:14, Hervé BOUTEMY <he...@free.fr> a
écrit :
> short version:
> I think I managed to extract exactly what we wanted:
> https://github.com/hboutemy/maven-build-cache-extension-shallow-filtered
> please review and confirm the result is ok
>
>
> longer version: how was it done?
> the first recipe I found is to drop old history:
>
> git clone https://github.com/hboutemy/maven-build-cache-extension.git
> shallow --shallow-since=2021-10-18
> cd shallow
> git filter-branch -- --all
>
> you can see the intermediate result in
> https://github.com/hboutemy/maven-build-cache-extension-shallow
>
> then I just filtered with "git filter-repo" to remove globally many files
> that were removed in
> https://github.com/hboutemy/maven-build-cache-extension-shallow/commit/a323d9859f091cdd8a2b946c71d12228ec29b70c
>
>
> Regards,
>
> Hervé
>
> Le dimanche 19 décembre 2021, 22:56:56 CET Hervé BOUTEMY a écrit :
> > I've tried to use git filter-repo, excluding unwanted directories or
> > extensions
> >
> > here is a sample result:
> > https://github.com/hboutemy/maven-build-cache-extension-filtered
> > = 4200 commits
> >
> > instead of initial 11700
> > https://github.com/hboutemy/maven-build-cache-extension
> >
> > we can still improve the list of directories to exclude
> >
> > before taking time for that, I need feedback: what do you think about
> this
> > approach?
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit :
> > > I've tried various things without any good results.
> > > Given there's not much history to preserve here, I'd go ahead and just
> > > create a new repo with the current contents of the branch.
> > > Any objections?
> > >
> > > Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> > > <je...@upstairstechnology.com>
> > >
> > > a écrit :
> > > > I've split git repos before and using filter-branch is the key to
> keep
> > > > the
> > > > desired and purge the rest.
> > > >
> > > > From my notes, these two posts helped me:
> > > > *
> > > >
> > > >
> https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-o
> > > > ut
> > > > -into-a-new-repository *
> > > >
> > > >
> https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in
> > > > -t
> > > > wo/
> > > >
> > > > These are my shortcut notes for doing so, hope they are clear enough
> for
> > > > you and help. In a new repo, locally convert a current source
> > > > subdirectory
> > > > to the root directory and purge everything else; then push to remote
> and
> > > >
> > > > locally cleanup:
> > > > 1.
> > > >
> > > > Make directory for new repo from current repo:
> > > > git clone current-repo to-new-directory
> > > >
> > > > 1.
> > > >
> > > > Disconnect from current remote immediately to prevent catastrophe
> and
> > > > verify none set
> > > >
> > > > git remote rm origin
> > > >
> > > > git remote -v
> > > >
> > > > 1.
> > > >
> > > > Keep desired dir and move it to top level, remove the rest
> > > > 1.
> > > >
> > > > FOLDER-NAME: which one to keep and move to top level
> > > > 2.
> > > >
> > > > BRANCH-NAME: which branch to do this on (must exist, e.g.
> master)
> > > >
> > > > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > > > BRANCH-NAME
> > > >
> > > > 1.
> > > >
> > > > Setup remote repo and verify set
> > > >
> > > > git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> > > > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> > > >
> > > > git remote -v
> > > >
> > > > 1.
> > > >
> > > > Push to new repo
> > > >
> > > > git push -u origin BRANCH-NAME
> > > >
> > > > 1.
> > > >
> > > > Further cleanup: delete all tags (locally only (Powershell))
> > > >
> > > > git tag | foreach-object -process { git tag -d $_ }
> > > >
> > > > 1.
> > > >
> > > > Further cleanup: remove local unreachable/recyclable commits
> > > > (remnants
> > > > of prior)
> > > >
> > > > git reflog expire --expire-unreachable=now --all
> > > >
> > > > git gc --prune=now
> > > >
> > > >
> > > > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <herve.boutemy@free.fr
> >
> > > >
> > > > wrote:
> > > > > nice work done
> > > > > I published the result to
> https://maven.apache.org/ref/caching-LATEST/
> > > > >
> > > > > now, on moving source to a separate Git repository, I did a basic
> test
> > > > > pushing
> > > > > to a new repository:
> > > > > https://github.com/hboutemy/maven-build-cache-extension
> > > > >
> > > > > this leads to getting quite a lot of Maven history
> > > > >
> > > > > I'm not a Git wizard: is there a way to cut down the history to
> keep
> > > > > only
> > > > > the
> > > > > interesting part when the build cache code donation was done?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <
> herve.boutemy@free.fr> a
> > > > >
> > > > > écrit :
> > > > > > > we have most plugins that are simple with only 1 mono-module
> build
> > > > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > > > see https://maven.apache.org/components/plugins/ for full list
> > > > > > >
> > > > > > > we have a few components that have a plugin as part of a larger
> > > > > > > multi-module
> > > > > > > build, like surefire, jxr, archetype, scm, plugin-tools,
> enforcer,
> > > > > > > release, and
> > > > > > > soon wrapper
> > > > > > >
> > > > > > > And from experience, it makes documentation harder because
> there
> > > > > > > is
> > > > >
> > > > > always
> > > > >
> > > > > > > the
> > > > > > > question of what to write in the plugin pages and what to
> write in
> > > > >
> > > > > other
> > > > >
> > > > > > > modules. Not talking of navigation from
> /plugins/maven-xxx-plugin
> > > > > > > to
> > > > >
> > > > > /xxx/
> > > > >
> > > > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > > > >
> > > > > > > In caching case, I see that there is only one submodule, that
> is
> > > > > > > done
> > > > >
> > > > > for
> > > > >
> > > > > > > ITs
> > > > > > > with Surefire: is it necessary? isn't maven-invoker-plugin
> usable,
> > > >
> > > > like
> > > >
> > > > > > > for
> > > > > > > plugins?
> > > > > >
> > > > > > Yes, that's actually a good point. I thought about that when I
> read
> > > > >
> > > > > Tamás
> > > > >
> > > > > > answer. I'll double check if the integration tests can be merged
> > > > > > into
> > > >
> > > > a
> > > >
> > > > > > single module.
> > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Hervé
> > > > > > >
> > > > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit
> :
> > > > > > > > I think the repository name should not contain 'extension',
> > > > > > > > similar
> > > > >
> > > > > to
> > > > >
> > > > > > > > surefire which provides a plugin, but it a bit more complex
> > > > > > > > The fact that it is provided as an extension is a
> technicality
> > > > > > > > in
> > > > >
> > > > > this
> > > > >
> > > > > > > case
> > > > > > >
> > > > > > > > imho.
> > > > > > > > No big deal though...
> > > > > > > >
> > > > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák
> > > > > > > > <ta...@cservenak.net>
> > > >
> > > > a
> > > >
> > > > > > > écrit :
> > > > > > > > > Howdy,
> > > > > > > > >
> > > > > > > > > I'd rather group ASF extensions (are there any existing
> ones
> > > >
> > > > aside
> > > >
> > > > > of
> > > > >
> > > > > > > > > caching?),
> > > > > > > > > to be clear... so GH repo could be something like
> > > > > > > > > apache/maven-caching-extension
> > > > > > > > > apache/maven-foobar-extension
> > > > > > > > > etc?
> > > > > > > > >
> > > > > > > > > T
> > > > > > > > >
> > > > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > > >
> > > > gnodet@apache.org>
> > > >
> > > > > > > wrote:
> > > > > > > > > > Following the recent work done to integrate the maven
> > > > > > > > > > caching
> > > > > > > > > > /
> > > > > > > > >
> > > > > > > > > incremental
> > > > > > > > >
> > > > > > > > > > build system into maven, I think it's now time to discuss
> > > > > > > > > > where
> > > > >
> > > > > we
> > > > >
> > > > > > > want
> > > > > > >
> > > > > > > > > its
> > > > > > > > >
> > > > > > > > > > long-term location to be.
> > > > > > > > > >
> > > > > > > > > > This extension was donated a few months ago and provides
> > > > > > > > > > local
> > > > >
> > > > > and
> > > > >
> > > > > > > > > > remote
> > > > > > > > > > caching of maven project's output, based on computed
> hashes
> > > > > > > > > > of
> > > > >
> > > > > the
> > > > >
> > > > > > > > > inputs.
> > > > > > > > >
> > > > > > > > > > It's defined as a maven extension and can be used as a
> core
> > > > > > > > > > or
> > > > >
> > > > > build
> > > > >
> > > > > > > > > > extension. This avoids building the project and speeds
> up
> > > > >
> > > > > builds a
> > > > >
> > > > > > > lot
> > > > > > >
> > > > > > > > > > !
> > > > > > > > > >
> > > > > > > > > > The current status of this work resides in 3 branches:
> > > > > > > > > > * MNG-7129-3.8.x (PR at
> > > > >
> > > > > https://github.com/apache/maven/pull/622)
> > > > >
> > > > > > > > > > * MNG-7129-master (PR at
> > > > >
> > > > > https://github.com/apache/maven/pull/607)
> > > > >
> > > > > > > > > > *
> > > >
> > > > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > >
> > > > > > > > > > The two first PRs include the required changes to
> integrate
> > > > > > > > > > the
> > > > > > > > > > extension
> > > > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last
> > > > > > > > > > branch
> > > > >
> > > > > is
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > > one
> > > > > > > > >
> > > > > > > > > > that should be moved to a separate repository and contain
> > > > > > > > > > the
> > > > >
> > > > > code
> > > > >
> > > > > > > for
> > > > > > >
> > > > > > > > > the
> > > > > > > > >
> > > > > > > > > > extension. The goal is to agree on the location and the
> > > > > > > > > > final
> > > > >
> > > > > name
> > > > >
> > > > > > > for
> > > > > > >
> > > > > > > > > the
> > > > > > > > >
> > > > > > > > > > repository (it can't be changed easily).
> > > > > > > > > >
> > > > > > > > > > I propose maven-caching as the repository / subproject
> name,
> > > >
> > > > but
> > > >
> > > > > any
> > > > >
> > > > > > > > > better
> > > > > > > > >
> > > > > > > > > > name is welcomed of course.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > ------------------------
> > > > > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > >
> ------------------------------------------------------------------
> > > > > > > --
> > > > > > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
short version:
I think I managed to extract exactly what we wanted:
https://github.com/hboutemy/maven-build-cache-extension-shallow-filtered
please review and confirm the result is ok
longer version: how was it done?
the first recipe I found is to drop old history:
git clone https://github.com/hboutemy/maven-build-cache-extension.git shallow --shallow-since=2021-10-18
cd shallow
git filter-branch -- --all
you can see the intermediate result in https://github.com/hboutemy/maven-build-cache-extension-shallow
then I just filtered with "git filter-repo" to remove globally many files that were removed in https://github.com/hboutemy/maven-build-cache-extension-shallow/commit/a323d9859f091cdd8a2b946c71d12228ec29b70c
Regards,
Hervé
Le dimanche 19 décembre 2021, 22:56:56 CET Hervé BOUTEMY a écrit :
> I've tried to use git filter-repo, excluding unwanted directories or
> extensions
>
> here is a sample result:
> https://github.com/hboutemy/maven-build-cache-extension-filtered
> = 4200 commits
>
> instead of initial 11700
> https://github.com/hboutemy/maven-build-cache-extension
>
> we can still improve the list of directories to exclude
>
> before taking time for that, I need feedback: what do you think about this
> approach?
>
> Regards,
>
> Hervé
>
> Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit :
> > I've tried various things without any good results.
> > Given there's not much history to preserve here, I'd go ahead and just
> > create a new repo with the current contents of the branch.
> > Any objections?
> >
> > Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> > <je...@upstairstechnology.com>
> >
> > a écrit :
> > > I've split git repos before and using filter-branch is the key to keep
> > > the
> > > desired and purge the rest.
> > >
> > > From my notes, these two posts helped me:
> > > *
> > >
> > > https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-o
> > > ut
> > > -into-a-new-repository *
> > >
> > > https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in
> > > -t
> > > wo/
> > >
> > > These are my shortcut notes for doing so, hope they are clear enough for
> > > you and help. In a new repo, locally convert a current source
> > > subdirectory
> > > to the root directory and purge everything else; then push to remote and
> > >
> > > locally cleanup:
> > > 1.
> > >
> > > Make directory for new repo from current repo:
> > > git clone current-repo to-new-directory
> > >
> > > 1.
> > >
> > > Disconnect from current remote immediately to prevent catastrophe and
> > > verify none set
> > >
> > > git remote rm origin
> > >
> > > git remote -v
> > >
> > > 1.
> > >
> > > Keep desired dir and move it to top level, remove the rest
> > > 1.
> > >
> > > FOLDER-NAME: which one to keep and move to top level
> > > 2.
> > >
> > > BRANCH-NAME: which branch to do this on (must exist, e.g. master)
> > >
> > > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > > BRANCH-NAME
> > >
> > > 1.
> > >
> > > Setup remote repo and verify set
> > >
> > > git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> > > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> > >
> > > git remote -v
> > >
> > > 1.
> > >
> > > Push to new repo
> > >
> > > git push -u origin BRANCH-NAME
> > >
> > > 1.
> > >
> > > Further cleanup: delete all tags (locally only (Powershell))
> > >
> > > git tag | foreach-object -process { git tag -d $_ }
> > >
> > > 1.
> > >
> > > Further cleanup: remove local unreachable/recyclable commits
> > > (remnants
> > > of prior)
> > >
> > > git reflog expire --expire-unreachable=now --all
> > >
> > > git gc --prune=now
> > >
> > >
> > > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <he...@free.fr>
> > >
> > > wrote:
> > > > nice work done
> > > > I published the result to https://maven.apache.org/ref/caching-LATEST/
> > > >
> > > > now, on moving source to a separate Git repository, I did a basic test
> > > > pushing
> > > > to a new repository:
> > > > https://github.com/hboutemy/maven-build-cache-extension
> > > >
> > > > this leads to getting quite a lot of Maven history
> > > >
> > > > I'm not a Git wizard: is there a way to cut down the history to keep
> > > > only
> > > > the
> > > > interesting part when the build cache code donation was done?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a
> > > >
> > > > écrit :
> > > > > > we have most plugins that are simple with only 1 mono-module build
> > > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > > see https://maven.apache.org/components/plugins/ for full list
> > > > > >
> > > > > > we have a few components that have a plugin as part of a larger
> > > > > > multi-module
> > > > > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > > > > release, and
> > > > > > soon wrapper
> > > > > >
> > > > > > And from experience, it makes documentation harder because there
> > > > > > is
> > > >
> > > > always
> > > >
> > > > > > the
> > > > > > question of what to write in the plugin pages and what to write in
> > > >
> > > > other
> > > >
> > > > > > modules. Not talking of navigation from /plugins/maven-xxx-plugin
> > > > > > to
> > > >
> > > > /xxx/
> > > >
> > > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > > >
> > > > > > In caching case, I see that there is only one submodule, that is
> > > > > > done
> > > >
> > > > for
> > > >
> > > > > > ITs
> > > > > > with Surefire: is it necessary? isn't maven-invoker-plugin usable,
> > >
> > > like
> > >
> > > > > > for
> > > > > > plugins?
> > > > >
> > > > > Yes, that's actually a good point. I thought about that when I read
> > > >
> > > > Tamás
> > > >
> > > > > answer. I'll double check if the integration tests can be merged
> > > > > into
> > >
> > > a
> > >
> > > > > single module.
> > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > > > > I think the repository name should not contain 'extension',
> > > > > > > similar
> > > >
> > > > to
> > > >
> > > > > > > surefire which provides a plugin, but it a bit more complex
> > > > > > > The fact that it is provided as an extension is a technicality
> > > > > > > in
> > > >
> > > > this
> > > >
> > > > > > case
> > > > > >
> > > > > > > imho.
> > > > > > > No big deal though...
> > > > > > >
> > > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák
> > > > > > > <ta...@cservenak.net>
> > >
> > > a
> > >
> > > > > > écrit :
> > > > > > > > Howdy,
> > > > > > > >
> > > > > > > > I'd rather group ASF extensions (are there any existing ones
> > >
> > > aside
> > >
> > > > of
> > > >
> > > > > > > > caching?),
> > > > > > > > to be clear... so GH repo could be something like
> > > > > > > > apache/maven-caching-extension
> > > > > > > > apache/maven-foobar-extension
> > > > > > > > etc?
> > > > > > > >
> > > > > > > > T
> > > > > > > >
> > > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > >
> > > gnodet@apache.org>
> > >
> > > > > > wrote:
> > > > > > > > > Following the recent work done to integrate the maven
> > > > > > > > > caching
> > > > > > > > > /
> > > > > > > >
> > > > > > > > incremental
> > > > > > > >
> > > > > > > > > build system into maven, I think it's now time to discuss
> > > > > > > > > where
> > > >
> > > > we
> > > >
> > > > > > want
> > > > > >
> > > > > > > > its
> > > > > > > >
> > > > > > > > > long-term location to be.
> > > > > > > > >
> > > > > > > > > This extension was donated a few months ago and provides
> > > > > > > > > local
> > > >
> > > > and
> > > >
> > > > > > > > > remote
> > > > > > > > > caching of maven project's output, based on computed hashes
> > > > > > > > > of
> > > >
> > > > the
> > > >
> > > > > > > > inputs.
> > > > > > > >
> > > > > > > > > It's defined as a maven extension and can be used as a core
> > > > > > > > > or
> > > >
> > > > build
> > > >
> > > > > > > > > extension. This avoids building the project and speeds up
> > > >
> > > > builds a
> > > >
> > > > > > lot
> > > > > >
> > > > > > > > > !
> > > > > > > > >
> > > > > > > > > The current status of this work resides in 3 branches:
> > > > > > > > > * MNG-7129-3.8.x (PR at
> > > >
> > > > https://github.com/apache/maven/pull/622)
> > > >
> > > > > > > > > * MNG-7129-master (PR at
> > > >
> > > > https://github.com/apache/maven/pull/607)
> > > >
> > > > > > > > > *
> > >
> > > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > >
> > > > > > > > > The two first PRs include the required changes to integrate
> > > > > > > > > the
> > > > > > > > > extension
> > > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last
> > > > > > > > > branch
> > > >
> > > > is
> > > >
> > > > > > the
> > > > > >
> > > > > > > > one
> > > > > > > >
> > > > > > > > > that should be moved to a separate repository and contain
> > > > > > > > > the
> > > >
> > > > code
> > > >
> > > > > > for
> > > > > >
> > > > > > > > the
> > > > > > > >
> > > > > > > > > extension. The goal is to agree on the location and the
> > > > > > > > > final
> > > >
> > > > name
> > > >
> > > > > > for
> > > > > >
> > > > > > > > the
> > > > > > > >
> > > > > > > > > repository (it can't be changed easily).
> > > > > > > > >
> > > > > > > > > I propose maven-caching as the repository / subproject name,
> > >
> > > but
> > >
> > > > any
> > > >
> > > > > > > > better
> > > > > > > >
> > > > > > > > > name is welcomed of course.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > ------------------------
> > > > > > > > > Guillaume Nodet
> > > > > >
> > > > > > ------------------------------------------------------------------
> > > > > > --
> > > > > > -
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
I've tried to use git filter-repo, excluding unwanted directories or extensions
here is a sample result:
https://github.com/hboutemy/maven-build-cache-extension-filtered
= 4200 commits
instead of initial 11700
https://github.com/hboutemy/maven-build-cache-extension
we can still improve the list of directories to exclude
before taking time for that, I need feedback: what do you think about this
approach?
Regards,
Hervé
Le vendredi 17 décembre 2021, 11:47:25 CET Guillaume Nodet a écrit :
> I've tried various things without any good results.
> Given there's not much history to preserve here, I'd go ahead and just
> create a new repo with the current contents of the branch.
> Any objections?
>
> Le dim. 12 déc. 2021 à 15:43, Jeff Jensen
> <je...@upstairstechnology.com>
> a écrit :
> > I've split git repos before and using filter-branch is the key to keep the
> > desired and purge the rest.
> >
> > From my notes, these two posts helped me:
> > *
> >
> > https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out
> > -into-a-new-repository *
> >
> > https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-t
> > wo/
> >
> > These are my shortcut notes for doing so, hope they are clear enough for
> > you and help. In a new repo, locally convert a current source subdirectory
> > to the root directory and purge everything else; then push to remote and
> >
> > locally cleanup:
> > 1.
> >
> > Make directory for new repo from current repo:
> > git clone current-repo to-new-directory
> >
> > 1.
> >
> > Disconnect from current remote immediately to prevent catastrophe and
> > verify none set
> >
> > git remote rm origin
> >
> > git remote -v
> >
> > 1.
> >
> > Keep desired dir and move it to top level, remove the rest
> > 1.
> >
> > FOLDER-NAME: which one to keep and move to top level
> > 2.
> >
> > BRANCH-NAME: which branch to do this on (must exist, e.g. master)
> >
> > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > BRANCH-NAME
> >
> > 1.
> >
> > Setup remote repo and verify set
> >
> > git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> >
> > git remote -v
> >
> > 1.
> >
> > Push to new repo
> >
> > git push -u origin BRANCH-NAME
> >
> > 1.
> >
> > Further cleanup: delete all tags (locally only (Powershell))
> >
> > git tag | foreach-object -process { git tag -d $_ }
> >
> > 1.
> >
> > Further cleanup: remove local unreachable/recyclable commits (remnants
> > of prior)
> >
> > git reflog expire --expire-unreachable=now --all
> >
> > git gc --prune=now
> >
> >
> > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> > > nice work done
> > > I published the result to https://maven.apache.org/ref/caching-LATEST/
> > >
> > > now, on moving source to a separate Git repository, I did a basic test
> > > pushing
> > > to a new repository:
> > > https://github.com/hboutemy/maven-build-cache-extension
> > >
> > > this leads to getting quite a lot of Maven history
> > >
> > > I'm not a Git wizard: is there a way to cut down the history to keep
> > > only
> > > the
> > > interesting part when the build cache code donation was done?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a
> > >
> > > écrit :
> > > > > we have most plugins that are simple with only 1 mono-module build
> > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > see https://maven.apache.org/components/plugins/ for full list
> > > > >
> > > > > we have a few components that have a plugin as part of a larger
> > > > > multi-module
> > > > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > > > release, and
> > > > > soon wrapper
> > > > >
> > > > > And from experience, it makes documentation harder because there is
> > >
> > > always
> > >
> > > > > the
> > > > > question of what to write in the plugin pages and what to write in
> > >
> > > other
> > >
> > > > > modules. Not talking of navigation from /plugins/maven-xxx-plugin to
> > >
> > > /xxx/
> > >
> > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > >
> > > > > In caching case, I see that there is only one submodule, that is
> > > > > done
> > >
> > > for
> > >
> > > > > ITs
> > > > > with Surefire: is it necessary? isn't maven-invoker-plugin usable,
> >
> > like
> >
> > > > > for
> > > > > plugins?
> > > >
> > > > Yes, that's actually a good point. I thought about that when I read
> > >
> > > Tamás
> > >
> > > > answer. I'll double check if the integration tests can be merged into
> >
> > a
> >
> > > > single module.
> > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > > > I think the repository name should not contain 'extension',
> > > > > > similar
> > >
> > > to
> > >
> > > > > > surefire which provides a plugin, but it a bit more complex
> > > > > > The fact that it is provided as an extension is a technicality in
> > >
> > > this
> > >
> > > > > case
> > > > >
> > > > > > imho.
> > > > > > No big deal though...
> > > > > >
> > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net>
> >
> > a
> >
> > > > > écrit :
> > > > > > > Howdy,
> > > > > > >
> > > > > > > I'd rather group ASF extensions (are there any existing ones
> >
> > aside
> >
> > > of
> > >
> > > > > > > caching?),
> > > > > > > to be clear... so GH repo could be something like
> > > > > > > apache/maven-caching-extension
> > > > > > > apache/maven-foobar-extension
> > > > > > > etc?
> > > > > > >
> > > > > > > T
> > > > > > >
> > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> >
> > gnodet@apache.org>
> >
> > > > > wrote:
> > > > > > > > Following the recent work done to integrate the maven caching
> > > > > > > > /
> > > > > > >
> > > > > > > incremental
> > > > > > >
> > > > > > > > build system into maven, I think it's now time to discuss
> > > > > > > > where
> > >
> > > we
> > >
> > > > > want
> > > > >
> > > > > > > its
> > > > > > >
> > > > > > > > long-term location to be.
> > > > > > > >
> > > > > > > > This extension was donated a few months ago and provides local
> > >
> > > and
> > >
> > > > > > > > remote
> > > > > > > > caching of maven project's output, based on computed hashes of
> > >
> > > the
> > >
> > > > > > > inputs.
> > > > > > >
> > > > > > > > It's defined as a maven extension and can be used as a core or
> > >
> > > build
> > >
> > > > > > > > extension. This avoids building the project and speeds up
> > >
> > > builds a
> > >
> > > > > lot
> > > > >
> > > > > > > > !
> > > > > > > >
> > > > > > > > The current status of this work resides in 3 branches:
> > > > > > > > * MNG-7129-3.8.x (PR at
> > >
> > > https://github.com/apache/maven/pull/622)
> > >
> > > > > > > > * MNG-7129-master (PR at
> > >
> > > https://github.com/apache/maven/pull/607)
> > >
> > > > > > > > *
> >
> > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> >
> > > > > > > > The two first PRs include the required changes to integrate
> > > > > > > > the
> > > > > > > > extension
> > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last
> > > > > > > > branch
> > >
> > > is
> > >
> > > > > the
> > > > >
> > > > > > > one
> > > > > > >
> > > > > > > > that should be moved to a separate repository and contain the
> > >
> > > code
> > >
> > > > > for
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > extension. The goal is to agree on the location and the final
> > >
> > > name
> > >
> > > > > for
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > repository (it can't be changed easily).
> > > > > > > >
> > > > > > > > I propose maven-caching as the repository / subproject name,
> >
> > but
> >
> > > any
> > >
> > > > > > > better
> > > > > > >
> > > > > > > > name is welcomed of course.
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
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. 17 déc. 2021 à 11:47, Guillaume Nodet <gn...@apache.org> a écrit :
> I've tried various things without any good results.
> Given there's not much history to preserve here, I'd go ahead and just
> create a new repo with the current contents of the branch.
> Any objections?
>
> Le dim. 12 déc. 2021 à 15:43, Jeff Jensen <
> jeffjensen@upstairstechnology.com>
> a écrit :
>
> > I've split git repos before and using filter-branch is the key to keep
> the
> > desired and purge the rest.
> >
> > From my notes, these two posts helped me:
> > *
> >
> >
> https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
> > *
> >
> >
> https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/
> >
> > These are my shortcut notes for doing so, hope they are clear enough for
> > you and help. In a new repo, locally convert a current source
> subdirectory
> > to the root directory and purge everything else; then push to remote and
> > locally cleanup:
> >
> > 1.
> >
> > Make directory for new repo from current repo:
> >
> > git clone current-repo to-new-directory
> >
> > 1.
> >
> > Disconnect from current remote immediately to prevent catastrophe and
> > verify none set
> >
> > git remote rm origin
> >
> > git remote -v
> >
> > 1.
> >
> > Keep desired dir and move it to top level, remove the rest
> > 1.
> >
> > FOLDER-NAME: which one to keep and move to top level
> > 2.
> >
> > BRANCH-NAME: which branch to do this on (must exist, e.g. master)
> >
> > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > BRANCH-NAME
> >
> > 1.
> >
> > Setup remote repo and verify set
> >
> > git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> > <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
> >
> > git remote -v
> >
> > 1.
> >
> > Push to new repo
> >
> > git push -u origin BRANCH-NAME
> >
> > 1.
> >
> > Further cleanup: delete all tags (locally only (Powershell))
> >
> > git tag | foreach-object -process { git tag -d $_ }
> >
> > 1.
> >
> > Further cleanup: remove local unreachable/recyclable commits (remnants
> > of prior)
> >
> > git reflog expire --expire-unreachable=now --all
> >
> > git gc --prune=now
> >
> >
> > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <he...@free.fr>
> > wrote:
> >
> > > nice work done
> > > I published the result to https://maven.apache.org/ref/caching-LATEST/
> > >
> > > now, on moving source to a separate Git repository, I did a basic test
> > > pushing
> > > to a new repository:
> > > https://github.com/hboutemy/maven-build-cache-extension
> > >
> > > this leads to getting quite a lot of Maven history
> > >
> > > I'm not a Git wizard: is there a way to cut down the history to keep
> only
> > > the
> > > interesting part when the build cache code donation was done?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a
> > > écrit :
> > > > > we have most plugins that are simple with only 1 mono-module build
> > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > see https://maven.apache.org/components/plugins/ for full list
> > > > >
> > > > > we have a few components that have a plugin as part of a larger
> > > > > multi-module
> > > > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > > > release, and
> > > > > soon wrapper
> > > > >
> > > > > And from experience, it makes documentation harder because there is
> > > always
> > > > > the
> > > > > question of what to write in the plugin pages and what to write in
> > > other
> > > > > modules. Not talking of navigation from /plugins/maven-xxx-plugin
> to
> > > /xxx/
> > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > >
> > > > > In caching case, I see that there is only one submodule, that is
> done
> > > for
> > > > > ITs
> > > > > with Surefire: is it necessary? isn't maven-invoker-plugin usable,
> > like
> > > > > for
> > > > > plugins?
> > > >
> > > > Yes, that's actually a good point. I thought about that when I read
> > > Tamás
> > > > answer. I'll double check if the integration tests can be merged
> into
> > a
> > > > single module.
> > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > > > I think the repository name should not contain 'extension',
> similar
> > > to
> > > > > > surefire which provides a plugin, but it a bit more complex
> > > > > > The fact that it is provided as an extension is a technicality in
> > > this
> > > > >
> > > > > case
> > > > >
> > > > > > imho.
> > > > > > No big deal though...
> > > > > >
> > > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <
> tamas@cservenak.net>
> > a
> > > > >
> > > > > écrit :
> > > > > > > Howdy,
> > > > > > >
> > > > > > > I'd rather group ASF extensions (are there any existing ones
> > aside
> > > of
> > > > > > > caching?),
> > > > > > > to be clear... so GH repo could be something like
> > > > > > > apache/maven-caching-extension
> > > > > > > apache/maven-foobar-extension
> > > > > > > etc?
> > > > > > >
> > > > > > > T
> > > > > > >
> > > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> > gnodet@apache.org>
> > > > >
> > > > > wrote:
> > > > > > > > Following the recent work done to integrate the maven
> caching /
> > > > > > >
> > > > > > > incremental
> > > > > > >
> > > > > > > > build system into maven, I think it's now time to discuss
> where
> > > we
> > > > >
> > > > > want
> > > > >
> > > > > > > its
> > > > > > >
> > > > > > > > long-term location to be.
> > > > > > > >
> > > > > > > > This extension was donated a few months ago and provides
> local
> > > and
> > > > > > > > remote
> > > > > > > > caching of maven project's output, based on computed hashes
> of
> > > the
> > > > > > >
> > > > > > > inputs.
> > > > > > >
> > > > > > > > It's defined as a maven extension and can be used as a core
> or
> > > build
> > > > > > > > extension. This avoids building the project and speeds up
> > > builds a
> > > > >
> > > > > lot
> > > > >
> > > > > > > > !
> > > > > > > >
> > > > > > > > The current status of this work resides in 3 branches:
> > > > > > > > * MNG-7129-3.8.x (PR at
> > > https://github.com/apache/maven/pull/622)
> > > > > > > > * MNG-7129-master (PR at
> > > https://github.com/apache/maven/pull/607)
> > > > > > > > *
> > https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > > > >
> > > > > > > > The two first PRs include the required changes to integrate
> the
> > > > > > > > extension
> > > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last
> branch
> > > is
> > > > >
> > > > > the
> > > > >
> > > > > > > one
> > > > > > >
> > > > > > > > that should be moved to a separate repository and contain the
> > > code
> > > > >
> > > > > for
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > extension. The goal is to agree on the location and the
> final
> > > name
> > > > >
> > > > > for
> > > > >
> > > > > > > the
> > > > > > >
> > > > > > > > repository (it can't be changed easily).
> > > > > > > >
> > > > > > > > I propose maven-caching as the repository / subproject name,
> > but
> > > any
> > > > > > >
> > > > > > > better
> > > > > > >
> > > > > > > > name is welcomed of course.
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
I've tried various things without any good results.
Given there's not much history to preserve here, I'd go ahead and just
create a new repo with the current contents of the branch.
Any objections?
Le dim. 12 déc. 2021 à 15:43, Jeff Jensen <je...@upstairstechnology.com>
a écrit :
> I've split git repos before and using filter-branch is the key to keep the
> desired and purge the rest.
>
> From my notes, these two posts helped me:
> *
>
> https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
> *
>
> https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/
>
> These are my shortcut notes for doing so, hope they are clear enough for
> you and help. In a new repo, locally convert a current source subdirectory
> to the root directory and purge everything else; then push to remote and
> locally cleanup:
>
> 1.
>
> Make directory for new repo from current repo:
>
> git clone current-repo to-new-directory
>
> 1.
>
> Disconnect from current remote immediately to prevent catastrophe and
> verify none set
>
> git remote rm origin
>
> git remote -v
>
> 1.
>
> Keep desired dir and move it to top level, remove the rest
> 1.
>
> FOLDER-NAME: which one to keep and move to top level
> 2.
>
> BRANCH-NAME: which branch to do this on (must exist, e.g. master)
>
> git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> BRANCH-NAME
>
> 1.
>
> Setup remote repo and verify set
>
> git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> <https://host-stuff.com/NEW-REPOSITORY-NAME.git>
>
> git remote -v
>
> 1.
>
> Push to new repo
>
> git push -u origin BRANCH-NAME
>
> 1.
>
> Further cleanup: delete all tags (locally only (Powershell))
>
> git tag | foreach-object -process { git tag -d $_ }
>
> 1.
>
> Further cleanup: remove local unreachable/recyclable commits (remnants
> of prior)
>
> git reflog expire --expire-unreachable=now --all
>
> git gc --prune=now
>
>
> On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <he...@free.fr>
> wrote:
>
> > nice work done
> > I published the result to https://maven.apache.org/ref/caching-LATEST/
> >
> > now, on moving source to a separate Git repository, I did a basic test
> > pushing
> > to a new repository:
> > https://github.com/hboutemy/maven-build-cache-extension
> >
> > this leads to getting quite a lot of Maven history
> >
> > I'm not a Git wizard: is there a way to cut down the history to keep only
> > the
> > interesting part when the build cache code donation was done?
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a
> > écrit :
> > > > we have most plugins that are simple with only 1 mono-module build
> > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > see https://maven.apache.org/components/plugins/ for full list
> > > >
> > > > we have a few components that have a plugin as part of a larger
> > > > multi-module
> > > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > > release, and
> > > > soon wrapper
> > > >
> > > > And from experience, it makes documentation harder because there is
> > always
> > > > the
> > > > question of what to write in the plugin pages and what to write in
> > other
> > > > modules. Not talking of navigation from /plugins/maven-xxx-plugin to
> > /xxx/
> > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > >
> > > > In caching case, I see that there is only one submodule, that is done
> > for
> > > > ITs
> > > > with Surefire: is it necessary? isn't maven-invoker-plugin usable,
> like
> > > > for
> > > > plugins?
> > >
> > > Yes, that's actually a good point. I thought about that when I read
> > Tamás
> > > answer. I'll double check if the integration tests can be merged into
> a
> > > single module.
> > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > > I think the repository name should not contain 'extension', similar
> > to
> > > > > surefire which provides a plugin, but it a bit more complex
> > > > > The fact that it is provided as an extension is a technicality in
> > this
> > > >
> > > > case
> > > >
> > > > > imho.
> > > > > No big deal though...
> > > > >
> > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net>
> a
> > > >
> > > > écrit :
> > > > > > Howdy,
> > > > > >
> > > > > > I'd rather group ASF extensions (are there any existing ones
> aside
> > of
> > > > > > caching?),
> > > > > > to be clear... so GH repo could be something like
> > > > > > apache/maven-caching-extension
> > > > > > apache/maven-foobar-extension
> > > > > > etc?
> > > > > >
> > > > > > T
> > > > > >
> > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> gnodet@apache.org>
> > > >
> > > > wrote:
> > > > > > > Following the recent work done to integrate the maven caching /
> > > > > >
> > > > > > incremental
> > > > > >
> > > > > > > build system into maven, I think it's now time to discuss where
> > we
> > > >
> > > > want
> > > >
> > > > > > its
> > > > > >
> > > > > > > long-term location to be.
> > > > > > >
> > > > > > > This extension was donated a few months ago and provides local
> > and
> > > > > > > remote
> > > > > > > caching of maven project's output, based on computed hashes of
> > the
> > > > > >
> > > > > > inputs.
> > > > > >
> > > > > > > It's defined as a maven extension and can be used as a core or
> > build
> > > > > > > extension. This avoids building the project and speeds up
> > builds a
> > > >
> > > > lot
> > > >
> > > > > > > !
> > > > > > >
> > > > > > > The current status of this work resides in 3 branches:
> > > > > > > * MNG-7129-3.8.x (PR at
> > https://github.com/apache/maven/pull/622)
> > > > > > > * MNG-7129-master (PR at
> > https://github.com/apache/maven/pull/607)
> > > > > > > *
> https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > > >
> > > > > > > The two first PRs include the required changes to integrate the
> > > > > > > extension
> > > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch
> > is
> > > >
> > > > the
> > > >
> > > > > > one
> > > > > >
> > > > > > > that should be moved to a separate repository and contain the
> > code
> > > >
> > > > for
> > > >
> > > > > > the
> > > > > >
> > > > > > > extension. The goal is to agree on the location and the final
> > name
> > > >
> > > > for
> > > >
> > > > > > the
> > > > > >
> > > > > > > repository (it can't be changed easily).
> > > > > > >
> > > > > > > I propose maven-caching as the repository / subproject name,
> but
> > any
> > > > > >
> > > > > > better
> > > > > >
> > > > > > > name is welcomed of course.
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Jeff Jensen <je...@upstairstechnology.com>.
I've split git repos before and using filter-branch is the key to keep the
desired and purge the rest.
From my notes, these two posts helped me:
*
https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
*
https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/
These are my shortcut notes for doing so, hope they are clear enough for
you and help. In a new repo, locally convert a current source subdirectory
to the root directory and purge everything else; then push to remote and
locally cleanup:
1.
Make directory for new repo from current repo:
git clone current-repo to-new-directory
1.
Disconnect from current remote immediately to prevent catastrophe and
verify none set
git remote rm origin
git remote -v
1.
Keep desired dir and move it to top level, remove the rest
1.
FOLDER-NAME: which one to keep and move to top level
2.
BRANCH-NAME: which branch to do this on (must exist, e.g. master)
git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
BRANCH-NAME
1.
Setup remote repo and verify set
git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
<https://host-stuff.com/NEW-REPOSITORY-NAME.git>
git remote -v
1.
Push to new repo
git push -u origin BRANCH-NAME
1.
Further cleanup: delete all tags (locally only (Powershell))
git tag | foreach-object -process { git tag -d $_ }
1.
Further cleanup: remove local unreachable/recyclable commits (remnants
of prior)
git reflog expire --expire-unreachable=now --all
git gc --prune=now
On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY <he...@free.fr> wrote:
> nice work done
> I published the result to https://maven.apache.org/ref/caching-LATEST/
>
> now, on moving source to a separate Git repository, I did a basic test
> pushing
> to a new repository:
> https://github.com/hboutemy/maven-build-cache-extension
>
> this leads to getting quite a lot of Maven history
>
> I'm not a Git wizard: is there a way to cut down the history to keep only
> the
> interesting part when the build cache code donation was done?
>
> Regards,
>
> Hervé
>
> Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a
> écrit :
> > > we have most plugins that are simple with only 1 mono-module build
> > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > see https://maven.apache.org/components/plugins/ for full list
> > >
> > > we have a few components that have a plugin as part of a larger
> > > multi-module
> > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > release, and
> > > soon wrapper
> > >
> > > And from experience, it makes documentation harder because there is
> always
> > > the
> > > question of what to write in the plugin pages and what to write in
> other
> > > modules. Not talking of navigation from /plugins/maven-xxx-plugin to
> /xxx/
> > > maven-xxx-plugin (we have a trick for redirecting...)
> > >
> > > In caching case, I see that there is only one submodule, that is done
> for
> > > ITs
> > > with Surefire: is it necessary? isn't maven-invoker-plugin usable, like
> > > for
> > > plugins?
> >
> > Yes, that's actually a good point. I thought about that when I read
> Tamás
> > answer. I'll double check if the integration tests can be merged into a
> > single module.
> >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > I think the repository name should not contain 'extension', similar
> to
> > > > surefire which provides a plugin, but it a bit more complex
> > > > The fact that it is provided as an extension is a technicality in
> this
> > >
> > > case
> > >
> > > > imho.
> > > > No big deal though...
> > > >
> > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a
> > >
> > > écrit :
> > > > > Howdy,
> > > > >
> > > > > I'd rather group ASF extensions (are there any existing ones aside
> of
> > > > > caching?),
> > > > > to be clear... so GH repo could be something like
> > > > > apache/maven-caching-extension
> > > > > apache/maven-foobar-extension
> > > > > etc?
> > > > >
> > > > > T
> > > > >
> > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org>
> > >
> > > wrote:
> > > > > > Following the recent work done to integrate the maven caching /
> > > > >
> > > > > incremental
> > > > >
> > > > > > build system into maven, I think it's now time to discuss where
> we
> > >
> > > want
> > >
> > > > > its
> > > > >
> > > > > > long-term location to be.
> > > > > >
> > > > > > This extension was donated a few months ago and provides local
> and
> > > > > > remote
> > > > > > caching of maven project's output, based on computed hashes of
> the
> > > > >
> > > > > inputs.
> > > > >
> > > > > > It's defined as a maven extension and can be used as a core or
> build
> > > > > > extension. This avoids building the project and speeds up
> builds a
> > >
> > > lot
> > >
> > > > > > !
> > > > > >
> > > > > > The current status of this work resides in 3 branches:
> > > > > > * MNG-7129-3.8.x (PR at
> https://github.com/apache/maven/pull/622)
> > > > > > * MNG-7129-master (PR at
> https://github.com/apache/maven/pull/607)
> > > > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > >
> > > > > > The two first PRs include the required changes to integrate the
> > > > > > extension
> > > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch
> is
> > >
> > > the
> > >
> > > > > one
> > > > >
> > > > > > that should be moved to a separate repository and contain the
> code
> > >
> > > for
> > >
> > > > > the
> > > > >
> > > > > > extension. The goal is to agree on the location and the final
> name
> > >
> > > for
> > >
> > > > > the
> > > > >
> > > > > > repository (it can't be changed easily).
> > > > > >
> > > > > > I propose maven-caching as the repository / subproject name, but
> any
> > > > >
> > > > > better
> > > > >
> > > > > > name is welcomed of course.
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
nice work done
I published the result to https://maven.apache.org/ref/caching-LATEST/
now, on moving source to a separate Git repository, I did a basic test pushing
to a new repository:
https://github.com/hboutemy/maven-build-cache-extension
this leads to getting quite a lot of Maven history
I'm not a Git wizard: is there a way to cut down the history to keep only the
interesting part when the build cache code donation was done?
Regards,
Hervé
Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a écrit :
> > we have most plugins that are simple with only 1 mono-module build
> > This makes documentation easy in /plugins/maven-*-plugin/:
> > see https://maven.apache.org/components/plugins/ for full list
> >
> > we have a few components that have a plugin as part of a larger
> > multi-module
> > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > release, and
> > soon wrapper
> >
> > And from experience, it makes documentation harder because there is always
> > the
> > question of what to write in the plugin pages and what to write in other
> > modules. Not talking of navigation from /plugins/maven-xxx-plugin to /xxx/
> > maven-xxx-plugin (we have a trick for redirecting...)
> >
> > In caching case, I see that there is only one submodule, that is done for
> > ITs
> > with Surefire: is it necessary? isn't maven-invoker-plugin usable, like
> > for
> > plugins?
>
> Yes, that's actually a good point. I thought about that when I read Tamás
> answer. I'll double check if the integration tests can be merged into a
> single module.
>
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > I think the repository name should not contain 'extension', similar to
> > > surefire which provides a plugin, but it a bit more complex
> > > The fact that it is provided as an extension is a technicality in this
> >
> > case
> >
> > > imho.
> > > No big deal though...
> > >
> > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a
> >
> > écrit :
> > > > Howdy,
> > > >
> > > > I'd rather group ASF extensions (are there any existing ones aside of
> > > > caching?),
> > > > to be clear... so GH repo could be something like
> > > > apache/maven-caching-extension
> > > > apache/maven-foobar-extension
> > > > etc?
> > > >
> > > > T
> > > >
> > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org>
> >
> > wrote:
> > > > > Following the recent work done to integrate the maven caching /
> > > >
> > > > incremental
> > > >
> > > > > build system into maven, I think it's now time to discuss where we
> >
> > want
> >
> > > > its
> > > >
> > > > > long-term location to be.
> > > > >
> > > > > This extension was donated a few months ago and provides local and
> > > > > remote
> > > > > caching of maven project's output, based on computed hashes of the
> > > >
> > > > inputs.
> > > >
> > > > > It's defined as a maven extension and can be used as a core or build
> > > > > extension. This avoids building the project and speeds up builds a
> >
> > lot
> >
> > > > > !
> > > > >
> > > > > The current status of this work resides in 3 branches:
> > > > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > >
> > > > > The two first PRs include the required changes to integrate the
> > > > > extension
> > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is
> >
> > the
> >
> > > > one
> > > >
> > > > > that should be moved to a separate repository and contain the code
> >
> > for
> >
> > > > the
> > > >
> > > > > extension. The goal is to agree on the location and the final name
> >
> > for
> >
> > > > the
> > > >
> > > > > repository (it can't be changed easily).
> > > > >
> > > > > I propose maven-caching as the repository / subproject name, but any
> > > >
> > > > better
> > > >
> > > > > name is welcomed of course.
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY <he...@free.fr> a écrit :
> we have most plugins that are simple with only 1 mono-module build
> This makes documentation easy in /plugins/maven-*-plugin/:
> see https://maven.apache.org/components/plugins/ for full list
>
> we have a few components that have a plugin as part of a larger
> multi-module
> build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> release, and
> soon wrapper
>
> And from experience, it makes documentation harder because there is always
> the
> question of what to write in the plugin pages and what to write in other
> modules. Not talking of navigation from /plugins/maven-xxx-plugin to /xxx/
> maven-xxx-plugin (we have a trick for redirecting...)
>
> In caching case, I see that there is only one submodule, that is done for
> ITs
> with Surefire: is it necessary? isn't maven-invoker-plugin usable, like
> for
> plugins?
>
Yes, that's actually a good point. I thought about that when I read Tamás
answer. I'll double check if the integration tests can be merged into a
single module.
>
> Regards,
>
> Hervé
>
> Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > I think the repository name should not contain 'extension', similar to
> > surefire which provides a plugin, but it a bit more complex
> > The fact that it is provided as an extension is a technicality in this
> case
> > imho.
> > No big deal though...
> >
> > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
> > > Howdy,
> > >
> > > I'd rather group ASF extensions (are there any existing ones aside of
> > > caching?),
> > > to be clear... so GH repo could be something like
> > > apache/maven-caching-extension
> > > apache/maven-foobar-extension
> > > etc?
> > >
> > > T
> > >
> > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org>
> wrote:
> > > > Following the recent work done to integrate the maven caching /
> > >
> > > incremental
> > >
> > > > build system into maven, I think it's now time to discuss where we
> want
> > >
> > > its
> > >
> > > > long-term location to be.
> > > >
> > > > This extension was donated a few months ago and provides local and
> > > > remote
> > > > caching of maven project's output, based on computed hashes of the
> > >
> > > inputs.
> > >
> > > > It's defined as a maven extension and can be used as a core or build
> > > > extension. This avoids building the project and speeds up builds a
> lot
> > > > !
> > > >
> > > > The current status of this work resides in 3 branches:
> > > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > >
> > > > The two first PRs include the required changes to integrate the
> > > > extension
> > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is
> the
> > >
> > > one
> > >
> > > > that should be moved to a separate repository and contain the code
> for
> > >
> > > the
> > >
> > > > extension. The goal is to agree on the location and the final name
> for
> > >
> > > the
> > >
> > > > repository (it can't be changed easily).
> > > >
> > > > I propose maven-caching as the repository / subproject name, but any
> > >
> > > better
> > >
> > > > name is welcomed of course.
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
we have most plugins that are simple with only 1 mono-module build
This makes documentation easy in /plugins/maven-*-plugin/:
see https://maven.apache.org/components/plugins/ for full list
we have a few components that have a plugin as part of a larger multi-module
build, like surefire, jxr, archetype, scm, plugin-tools, enforcer, release, and
soon wrapper
And from experience, it makes documentation harder because there is always the
question of what to write in the plugin pages and what to write in other
modules. Not talking of navigation from /plugins/maven-xxx-plugin to /xxx/
maven-xxx-plugin (we have a trick for redirecting...)
In caching case, I see that there is only one submodule, that is done for ITs
with Surefire: is it necessary? isn't maven-invoker-plugin usable, like for
plugins?
Regards,
Hervé
Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> I think the repository name should not contain 'extension', similar to
> surefire which provides a plugin, but it a bit more complex
> The fact that it is provided as an extension is a technicality in this case
> imho.
> No big deal though...
>
> Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a écrit :
> > Howdy,
> >
> > I'd rather group ASF extensions (are there any existing ones aside of
> > caching?),
> > to be clear... so GH repo could be something like
> > apache/maven-caching-extension
> > apache/maven-foobar-extension
> > etc?
> >
> > T
> >
> > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org> wrote:
> > > Following the recent work done to integrate the maven caching /
> >
> > incremental
> >
> > > build system into maven, I think it's now time to discuss where we want
> >
> > its
> >
> > > long-term location to be.
> > >
> > > This extension was donated a few months ago and provides local and
> > > remote
> > > caching of maven project's output, based on computed hashes of the
> >
> > inputs.
> >
> > > It's defined as a maven extension and can be used as a core or build
> > > extension. This avoids building the project and speeds up builds a lot
> > > !
> > >
> > > The current status of this work resides in 3 branches:
> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > >
> > > The two first PRs include the required changes to integrate the
> > > extension
> > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> >
> > one
> >
> > > that should be moved to a separate repository and contain the code for
> >
> > the
> >
> > > extension. The goal is to agree on the location and the final name for
> >
> > the
> >
> > > repository (it can't be changed easily).
> > >
> > > I propose maven-caching as the repository / subproject name, but any
> >
> > better
> >
> > > name is welcomed of course.
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Tamás Cservenák <ta...@cservenak.net>.
s/scp/scm
Sorry
T
On Thu, Dec 9, 2021 at 9:04 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> yes, like maven-scm, that contains m-scp-p among other things, but there
> is complete scm codebase (while m-scp-p merely "invokes" it), also, there
> are examples of re-using maven-scm outside of maven, like in case of m2e....
>
> Can maven-caching be reused in any other way than extension (by maven or
> 3rd party integrator?) As in that case I agree.
> In other words, if it is really just a "specific maven extension, non
> workable outside of maven", then disagree :)
>
> T
>
> On Thu, Dec 9, 2021 at 9:01 AM Guillaume Nodet <gn...@apache.org> wrote:
>
>> I think the repository name should not contain 'extension', similar to
>> surefire which provides a plugin, but it a bit more complex
>> The fact that it is provided as an extension is a technicality in this
>> case
>> imho.
>> No big deal though...
>>
>> Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a
>> écrit :
>>
>> > Howdy,
>> >
>> > I'd rather group ASF extensions (are there any existing ones aside of
>> > caching?),
>> > to be clear... so GH repo could be something like
>> > apache/maven-caching-extension
>> > apache/maven-foobar-extension
>> > etc?
>> >
>> > T
>> >
>> > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org>
>> wrote:
>> >
>> > > Following the recent work done to integrate the maven caching /
>> > incremental
>> > > build system into maven, I think it's now time to discuss where we
>> want
>> > its
>> > > long-term location to be.
>> > >
>> > > This extension was donated a few months ago and provides local and
>> remote
>> > > caching of maven project's output, based on computed hashes of the
>> > inputs.
>> > > It's defined as a maven extension and can be used as a core or build
>> > > extension. This avoids building the project and speeds up builds a
>> lot !
>> > >
>> > > The current status of this work resides in 3 branches:
>> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
>> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
>> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
>> > > The two first PRs include the required changes to integrate the
>> extension
>> > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
>> > one
>> > > that should be moved to a separate repository and contain the code for
>> > the
>> > > extension. The goal is to agree on the location and the final name
>> for
>> > the
>> > > repository (it can't be changed easily).
>> > >
>> > > I propose maven-caching as the repository / subproject name, but any
>> > better
>> > > name is welcomed of course.
>> > >
>> > > --
>> > > ------------------------
>> > > Guillaume Nodet
>> > >
>> >
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
yes, like maven-scm, that contains m-scp-p among other things, but there is
complete scm codebase (while m-scp-p merely "invokes" it), also, there are
examples of re-using maven-scm outside of maven, like in case of m2e....
Can maven-caching be reused in any other way than extension (by maven or
3rd party integrator?) As in that case I agree.
In other words, if it is really just a "specific maven extension, non
workable outside of maven", then disagree :)
T
On Thu, Dec 9, 2021 at 9:01 AM Guillaume Nodet <gn...@apache.org> wrote:
> I think the repository name should not contain 'extension', similar to
> surefire which provides a plugin, but it a bit more complex
> The fact that it is provided as an extension is a technicality in this case
> imho.
> No big deal though...
>
> Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Howdy,
> >
> > I'd rather group ASF extensions (are there any existing ones aside of
> > caching?),
> > to be clear... so GH repo could be something like
> > apache/maven-caching-extension
> > apache/maven-foobar-extension
> > etc?
> >
> > T
> >
> > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> > > Following the recent work done to integrate the maven caching /
> > incremental
> > > build system into maven, I think it's now time to discuss where we want
> > its
> > > long-term location to be.
> > >
> > > This extension was donated a few months ago and provides local and
> remote
> > > caching of maven project's output, based on computed hashes of the
> > inputs.
> > > It's defined as a maven extension and can be used as a core or build
> > > extension. This avoids building the project and speeds up builds a
> lot !
> > >
> > > The current status of this work resides in 3 branches:
> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > The two first PRs include the required changes to integrate the
> extension
> > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> > one
> > > that should be moved to a separate repository and contain the code for
> > the
> > > extension. The goal is to agree on the location and the final name for
> > the
> > > repository (it can't be changed easily).
> > >
> > > I propose maven-caching as the repository / subproject name, but any
> > better
> > > name is welcomed of course.
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
I think the repository name should not contain 'extension', similar to
surefire which provides a plugin, but it a bit more complex
The fact that it is provided as an extension is a technicality in this case
imho.
No big deal though...
Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy,
>
> I'd rather group ASF extensions (are there any existing ones aside of
> caching?),
> to be clear... so GH repo could be something like
> apache/maven-caching-extension
> apache/maven-foobar-extension
> etc?
>
> T
>
> On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> > Following the recent work done to integrate the maven caching /
> incremental
> > build system into maven, I think it's now time to discuss where we want
> its
> > long-term location to be.
> >
> > This extension was donated a few months ago and provides local and remote
> > caching of maven project's output, based on computed hashes of the
> inputs.
> > It's defined as a maven extension and can be used as a core or build
> > extension. This avoids building the project and speeds up builds a lot !
> >
> > The current status of this work resides in 3 branches:
> > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > The two first PRs include the required changes to integrate the extension
> > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> one
> > that should be moved to a separate repository and contain the code for
> the
> > extension. The goal is to agree on the location and the final name for
> the
> > repository (it can't be changed easily).
> >
> > I propose maven-caching as the repository / subproject name, but any
> better
> > name is welcomed of course.
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
I'd rather group ASF extensions (are there any existing ones aside of
caching?),
to be clear... so GH repo could be something like
apache/maven-caching-extension
apache/maven-foobar-extension
etc?
T
On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <gn...@apache.org> wrote:
> Following the recent work done to integrate the maven caching / incremental
> build system into maven, I think it's now time to discuss where we want its
> long-term location to be.
>
> This extension was donated a few months ago and provides local and remote
> caching of maven project's output, based on computed hashes of the inputs.
> It's defined as a maven extension and can be used as a core or build
> extension. This avoids building the project and speeds up builds a lot !
>
> The current status of this work resides in 3 branches:
> * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> The two first PRs include the required changes to integrate the extension
> in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the one
> that should be moved to a separate repository and contain the code for the
> extension. The goal is to agree on the location and the final name for the
> repository (it can't be changed easily).
>
> I propose maven-caching as the repository / subproject name, but any better
> name is welcomed of course.
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 for maven-build-cache-extension as well
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. 10 déc. 2021 à 12:22, Tamás Cservenák <ta...@cservenak.net> a
écrit :
> +1 for maven-build-cache-extension
>
> On Fri, Dec 10, 2021 at 11:00 AM Guillaume Nodet <gn...@apache.org>
> wrote:
>
> > I've refactored the build to be a single-module build.
> > I agree that maven-caching is not the most descriptive, I'd be pleased
> with
> > * maven-build-cache-extension*
> >
> > Guillaume
> >
> > Le jeu. 9 déc. 2021 à 11:40, Michael Osipov <mi...@apache.org> a
> écrit
> > :
> >
> > > Am 2021-12-07 um 09:47 schrieb Guillaume Nodet:
> > > > Following the recent work done to integrate the maven caching /
> > > incremental
> > > > build system into maven, I think it's now time to discuss where we
> want
> > > its
> > > > long-term location to be.
> > > >
> > > > This extension was donated a few months ago and provides local and
> > remote
> > > > caching of maven project's output, based on computed hashes of the
> > > inputs.
> > > > It's defined as a maven extension and can be used as a core or build
> > > > extension. This avoids building the project and speeds up builds a
> > lot !
> > > >
> > > > The current status of this work resides in 3 branches:
> > > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607
> )
> > > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > The two first PRs include the required changes to integrate the
> > extension
> > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is
> the
> > > one
> > > > that should be moved to a separate repository and contain the code
> for
> > > the
> > > > extension. The goal is to agree on the location and the final name
> for
> > > the
> > > > repository (it can't be changed easily).
> > > >
> > > > I propose maven-caching as the repository / subproject name, but any
> > > better
> > > > name is welcomed of course.
> > > >
> > >
> > > I dislike the name 'maven-caching' because it is very very generic.
> > > What does it cache? Just like we have Maven Artifact Resolver. The name
> > > should tell what it caches, e.g., maven-build-cache/caching/cacher, or
> > > maven-incremental-build...
> > >
> > > Consider that the Maven local repository is also called Maven local
> > > artifact repo cache, etc.
> > >
> > > M
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1 for maven-build-cache-extension
On Fri, Dec 10, 2021 at 11:00 AM Guillaume Nodet <gn...@apache.org> wrote:
> I've refactored the build to be a single-module build.
> I agree that maven-caching is not the most descriptive, I'd be pleased with
> * maven-build-cache-extension*
>
> Guillaume
>
> Le jeu. 9 déc. 2021 à 11:40, Michael Osipov <mi...@apache.org> a écrit
> :
>
> > Am 2021-12-07 um 09:47 schrieb Guillaume Nodet:
> > > Following the recent work done to integrate the maven caching /
> > incremental
> > > build system into maven, I think it's now time to discuss where we want
> > its
> > > long-term location to be.
> > >
> > > This extension was donated a few months ago and provides local and
> remote
> > > caching of maven project's output, based on computed hashes of the
> > inputs.
> > > It's defined as a maven extension and can be used as a core or build
> > > extension. This avoids building the project and speeds up builds a
> lot !
> > >
> > > The current status of this work resides in 3 branches:
> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > The two first PRs include the required changes to integrate the
> extension
> > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> > one
> > > that should be moved to a separate repository and contain the code for
> > the
> > > extension. The goal is to agree on the location and the final name for
> > the
> > > repository (it can't be changed easily).
> > >
> > > I propose maven-caching as the repository / subproject name, but any
> > better
> > > name is welcomed of course.
> > >
> >
> > I dislike the name 'maven-caching' because it is very very generic.
> > What does it cache? Just like we have Maven Artifact Resolver. The name
> > should tell what it caches, e.g., maven-build-cache/caching/cacher, or
> > maven-incremental-build...
> >
> > Consider that the Maven local repository is also called Maven local
> > artifact repo cache, etc.
> >
> > M
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] Move maven caching to an external repository
Posted by Jason van Zyl <ja...@vanzyl.ca>.
+1
jvz
> On Dec 10, 2021, at 4:30 AM, Guillaume Nodet <gn...@apache.org> wrote:
>
> I've refactored the build to be a single-module build.
> I agree that maven-caching is not the most descriptive, I'd be pleased with
> * maven-build-cache-extension*
>
> Guillaume
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Arnaud Héritier <ah...@gmail.com>.
+1
go for it !!
On Fri, Dec 10, 2021 at 7:37 PM Michael Osipov <mi...@apache.org> wrote:
> Am 2021-12-10 um 10:30 schrieb Guillaume Nodet:
> > I've refactored the build to be a single-module build.
> > I agree that maven-caching is not the most descriptive, I'd be pleased
> with
> > * maven-build-cache-extension*
>
> This sounds very promising.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Arnaud Héritier
Twitter/GitHub/... : aheritier
Re: [DISCUSS] Move maven caching to an external repository
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-12-10 um 10:30 schrieb Guillaume Nodet:
> I've refactored the build to be a single-module build.
> I agree that maven-caching is not the most descriptive, I'd be pleased with
> * maven-build-cache-extension*
This sounds very promising.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
I've refactored the build to be a single-module build.
I agree that maven-caching is not the most descriptive, I'd be pleased with
* maven-build-cache-extension*
Guillaume
Le jeu. 9 déc. 2021 à 11:40, Michael Osipov <mi...@apache.org> a écrit :
> Am 2021-12-07 um 09:47 schrieb Guillaume Nodet:
> > Following the recent work done to integrate the maven caching /
> incremental
> > build system into maven, I think it's now time to discuss where we want
> its
> > long-term location to be.
> >
> > This extension was donated a few months ago and provides local and remote
> > caching of maven project's output, based on computed hashes of the
> inputs.
> > It's defined as a maven extension and can be used as a core or build
> > extension. This avoids building the project and speeds up builds a lot !
> >
> > The current status of this work resides in 3 branches:
> > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > The two first PRs include the required changes to integrate the extension
> > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the
> one
> > that should be moved to a separate repository and contain the code for
> the
> > extension. The goal is to agree on the location and the final name for
> the
> > repository (it can't be changed easily).
> >
> > I propose maven-caching as the repository / subproject name, but any
> better
> > name is welcomed of course.
> >
>
> I dislike the name 'maven-caching' because it is very very generic.
> What does it cache? Just like we have Maven Artifact Resolver. The name
> should tell what it caches, e.g., maven-build-cache/caching/cacher, or
> maven-incremental-build...
>
> Consider that the Maven local repository is also called Maven local
> artifact repo cache, etc.
>
> M
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Move maven caching to an external repository
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-12-07 um 09:47 schrieb Guillaume Nodet:
> Following the recent work done to integrate the maven caching / incremental
> build system into maven, I think it's now time to discuss where we want its
> long-term location to be.
>
> This extension was donated a few months ago and provides local and remote
> caching of maven project's output, based on computed hashes of the inputs.
> It's defined as a maven extension and can be used as a core or build
> extension. This avoids building the project and speeds up builds a lot !
>
> The current status of this work resides in 3 branches:
> * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> The two first PRs include the required changes to integrate the extension
> in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the one
> that should be moved to a separate repository and contain the code for the
> extension. The goal is to agree on the location and the final name for the
> repository (it can't be changed easily).
>
> I propose maven-caching as the repository / subproject name, but any better
> name is welcomed of course.
>
I dislike the name 'maven-caching' because it is very very generic.
What does it cache? Just like we have Maven Artifact Resolver. The name
should tell what it caches, e.g., maven-build-cache/caching/cacher, or
maven-incremental-build...
Consider that the Maven local repository is also called Maven local
artifact repo cache, etc.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Guillaume Nodet <gn...@apache.org>.
Awesome, thx a ton Hervé !
Le sam. 15 janv. 2022 à 19:01, Herve Boutemy <hb...@apache.org> a écrit :
> Jira project created and issues moved: old issues like
> https://issues.apache.org/jira/browse/MNG-7129 will automatically
> redirect to their new location
>
> issue https://issues.apache.org/jira/browse/MNG-7391 created to track the
> addition of API to Maven core that is required for Build Cache extension,
> with associated PRs for Maven 3.8.x and Maven 4
> We'll need review to merge these PRs for the next Maven releases to be
> able to support the extension
>
> Documentation published to
> https://maven.apache.org/extensions/maven-build-cache-extension/
>
> I think this extension starts to be in a reasonable state for Maven devs
> to test: next key step will be MNG-7391 PRs merged and Maven releases done
>
> Regards,
>
> Hervé
>
> On 2022/01/13 09:55:01 Maximilian Novikov wrote:
> > Thanks a lot Herve, well done on moving the extension to a new repo.
> >
> > >> (1) ok if I delete MNG-7129-maven-caching branch from maven.git?
> > +1, ok
> >
> > >> (2) ok for me to create MBUILDCACHE Jira project?
> > +1
> >
> > >>(3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira
> project?
> > Mb, copy or clone ? as #607 and #622 are done under this Jira
> >
> > Kind regards,
> > Max
> >
> > -----Original Message-----
> > From: Hervé BOUTEMY <he...@free.fr>
> > Sent: Tuesday, January 11, 2022 2:17 AM
> > To: Maven Developers List <de...@maven.apache.org>
> > Subject: Re: [DISCUSS] Move maven caching to an external repository
> >
> > let's finish the work
> >
> > code of former MNG-7129-maven-caching branch is now in
> https://github.com/apache/maven-build-cache-extension
> >
> > (1) ok if I delete MNG-7129-maven-caching branch from maven.git?
> >
> > (2) ok for me to create MBUILDCACHE Jira project?
> >
> > (3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira
> project?
> >
> > (4) I tried to rebase MNG-7129-3.8.x, but it was not ok: please rebase
> (to avoid future merge commit)
> >
> > (5) https://github.com/apache/maven/pull/607 requires some rework and
> rebase on top of master to become mergeable
> >
> > (6) for (4) and (5), define if the new API should be tracked with
> MNG-7129 or if another MNG issue should be defined (= what I suppose)
> >
> > (7) update Maven 3 and Maven 4 submodules link in
> https://github.com/apache/ maven-build-cache-extension to match previous
> updates
> >
> >
> > I don't know what will remain after that for a release, but at least,
> we'll be in a clean situation
> >
> > Regards
> >
> > Hervé
> >
> > Le mardi 7 décembre 2021, 09:47:12 CET Guillaume Nodet a écrit :
> > > Following the recent work done to integrate the maven caching /
> > > incremental build system into maven, I think it's now time to discuss
> > > where we want its long-term location to be.
> > >
> > > This extension was donated a few months ago and provides local and
> > > remote caching of maven project's output, based on computed hashes of
> the inputs.
> > > It's defined as a maven extension and can be used as a core or build
> > > extension. This avoids building the project and speeds up builds a
> lot !
> > >
> > > The current status of this work resides in 3 branches:
> > > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > The two first PRs include the required changes to integrate the
> > > extension in maven 3.8.x (or rather 3.9.x) and in master. The last
> > > branch is the one that should be moved to a separate repository and
> > > contain the code for the extension. The goal is to agree on the
> > > location and the final name for the repository (it can't be changed
> easily).
> > >
> > > I propose maven-caching as the repository / subproject name, but any
> > > better name is welcomed of course.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > ---
> > This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
> >
> > Please refer to https://www.db.com/disclosures for additional EU
> corporate and regulatory disclosures and to
> http://www.db.com/unitedkingdom/content/privacy.htm for information about
> privacy.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
RE: [DISCUSS] Move maven caching to an external repository
Posted by Herve Boutemy <hb...@apache.org>.
Jira project created and issues moved: old issues like
https://issues.apache.org/jira/browse/MNG-7129 will automatically redirect to their new location
issue https://issues.apache.org/jira/browse/MNG-7391 created to track the addition of API to Maven core that is required for Build Cache extension, with associated PRs for Maven 3.8.x and Maven 4
We'll need review to merge these PRs for the next Maven releases to be able to support the extension
Documentation published to
https://maven.apache.org/extensions/maven-build-cache-extension/
I think this extension starts to be in a reasonable state for Maven devs to test: next key step will be MNG-7391 PRs merged and Maven releases done
Regards,
Hervé
On 2022/01/13 09:55:01 Maximilian Novikov wrote:
> Thanks a lot Herve, well done on moving the extension to a new repo.
>
> >> (1) ok if I delete MNG-7129-maven-caching branch from maven.git?
> +1, ok
>
> >> (2) ok for me to create MBUILDCACHE Jira project?
> +1
>
> >>(3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira project?
> Mb, copy or clone ? as #607 and #622 are done under this Jira
>
> Kind regards,
> Max
>
> -----Original Message-----
> From: Hervé BOUTEMY <he...@free.fr>
> Sent: Tuesday, January 11, 2022 2:17 AM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: [DISCUSS] Move maven caching to an external repository
>
> let's finish the work
>
> code of former MNG-7129-maven-caching branch is now in https://github.com/apache/maven-build-cache-extension
>
> (1) ok if I delete MNG-7129-maven-caching branch from maven.git?
>
> (2) ok for me to create MBUILDCACHE Jira project?
>
> (3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira project?
>
> (4) I tried to rebase MNG-7129-3.8.x, but it was not ok: please rebase (to avoid future merge commit)
>
> (5) https://github.com/apache/maven/pull/607 requires some rework and rebase on top of master to become mergeable
>
> (6) for (4) and (5), define if the new API should be tracked with MNG-7129 or if another MNG issue should be defined (= what I suppose)
>
> (7) update Maven 3 and Maven 4 submodules link in https://github.com/apache/ maven-build-cache-extension to match previous updates
>
>
> I don't know what will remain after that for a release, but at least, we'll be in a clean situation
>
> Regards
>
> Hervé
>
> Le mardi 7 décembre 2021, 09:47:12 CET Guillaume Nodet a écrit :
> > Following the recent work done to integrate the maven caching /
> > incremental build system into maven, I think it's now time to discuss
> > where we want its long-term location to be.
> >
> > This extension was donated a few months ago and provides local and
> > remote caching of maven project's output, based on computed hashes of the inputs.
> > It's defined as a maven extension and can be used as a core or build
> > extension. This avoids building the project and speeds up builds a lot !
> >
> > The current status of this work resides in 3 branches:
> > * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > The two first PRs include the required changes to integrate the
> > extension in maven 3.8.x (or rather 3.9.x) and in master. The last
> > branch is the one that should be moved to a separate repository and
> > contain the code for the extension. The goal is to agree on the
> > location and the final name for the repository (it can't be changed easily).
> >
> > I propose maven-caching as the repository / subproject name, but any
> > better name is welcomed of course.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
> Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [DISCUSS] Move maven caching to an external repository
Posted by Maximilian Novikov <ma...@db.com.INVALID>.
Thanks a lot Herve, well done on moving the extension to a new repo.
>> (1) ok if I delete MNG-7129-maven-caching branch from maven.git?
+1, ok
>> (2) ok for me to create MBUILDCACHE Jira project?
+1
>>(3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira project?
Mb, copy or clone ? as #607 and #622 are done under this Jira
Kind regards,
Max
-----Original Message-----
From: Hervé BOUTEMY <he...@free.fr>
Sent: Tuesday, January 11, 2022 2:17 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: [DISCUSS] Move maven caching to an external repository
let's finish the work
code of former MNG-7129-maven-caching branch is now in https://github.com/apache/maven-build-cache-extension
(1) ok if I delete MNG-7129-maven-caching branch from maven.git?
(2) ok for me to create MBUILDCACHE Jira project?
(3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira project?
(4) I tried to rebase MNG-7129-3.8.x, but it was not ok: please rebase (to avoid future merge commit)
(5) https://github.com/apache/maven/pull/607 requires some rework and rebase on top of master to become mergeable
(6) for (4) and (5), define if the new API should be tracked with MNG-7129 or if another MNG issue should be defined (= what I suppose)
(7) update Maven 3 and Maven 4 submodules link in https://github.com/apache/ maven-build-cache-extension to match previous updates
I don't know what will remain after that for a release, but at least, we'll be in a clean situation
Regards
Hervé
Le mardi 7 décembre 2021, 09:47:12 CET Guillaume Nodet a écrit :
> Following the recent work done to integrate the maven caching /
> incremental build system into maven, I think it's now time to discuss
> where we want its long-term location to be.
>
> This extension was donated a few months ago and provides local and
> remote caching of maven project's output, based on computed hashes of the inputs.
> It's defined as a maven extension and can be used as a core or build
> extension. This avoids building the project and speeds up builds a lot !
>
> The current status of this work resides in 3 branches:
> * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> The two first PRs include the required changes to integrate the
> extension in maven 3.8.x (or rather 3.9.x) and in master. The last
> branch is the one that should be moved to a separate repository and
> contain the code for the extension. The goal is to agree on the
> location and the final name for the repository (it can't be changed easily).
>
> I propose maven-caching as the repository / subproject name, but any
> better name is welcomed of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org
---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Move maven caching to an external repository
Posted by Hervé BOUTEMY <he...@free.fr>.
let's finish the work
code of former MNG-7129-maven-caching branch is now in
https://github.com/apache/maven-build-cache-extension
(1) ok if I delete MNG-7129-maven-caching branch from maven.git?
(2) ok for me to create MBUILDCACHE Jira project?
(3) ok for me to move MNG-7129 issue (and sub-tasks) to that new Jira project?
(4) I tried to rebase MNG-7129-3.8.x, but it was not ok: please rebase (to
avoid future merge commit)
(5) https://github.com/apache/maven/pull/607 requires some rework and rebase
on top of master to become mergeable
(6) for (4) and (5), define if the new API should be tracked with MNG-7129 or
if another MNG issue should be defined (= what I suppose)
(7) update Maven 3 and Maven 4 submodules link in https://github.com/apache/
maven-build-cache-extension to match previous updates
I don't know what will remain after that for a release, but at least, we'll be
in a clean situation
Regards
Hervé
Le mardi 7 décembre 2021, 09:47:12 CET Guillaume Nodet a écrit :
> Following the recent work done to integrate the maven caching / incremental
> build system into maven, I think it's now time to discuss where we want its
> long-term location to be.
>
> This extension was donated a few months ago and provides local and remote
> caching of maven project's output, based on computed hashes of the inputs.
> It's defined as a maven extension and can be used as a core or build
> extension. This avoids building the project and speeds up builds a lot !
>
> The current status of this work resides in 3 branches:
> * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> The two first PRs include the required changes to integrate the extension
> in maven 3.8.x (or rather 3.9.x) and in master. The last branch is the one
> that should be moved to a separate repository and contain the code for the
> extension. The goal is to agree on the location and the final name for the
> repository (it can't be changed easily).
>
> I propose maven-caching as the repository / subproject name, but any better
> name is welcomed of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org