Alexander, Releasing on downloads.apache.org is Apache policy, period, and not up for discussion here within the Xalan project. Please read https://www.apache.org/legal/release-policy.html
Gary On Thu, Dec 21, 2023, 7:45 PM Alexander Kriegisch <alexan...@kriegisch.name> wrote: > Gary Gregory wrote elsewhere a couple of weeks ago: > > >>> The source zip/tar is an Apache requirement, the binary, a > >>> convenience. Both are "easy" to produce with a Maven build, for > >>> example, see Apache Commons VFS (or any Apache maven multi module > >>> project). > > Such requirements might exist, I just want to point out that they are > outdated and should be abolished or even relaxed. They were no doubt > made in a time before GitHub and Maven Central, but times have changed. > Such distributions are anachronisms. If the requirement is that a > complete build ought to be possible from the source ZIP, what is the > benefit of that? Users can instead be instructed to just clone the Git > repo and check out the release tag. Nobody who seriously wants to build > the product would do that from a source zip, depriving himself of the > convenience to inspect the Git commit history, switch to other branches > or tags, try to solve a problem in a local branch, switching back to the > original release tag for comparison etc. > > Of course, it would be easy to do, if that is the requirement. It would > just zip up the whole working directory after 'mvn clean'. I was under > the impression that the requirement was to reconstruct the structure of > previous source archives, e.g. Xalan-J 2.7.1, which is not the same. > That was a misunderstanding on my part. > > Anyway, it is a waste of resources and yields no benefit. Even if a user > does *not* want to clone the Git repo with history etc., he can still > just navigate to e.g. > > https://github.com/apache/xalan-java/tree/xalan-j_2_7_1 > > click the green "Code" button and select "Download ZIP" from there, > resulting in exactly > > https://github.com/apache/xalan-java/archive/refs/tags/xalan-j_2_7_1.zip > > That is pretty much identical to the source zip for 2.7.1, only this > version contains the actually tagged release versions, while the > manually created source zip contains sources many of which have a > slightly different content, meaning that either the tag is on the wrong > version (bad) or the source zip is not really equivalent to the > correctly tagged 2.7.1 (equally bad). Do you see, how error-prone and > unreliable that kind of process to recreate something that already is > under source control and then serve it from Apache hardware is? Really, > I do not need a Maven Assembly to reproduce something that is under SCM > control. > > Grace Hopper - I hope you know who she was - famously and truly said: > > Humans are allergic to change. > They love to say, "We've always done it this way." > I try to fight that. > That's why I have a clock on my wall that runs counter-clockwise. > > >>> Note that this src zip/tar file is distributed on Apache hardware > >>> from a distribution server folder which is DIFFERENT from any other > >>> files from a Maven repository for -sources and -javadoc JAR files. > > Of course, it is different, because it contains a snapshot of the source > repo for a certain release tag, while artifacts on Maven Central contain > sources per module. The latter do not mean to be compilable projects, > but references, e.g. to be used when displaying the source for > dependency classes or javadocs from an IDE. But like I explained above, > that does not justify the existence of the former, as it can be obtained > via Git or GitHub (replace by any other future SCM platform). > > Some more thoughts, after I let this topic rest for a few weeks: > > Assuming, you have cloned the repo already, you can create a source ZIP > in no time for any tag, current branch head or commit ID like this: > > $ time git archive -o xalan-j_2_7_1-src.zip xalan-j_2_7_1 > > real 0m0.861s > user 0m0.015s > sys 0m0.000s > > If you have not cloned the repo yet and only want a shallow clone for > the purpose of creating just the zip for a specific commit: > > $ git clone --branch xalan-j_2_7_1 --depth=1 > https://github.com/apache/xalan-java.git > > Then, use 'git archive' to create a ZIP and afterwards delete the > shallow clone again to clean up. > > $ git --git-dir=xalan-java/.git archive -o xalan-j_2_7_1-src.zip > xalan-j_2_7_1 > $ rm -rf xalan-java/ > > There is even 'git archive --remote', but GitHub does not support it in > favour of its own archive download URLs, like mentioned further above. > Again, for overview: > > https://github.com/apache/xalan-java/archive/refs/tags/xalan-j_2_7_1.zip > > You see, there are plenty of ways we could instruct users how to get > source archives, right on the distro download page. It would be easy to > explain, most easily the GitHub URLs, because they do not even require a > local Git installation. (But which developer does not have that?) If I > want to build an OSS project from source, I want a full clone, not a > shallow copy or a ZIP. > > Welcome to the 21st century! ;-) > > -- > Alexander Kriegisch > https://scrum-master.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org > For additional commands, e-mail: dev-h...@xalan.apache.org > >
