[ALL] HEADER and README html links on release distribution site
There are HEADER.html and README.html files under each component, and also under the binaries/ and source/ folders. Since the content is intended to be the same, the files under binaries and source are set up as soft links to the files in the component directory. This means that only a single file has to be updated for each release, viz. the README.html file The only exception is daemon, which has a binaries/windows directory with its own files. The links had been replaced under some components, but these have now been corrected. Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] issue with publication of Jexl 3.3
On Tue, 17 Oct 2023 at 22:16, sebb wrote: > > Something went wrong with the publication of the dev staging files from > 3.3-RC2. > > The commit [1] should have included the 6 HEADER.html and README.html > files from the staging site, however these were left behind, e.g. [2] On further investigation, there should only have been HEADER and README files at the same level as the binaries and source directories. There are soft links in the subdirectories. i.e. 2 files to be created and moved, not 6. If indeed this is supposed to be done by the release plugin See https://commons.apache.org/releases/release.html > They can easily be moved, but it would be useful to know why this step > did not work, as I thought most of it was now automated? It's unclear why 6 staging files were created. > AFAICT the rest of the commit was OK. I am in process of fixing the html files, but it would be useful to know if there is a bug in the documentation or the release plugin (or both). > Sebb > [1] https://lists.apache.org/thread/oowy3bq41zncsdbns4yxslknr8r2dmbn > [2] https://dist.apache.org/repos/dist/dev/commons/jexl/3.3-RC2/binaries/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] JexlFeatures exposes internal flag representation
There's another reason why using public constants is problematic: The Java compiler inlines constants into the class that uses them. So, if we change a constant and only recompile that class and not the referencing class, we can get inconsistent constant values. This means that changes to public constants will create a new jar that is **not binary compatible**. I was caught by this feature in JMeter, which originally used public constants for version details. JMeter consists of multiple separately compiled plugin jars, and I could not work out why updated version info was not propagating. (The solution was to use a getter for the constant) Best to only expose constants that truly are constant, and also only to expose constants that need to be exposed. Sebb See for example: https://forums.oracle.com/ords/apexds/post/final-variable-inlining-why-2465 On Sun, 22 Oct 2023 at 07:12, sebb wrote: > > A recent change to JexlFeatures made some flag combinations public. > Seems to me that this unnecessarily exposes the internal > representation, which makes it much harder to change it later. > > Making constants public can constrain future changes, whereas > providing access via methods is easier to maintain, so ideally don't > expose constants unnecessarily. > > Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] - Move commons-chain to dormant?
+1 > On Oct 21, 2023, at 7:46 PM, Gary Gregory wrote: > > Seems reasonable to me. > > Gary > > On Sat, Oct 21, 2023, 6:49 PM sebb wrote: > >> Reviving this thread. >> >> I think we should now change chain to dormant. >> >> Sebb >> >> On Sun, 8 Oct 2017 at 16:10, Pascal Schumacher >> wrote: >>> >>> Looks like Apache Tiles 3 does not use commons-chain. >>> >>> The only mention of commons-chain I could find in >>> https://github.com/apache/tiles/tree/trunk was an exclusion a of >>> transitive commons-chain dependency. >>> >>> https://tiles.apache.org/framework/tiles-compat/dependencies.html also >>> does not list commons-chain. >>> >>> Looks like the most popular project depending on commons-chain was >>> Struts (but only till 1.3.x (last released in 2008)). >>> >>> According to >>> >> https://mvnrepository.com/artifact/commons-chain/commons-chain/1.2/usages >>> "Magnolia" and "eXo JCR" are the most popular projects using >> commons-chain. >>> >>> -Pascal >>> >>> Am 08.10.2017 um 16:48 schrieb Rob Tompkins: What’s the largest project that depends upon it? Apache “Tiles” seems >> to. -Rob > On Oct 8, 2017, at 9:44 AM, Benedikt Ritter >> wrote: > > > >> Am 07.10.2017 um 12:35 schrieb Pascal Schumacher < >> pascalschumac...@gmx.net>: >> >> Hello everybody, >> >> the last commons-chain release is from 2008. >> >> The last bugfix/feature commits are from 2013. >> >> Since 2013 only one bugfix/feature released issue was created in >> JIRA. >> >> Maybe it is time to move the component to dormant? >> >> What do you think? > We had somebody asking for the component a few weeks ago, but that is >> everything that has happened in ages. So +1 > >> -Pascal >> >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JEXL] JexlFeatures exposes internal flag representation
A recent change to JexlFeatures made some flag combinations public. Seems to me that this unnecessarily exposes the internal representation, which makes it much harder to change it later. Making constants public can constrain future changes, whereas providing access via methods is easier to maintain, so ideally don't expose constants unnecessarily. Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
