Search Criteria
Package Details: payara 6.2024.8-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/payara.git (read-only, click to copy) |
---|---|
Package Base: | payara |
Description: | Jakarta EE (Java EE) & MicroProfile compatible application server for production and containerized deployments. |
Upstream URL: | http://www.payara.fish/ |
Keywords: | glassfish jakartaee java javaee |
Licenses: | GPL2, CDDL |
Submitter: | None |
Maintainer: | morealaz |
Last Packager: | morealaz |
Votes: | 5 |
Popularity: | 0.000000 |
First Submitted: | 2016-12-19 20:58 (UTC) |
Last Updated: | 2024-08-25 07:30 (UTC) |
Dependencies (1)
- java-environment (jdk12AUR, jdk10AUR, jdk10-openj9-binAUR, jdk7AUR, amazon-corretto-16AUR, jdk8-graalvm-binAUR, jdk16-graalvm-binAUR, jdk16-adoptopenjdkAUR, jdk8-armAUR, liberica-jre-11-binAUR, jdk11-j9-binAUR, jdk11-jbr-xdgAUR, jdk16-openjdkAUR, jdk14-openjdkAUR, jdk18-openjdkAUR, amazon-corretto-19-binAUR, jdk19-graalvm-binAUR, liberica-jre-11-full-binAUR, jdk19-graalvm-ee-binAUR, jdk13-openjdk-binAUR, liberica-jre-8-full-binAUR, jdk11-graalvm-binAUR, jdk-openj9AUR, jdk11-graalvm-ee-binAUR, jdk12-openjdkAUR, jdk11-dragonwell-standard-binAUR, jdk11-jetbrains-binAUR, jdk20-graalvm-binAUR, jdk17-graalvm-binAUR, jdk8-graalvm-ee-binAUR, zulu-15-binAUR, jdk20-openj9-binAUR, zulu-13-binAUR, jdk8-dragonwell-extended-binAUR, jdk8-dragonwell-standard-binAUR, jdk11-dragonwell-extended-binAUR, jdk17-dragonwell-standard-binAUR, jdk11AUR, jdk8-j9-binAUR, jdk7-j9-binAUR, jdk7r1-j9-binAUR, jdk8-dragonwell-extendedAUR, jdk13-openjdkAUR, jdk15-openjdkAUR, jdk21-graalvm-binAUR, jdk17-jetbrainsAUR, jdk8-openj9-binAUR, jdk-ltsAUR, microsoft-openjdk-11-binAUR, microsoft-openjdk-17-binAUR, microsoft-openjdk-21-binAUR, liberica-nik-24-full-binAUR, jdk21-jetbrains-gitAUR, zulu-17-binAUR, zulu-11-binAUR, zulu-8-binAUR, mandrel-binAUR, mandrel24-binAUR, liberica-jdk-17-full-binAUR, liberica-jdk-11-lite-binAUR, liberica-jdk-11-full-binAUR, liberica-jdk-11-binAUR, jdk17-graalvm-ee-binAUR, jdk21-graalvm-ee-binAUR, jdk22-graalvm-ee-binAUR, jdk20-graalvm-ee-binAUR, jdk22-graalvm-binAUR, jdk19-openjdkAUR, jdk17-jetbrains-binAUR, zulu-jdk-fx-binAUR, jabba-binAUR, jdk21-jetbrainsAUR, jdk17-zulu-prime-binAUR, zing-21-binAUR, zing-8-binAUR, jdk23-graalvm-ee-binAUR, jdk-android-studioAUR, java-openjdk-binAUR, amazon-corretto-17AUR, amazon-corretto-21-binAUR, jdk21-temurinAUR, amazon-corretto-8AUR, amazon-corretto-11AUR, jdk11-temurinAUR, liberica-jdk-full-binAUR, liberica-jdk-21-full-binAUR, liberica-jdk-8-full-binAUR, jdk17-temurinAUR, jdk8-temurinAUR, zulu-21-binAUR, jdk-temurinAUR, jdk8AUR, zulu-17-fx-binAUR, jdk8-perfAUR, zulu-fx-binAUR, zulu8-fx-binAUR, zulu11-fx-binAUR, zulu17-fx-binAUR, zulu21-fx-binAUR, jdk-openj9-binAUR, jdk11-openj9-binAUR, jdk17-openj9-binAUR, jre-jetbrainsAUR, jdk-openjdk-wakefieldAUR, jdk21-openj9-binAUR, java-openjdk-ea-binAUR, zulu-23-binAUR, jdkAUR, jdk21-jetbrains-binAUR, jdk21-dragonwell-standard-binAUR, jdk21-dragonwell-extended-binAUR, jdk-openjdk, jdk11-openjdk, jdk17-openjdk, jdk21-openjdk, jdk8-openjdk)
Latest Comments
1 2 Next › Last »
<deleted-account> commented on 2019-02-05 10:29 (UTC)
@hrauch: thank you for updating package, but why suddenly
pkgrel
increased from 1 to 3?wget commented on 2018-09-01 18:53 (UTC)
@se1by And btw, the permissions are incorrect to the domain folder leading to the inability to deploy apps using an IDE like NetBeans for example (the latter has no write rights to this folder and cannot deploy an app. The IDE is then asking us to create an out of tree domain).
So I assume what would be best is to create a dedicated user/group for payara and add the end user to that group in order for him to have write access to the domain folder (some kind of instructions should be written on the Wiki). What do you think?
<deleted-account> commented on 2018-09-01 16:24 (UTC)
@se1by: As @Eschwartz said, please remove
Provides
andConflicts
fromPKGBUILD
.eschwartz commented on 2018-08-26 02:19 (UTC)
Regarding the micro version, you can just upload the new package named "payara-micro", then submit a merge request for it to be merged into the new package.
Merge requests result in the package being deleted and votes and comments being transferred over, so in this case it doesn't really matter whether it is deleted or merged... but either way, you cannot just rename the repo. (e.g. the pkgbase still needs to match.)
Also while you are at it, you can remove the provides/conflicts =("$pkgname") because that's entirely pointless. Packages don't need to provide themselves on account of they already are themselves, and claiming they're self-conflicting is... illogical and counterproductive, even if it worked which it doesn't (since as you can see you managed to install it without pacman objecting that the package you tried to install conflicts the package you tried to install). That goes for this package too.
eschwartz commented on 2018-08-26 02:11 (UTC)
@hrauch,
There's really no reason to upload duplicate packages at all.
If this package is out of date, flag it out of date. If this package is not being updated, submit an orphan request. That's the standard and supported way(s) to get a package updated.
If you upload duplicate packages, then it just causes people to not know which one to install, and get confused as to the difference between the two. It introduces clutter, makes searching for legitimately different variants of this package (i.e. -micro and the legacy 41 version) harder, and many people won't even find it in the first place because it's just illegitimately named... packages suffixed with version numbers are an indication of legacy versions of packages uploaded because someone specifically has a use for a legacy version.
I severely doubt that lots of people are being so inconvenienced by the lack of an update, that it becomes desperately important to create another package... rather than wait 14 days for an orphan request.
You already had a working update for yourself, and anyone else who needed the same was entirely free to bump the pkgver with no other changes.
Please do not submit duplicate packages again. Thanks.
hrauch commented on 2018-08-24 21:52 (UTC)
@wget yes, you're right the payare51 was created by me in order to have the latest Payara5 version ASAP.
Since now the original PKGBUILD has been updated, there's no point in the payara51 anymore.
A micro version as such does make sense (IMHO) when deploying JEE conformant micro services. You definately got a point concerning naming: it should've been named payara-micro from the start (my mistake; apologies).
Unfortunately, I haven't ssen an option to completely remove a repo (the only two options that seemed reasonable to me were to flag it as out of date and to disown it. It opted for both.
Concerning payara5-micro: I haven't come accross an option to just rename a repo, unfortunately.
wget commented on 2018-08-24 17:55 (UTC)
@se1by, there is no harm in adding someone willing to help as co-maintainer, I'm always in favor of it. Plurality is always better than a single point of failure (bus factor).
I asked the TUs to merge payara51 into this one. That version wasn't adding something very useful. I saw there was a micro version as well, please talk to each other about the need to have a micro version. Then maybe payara-micro would be better than payara5-micro.
Just my two cents.
se1by commented on 2018-03-22 13:48 (UTC)
@hrauch Updated to the new version ;) Thanks for your offer, but I think one maintainer is enough, as it is really not that much work to keep this package up to date. Just mark it out of date if I miss a version and I'll update it ASAP :)
hrauch commented on 2018-03-22 13:08 (UTC)
@se1by could you please add me as a co maintainer? There's a new version available (5.181). I've already made the minor changes to PKGBUILD and tested them locally. Thanks.
<deleted-account> commented on 2017-11-16 18:46 (UTC)
1 2 Next › Last »