Re: Merging via GitHub
Could someone who understands Git and what should happen update https://maven.apache.org/developers/conventions/git.html with detailed instructions? I've tried every variation I can imagine and nothing seems to produce the results that are being asked for. Also, if you don't want people to use Merge || Squash || Rebase each of those can be disabled in the repo. On Mon, May 11, 2020 at 6:24 PM Benson Margulies wrote: > > Could you send me a pointer to refresh my memory on procedures? It's been a > while ... > > On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote: > > > Folks, > > > > please do NOT merge via merge button in GitHub: > > > > > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, > > origin/HEAD) > > > Merge: 34253e3d f7de3a6e > > > Author: Elliotte Rusty Harold > > > Commit: GitHub > > > > > > Merge pull request #66 from apache/plex > > > > > > [SCM-930] update plexus-utils > > > > > > commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 > > > Author: Elliotte Rusty Harold > > > Commit: Elliotte Rusty Harold > > > > > > update plexus-utils > > > > 1. It produces useless merge commits > > 2. GitHub is NOT a blessed committer > > > > It is OK, wenn a clean rebased merge is performed and not traces of > > GitHub are left. > > > > Michael > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Merging via GitHub
It's possible to configure GitHub to allow rebase and merge, which I think is what you want. It may be possible to configure GitHub to only allow this. I’m not sure if this is something infra has to do or if a project admin can set it up. Camel recently made a related change. David Jencks > On May 11, 2020, at 3:23 PM, Benson Margulies wrote: > > Could you send me a pointer to refresh my memory on procedures? It's been a > while ... > > On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote: > >> Folks, >> >> please do NOT merge via merge button in GitHub: >> >>> commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, >> origin/HEAD) >>> Merge: 34253e3d f7de3a6e >>> Author: Elliotte Rusty Harold >>> Commit: GitHub >>> >>>Merge pull request #66 from apache/plex >>> >>>[SCM-930] update plexus-utils >>> >>> commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 >>> Author: Elliotte Rusty Harold >>> Commit: Elliotte Rusty Harold >>> >>>update plexus-utils >> >> 1. It produces useless merge commits >> 2. GitHub is NOT a blessed committer >> >> It is OK, wenn a clean rebased merge is performed and not traces of >> GitHub are left. >> >> Michael >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Merging via GitHub
This probably happens when the committer has pressed "Squash and merge". I expect it does not rebase. But when you press "Rebase and merge" then the commits would be rebased on the HEAD but it does not squash the commits to one. So you have to check the parent commit. If it is old then the contributor has to squash all his commits and the committer will push "Rebase and merge". This would work. If the parent is the HEAD commit then it should not be a problem to "Squash and merge". On Mon, May 11, 2020 at 10:42 PM Michael Osipov wrote: > Folks, > > please do NOT merge via merge button in GitHub: > > > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, > origin/HEAD) > > Merge: 34253e3d f7de3a6e > > Author: Elliotte Rusty Harold > > Commit: GitHub > > > > Merge pull request #66 from apache/plex > > > > [SCM-930] update plexus-utils > > > > commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 > > Author: Elliotte Rusty Harold > > Commit: Elliotte Rusty Harold > > > > update plexus-utils > > 1. It produces useless merge commits > 2. GitHub is NOT a blessed committer > > It is OK, wenn a clean rebased merge is performed and not traces of > GitHub are left. > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Merging via GitHub
Could you send me a pointer to refresh my memory on procedures? It's been a while ... On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote: > Folks, > > please do NOT merge via merge button in GitHub: > > > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, > origin/HEAD) > > Merge: 34253e3d f7de3a6e > > Author: Elliotte Rusty Harold > > Commit: GitHub > > > > Merge pull request #66 from apache/plex > > > > [SCM-930] update plexus-utils > > > > commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 > > Author: Elliotte Rusty Harold > > Commit: Elliotte Rusty Harold > > > > update plexus-utils > > 1. It produces useless merge commits > 2. GitHub is NOT a blessed committer > > It is OK, wenn a clean rebased merge is performed and not traces of > GitHub are left. > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Merging via GitHub
Folks, please do NOT merge via merge button in GitHub: commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, origin/HEAD) Merge: 34253e3d f7de3a6e Author: Elliotte Rusty Harold Commit: GitHub Merge pull request #66 from apache/plex [SCM-930] update plexus-utils commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 Author: Elliotte Rusty Harold Commit: Elliotte Rusty Harold update plexus-utils 1. It produces useless merge commits 2. GitHub is NOT a blessed committer It is OK, wenn a clean rebased merge is performed and not traces of GitHub are left. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[CANCELLED] [VOTE] Release Apache Maven Surefire Plugin version 2.22.3
Hi, I am cancelling the vote due to an issue we found. -- Cheers Tibor
Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.3
Thank you for participating. The Vote is cancelled. On Sun, May 3, 2020 at 11:44 PM Tibor Digana wrote: > Hi, > > We solved 2 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12345472 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1572/ > > https://repository.apache.org/content/repositories/maven-1572/org/apache/maven/surefire/surefire/2.22.3/surefire-2.22.3-source-release.zip > > Source release checksum(s): > > surefire-2.22.3-source-release.zip sha512:: > > c1533ed45fd3119d028a4914ca7557acfbfea5218b5536bbafeed4b33845486b976f20b39334e2917636e3739240478ca46bd25a0dc011e5fb2aa85033e9e959 > surefire-2.22.3-source-release.zip sha1: > 2db957105d2929911927482c8d2198bd6ef718a7 > > > Staging site: > N/A - we do not want to override new site with old versions 2.22.x > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Cheers > Tibor >
Re: JDK 8 Minimum Requirement for Maven Resolver 2.0
The code written in j8 looks more compact. The loops and annonymous classes with one method do not waste the code lines. You can create a branch for the Maven Resolver 2.0 and the later Maven can use it. Do we need to have Maven Resolver 2.0 in the Maven 3.7.0? The Maven 3.7.0 is @j8 and using Resolver 1.4.2. What changes you expect in Maven Resolver 2.0? If it is only Java 1.8 *code *then it should be no problem except the performance of some Streams. Probably the Maven Resolver 2.0 would be used in 3.7.1 or 3.8.0. But if the Maven 3.7.0 is @j8 then using Resolver 2.0@j8 should not harm the Maven. The older versions of Resolver can continue the development in branches. Everything would have a permanent progress and we don't have to stop somewhere in the master. On Sat, May 9, 2020 at 10:13 PM Sylwester Lachiewicz wrote: > Hi to all, > > based on the previous vote to require Java 8 for Maven Core - I would like > to propose setting the same minimum for Maven Resolver 2.0 > > Maven Resolver is a base component to solve dependencies for Maven. It can > also be used separately from Maven for other projects. > Because Java 7 updates are no longer available, the market is also moving > towards using the newer version of Java 8/11. > Practically the Core requirement means that Resolver has little chance of > being used in Java 7 (see tricks to connect to Central). > > Benefits - more programmers can practice coding while improving our > codebase. > > What's your opinion on the subject? > > https://maven.apache.org/resolver/ > > Kind regards > Sylwester >
Re: JDK 8 Minimum Requirement for Maven Resolver 2.0
Strongly agree with Elliotte. Rather than rewriting existing, working code, I'd rather see issues addressed. M Am 2020-05-09 um 22:19 schrieb Elliotte Rusty Harold: It is not true that Java 7 updates are no longer available. Java 7 updates are available from Oracle for paying customers and from other vendors such as Azul for everyone. My preference is not to move unless there's a clear reason to do so. Are there specific features in Java 8 that would be useful for Maven resolver? E.g. support for a new protocol that isn't available in Java 7 such as TLS 1.3? On Sat, May 9, 2020 at 4:13 PM Sylwester Lachiewicz wrote: Hi to all, based on the previous vote to require Java 8 for Maven Core - I would like to propose setting the same minimum for Maven Resolver 2.0 Maven Resolver is a base component to solve dependencies for Maven. It can also be used separately from Maven for other projects. Because Java 7 updates are no longer available, the market is also moving towards using the newer version of Java 8/11. Practically the Core requirement means that Resolver has little chance of being used in Java 7 (see tricks to connect to Central). Benefits - more programmers can practice coding while improving our codebase. What's your opinion on the subject? https://maven.apache.org/resolver/ Kind regards Sylwester -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] slachiewicz commented on pull request #164: [MNGSITE-407] remove old page
slachiewicz commented on pull request #164: URL: https://github.com/apache/maven-site/pull/164#issuecomment-626516421 For our site changes - no need to create jira every time This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Runtime Metrics System - MNG-6899
Hmm, it shouldn't be:
metricsSystem
.getMetricsContext()
.getSummary( "resolvePluginDependency", "Time to resolve dependencies of a
plugin (ms)" )
.add( MetricsUtils.elapsedMillis( startResolve ) );
but
counter.add(duration).
Resolution of the counter can be either (just in terms of inputs, then api
can be fluent or not, it is a detail for me):
Counter counter = metricSystem.get(new CounterSpec("my counter", "ms"));
or, since any operation in maven has a scope (mojo, artifact resolution,
...):
@Inject @MetricSpec("my-counter", "ms") Counter counter;
Concretely metrics system should enable to resolve a counter from a few
meta (at least name, likely also the unit) and counter is just a long (then
in terms of impl it is a LongAdder to be concurrency friendly I guess but
it is a detail).
We likely don't want to pay any other overhead otherwise I fully agree
events are almost 1-1 in terms of feature but totally opposed in terms of
design:
1. A counter is a unified view of data where data are pushed from
contributors
2. Event are an heterogeneous set of data where consumers are interpreting
the value
If you want to be iso you create a Counter event but then you have this
overhead we should avoid IMO + you just recreated metric system with
another API (likely slower due to the bus usage which requires a lot of
caching and JIT to be iso in terms of perf but it is really after some
dozen of thousands of executions).
Romain Manni-Bucau
@rmannibucau | Blog
| Github |
LinkedIn | Book
Le dim. 10 mai 2020 à 22:23, Enrico Olivelli a écrit :
> Il giorno dom 10 mag 2020 alle ore 22:10 Robert Scholte <
> rfscho...@apache.org> ha scritto:
>
> > This looks more like a bug, so this should be analyzed.
> > It sounds to me, that if this information was accurate, there wouldn't be
> > a need for the a separate MetricSystem.
> >
>
> Sorry, I have added that metric just to have some data to retrieve and
> monitor.
> Maybe this is not interesting.
>
> The point is that if I want to track this duration, now I can do it just by
> adding a bunch of lines locally.
> There is no need to introduce a new formal "event", that would be part of
> some public API.
> If the information is not useful I can remove it in the next release, there
> is no strong contract with the end user
>
> Enrico
>
>
>
>
>
>
>
>
> >
> > Robert
> > On 10-5-2020 20:38:39, Romain Manni-Bucau wrote:
> > Le dim. 10 mai 2020 à 20:11, Karl Heinz Marbaise a
> > écrit :
> >
> > >
> > > On 10.05.20 19:59, Romain Manni-Bucau wrote:
> > > > Events vs metrics is an old topic.
> > > > The choice between both is not only design but also about perf. In
> > terms
> > > of
> > > > design it brings the ability to export data without exposing it in
> code
> > > > (events are public). It also avoid to expose a stable api of events
> and
> > > > create coupling between plugin/exts and only require a single stable
> > api
> > > > which is very minimal (lot of projects kept their metric abstraction
> > > > stable).
> > > >
> > > > Typically wagon should export metrics but if you fire an event per
> > > download
> > > > progress it will be quite slow currently and you will allocate a lot
> of
> > > > objects (or create contentions) just to increase a monotonic counter
> (a
> > > > longadder concretely).
> > > >
> > > > So I think Enrico is right and we cant avoid metrics (I have to admit
> > > > events are overcomplex to use for plugin/ext dev, see all profiling
> > > > extensions,
> > >
> > > > not a single one works and report accurate data whereas metrics
> > > > can miss some drilldown data but would be right).
> > >
> > > Interesting point cause can you give some more details on which the
> > > testimony is based that none of them works?
> > >
> >
> > They all measure bus events, mainly mojo_start, mojo_end but at the end
> > several mojo have a duration of 0ms...even if they take minutes.
> >
> > What I saw last time I checked the two top rated by github (and google I
> > think), some events were missing (one ex where metrics are easier to
> > handle, you push your data, no computation on consumer side).
> > Out of my head in the project i was working on, gmaven plugin was totally
> > missed.
> >
> >
> > > Can you explain a accurate implementation?
> > >
> >
> > If my build take 5mn and i sum all not overlapping times of the report
> of a
> > monothreaded (T1) build then i should be close to 5mn (+- some sec for
> the
> > boot, ioc, logging, final report).
> > If I cant extract where time is spent these tools are uselesd.
> >
> > For the story i used a javaagent (based on sirona) to instrument the
> build
> > i was optimizing, was using in memory counters with dump at shutdown (in
> > csv). Indeed
