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
