>“.gitignore” and “.gitattributes” files
.gitignore and .gitattributes can easily be helpful during the build, so it
does sound strange to exclude them.
For instance, Apache Calcite uses .gitattribute to configure that specific
files should have an "executable" bit in the resulting tar.gz
>correctly even if the encoding changes, because that will lead to the file
>being overwritten.
Once again: decoding does **not** guarantee you get **invalid** string when
decoding fails.
The replacement string might look like a regular string, and it might even
collide with the input string.
>the result string will be corrupted when read
The javadoc does not guarantee the string will be "corrupted" :-/
The "default replacement string" is quite a vague definition,
so there might be an encoding where "default replacement string"
means regular ASCII question mark "?".
All in all,
I believe the added CachingWriter is might become a cause of silent
failures.
What CachingWriter does is an attempt to read the file and decode it with
the provided encoding.
Apparently, the decoding might fail since the file might be written in
another encoding or it might be corrupted.
A
Enrico>signed by another Apache committer (not strictly from Maven project)
AFAIK that is not required:
https://infra.apache.org/release-distribution.html#sigs-and-sums
The key must be in Maven's KEYS file though.
Vladimir
Hi,
Do you think $subj message can be more user-friendly?
Can it include the reasons for the failure and steps to resolve the issue
rather than merely "This project has been banned"?
The message is extremely confusing :((
In case you wonder, here's a sample build log:
> Copyright problem in Google sources.
Are you going to copy gson sources to maven source code?
If you do that, you need to keep the copyright.
Are you going to take the jar and optionally shade it?
In that case you need to check if gson.jar is accompanied with NOTICE file.
If notice is there,
>Why not using XML and built in java support?
It is no longer built-in:
https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#JDK-8190378
Vladimir
> Here the GSON library is only one
https://github.com/FasterXML/jackson-jr is 100KiB or so.
Have you checked it?
Vladimir
Robert>Once the Maven Wrapper has it's final location, one can provide new
PRs on our codebase
Do you think Wrapper script should verify the integrity of the downloaded
file?
AFAIK the current implementation just downloads a file and executes it.
Executing random files from the internet does not
Cristi>Is there any place to contribute the change?
Here:
https://github.com/apache/maven-ant-tasks/blob/ed4d9a3bd1a41613791f2466f19c225898d45519/src/main/java/org/apache/maven/artifact/ant/AbstractArtifactWithRepositoryTask.java#L55
PS. https://issues.apache.org/jira/browse/MANTTASKS-206 seems
Robert>last time their argument was that they didn't have enough committers
to also maintain a maven plugin
TL;DR: I'm neither Maven nor Checkstyle committer, and I'm inclined that
the PR should be declined.
The case is as follows: there's a method in Checkstyle which is a no-op for
3 years or
Enrico>(I apologize, I don't want to pollute the vote thread, but this is
somehow
related)
I've altered the subject.
Enrico> For binary release (that actually is not part of the official VOTE)
I'm not a lawyer, but:
> http://www.apache.org/legal/release-policy.html#what
> WHAT IS A RELEASE?
>
> Are you referring to his statement of the MIT license?
I am
Vladimir
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1535/
-1 since
https://repository.apache.org/content/repositories/maven-1535/org/apache/maven/wagon/wagon-http/3.3.4/wagon-http-3.3.4-shaded.jar
violates licensing terms for the third-party code.
One of the violations is
OpenJDK8 uses hashmap for manifest entries, so jar files are not really
reproducible there.
Note: there's run-to-run randomization in j.u.HashMap, so the manifest
contents is not predictable.
Vladimir
Karl>on the language features but since JDK8 I don't see any advantage
What about Kotlin?
There are nice things there: the language is statically compiled, great
Java interop, there are extension functions, multiline strings, helpful
standard library, default parameters.
Kotlin is great for
Mickael>there was no other critical issues pending
I guess https://issues.apache.org/jira/browse/MNG-6771 (licensing issues
with binary artifacts) is a blocker for the release.
Vladimir
>ISO 8601 is neither aware of zones or
>DSTs, just abstract offsets which is a good thing
Well. ISO 8601 allows timestamps without "UTC offset"
For instance, 2019-10-06T12:30:00 is ISO 8601-compatible timestamp, however
it is ambiguous.
So I suggest that the property must require Z or +HH:MM
>but
>who really looks at the timestamp of entries in release zips/jars/tar.gz
>honestly?
Tomcat when it decides on what to send in the "Last-Modified" header.
For instance, current Gradle does not allow to configure the timestamp, and
for reproducible builds it always sets the timestamp to 0 or
Robert> According to the ASF the -sources.zip are the official release, not
the git tag
That's right
Robert>In this case you don't control the EOL, it is based on the OS of the
release manager.
Is it? I would disagree here.
For instance, Apache JMeter produces both -src.zip (CRLF), and
Eric>In that case, we should generate the test files (to
Eric>avoid git interfering), one with linux-style EOLs and one with
Eric>Windows-style EOLs and test with both.
You'd better have those files under Git control, and you could just specify
.gitattributes so the LF file is always LF, and CRLF
Just in case: I see you seem to be battling against CRLF
For instance: https://github.com/apache/maven-checkstyle-plugin/pull/16
Did you consider to add the relevant .gitattributes file to ensure Git
converts the files automatically?
With a proper .gitattributes file, it is just impossible to
Robert>A clone from Git succeeds, but the sources.zip fails.
Robert>The files in the zip are generated on a unix system, so all EOLs in
text files are LF
Robert>...
Robert>The fix: add a setup.groovy to the IT and rewrite the java files
with OS specific EOLs
Alternative approaches:
A) Provide
Enrico> limited to linux and osx, not windows.
Windows can be tested via AppVeyor.
The configuration is the same: one adds appveyor.yml (e.g.
https://github.com/apache/calcite/blob/master/appveyor.yml ) and asks
Infra team to enable AppVeyo-GitHub integration.
Vladimir
Enrico> For instance maven-surefire
integration tests take 2 hours.
In general I see Travis (free edition) does not offer many resources.
Each Travis job is limited by 50 minutes, however one can split tests into
multiple jobs, so it will run fine.
Vladimir
Enrico> Probably Travis won't be able to run our ITs, at least the free
version
Why do you think so?
Vladimir
Stephen > Are you sure?
I've just created a dummy account and "approval" does not make merge button
magically appear.
If you have a couple of minutes, please make a PR (I'll approve it shortly)
to https://github.com/vlsi/KE-complex_modifications
Note: you can click "edit" button in GitHub UI for
Karl Heinz Marbaise > The user community is very big but unfortunately the
people who are
Karl Heinz Marbaise > willing to help is not that big...
Can I (ab)use the thread a bit?
One of the issues I run into with Maven is "it takes ages for repeated
build when nothing has changed".
Of course
> And, again, TravisCI also does the same in a decent way, with the benefit
> of worrying less about underlying infra and security, and only drawback of
> being discoupled from a specific infra (is it really a drawback?)
Just in case: Apache Calcite uses both Travis CI and AppVeryor. It just
Stephen> Well on other GitHub orgs i’ve seen PR author has Merge
button once PR is
Stephen> approved by someone with push rights to the repo... until
they add a commit
Stephen> or the merge result changes
It does not work the way you describe.
1) By default GitHub defaults to "Base permissions"
Stephen> Nah. Once committers have approved the PR then the PR can be
merged by the
Stephen> creator of the PR even if not a committer... at least that’s
the default
Stephen> way GitHub PRs work
By default one needs push rights on the repository to merge PRs.
"Approval" changes nothing. "PR
Hi,
Would anyone be so kind to release maven-remote-resources-plugin ?
My patch was merged more than 3 years ago, and the official release is
still missing.
Here's the JIRA link: https://issues.apache.org/jira/browse/MRRESOURCES-91
The problem is org.apache:apache pom uses
33 matches
Mail list logo
