Re: Generated BOM files
While GitHub actions shouldn’t be able to commit anything, they can create a PR that can then be reviewed and merged by a committer. Apache camel uses this to good effect: they have far more complicated things than BOMs generated. David Jencks Sent from my iPhone > On Feb 9, 2022, at 6:40 AM, Zowalla, Richard > wrote: > > I think, that the inconvience originates from the fact, that one has to > conduct a quick build w/o tests after changing a simple version string > - even if one does not expect any compile issues and just want to see > the impact in a CI/CD environment > > The current "generate in the build" is tied to "package". > > >> Am Mittwoch, dem 09.02.2022 um 15:33 +0100 schrieb Jean-Louis Monteiro: >> Thanks David for the extra infra information. That makes the >> automation a >> bit harder indeed. >> >> Let's keep the "generate in the build" as it is today and see if we >> can >> remember to push and when I say we, I mean "I" >> >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> >> On Wed, Feb 9, 2022 at 3:15 PM David Blevins >> wrote: >> >>> The trick is that Apache doesn’t have any bot accounts that we >>> could use to >>> do commits to master. So there really isn’t any way to use >>> Jenkins, GitHub >>> Actions, etc. >>> >>> The limited functionality Apache does have for committing files is >>> for >>> website generation, but it is setup to only work for branches >>> called >>> “asf-site” (or something like that) and works from only one >>> specific >>> Jenkins node. >>> >>> The best we could do is create a bot that made a PR one of us had >>> to merge >>> and/or get this to be done in the build and we ensure we remember >>> to commit >>> it. (We could potentially do both so there is a convenient backup >>> if we >>> forget to do the commit ourselves before we push). >>> >>> -David >>> >>> On Wed, Feb 9, 2022 at 8:51 AM Jean-Louis Monteiro < >>> jlmonte...@tomitribe.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> We have discussed many times with Richard on Slack mainly around >>>> this >>>> topic. But I wanted to discuss it over here and have some >>>> brainstorming. >>>> >>>> We have had BOM files for quite a while. To avoid the pain to >>>> update and >>>> maintain them, David created a script to generate them. All good. >>>> >>>> The problem comes when one is updating or adding or removing a >>> dependency. >>>> And I must apologize because it happened to me pretty much every >>>> single >>>> time. Richard has been looking after the build and fixing my >>>> garbage by >>>> generating again the BOM files to commit them. Thanks for that. >>>> >>>> We discussed an approach to generate them in the build so Jenkins >>>> is >>> always >>>> happy. It works but it has bigger side effects in my opinion. >>>> >>>> 1/ Jenkins does not commit and then it does not fix my garbage >>>> 2/ the snapshots the user uses don't reflect what the CI is >>>> testing which >>>> deserves the purpose. >>>> 3/ the mess is hidden and when cutting the release there is a >>>> risk for >>> the >>>> BOM files to not be up to date >>>> >>>> I think we should revert this and at least let the build to fail >>>> so we >>> can >>>> fix it and maintain the BOM files. >>>> >>>> I have also investigated Github actions. We could also create a >>>> couple of >>>> Github actions >>>> >>>> - to generate the BOM files AND commit them to git if they >>>> changed. So >>> they >>>> are always up to date and the CI system runs on what the user is >>>> using >>>> >>>> - check file headers to make sure they have ASLv2 header. This is >>>> a >>> common >>>> error and CI will fail with RAT/checkstyle/PMD in the sanity >>>> checks build >>>> >>>> - do some updates on the website if needed >>>> >>>> We could start with the BOM and look at the headers. They should >>>> be >>> fairly >>>> easy to handle and bring some immediate value. >>>> >>>> What do you think? >>>> >>>> -- >>>> Jean-Louis Monteiro >>>> http://twitter.com/jlouismonteiro >>>> http://www.tomitribe.com >>>> >>> -- >>> Sent from Gmail Mobile >>>
Re: TomEE Jakarta project - have we reach the limit?
Maybe even “Our second release _confirmed_…”… David Jencks > On Oct 4, 2021, at 12:33 PM, David Blevins wrote: > >> - Our first release proved releasing both 8 & 9 together can be impractical. >> The TomEE 8 binaries were a dud, only TomEE 9 was released. There was >> communication overhead and made for a potentially confusing release. The >> TomEE 9 binaries are still very limited. >> >> - Our first release proved releasing both 8 & 9 together can be impractical. >> The TomEE 8 binaries were released, we didn't release TomEE 9. It's the >> second time we've done that. We've only managed one TomEE 9 release in the >> last 10 months. > > This was supposed to start "our second release". CopyPasteException :) > > -David >
Re: Website documentation for own-git-repo subprojects
OOPS wrong list, sorry, David Jencks > On Jul 21, 2021, at 9:37 AM, David Jencks wrote: > > The CMS website and the Antora website currently have the docs source far > from the code. As a result several subprojects (SCR, Atomos at least) have > put their documentation in a README in the subproject git repo. This results > in these subproject documentation appearing really different from other > subprojects docs and lacking the overall navigation facilities from the site. > Currently the Antora based website doesn’t attempt to include this > documentation. > > With Antora this is not necessary: Antora can extract documentation source > from any number of git repos and assemble it all seamlessly. I think it would > be a good idea to set this up. In general Antora requires sources in each git > repo to be in a specific directory structure, for the current felix site > `…/modules/ROOT/pages/*.adoc`. > > There are several choices for how to do this: > > - Move the README contents to a concrete .adoc page in the above structure > and have the README mostly point to the website. This allows use of the full > power of Asciidoc on the pages, rather than the quite constricted subset > available from the GitHub asciidoc renderer (or the GitHub markdown > renderer). I think this is the best choice. > > - Symlink from the above structure location to the README (which will need to > be translated to Asciidoc, which will still be rendered by GitHub). Symlink > support was recently added to Antora but I haven’t tried it in this scenario. > This would give the same content at GitHub (in roughly its current format) > and in the website(integrated, with nav, header, footer, etc), but would > limit subproject documentation to a single page and inhibit links to other > website pages, among other problems. > > - Add (external) links in the nav to the READMEs on GitHub. In this case > there will be no version of the documentation integrated into the website. > > Thoughts? > > David Jencks > >
Website documentation for own-git-repo subprojects
The CMS website and the Antora website currently have the docs source far from the code. As a result several subprojects (SCR, Atomos at least) have put their documentation in a README in the subproject git repo. This results in these subproject documentation appearing really different from other subprojects docs and lacking the overall navigation facilities from the site. Currently the Antora based website doesn’t attempt to include this documentation. With Antora this is not necessary: Antora can extract documentation source from any number of git repos and assemble it all seamlessly. I think it would be a good idea to set this up. In general Antora requires sources in each git repo to be in a specific directory structure, for the current felix site `…/modules/ROOT/pages/*.adoc`. There are several choices for how to do this: - Move the README contents to a concrete .adoc page in the above structure and have the README mostly point to the website. This allows use of the full power of Asciidoc on the pages, rather than the quite constricted subset available from the GitHub asciidoc renderer (or the GitHub markdown renderer). I think this is the best choice. - Symlink from the above structure location to the README (which will need to be translated to Asciidoc, which will still be rendered by GitHub). Symlink support was recently added to Antora but I haven’t tried it in this scenario. This would give the same content at GitHub (in roughly its current format) and in the website(integrated, with nav, header, footer, etc), but would limit subproject documentation to a single page and inhibit links to other website pages, among other problems. - Add (external) links in the nav to the READMEs on GitHub. In this case there will be no version of the documentation integrated into the website. Thoughts? David Jencks
Re: Automatic website publishing
I got this working recently with the Aries website. I just ran ‘git branch asf-site’ and pushed and then my script worked. I run this from a Jenkins pipeline in the equivalent of tomee-site-generator ( if I remember the tomee repo name correctly). There’s only one Aries pipeline so it should be easy to find if you want to take a look. David jencks. Sent from my iPhone > On May 19, 2021, at 6:03 PM, David Blevins wrote: > > I've been trying to setup automatic website publishing. > > So far I have a test Jenkins job that does a simple commit/push: > > - https://ci-builds.apache.org/job/Tomee/job/site-publish > > At the moment it's just a simple Freestyle job with a test script to see a > successful commit/push work: > >git clone https://gitbox.apache.org/repos/asf/tomee-site-pub.git -b > asf-staging-test >cd tomee-site-pub >date > test.txt >git add test.txt >git commit -m "test publish from ci-builds.apache.org" test.txt >git push origin asf-staging-test > > The trick and where I'm stuck is that we're using `master` as our main branch > for https://tomee.apache.org and Jenkins is setup to only let us push a > branch called `asf-site` or `asf-staging-*` > > I've attempted to switch `tomee-site-pub` from `master` to `asf-site`, but it > doesn't seem to work. I've filed a ticket with Infra and will keep you > updated: > > - https://issues.apache.org/jira/browse/INFRA-21903 > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com >
Re: [DISCUSS] Release Apache TomEE 8.0.7 and 9.0.0-M7
This seems like a good idea, but the current vote is for 3 sets of artifacts and if it passes would we be obligated to release all to the mirror system? Is it too late to have independent votes for the 3 sets? David Jencks > On May 3, 2021, at 1:30 PM, David Blevins wrote: > > Launching off a discuss thread so we can track issues and discuss without > filling up the vote thread. > > Sounds like there are regressions on the 8.0.7. What I'd recommend is we > just don't put 8.0.7 on the mirror system or website. We leave the mirrors > and website with 8.0.6 until there are better 8.0.x binaries available and > just put up the 9.x binaries. > > Tomcat does this fairly often if there's a bad build of one of the branches. > If you look here there are 36 releases of 9.x, but the highest version number > is 9.0.45, so a decent percentage were never published: > > - http://archive.apache.org/dist/tomcat/tomcat-9/ > > I think that's probably one of the reasons they can crank out so many > releases so consistently despite maintaining 3 branches. > > Thoughts? > > > -David >
Re: [VOTE] Release Apache TomEE 8.0.7 and 9.0.0-M7
Congratulations! It looks like 1182 is TomEE 8.0.7 and 1183 is the patch plugin. There are some confusingly labeled artifacts such as apache-tomee-8.0.7-sources.jar <https://repository.apache.org/content/repositories/orgapachetomee-1182/org/apache/tomee/apache-tomee/8.0.7/apache-tomee-8.0.7-sources.jar> which doesn’t have any sources in it. The sources seem to be in tomee-project-9.0.0-M7-source-release.zip <https://repository.apache.org/content/repositories/orgapachetomee-1184/org/apache/tomee/tomee-project/9.0.0-M7/tomee-project-9.0.0-M7-source-release.zip>, tomee-project-8.0.7-source-release.zip <https://repository.apache.org/content/repositories/orgapachetomee-1182/org/apache/tomee/tomee-project/8.0.7/tomee-project-8.0.7-source-release.zip>, and tomee-patch-core-0.5-sources.jar <https://repository.apache.org/content/repositories/orgapachetomee-1183/org/apache/tomee/patch/tomee-patch-core/0.5/tomee-patch-core-0.5-sources.jar>. +1 David Jencks > On May 3, 2021, at 8:01 AM, David Blevins wrote: > > Ok, folks, > > Here we go. Again, bear in mind we need these binaries for the Jakarta EE > 9.1 release ballot today. Any issues and we can roll a Apache TomEE 8.0.8 > and Apache TomEE 9.0.0-M8 asap. I think we should plan on doing that anyway, > so feel free to say call it straight out when reporting "I found x issue we > should fix in 8.0.8" > > > TomEE Patch Plugin v0.5 > https://repository.apache.org/content/repositories/orgapachetomee-1182/ > > Apache TomEE 8.0.7 > https://repository.apache.org/content/repositories/orgapachetomee-1183/ > > Apache TomEE 9.0.0-M7 > https://repository.apache.org/content/repositories/orgapachetomee-1184/ > > This vote will be open for 72 hours. Please vote +1, 0, -1. When voting -1, > please state the reason. > > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com >
Re: TCK work on Jakarta EE 8 and Jakarta EE 9
Great work! It’s really nice we don’t have to hide it! David Jencks > On Nov 16, 2020, at 3:40 PM, Jean-Louis Monteiro > wrote: > > Hi community, > > Alongside with the Jakarta EE 9 work I've been doing, I tried to look at > TomEE coverage for EE 8 and EE 9. They are quite close in terms of scope. > The only difference is pretty much only the namespace change from javax to > jakarta. > > I looked into our EE 9 coverage with our TomEE 9 milestone and we are quite > far in terms of coverage. > > I pushed some setup changes in the dedicated > https://github.com/apache/tomee-tck/tree/jakartaee9-tck branch to bring the > coverage near EE 8 coverage with TomEE (aka around 90+ %) > > The big gaps were as far as I can see around jaspic, securityapi and jta. > > 1/ JASPIC > It's about authentication for containers. We don't have much but setup > because we rely on Tomcat's implementation. > We are having some issues with the setup because of the way TCK is built > for jaspic. I've been able to workaround some, but I also got hit by TCK > issues. > See TomEE tickets > > https://issues.apache.org/jira/browse/TOMEE-2923 > https://issues.apache.org/jira/browse/TOMEE-2924 > https://issues.apache.org/jira/browse/TOMEE-2925 > > 2/ Security API > This is about authorization and stores. > This time implementation is all in TomEE (see tomee-security module). I'll > try to send another email with a walk through. It's been mostly implemented > in a quick and dirty mode but it needs tests and hardening before we can > call it done. With that we can cover nearly 100% coverage of TCK. > But, because there is a bug, we have random failures due to the way TCK is > built. I'll create a new ticket shortly to describe the issue. > > 3/ JTA > We used to be covering 100% but we are down to 70% because of the addition > of @Transactional CDI tests. I again looked into our implementation and the > tests and found again issues with the TCK > > See ticket https://issues.apache.org/jira/browse/TOMEE-2921 > > I'll continue to dig into the other areas. > Especially everything related to Tomcat should be closer to 100% than it is > today (JSTL, JSP, Servlet and WebSockets). > > If you want to help and look at them, that'd be great. > Basically follow the steps to run the TCK locally as described here > https://github.com/apache/tomee-tck > > and run > > com.sun.ts.tests.jstl > com.sun.ts.tests.jsp > com.sun.ts.tests.servlet > com.sun.ts.tests.websocket > > Then go ahead and investigate. Feel free to create a ticket or at least > shoot something in the mailing list so we don't duplicate the efforts. > > Hope it helps > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com
Re: Website
> On Oct 20, 2020, at 6:11 PM, David Blevins wrote:
>
>> On Oct 20, 2020, at 7:11 AM, Jonathan Gallimore
>> wrote:
>>
>> Could I get some pointers on publishing the website? I guess its changed as
>> we don't have the CMS any more.
>>
>> I have some updates I'd like to get on there, including new download links
>> and updating documentation. I've pushed some updates to SVN, if that helps.
>> :)
>
> If you can help with the documentation that'd be great. The short version is
> everything is the same except now we publish to this git repo instead of SVN.
>
> - https://github.com/apache/tomee-site-pub
>
> The convenience code that does the copy and svn update needs to get updated,
> but short of that there's nothing stopping a manual copy of the generated
> files into a git clone and doing an add/commit/push.
>
> After the push, you're done. Just wait a bit and changes will show up. No
> need to visit https://cms.apache.org/tomee/publish anymore.
>
> Long term, Apache has a special Jenkins node that has permissions to publish.
> Eventually we should set that up to run the generator and check in the new
> content automatically.
>
Personally I find both jenkins and buildbot 100% incomprehensible. It looks
like it may be possible to use GitHub actions to publish websites;
[
https://issues.apache.org/jira/browse/INFRA-20633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217967#comment-17217967
<https://issues.apache.org/jira/browse/INFRA-20633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217967#comment-17217967>
]
Gavin McDonald commented on INFRA-20633:
in combination with Github Actions committing to the same repository as the
action, to the asf-site branch, then this is possible with a built in GHA
token. asf-site branch would then be published by configuring a .asf.yaml file
accordingly.
Example code to use for a built in GHA token:
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Would you like to give that a try?
David Jencks
Re: Main site https://tomee.apache.org/ throws 404 error
Hi David, Do you have the site being published automatically now or is it a manual local process? I haven’t been able to work out how to get an automatic commit-site-to-other-git-repo working, so if you have some system I’d like to look at it. thanks, David Jencks > On Sep 14, 2020, at 3:09 PM, David Blevins wrote: > > >> On Sep 14, 2020, at 7:41 AM, David Blevins wrote: >>> On Sep 14, 2020, at 7:27 AM, Juan Moreno wrote: >>> >>> Hi guys! >>> >>> Is the site in maintenance? In my environment throws 404 error. >> >> Thanks for reporting, Juan.. It's likely related to this. I've asked Infra >> how to proceed: >> >> - https://issues.apache.org/jira/browse/INFRA-20820 > > Quick follow up that this is fixed. We're doing a cutover from the old > Apache CMS to the newer git-based setup and it turns out we had a slightly > a-typical CMS setup so the cutover didn't work properly. > > Working now! > > Thank you again, Juan! > > > -David > > >
Re: Your project's website
The content history is now in tomee-site-pub. I added an .asf.yaml file: ``` notifications: commits: site-...@tomee.apache.org issues: site-...@tomee.apache.org pullrequests: site-...@tomee.apache.org jira_options: link label link label # this staging config will publish any commits to https://tomee-beta.staged.apache.org #staging: # profile: beta # whoami: master ``` that directs mail to site-...@tomee.apache.org. Mail notifications are turned back on. For reference, here’s how far I’ve got with publishing the Aries site: ``` #!/bin/bash npm run clean-install rm -rf build mkdir -p build/site # clone the aries-site-pub repo ( cd build/site git clone --depth 1 g...@github.com:apache/aries-site-pub.git . git rm -r . ) npm run build-noclean ( cd build/site git add . git commit -m "site build" git push origin master ) ``` This is for an Antora-only site; the site build is actually `npm run build-noclean`. So far I only know how to run this locally, buildbot and jenkins remain mysteries to me. I don’t see why this couldn’t be run on GitHub using GitHub actions, but it might be against infra policy. David Jencks > On Aug 27, 2020, at 9:51 PM, David Jencks wrote: > > Maybe my memory’s just a bit slow. > > svn log https://svn.apache.org/repos/infra/websites/production/tomee/content > <https://svn.apache.org/repos/infra/websites/production/tomee/content> shows > that I’ve found the last commit. > > David Jencks > >> On Aug 27, 2020, at 9:47 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote: >> >> I’m afraid I no longer understand how svn works or how to see what’s in it. >> I can’t find the published site on viewvc. >> >> The last imported-to-git revision I got was >> >> commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk) >> Author: Daniel Gruno mailto:humbed...@apache.org>> >> Date: Mon Aug 10 17:53:26 2020 + >> >> Publishing svnmucc operation to tomee site by humbedooh >> >> git-svn-id: >> https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188 >> <https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188> >> 90ea9780-b833-de11-8433-001ec94261de >> >> >> however there appeared to be a git gc error after that. I can’t figure out >> how to confirm that this is indeed the last site commit, although running >> the svn2git command again doesn’t find anything more. >> >> What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log >> <https://svn.apache.org/viewvc/tomee/site/trunk/?view=log> is >> >> Revision 1880750 >> <https://svn.apache.org/viewvc?view=revision=1880750> - Directory >> Listing <https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> >> Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins >> force cms to update >> so the time frame seems approximately right. >> >> Can anyone confirm I’ve got the whole history? >> >> Thanks >> David Jencks >> >>> On Aug 27, 2020, at 7:44 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote: >>> >>> tomee-site-pub created >>> site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested >>> INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable >>> commit emails) opened >>> svn2git still in process. >>> >>> If things go really quickly I might be able to push tomorrow. >>> >>> David Jencks >>> >>>> On Aug 27, 2020, at 4:42 PM, David Blevins >>> <mailto:dblev...@tomitribe.com>> wrote: >>>> >>>>> On Aug 27, 2020, at 1:58 PM, David Jencks >>>> <mailto:david.a.jen...@gmail.com>> wrote: >>>>> >>>>> I’ve been “warming up” with the Aries website and did this recently for >>>>> them. I think I can do this easily. What do we want the TomEE repo to >>>>> be named? I’d suggest tomee-site-pub. >>>> >>>> I was struggling to think of a good name. `tomee-site-pub` is great! >>>> >>>>> On Aug 27, 2020, at 2:11 PM, David Jencks >>>> <mailto:david.a.jen...@gmail.com>> wrote: >>>>> >>>>> I started…. should be done in a few hours. Next step is to create the >>>>> apache git repo using self-serve and ask infra to turn off commit emails >>>>> for the push (which may take a day or so). >>>>> >>>>> Where sho
Re: Your project's website
Maybe my memory’s just a bit slow. svn log https://svn.apache.org/repos/infra/websites/production/tomee/content shows that I’ve found the last commit. David Jencks > On Aug 27, 2020, at 9:47 PM, David Jencks wrote: > > I’m afraid I no longer understand how svn works or how to see what’s in it. > I can’t find the published site on viewvc. > > The last imported-to-git revision I got was > > commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk) > Author: Daniel Gruno mailto:humbed...@apache.org>> > Date: Mon Aug 10 17:53:26 2020 + > > Publishing svnmucc operation to tomee site by humbedooh > > git-svn-id: > https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188 > <https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188> > 90ea9780-b833-de11-8433-001ec94261de > > > however there appeared to be a git gc error after that. I can’t figure out > how to confirm that this is indeed the last site commit, although running the > svn2git command again doesn’t find anything more. > > What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log > <https://svn.apache.org/viewvc/tomee/site/trunk/?view=log> is > > Revision 1880750 > <https://svn.apache.org/viewvc?view=revision=1880750> - Directory > Listing <https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> > Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins > force cms to update > so the time frame seems approximately right. > > Can anyone confirm I’ve got the whole history? > > Thanks > David Jencks > >> On Aug 27, 2020, at 7:44 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote: >> >> tomee-site-pub created >> site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested >> INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable >> commit emails) opened >> svn2git still in process. >> >> If things go really quickly I might be able to push tomorrow. >> >> David Jencks >> >>> On Aug 27, 2020, at 4:42 PM, David Blevins >> <mailto:dblev...@tomitribe.com>> wrote: >>> >>>> On Aug 27, 2020, at 1:58 PM, David Jencks >>> <mailto:david.a.jen...@gmail.com>> wrote: >>>> >>>> I’ve been “warming up” with the Aries website and did this recently for >>>> them. I think I can do this easily. What do we want the TomEE repo to be >>>> named? I’d suggest tomee-site-pub. >>> >>> I was struggling to think of a good name. `tomee-site-pub` is great! >>> >>>> On Aug 27, 2020, at 2:11 PM, David Jencks >>> <mailto:david.a.jen...@gmail.com>> wrote: >>>> >>>> I started…. should be done in a few hours. Next step is to create the >>>> apache git repo using self-serve and ask infra to turn off commit emails >>>> for the push (which may take a day or so). >>>> >>>> Where should commit emails for this repo go? For aries I created a >>>> site-...@aries.apache.org <mailto:site-...@aries.apache.org> list since I >>>> don’t think anyone is interested in looking at the html changes directly. >>>> Should I ask for such a list for TomEE? Sending the emails there is >>>> configured with the .asf.yaml file in the root of the repo. >>> >>> I think site-pub@ is another very good suggestion. >>> >>> Thank you so much for taking this one up, David! >>> >>> I'm pretty excited to ditch the CMS! The last publish I did took hours of >>> checking/poking and prodding just to get the updates to go live as the >>> commit size was so large and there are 2 repos to go through. It'll be >>> wonderful to be done with that. >>> >>> >>> -David >>> >> >
Re: Your project's website
I’m afraid I no longer understand how svn works or how to see what’s in it. I can’t find the published site on viewvc. The last imported-to-git revision I got was commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk) Author: Daniel Gruno Date: Mon Aug 10 17:53:26 2020 + Publishing svnmucc operation to tomee site by humbedooh git-svn-id: https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188 90ea9780-b833-de11-8433-001ec94261de however there appeared to be a git gc error after that. I can’t figure out how to confirm that this is indeed the last site commit, although running the svn2git command again doesn’t find anything more. What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log is Revision 1880750 <https://svn.apache.org/viewvc?view=revision=1880750> - Directory Listing <https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins force cms to update so the time frame seems approximately right. Can anyone confirm I’ve got the whole history? Thanks David Jencks > On Aug 27, 2020, at 7:44 PM, David Jencks wrote: > > tomee-site-pub created > site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested > INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable > commit emails) opened > svn2git still in process. > > If things go really quickly I might be able to push tomorrow. > > David Jencks > >> On Aug 27, 2020, at 4:42 PM, David Blevins > <mailto:dblev...@tomitribe.com>> wrote: >> >>> On Aug 27, 2020, at 1:58 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote: >>> >>> I’ve been “warming up” with the Aries website and did this recently for >>> them. I think I can do this easily. What do we want the TomEE repo to be >>> named? I’d suggest tomee-site-pub. >> >> I was struggling to think of a good name. `tomee-site-pub` is great! >> >>> On Aug 27, 2020, at 2:11 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote: >>> >>> I started…. should be done in a few hours. Next step is to create the >>> apache git repo using self-serve and ask infra to turn off commit emails >>> for the push (which may take a day or so). >>> >>> Where should commit emails for this repo go? For aries I created a >>> site-...@aries.apache.org <mailto:site-...@aries.apache.org> list since I >>> don’t think anyone is interested in looking at the html changes directly. >>> Should I ask for such a list for TomEE? Sending the emails there is >>> configured with the .asf.yaml file in the root of the repo. >> >> I think site-pub@ is another very good suggestion. >> >> Thank you so much for taking this one up, David! >> >> I'm pretty excited to ditch the CMS! The last publish I did took hours of >> checking/poking and prodding just to get the updates to go live as the >> commit size was so large and there are 2 repos to go through. It'll be >> wonderful to be done with that. >> >> >> -David >> >
Re: Your project's website
tomee-site-pub created site-...@tomee.apache.org requested INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable commit emails) opened svn2git still in process. If things go really quickly I might be able to push tomorrow. David Jencks > On Aug 27, 2020, at 4:42 PM, David Blevins wrote: > >> On Aug 27, 2020, at 1:58 PM, David Jencks wrote: >> >> I’ve been “warming up” with the Aries website and did this recently for >> them. I think I can do this easily. What do we want the TomEE repo to be >> named? I’d suggest tomee-site-pub. > > I was struggling to think of a good name. `tomee-site-pub` is great! > >> On Aug 27, 2020, at 2:11 PM, David Jencks wrote: >> >> I started…. should be done in a few hours. Next step is to create the >> apache git repo using self-serve and ask infra to turn off commit emails for >> the push (which may take a day or so). >> >> Where should commit emails for this repo go? For aries I created a >> site-...@aries.apache.org list since I don’t think anyone is interested in >> looking at the html changes directly. Should I ask for such a list for >> TomEE? Sending the emails there is configured with the .asf.yaml file in >> the root of the repo. > > I think site-pub@ is another very good suggestion. > > Thank you so much for taking this one up, David! > > I'm pretty excited to ditch the CMS! The last publish I did took hours of > checking/poking and prodding just to get the updates to go live as the commit > size was so large and there are 2 repos to go through. It'll be wonderful to > be done with that. > > > -David >
Re: Your project's website
I started…. should be done in a few hours. Next step is to create the apache git repo using self-serve and ask infra to turn off commit emails for the push (which may take a day or so). Where should commit emails for this repo go? For aries I created a site-...@aries.apache.org list since I don’t think anyone is interested in looking at the html changes directly. Should I ask for such a list for TomEE? Sending the emails there is configured with the .asf.yaml file in the root of the repo. David Jencks > On Aug 27, 2020, at 1:58 PM, David Jencks wrote: > > I’ve been “warming up” with the Aries website and did this recently for them. > I think I can do this easily. What do we want the TomEE repo to be named? > I’d suggest tomee-site-pub. > > David Jencks > >> On Aug 26, 2020, at 5:41 PM, David Blevins wrote: >> >> The first step we need to migrate away from the CMS is a git repo to hold >> the finished HTML. With the help of some fine folks on users@infra.a.o here >> is the SVN repo that hold our site currently: >> >> - https://svn.apache.org/repos/infra/websites/production/tomee/content/ >> >> Cesar, you were the last person to do an SVN to GIT migration. Do you >> recall the steps or have any documents that helped you? >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >>> On Aug 7, 2020, at 6:16 AM, Andrew Wetmore wrote: >>> >>> Hi: >>> >>> I am part of the Infrastructure team, and am writing to ask whether your >>> project is still using the Apache CMS for your project website. As you >>> know, the CMS is reaching end-of-life, and we need projects to move their >>> websites onto a different option within the next few weeks. >>> >>> There are several alternatives available, including those listed on this >>> page [1] on managing project websites. Infra is assembling a Wiki page [2] >>> on migrating a website from the CMS, and is looking forward to helping >>> projects with this transition. >>> >>> Please let me know whether your site is still on the Apache CMS and, if so, >>> who will be the project point-of-contact with Infra for the migration. >>> >>> Thank you! >>> >>> >>> >>> >>> [1] https://infra.apache.org/project-site.html >>> >>> [2] >>> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS >>> >>> >>> -- >>> Andrew Wetmore >>> Technical Writer-Editor >>> Infra >>> *Apache Software Foundation* >>> andr...@apache.org >>> >>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> >>> Virus-free. >>> www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >
Re: Your project's website
I’ve been “warming up” with the Aries website and did this recently for them. I think I can do this easily. What do we want the TomEE repo to be named? I’d suggest tomee-site-pub. David Jencks > On Aug 26, 2020, at 5:41 PM, David Blevins wrote: > > The first step we need to migrate away from the CMS is a git repo to hold the > finished HTML. With the help of some fine folks on users@infra.a.o here is > the SVN repo that hold our site currently: > > - https://svn.apache.org/repos/infra/websites/production/tomee/content/ > > Cesar, you were the last person to do an SVN to GIT migration. Do you recall > the steps or have any documents that helped you? > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >> On Aug 7, 2020, at 6:16 AM, Andrew Wetmore wrote: >> >> Hi: >> >> I am part of the Infrastructure team, and am writing to ask whether your >> project is still using the Apache CMS for your project website. As you >> know, the CMS is reaching end-of-life, and we need projects to move their >> websites onto a different option within the next few weeks. >> >> There are several alternatives available, including those listed on this >> page [1] on managing project websites. Infra is assembling a Wiki page [2] >> on migrating a website from the CMS, and is looking forward to helping >> projects with this transition. >> >> Please let me know whether your site is still on the Apache CMS and, if so, >> who will be the project point-of-contact with Infra for the migration. >> >> Thank you! >> >> >> >> >> [1] https://infra.apache.org/project-site.html >> >> [2] >> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS >> >> >> -- >> Andrew Wetmore >> Technical Writer-Editor >> Infra >> *Apache Software Foundation* >> andr...@apache.org >> >> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> >> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >
Re: Making Antora actionable
I’m also helping Aries move off CMS to an Antora site, and I may postpone working on the TomEE site more until that is more complete and I know more what to expect. Two things we can expect here are - a PMC vote to adopt Antora/git site publishing for parts of the site from CMS - an infra ticket to set ??? up. David Jencks > On Aug 11, 2020, at 8:52 AM, David Jencks wrote: > > David Blevins and I had a long chat about the history of OpenEJB/TomEE > documentation and I have a considerably different perspective now on the best > way forward. I’d say the most fundamental shift is my realizing that even if > doing everything with Antora is the most elegant and efficient solution, it > may not be appropriate for TomEE because it involves extending the doc build > system with javascript, whereas TomEE developers are more likely to be > comfortable with java. Learning a new language in order to improve or even > understand the doc build is too big a barrier. I’m likely to continue to see > how, for instance, “marketing pages” and the tricks in the examples can be > implemented in Antora, but because I want to learn how to do those things > rather than because they are appropriate to use in TomEE. > > I think the following steps make sense: > > - versioned doc consolidation: There are now 5 copies of the “tomee” > versioned docs; one in common, and 4 identical copies done by asciidoc > includes. Looking at one of these includes, it’s not very obvious how to > edit the page, and certainly having one copy in ‘common’ is silly. So, the > “originals” should be moved to one of the versions. The obvious choices are > 7.0.x and 8.0.x. 7 might make it more obvious that changing the doc will > change all 4 versions, but development is most convenient on master, 8.0. To > make it easiest to locate the actual source, I’ll move the ‘original’ to 8.0. > I hope that there will be a period of organization and improvement of the > existing content followed by writing new content. After reorganization has > settled down it may make sense to replace the “include” copies with one or > two actual copies in the 7.0.x and 7.1.x branches so changes in master won’t > inadvertently affect older versions. > > - common doc consolidation. The pages that show up in the common component > come from two repos: tomee-site-generator and tomee-site. I don’t think it’s > a good idea to have content in the same repo as site generator code, so I’m > planning to move the content in tomee-site-generator to tomee-site. David > said something indicating that this may not be an appropriate location, so > perhaps a new repo would be appropriate…. I’ll investigate. Also, this > content includes all the stuff that was previously in CMS and not served by > the current site build. It’s apt to need a lot of editing, consolidation, > etc, and it’s possible that this entire component should not be produced by > Antora. However, at the moment, the only place all the content is accessible > for consideration is in the Antora build, so I propose we leave it there for > now, organize it, and consider what to do with it afterwards. One > possibility, since Antora deals well with multiple versions, is to have > something similar to the current common content minus the doc pages mentioned > above as a “historical content” component version with the “current common” > component version redirect to elsewhere. > > - examples. I’ve accumulated a pile of asciidoc fixes for the READMEs and > I’ll see about getting them back to the master branch. > > - source directory structure. David pointed out that the shorter the path to > the actual adoc files the more likely people are to find them…. I’ll see how > much the path can be shortened. > > - publishing. It’s very tempting to work hard to create a highly unified > site where the Antora and non-antora pieces are indistinguishable, however > that may not be the best plan here. One of the persistent problems with > documentation is that no one likes to work on it. Any complexity or > difficulty is likely to deter people from contributing. A unified site would > need a way for all the pieces of the site build to not step on each other, > which could be hard to maintain. It may well be simpler to have two sites, > one containing the front page, “marketing material”, possibly eventually the > “common” component, the examples, and the other the Antora generated docs. > This requires more investigation but the two-site approach is very attractive > as reducing “friction”. > > > Possibly this can lead quickly to actually getting the Antora portion of the > site published soon. > > Thanks, > David Jencks > > >>
Re: Making Antora actionable
David Blevins and I had a long chat about the history of OpenEJB/TomEE documentation and I have a considerably different perspective now on the best way forward. I’d say the most fundamental shift is my realizing that even if doing everything with Antora is the most elegant and efficient solution, it may not be appropriate for TomEE because it involves extending the doc build system with javascript, whereas TomEE developers are more likely to be comfortable with java. Learning a new language in order to improve or even understand the doc build is too big a barrier. I’m likely to continue to see how, for instance, “marketing pages” and the tricks in the examples can be implemented in Antora, but because I want to learn how to do those things rather than because they are appropriate to use in TomEE. I think the following steps make sense: - versioned doc consolidation: There are now 5 copies of the “tomee” versioned docs; one in common, and 4 identical copies done by asciidoc includes. Looking at one of these includes, it’s not very obvious how to edit the page, and certainly having one copy in ‘common’ is silly. So, the “originals” should be moved to one of the versions. The obvious choices are 7.0.x and 8.0.x. 7 might make it more obvious that changing the doc will change all 4 versions, but development is most convenient on master, 8.0. To make it easiest to locate the actual source, I’ll move the ‘original’ to 8.0. I hope that there will be a period of organization and improvement of the existing content followed by writing new content. After reorganization has settled down it may make sense to replace the “include” copies with one or two actual copies in the 7.0.x and 7.1.x branches so changes in master won’t inadvertently affect older versions. - common doc consolidation. The pages that show up in the common component come from two repos: tomee-site-generator and tomee-site. I don’t think it’s a good idea to have content in the same repo as site generator code, so I’m planning to move the content in tomee-site-generator to tomee-site. David said something indicating that this may not be an appropriate location, so perhaps a new repo would be appropriate…. I’ll investigate. Also, this content includes all the stuff that was previously in CMS and not served by the current site build. It’s apt to need a lot of editing, consolidation, etc, and it’s possible that this entire component should not be produced by Antora. However, at the moment, the only place all the content is accessible for consideration is in the Antora build, so I propose we leave it there for now, organize it, and consider what to do with it afterwards. One possibility, since Antora deals well with multiple versions, is to have something similar to the current common content minus the doc pages mentioned above as a “historical content” component version with the “current common” component version redirect to elsewhere. - examples. I’ve accumulated a pile of asciidoc fixes for the READMEs and I’ll see about getting them back to the master branch. - source directory structure. David pointed out that the shorter the path to the actual adoc files the more likely people are to find them…. I’ll see how much the path can be shortened. - publishing. It’s very tempting to work hard to create a highly unified site where the Antora and non-antora pieces are indistinguishable, however that may not be the best plan here. One of the persistent problems with documentation is that no one likes to work on it. Any complexity or difficulty is likely to deter people from contributing. A unified site would need a way for all the pieces of the site build to not step on each other, which could be hard to maintain. It may well be simpler to have two sites, one containing the front page, “marketing material”, possibly eventually the “common” component, the examples, and the other the Antora generated docs. This requires more investigation but the two-site approach is very attractive as reducing “friction”. Possibly this can lead quickly to actually getting the Antora portion of the site published soon. Thanks, David Jencks > On Aug 10, 2020, at 1:44 PM, David Jencks wrote: > > The reason Antora has a separate front page is that Dan didn’t write > asciidoctor-openblock <https://gitlab.com/djencks/asciidoctor-openblock>. > Since I did, it’s easy to have a front page generated by Antora. He’s known > about this possibility for at least 5 years, but never found the time or > motivation to do it. > > If you have specific complaints about the front page I wrote, please air them > rather than ignoring my request for feedback. > > Could you be extremely specific about what you want generated by Antora and > what by tomee-site-generator and what by some other unnamed tool? Are there > parts of the current antora previe
Re: Making Antora actionable
The reason Antora has a separate front page is that Dan didn’t write asciidoctor-openblock <https://gitlab.com/djencks/asciidoctor-openblock>. Since I did, it’s easy to have a front page generated by Antora. He’s known about this possibility for at least 5 years, but never found the time or motivation to do it. If you have specific complaints about the front page I wrote, please air them rather than ignoring my request for feedback. Could you be extremely specific about what you want generated by Antora and what by tomee-site-generator and what by some other unnamed tool? Are there parts of the current antora preview site that you think should not be generated by Antora? (I expect to add examples to the preview shortly, but we can discuss that separately). thanks David Jencks > On Aug 10, 2020, at 1:09 PM, David Blevins wrote: > >> On Jul 14, 2020, at 7:34 PM, David Blevins wrote: >> >> I think there are two gaps we need to understand to have a better >> conversation about using Antora >> >> - Eliminating the Apache CMS from our lives. This is the biggest blocker to >> any true progress. The only reason our site doesn't automatically update >> now is because we're using the Apache CMS which has a manual publish step >> that takes about an hour of machine time and periodic manual checking/poking >> during that time. >> >> - Understanding `tomee-site-generator` isn't an enemy to Antora and doesn't >> need to die or be eliminated. Among other things, we use it to generate >> asciidoc content when and where we can. It will most likely need to run >> just before Antora. Antora would be building some mix of manually created >> docs and some generated docs. If Antora is not capable of committing >> generated files to git, then `tomee-site-generator` is where we would do >> that work. >> >> I recommend we first eliminate the Apache CMS so we have a hands-free setup. >> Then I recommend we make it so the `tomee-site-generator` maven project is >> the thing that kicks off and runs Antora. > > I've been doing some research and have some revised thoughts on how we could > potentially proceed with this. > > Being terse as possible so we can try to get this out of discussion/debate > mode and into action mode. > > Many Antora users, including Antora.org itself, seem to use this pattern and > I think it's probably the one we want. > > - https://antora.org/ -> Built with a general purpose tool > (Middleman+Asciidoc) > - https://docs.antora.org/ -> Built with Antora > > - https://getfedora.org/ -> Built with a general purpose tool > - https://docs.fedoraproject.org/ -> Built with Antora > > - http://pinot.apache.org/ -> Built with a general purpose tool > - https://docs.pinot.apache.org/ -> Built with GitBook > > - https://www.mulesoft.com/-> Built with a general purpose tool > - https://docs.mulesoft.com/ -> Built with Antora > > If we did this pattern we could probably get it done by end of week: > > - https://tomee.apache.org/-> Built with tomee-site-generator as is > now > - https://docs.tomee.apache.org/ -> Built with Antora > > We would request a new repo not connected to the CMS for > docs.tomee.apache.org and have David push directly to it right now. David > can lead that effort and just inform us on how it goes. > > We would then make the "Documentation" navigation item of tomee.apache.org > point to docs.tomee.apache.org. We'd still move it off the CMS, but I'm > happy to do the lifting on that. > > I greatly prefer this approach to either 1) endlessly debating tools or 2) > holding up David's work any longer. > > There would still be room for debate, but that debate could happen using the > staging capabilities of the git-based solution. I think we'd be in an > overall better position to introduce more changes with everyone on equal > footing. > > > Thoughts? > > > -David > >
Re: [Website-Antora] New preview
> On Aug 9, 2020, at 8:49 PM, David Blevins wrote: > >> On Aug 9, 2020, at 8:10 PM, Willes Reis wrote: >> >>> I’m not sure supplying identical copies of the documentation that claim >>> to be for different versions is entirely desirable. Presumably we need two >>> copies for javax/jakarta, but I’m not sure the one in tomee-site (from CMS) >>> or the identical 7.0, 7.1, and 8.0 versions are truly essential. >>> >>> Next I may look into the examples. IIUC the java source for them is going >>> to remain as javax for the foreseeable future. I think that means that the >>> README’s should also remain javax-only. Among other things this should >>> enable easy inclusion of source-code snippets and avoid confusion when the >>> doc says jakarta and the source says javax. >>> >>> I suggested earlier that there’s no need for more than one version of the >>> examples. I haven’t changed my mind on this and although someone didn’t >>> seem to like the idea, I didn’t see any arguments why having more than one >>> version was a good idea. Since IMO the largest problem with the docs site >>> is that there’s too much outdated useless and wrong content, and it’s >>> nearly totally disorganized, I think reducing the size will make everything >>> else easier. >>> >> >> I agree with David Jencks. >> For sake of organization, I would like to suggest that we keep the >> documentations isolated by branches, where each branch is a documentation >> version (7.0.x, 7.1.x, 8.x and 9.x). Therefore, old docs will be >> kept, while newly created ones evolve, beyond being compatible with >> Antora's source repositories through branches. > > I'd agree with that as well and it's what we currently have. I get the > impression this is what David points out as a problem. > > We historically have had one base of documentation that applied to all > versions. It's only been in the last year that we've attempted to branch the > documentation as described. I'm the only one who put any effort into it, so > it didn't go far. I do think that's the right long-term approach, but I am > sympathetic to the argument with the documentation in the shape it's in we > perhaps branched too early. > > I could be on board for focusing on one branch for a while with the plan to > return to branching once we get something we like. > > As we have done one doc-base for all the versions over 19 of the last 20 > years I wouldn't be willing to make that the permanent plan. A major problem > with it is no one deletes anything because "maybe it applies to an older > version." When Romain created the JBake setup he included only a subset of > the documentation in an attempt to fix that problem. The way he did it ended > up creating new problems as much of those documents still applied, but I > understand what he was trying to solve. > I didn’t notice any differences between any of the doc versions in february except fairly different bad attempts to translate from markdown to asciidoc. IIRC some pages disappeared but I didn’t see any content updates in the versioned docs. I think it would be a really good idea for someone (hopefully someone more familiar with TomEE than me) to spend some time and organize the existing docs by hand. To me, the current “sort by tag” approach is an admission that the docs are incoherent and will stay that way. One way this might work would be to copy the “originals” from common to 7.0.x, then organize them there, and then propagate the organization to include stubs in the other versions, removing the copy from common. I suppose it might be possible to write a script to produce an include stub matching every “original” in all the copied versions, in which case we could start by moving the “originals” from common to 7.0.x. David Jencks > > > -David
Re: [Website-Antora] New preview
I’ve rebased my branches on current work, added 9.0 docs and implemented
javax/jakarta via an attribute, and pushed the preview.
You can see the javax/jakarta at work by looking at different versions of
https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/9.0/jpa-concepts.html#_valid_resource_local_unit_usage
I think a few pages got added to explain 9.0 but I don’t think they are in the
right place in any of my branches. Could someone point me to all the new pages?
I asked about this in perhaps february with no response, but I’ll try again
since the situation is now 25% worse.
With the exception of a few pages getting dropped as time went on, there are
now 5 identical copies of every page in the docs component. The original is in
tomes-site, where I found it. In order to prevent the sort of unintended drift
that plagues the current site, the other copies are all made to be identical
with include stubs, like this:
include::{common-vc}::page$unix-daemon.adoc[]
I’m not sure supplying identical copies of the documentation that claim to be
for different versions is entirely desirable. Presumably we need two copies
for javax/jakarta, but I’m not sure the one in tomee-site (from CMS) or the
identical 7.0, 7.1, and 8.0 versions are truly essential.
Next I may look into the examples. IIUC the java source for them is going to
remain as javax for the foreseeable future. I think that means that the
README’s should also remain javax-only. Among other things this should enable
easy inclusion of source-code snippets and avoid confusion when the doc says
jakarta and the source says javax.
I suggested earlier that there’s no need for more than one version of the
examples. I haven’t changed my mind on this and although someone didn’t seem
to like the idea, I didn’t see any arguments why having more than one version
was a good idea. Since IMO the largest problem with the docs site is that
there’s too much outdated useless and wrong content, and it’s nearly totally
disorganized, I think reducing the size will make everything else easier.
BTW if anyone wants to try editing asciidoc I recommend using intellij tools
with the asciidctor plugin. It’s fairly Antora-aware and is by far the best
tool I’ve found. IDEA CE works fine for this.
David Jencks
> On Aug 7, 2020, at 10:56 PM, David Jencks wrote:
>
>
>
>> On Aug 7, 2020, at 6:16 PM, David Blevins wrote:
>>
>>> On Aug 7, 2020, at 5:02 PM, David Jencks wrote:
>>>
>>> It’s possible to customize antora to do some sorts of editing on the fly,
>>> but I really don’t recommend it. The first two possibilities are also
>>> pretty bad ideas near Antora.
>>
>> Do you have a link on the editing capabilities?
>
> As far as I know no one has ever done this, and as I said I think it’s a
> really bad idea. However, Antora is flexible enough so this is possible.
>
> IMO magic is really bad news in something like a website that no one is
> really interested in dedicating themselves to. Any time you have something
> happening that is the least bit non-standard and non-obvious you dramatically
> increase the barriers to contribution and maintenance. Maven is sort of
> awful, but it’s fairly consistent, and it pretty much brought about a
> revolution in build systems by a great deal of transparency and consistency.
> I’m going to argue really strongly against any solution that isn’t entirely
> visible from the source. The two solutions I know of are two copies of the
> docs, with the EE prefix hardcoded, and one copy with the prefix as an
> attribute, i.e. asciidoctor “variable”.
>
> Lets look for a solution that is completely visible in the adoc source. I
> think an ee prefix attribute will do that, lets try it.
>
>>
>> Recommended or not, is it possible to do either of the last two and what
>> would that look like?
>
> It would look like incomprehensible magic, and no one would be able to figure
> out how the result was obtained. At least I wouldn’t be able to if I stepped
> away for a week.
>
>>
>>> I think we should take a look at the attribute idea in action before ruling
>>> it out. For one thing, it might be possible to check for non-use of the
>>> attribute by grepping for javax or jakarta, maybe in a pre-commit hook.
>>
>> We can certainly take a look. Even if the feature doesn't get used for this
>> problem doesn't mean learning about it is bad -- we may see another valuable
>> way to use it.
>>
>> In terms of commit hooks, if I had to chose between writing tool/script to
>> force a developer to do something or writing a tool/script to do it for
>> them, I'll always favor the latter if that's possible.
>
> Well, the commit hook might replace either of ‘javax’ or ‘jakarta’ with
> {ee-prefix}. I imagine there would need to be a way to use the other prefix
> in a particular document. That could be another 2 attributes.
>
> David Jencks
>
>>
>>
>> -David
>>
>
Re: [Website-Antora] New preview
> On Aug 7, 2020, at 6:16 PM, David Blevins wrote:
>
>> On Aug 7, 2020, at 5:02 PM, David Jencks wrote:
>>
>> It’s possible to customize antora to do some sorts of editing on the fly,
>> but I really don’t recommend it. The first two possibilities are also
>> pretty bad ideas near Antora.
>
> Do you have a link on the editing capabilities?
As far as I know no one has ever done this, and as I said I think it’s a really
bad idea. However, Antora is flexible enough so this is possible.
IMO magic is really bad news in something like a website that no one is really
interested in dedicating themselves to. Any time you have something happening
that is the least bit non-standard and non-obvious you dramatically increase
the barriers to contribution and maintenance. Maven is sort of awful, but it’s
fairly consistent, and it pretty much brought about a revolution in build
systems by a great deal of transparency and consistency. I’m going to argue
really strongly against any solution that isn’t entirely visible from the
source. The two solutions I know of are two copies of the docs, with the EE
prefix hardcoded, and one copy with the prefix as an attribute, i.e.
asciidoctor “variable”.
Lets look for a solution that is completely visible in the adoc source. I
think an ee prefix attribute will do that, lets try it.
>
> Recommended or not, is it possible to do either of the last two and what
> would that look like?
It would look like incomprehensible magic, and no one would be able to figure
out how the result was obtained. At least I wouldn’t be able to if I stepped
away for a week.
>
>> I think we should take a look at the attribute idea in action before ruling
>> it out. For one thing, it might be possible to check for non-use of the
>> attribute by grepping for javax or jakarta, maybe in a pre-commit hook.
>
> We can certainly take a look. Even if the feature doesn't get used for this
> problem doesn't mean learning about it is bad -- we may see another valuable
> way to use it.
>
> In terms of commit hooks, if I had to chose between writing tool/script to
> force a developer to do something or writing a tool/script to do it for them,
> I'll always favor the latter if that's possible.
Well, the commit hook might replace either of ‘javax’ or ‘jakarta’ with
{ee-prefix}. I imagine there would need to be a way to use the other prefix in
a particular document. That could be another 2 attributes.
David Jencks
>
>
> -David
>
Re: [Website-Antora] New preview
> On Aug 7, 2020, at 4:25 PM, David Blevins wrote: > >> On Aug 7, 2020, at 3:49 PM, David Jencks wrote: >> >>> On Aug 7, 2020, at 1:47 PM, David Blevins wrote: >>> >>>> On Aug 4, 2020, at 11:55 PM, David Jencks wrote: >>>> >>>> I updated the navigation in the preview to include all the common pages >>>> (most of which are from apache CMS and previously hard to find) and the >>>> doc pages to more closely match the existing sections. >>>> >>>> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html >>>> >>>> There are some pages I used to help generate the navigation that will be >>>> useful until things stabilize a bit more. >>>> >>>> This isn’t perfect but I think it’s in a state where it could replace the >>>> current site, with the exception of examples and javadoc. >>> >>> It's definitely a large step forward. I think there needs to be some TomEE >>> 9 presence even if the docs are a 100% copy of 8 -- i.e. you point Antora >>> at the same place as where 8 docs are getting pulled, but publish it as 9. >>> >>> Ultimately I just did a very surgical javax-to-jakarta rename on the 8 docs >>> to turn them into 9. >>> >>> Would any of these be an option we could employ? >>> >>> - post-processing: perform some final edits to the Antora-generated html >>> pages before they are committed to git >>> - pre-processing: supply a non-git source for TomEE 9 asciidoc files >>> (perhaps a zip) so we ourselves can clone/edit them and hand them to Antora >>> - hooks: does Antora have any way to allow us to hook in so we can do our >>> own prep before the generation happens? >> >> I haven’t looked into incorporating any of the doc changes since March, >> including the new TomEE 9. >> If the desired changes are that all uses of `javax` are replaced with >> `jakarta` the simplest way to do it is probably to use an attribute and >> define it as `javax` for versions < 9 and `jakarta` for versions >= 9. > > Not a complete set of concerns, but anytime someone has to remember do > something different or special to write a doc my observation is it ages very > poorly. Someone writes a script and runs it once, then it shifts to a human > task and starts to degrade. If possible, leaving it a script task run > automatically is best. > > Do you know if any of the options I mention are possible? It’s possible to customize antora to do some sorts of editing on the fly, but I really don’t recommend it. The first two possibilities are also pretty bad ideas near Antora. I think we should take a look at the attribute idea in action before ruling it out. For one thing, it might be possible to check for non-use of the attribute by grepping for javax or jakarta, maybe in a pre-commit hook. For another, I’d guess new documentation is likely to apply only to jakarta, and if someone hardcodes jakarta there it won’t be a problem. I’m sure we can find a good solution here. > > >>>> I think that the apache git website deploy system allows a preview site, >>>> so i may investigate and see if I can get that set up. >>> >>> The Apache CMS has staging built into it (it's not great for a site of our >>> size). I asked about similar capabilities in the git-based publishing that >>> is there now and I swear there was something that allowed you to create >>> branches, but I have to go back and read those emails. >> >> There’s something about that in the asf.yml documentation here: >> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features >> <https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features> >> but I haven’t tried anything related to that yet. > > That's the one. Here was the most encouraging section: > >Staging a web site preview domain > >To enable staging (live preview) of your project's web site, add a >staging entry to the site repository's .asf.yaml file. As an >example, take the imaginary yourproject-website.git with an >.asf.yaml file containing the following entry: > >staging: > profile: beta > >This would stage the current branch at >https://yourproject-beta.staged.apache.org/ > <https://yourproject-beta.staged.apache.org/> . You can add multiple >staging profiles and thus multiple branches staged for >preview. This can be helpful when doing A/B evaluations of website >contents and features. > > The ability to have many different preview sites would be an awesome enabler > of change. yes :-) David Jencks > > > -David
Re: [Website-Antora] New preview
> On Aug 7, 2020, at 1:47 PM, David Blevins wrote: > >> On Aug 4, 2020, at 11:55 PM, David Jencks wrote: >> >> I updated the navigation in the preview to include all the common pages >> (most of which are from apache CMS and previously hard to find) and the doc >> pages to more closely match the existing sections. >> >> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html >> >> There are some pages I used to help generate the navigation that will be >> useful until things stabilize a bit more. >> >> This isn’t perfect but I think it’s in a state where it could replace the >> current site, with the exception of examples and javadoc. > > It's definitely a large step forward. I think there needs to be some TomEE 9 > presence even if the docs are a 100% copy of 8 -- i.e. you point Antora at > the same place as where 8 docs are getting pulled, but publish it as 9. > > Ultimately I just did a very surgical javax-to-jakarta rename on the 8 docs > to turn them into 9. > > Would any of these be an option we could employ? > > - post-processing: perform some final edits to the Antora-generated html > pages before they are committed to git > - pre-processing: supply a non-git source for TomEE 9 asciidoc files (perhaps > a zip) so we ourselves can clone/edit them and hand them to Antora > - hooks: does Antora have any way to allow us to hook in so we can do our own > prep before the generation happens? I haven’t looked into incorporating any of the doc changes since March, including the new TomEE 9. If the desired changes are that all uses of `javax` are replaced with `jakarta` the simplest way to do it is probably to use an attribute and define it as `javax` for versions < 9 and `jakarta` for versions >= 9. The three existing doc versions are all the same except for a couple pages that appear or disappear in different versions. > >> I think that the apache git website deploy system allows a preview site, so >> i may investigate and see if I can get that set up. > > The Apache CMS has staging built into it (it's not great for a site of our > size). I asked about similar capabilities in the git-based publishing that > is there now and I swear there was something that allowed you to create > branches, but I have to go back and read those emails. There’s something about that in the asf.yml documentation here: https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features but I haven’t tried anything related to that yet. David Jencks > > > -David >
Re: Your project's website
At this point I’m willing to do the following with the Antora site effort: - put the examples back into the Antora site - find some way of including or referencing javadoc. - figuring out how to relate to the pypubsub system so the site is published through git. - be the point of contact with infra. What I’m not willing to do is try to have a two-builder site when AFAICT one part is distinctly inferior and less capable and no one will tell me anything about why it’s better or required or nice or I’m also not willing to wait indefinitely for feedback. If I proceed with this it will have to be commit-then-review, as my previous requests for review have generally been met with silence. David Jencks > On Aug 7, 2020, at 6:16 AM, Andrew Wetmore wrote: > > Hi: > > I am part of the Infrastructure team, and am writing to ask whether your > project is still using the Apache CMS for your project website. As you > know, the CMS is reaching end-of-life, and we need projects to move their > websites onto a different option within the next few weeks. > > There are several alternatives available, including those listed on this > page [1] on managing project websites. Infra is assembling a Wiki page [2] > on migrating a website from the CMS, and is looking forward to helping > projects with this transition. > > Please let me know whether your site is still on the Apache CMS and, if so, > who will be the project point-of-contact with Infra for the migration. > > Thank you! > > > > > [1] https://infra.apache.org/project-site.html > > [2] > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS > > > -- > Andrew Wetmore > Technical Writer-Editor > Infra > *Apache Software Foundation* > andr...@apache.org > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
[Website-Antora] New preview
I updated the navigation in the preview to include all the common pages (most of which are from apache CMS and previously hard to find) and the doc pages to more closely match the existing sections. https://tomee-preview.s3-us-west-2.amazonaws.com/index.html There are some pages I used to help generate the navigation that will be useful until things stabilize a bit more. This isn’t perfect but I think it’s in a state where it could replace the current site, with the exception of examples and javadoc. I think that the apache git website deploy system allows a preview site, so i may investigate and see if I can get that set up. David Jencks
Re: [Antora Website] home page experiment
I’ve updated this with Willes’ header PR which I think looks really nice. David Jencks > On Jul 23, 2020, at 11:34 AM, David Jencks wrote: > > At least two people (David Blevins and Cesar Hernandez) have expressed the > idea that the “static site” should not be generated by Antora. I’ve been > wondering why, and what the “static site” might be. The home page of the > current site seems like the most obvious candidate, so I decided to learn a > little bit of css… > > Investigating the source of the current home page, it appears to be a > hodgepodge of outdated table layout and scripts and css whose origin is not > clear to me. Understanding what it does I found rather difficult. > > I’ve replicated most of the features of the current home page in an .adoc > page rendered by Antora. I learned enough css for now, so I didn’t pursue an > exact replica. I imagine that for someone who knows a reasonable amount of > css finishing the synchronization would be easy. > > Present: > > - Layout and images > - general behavior of hover animation > > Missing: > > - clipping on background image > - “typewriter” effect on subtitle (personally this reminds me of a “blink” > tag….) > - specific details of hover animation > > I find the .adoc source very clear about the structure of the resulting page, > and the css is really quite short and to the point. I can easily understand > and work with both. > > What is better about the current situation? > > —— > > Preview: https://tomee-preview.s3-us-west-2.amazonaws.com/ > <https://tomee-preview.s3-us-west-2.amazonaws.com/> > > branches “home-page” at > > - tomee-antora <https://github.com/djencks/tomee-antora> (playbook) > > - tomee-antora-ui <https://github.com/djencks/tomee-antora-ui> > > — css: src/css/home-doc.css, src/css/home.css > (https://raw.githubusercontent.com/djencks/tomee-antora-ui/home-page/src/css/home-doc.css > > <https://raw.githubusercontent.com/djencks/tomee-antora-ui/home-page/src/css/home-doc.css>) > — layout: src/layouts/home-page.hbs, src/partials/home-body.hbs > > - tomee-site-generator <https://github.com/djencks/tomee-site-generator> > > — tomee/modules/ROOT/pages/home-page.adoc > (https://raw.githubusercontent.com/djencks/tomee-site-generator/home-page/tomee/modules/ROOT/pages/home-page.adoc > > <https://raw.githubusercontent.com/djencks/tomee-site-generator/home-page/tomee/modules/ROOT/pages/home-page.adoc>) > > David Jencks > >
Re: Making Antora actionable
Sorry for the delay…. I love it! I merged your PR to master and also rebased the home-page branch on it, I hope this doesn’t cause a lot of problems. The preview is here, including my home-page work: https://tomee-preview.s3-us-west-2.amazonaws.com/common/home-page.html <https://tomee-preview.s3-us-west-2.amazonaws.com/common/home-page.html> Thanks! David Jencks > On Jul 27, 2020, at 7:11 PM, Willes Reis wrote: > > Inline... > > Em seg., 27 de jul. de 2020 às 13:56, David Jencks > escreveu: > >> Hi Willes, >> >> I think the simplest thing to do for now would be for you to have a GitHub >> fork of my project and push your branch to it, and open a PR. There might >> be better solutions but I don’t know how to make them work :-) >> > I did the GitHub fork to me and already created the PR for your project. > No problem, let's follow in this way, through GitHub PRs. > > I think this is a good idea. I think I may have written something >> misleading or wrong above about git worktrees; Antora doesn’t recognize >> them other than the main checkout. Therefore I think the playbook will >> need to have a path to the local checkout of tomEE but list the 3 or 4 >> branches; the one you happen to be working on currently will have to be >> renamed “HEAD”. Alternatively we could expect 3 or 4 complete checkouts of >> TomEE, but I think that will be too hard to work with. >> >> I hope I’ve written this in a way you can understand :-) >> >> David Jencks >> > Yes, I understood. I tested the "dev-build" with the local-playbook > targeting the HEAD branch and works well, i.e. the changes reflect in the > build/site folder to preview statically. > Of course, before we decide anything, we need to decide where we'll keep > our "repository for docs and examples". > > Willes
Re: Making Antora actionable
Hi Willes, > On Jul 25, 2020, at 1:48 PM, Willes Reis wrote: > > Hi David Jencks, but anyone can interact ;) > > Follow some updates... > > I don’t know :-) We could experiment with the header color. it might work >> to have the same gradient as in the footer in the header. It would be good >> to get feedback from others on this point. >>> > > I did an experiment with the header successfully. The updates are committed > locally and I'd like to push it to remote, but it doesn't allow push to > your repository tomee-antora-ui. > Thinking about... what do you think about working out a strategy to push > and branches allowed to accept it? I think the simplest thing to do for now would be for you to have a GitHub fork of my project and push your branch to it, and open a PR. There might be better solutions but I don’t know how to make them work :-) > > >>> About tomee-antora, I am studying the "todo" item "Make it easy to work >>> locally" to work in it. >> >> As a possible hint, the commented-out urls such as >> >> # - url: ./../../tomee-site-generator >> are what I use for a local playbook. I didn’t know it at the time I did >> this, but it’s possible to use git work trees to check out all three (or 4 >> now?) main tomee branches at once from one clone. >> >> I have all the tomee projects checked out next to one another. This >> playbook was transplanted from another project so I think all the paths >> need to be shortened by one parent directory, e.g. >> ./../tomee-site-generator. >> > About this, I read about the "Author Mode" in Antora and was wondering > whether this would be tangible for our purpose. > I am updating the tomee-antora playbook for some tests and will inform you > if it is ok. > Right now, I copied the antora-playbook.yml to local-antora-playbook.yml > changing the content > sources > url to local resources, considering that > all cloned git repositories are in the same level as this project. Even > more, I am making an appropriate npm script as "dev-clean-build" to > automate build as you made. I think this is a good idea. I think I may have written something misleading or wrong above about git worktrees; Antora doesn’t recognize them other than the main checkout. Therefore I think the playbook will need to have a path to the local checkout of tomEE but list the 3 or 4 branches; the one you happen to be working on currently will have to be renamed “HEAD”. Alternatively we could expect 3 or 4 complete checkouts of TomEE, but I think that will be too hard to work with. I hope I’ve written this in a way you can understand :-) David Jencks > > Willes.
[Antora Website] home page experiment
At least two people (David Blevins and Cesar Hernandez) have expressed the idea that the “static site” should not be generated by Antora. I’ve been wondering why, and what the “static site” might be. The home page of the current site seems like the most obvious candidate, so I decided to learn a little bit of css… Investigating the source of the current home page, it appears to be a hodgepodge of outdated table layout and scripts and css whose origin is not clear to me. Understanding what it does I found rather difficult. I’ve replicated most of the features of the current home page in an .adoc page rendered by Antora. I learned enough css for now, so I didn’t pursue an exact replica. I imagine that for someone who knows a reasonable amount of css finishing the synchronization would be easy. Present: - Layout and images - general behavior of hover animation Missing: - clipping on background image - “typewriter” effect on subtitle (personally this reminds me of a “blink” tag….) - specific details of hover animation I find the .adoc source very clear about the structure of the resulting page, and the css is really quite short and to the point. I can easily understand and work with both. What is better about the current situation? —— Preview: https://tomee-preview.s3-us-west-2.amazonaws.com/ branches “home-page” at - tomee-antora <https://github.com/djencks/tomee-antora> (playbook) - tomee-antora-ui <https://github.com/djencks/tomee-antora-ui> — css: src/css/home-doc.css, src/css/home.css (https://raw.githubusercontent.com/djencks/tomee-antora-ui/home-page/src/css/home-doc.css) — layout: src/layouts/home-page.hbs, src/partials/home-body.hbs - tomee-site-generator <https://github.com/djencks/tomee-site-generator> — tomee/modules/ROOT/pages/home-page.adoc (https://raw.githubusercontent.com/djencks/tomee-site-generator/home-page/tomee/modules/ROOT/pages/home-page.adoc) David Jencks
Re: Making Antora actionable
inline...
> On Jul 17, 2020, at 2:53 PM, Willes Reis wrote:
>
> inline and other points...
>
>
>> I added a TOC and the {done} checkmark seems to display nicely in that. I
>> like having things organized in sections as it’s easier to write text
>> describing the activity, and now the TOC provides a list view. What do you
>> think?
>>
>> Thanks,
>> David Jencks
>>>
>
> The TOC is great, I agree that it's good to organize. About {done}
> checkmark, I didn't know, +1 learned. Thanks!
>
> About tomee-antora-ui, it looks like most of it has already been done, but
> the items in "todo" refer to decisions.
> How to approach this subject?
I don’t know :-) We could experiment with the header color. it might work to
have the same gradient as in the footer in the header. It would be good to get
feedback from others on this point.
>
> About tomee-antora, I am studying the "todo" item "Make it easy to work
> locally" to work in it.
As a possible hint, the commented-out urls such as
# - url: ./../../tomee-site-generator
are what I use for a local playbook. I didn’t know it at the time I did this,
but it’s possible to use git work trees to check out all three (or 4 now?) main
tomee branches at once from one clone.
I have all the tomee projects checked out next to one another. This playbook
was transplanted from another project so I think all the paths need to be
shortened by one parent directory, e.g. ./../tomee-site-generator.
David
>
> Willes
Re: Making Antora actionable
Inline...
> On Jul 16, 2020, at 11:39 PM, Willes Reis wrote:
>
> Hi David Jencks, thank you for updates.
>
> Em qui., 16 de jul. de 2020 às 18:13, David Jencks
> escreveu:
>
>> Hi Willes,
>>
>> I’ve never seen that particular error from npm! I changed the relevant
>> url to be https://, could you try again?
>
>
> I tried the build again and was successful: downloaded node modules,
> processed antora-playbook and built site folder.
> Browsing on this local site was great!
>
Wonderful!
>
>>
>>
> I also added some todo.adoc files to these two new projects…. take a look,
>> are they more or less what you had in mind?
>>
>
> Yes, it's more or less that I had in mind.
> I thought about keeping it in checklist, as in asciidoc:
> * [x] Task that is already done
> * [ ] Task that is missing
> ... to make it visible to anyone who checks the repository, understanding
> the progress, what already was done and what is missing, as simple as
> possible.
> With this in mind and your wide knowledge, I will know the first steps to
> help you even more.
I added a TOC and the {done} checkmark seems to display nicely in that. I like
having things organized in sections as it’s easier to write text describing the
activity, and now the TOC provides a list view. What do you think?
Thanks,
David Jencks
>
> Willes
Re: Making Antora actionable
Hi Willes, I’ve never seen that particular error from npm! I changed the relevant url to be https://, could you try again? I also added some todo.adoc files to these two new projects…. take a look, are they more or less what you had in mind? Thanks! David Jencks > On Jul 16, 2020, at 1:00 PM, Willes Reis wrote: > > Hi David, thanks for your effort. > > >>> On Jul 15, 2020, at 6:03 PM, David Jencks >> wrote: >>> >>> I’ve: >>> >>> - started an Antora UI bundle project for TomEE: tomee-antora-ui < >> https://github.com/djencks/tomee-antora-ui> >>> It’s already built, but if you want to build it yourself, clone it, run >> npm i, and gulp. > > I did fork/clone this project, but I haven't built it yet.. > > >>> In order to track what is changed from the default UI, I used my >> slightly experimental UI builder. If we want to proceed on this path I >> can release it to npm; right now it’s in my space on AWS. >> >> >>> I set header/footer colors/images to match the existing site and removed >> the cruft from the header. I didn’t try to match header/footer content >> with the existing site since I think it needs to be rethought for Antora. >> > I could help you with this details in design/UI asap. > >> - started an Antora playbook project for TomEE: tomee-antora < >> https://github.com/djencks/tomee-antora> >>> To build this, clone it, and run npm run clean-build. The site will be >> at build/site. >>> I have not yet provided a maven project to run this. >> > > I did fork/clone this project and run build, but there was some error at > authentication in your GitHub repo tomee-antora-ui, as follows: > Perhaps you can understand and know what to do. > > >> willesreis@host tomme-antora % npm run clean-build >> > >>> @ clean-build /Users/willesreis/tomee-antora >> >>> npm run clean-install;npm run build >> >> >> >>> @ clean-install /Users/willesreis/tomee-antora >> >>> rm -rf node_modules/ .cache/ package-lock.json;npm i --cache=.cache/npm >> >> >> The authenticity of host 'github.com (18.228.52.138)' can't be >> established.tf8@0.0.1 fetched in 1083ms >> >> RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. >> >> ⸨░░⸩ ⠼ fetchMetadata: sill pacote version manifest for >> to-utf8@0.0.1 fetched in 1083ms >> >> npm ERR! Error while executing: >> >> npm ERR! /usr/bin/git ls-remote -h -t ssh:// >> g...@github.com/djencks/tomee-antora-ui.git >> >> npm ERR! >> >> npm ERR! Host key verification failed. >> >> npm ERR! fatal: Could not read from remote repository. >> >> npm ERR! >> >> npm ERR! Please make sure you have the correct access rights >> >> npm ERR! and the repository exists. >> >> npm ERR! >> >> npm ERR! exited with error code: 128 >> > > I suggest that we put a ".adoc" file kind "to do" or "progress" on each > repo, on which we can write all of things to do, i.e. our path, and we go > "checking" each item as we progress. What do you think? > > Willes Reis
Re: Making Antora actionable
I’ve updated the UI to more closely match the existing site (especially the header :-) and enabled prev/next pagination, and updated the preview. IMO this is close to usable. We still have to decide on what should go in the footer, but that may be more evident when the navigation is developed to a workable state. David Jencks > On Jul 15, 2020, at 6:03 PM, David Jencks wrote: > > I’ve: > > - started an Antora UI bundle project for TomEE: tomee-antora-ui > <https://github.com/djencks/tomee-antora-ui> > It’s already built, but if you want to build it yourself, clone it, run npm > i, and gulp. > In order to track what is changed from the default UI, I used my slightly > experimental UI builder. If we want to proceed on this path I can release > it to npm; right now it’s in my space on AWS. > > I set header/footer colors/images to match the existing site and removed the > cruft from the header. I didn’t try to match header/footer content with the > existing site since I think it needs to be rethought for Antora. > > - started an Antora playbook project for TomEE: tomee-antora > <https://github.com/djencks/tomee-antora> > To build this, clone it, and run npm run clean-build. The site will be at > build/site. > I have not yet provided a maven project to run this. > > I removed the examples from what was previously in the Antora site. > > The results are visible at > https://tomee-preview.s3-us-west-2.amazonaws.com/common/contribute.html > <https://tomee-preview.s3-us-west-2.amazonaws.com/common/contribute.html> (a > somewhat arbitrary start page). Since an AWS bucket isn’t a web server or a > local file system, there are some strange things happening for some links. > > Comments: > > - In order to combine the playbook project with tomee-site-generator, I think > tomee-site-generator needs to become a multi-module reactor maven project. > Let’s make sure that is actually the most sensible approach before proceeding. > > - I believe this preview includes all of what I think people have been > describing as the non-example non-doc content. I think this includes all the > stuff previously buried in secret in, mostly, markdown and html in the CMS. > IIUC there’s some objection to this being in the Antora part of the site. I > would like a clear explanation of what is better for this to be non-Antora > content. > > - IIRC the content for 7.0, 7.1, and 8 is identical (there might be slight > differences, of a couple of pages). I’d suggest that since there is not > enough interest to maintain the site at a high level, this be collapsed to > one version. Small differences can be pointed out with “since 8.0” etc. If > in the future new docs for 9.0 are actually written, that would be a good > time to add another version. > > - I haven’t yet considered how this might be combined with non-Antora parts > of the site. I pointed out a few messages ago that at least the Antora part > can easily use ASF infrastructure to publish to the appropriate git repo. > > - I haven’t made any attempt to set up reasonable navigation in the site. I > think all pages are present in navigation, but wouldn’t promise anything. I > think this may relate to the “what needs to be generated” discussion. > > I think it would be really great if this could get enough attention so that > we can end up with a new site soon. > > Thanks! > David Jencks > >> On Jul 15, 2020, at 8:22 AM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote: >> >> >> >>> On Jul 15, 2020, at 3:58 AM, Jonathan Gallimore >>> mailto:jonathan.gallim...@gmail.com>> wrote: >>> >>>> I recommend we first eliminate the Apache CMS so we have a hands-free >>> setup. Then I recommend we make it so the `tomee-site-generator` maven >>> project is the thing that kicks off and runs Antora. >>> >>> Sounds good to me. >>> >>>> I seriously don't care what we use for them as the majority of the issues >>> are content, not tool. If we need to rollout a tool to motivate people to >>> pay attention to the content, let's do it. As long as everything remains >>> in Asciidoc we are free to switch at any time, so there's no harm in giving >>> it a try. >>> >>> I agree. I recall there's been some discussion about the navigation >>> hierarchy and splitting stuff into "admin" and "developer", and I don't >>> think that went anywhere. If we have good content, then the right >>> structure will follow. Some way of enumerating what we have so we can >>> identify gaps, an
Re: Making Antora actionable
There’s also going to be updating the content to include any changes since february or march when I last worked on this. > On Jul 15, 2020, at 6:16 PM, David Jencks wrote: > > Great! > > I think there is general agreement that some part of the site should be > generated with Antora, and I’d certainly like some collaboration. If you are > interested in this, you could start by looking into Antora a bit (perhaps > Antora Documentation :: Antora Docs <https://docs.antora.org/>), installing > node and npm, and seeing if you can build the lates preview site I just set > up (see my other latest post). To understand some of Antora’s capabilities > it might be useful to look at the projects in David Jencks / Simple Examples > · GitLab <https://gitlab.com/djencks/simple-examples> which are each intended > to demonstrate one feature without a lot of distracting content :-) > > If you like web design, the UI project is going to need some work. > > Another very incomplete area is organization of the pages within an Antora > component. So far I just concentrated on getting all the content into > grammatical asciidoc, without considering organization. If I remember > correctly, the existing site has some lists of pages generated from asciidoc > header attributes; nearly all the pages are in a flat directory structure. I > think it would make sense to look at all the existing documentation and > organize it into categories in different Antora modules or topics, and > provide lists of pages in the nav that are ordered in a well-thought out > arrangement. > > If you have any questions, please ask! > > Thanks, > David Jencks > >> On Jul 15, 2020, at 5:37 PM, Willes Reis > <mailto:willesr...@gmail.com>> wrote: >> >> I have seen plenty of discussions and thoughts about evolution in tomee >> site and some hard decisions to make. >> But independently of the goal adopted, I'd really like to help with >> something. >> I like to face challenges and I have been interested in using these tools >> to learn more and contribute to the organization and standardization of the >> platform. >> Is there a small step to get started? >> >> Willes Reis >> >> Em qua., 15 de jul. de 2020 às 12:22, David Jencks > <mailto:david.a.jen...@gmail.com>> >> escreveu: >> >>> >>> >>>> On Jul 15, 2020, at 3:58 AM, Jonathan Gallimore < >>> jonathan.gallim...@gmail.com <mailto:jonathan.gallim...@gmail.com>> wrote: >>>> >>>>> I recommend we first eliminate the Apache CMS so we have a hands-free >>>> setup. Then I recommend we make it so the `tomee-site-generator` maven >>>> project is the thing that kicks off and runs Antora. >>>> >>>> Sounds good to me. >>>> >>>>> I seriously don't care what we use for them as the majority of the >>> issues >>>> are content, not tool. If we need to rollout a tool to motivate people >>> to >>>> pay attention to the content, let's do it. As long as everything remains >>>> in Asciidoc we are free to switch at any time, so there's no harm in >>> giving >>>> it a try. >>>> >>>> I agree. I recall there's been some discussion about the navigation >>>> hierarchy and splitting stuff into "admin" and "developer", and I don't >>>> think that went anywhere. If we have good content, then the right >>>> structure will follow. Some way of enumerating what we have so we can >>>> identify gaps, and review content feels like a potential starting point. >>>> Seeing what we have on the "old" site that isn't on the "new" site could >>> be >>>> interesting - if I search for something, I usually get a page from the >>>> "old" site. >>>> >>> >>> AFAIK I’ve found all the “old content”, translated it to Asciidoc, and >>> included it in the preview Antora site. >>> >>> David Jencks >>>> Jon >>>> >>>> On Wed, Jul 15, 2020 at 3:35 AM David Blevins >>> <mailto:david.blev...@gmail.com>> >>>> wrote: >>>> >>>>> Attempting to combine a few threads. >>>>> >>>>> - https://github.com/apache/tomee/pull/670#issuecomment-658452277 >>>>> <https://github.com/apache/tomee/pull/670#issuecomment-658452277> >>>>> >>>>> Antora-based website progress >>>&
Re: Making Antora actionable
Great! I think there is general agreement that some part of the site should be generated with Antora, and I’d certainly like some collaboration. If you are interested in this, you could start by looking into Antora a bit (perhaps Antora Documentation :: Antora Docs <https://docs.antora.org/>), installing node and npm, and seeing if you can build the lates preview site I just set up (see my other latest post). To understand some of Antora’s capabilities it might be useful to look at the projects in David Jencks / Simple Examples · GitLab <https://gitlab.com/djencks/simple-examples> which are each intended to demonstrate one feature without a lot of distracting content :-) If you like web design, the UI project is going to need some work. Another very incomplete area is organization of the pages within an Antora component. So far I just concentrated on getting all the content into grammatical asciidoc, without considering organization. If I remember correctly, the existing site has some lists of pages generated from asciidoc header attributes; nearly all the pages are in a flat directory structure. I think it would make sense to look at all the existing documentation and organize it into categories in different Antora modules or topics, and provide lists of pages in the nav that are ordered in a well-thought out arrangement. If you have any questions, please ask! Thanks, David Jencks > On Jul 15, 2020, at 5:37 PM, Willes Reis wrote: > > I have seen plenty of discussions and thoughts about evolution in tomee > site and some hard decisions to make. > But independently of the goal adopted, I'd really like to help with > something. > I like to face challenges and I have been interested in using these tools > to learn more and contribute to the organization and standardization of the > platform. > Is there a small step to get started? > > Willes Reis > > Em qua., 15 de jul. de 2020 às 12:22, David Jencks > escreveu: > >> >> >>> On Jul 15, 2020, at 3:58 AM, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >>> >>>> I recommend we first eliminate the Apache CMS so we have a hands-free >>> setup. Then I recommend we make it so the `tomee-site-generator` maven >>> project is the thing that kicks off and runs Antora. >>> >>> Sounds good to me. >>> >>>> I seriously don't care what we use for them as the majority of the >> issues >>> are content, not tool. If we need to rollout a tool to motivate people >> to >>> pay attention to the content, let's do it. As long as everything remains >>> in Asciidoc we are free to switch at any time, so there's no harm in >> giving >>> it a try. >>> >>> I agree. I recall there's been some discussion about the navigation >>> hierarchy and splitting stuff into "admin" and "developer", and I don't >>> think that went anywhere. If we have good content, then the right >>> structure will follow. Some way of enumerating what we have so we can >>> identify gaps, and review content feels like a potential starting point. >>> Seeing what we have on the "old" site that isn't on the "new" site could >> be >>> interesting - if I search for something, I usually get a page from the >>> "old" site. >>> >> >> AFAIK I’ve found all the “old content”, translated it to Asciidoc, and >> included it in the preview Antora site. >> >> David Jencks >>> Jon >>> >>> On Wed, Jul 15, 2020 at 3:35 AM David Blevins >>> wrote: >>> >>>> Attempting to combine a few threads. >>>> >>>> - https://github.com/apache/tomee/pull/670#issuecomment-658452277 >>>> >>>> Antora-based website progress >>>> - >>>> >> https://lists.apache.org/thread.html/rfbd39e3db0509fe4b8f65e679774699c3b55ae1c3eee5adb72ae551e%40%3Cdev.tomee.apache.org%3E >>>> >>>> The short version is there was doubt as to if the project was willing to >>>> consider using Antora. Cesar's feedback is closest to mine: >>>> >>>>> - Keep current tomee-site generator as the main content and website >>>> layout >>>>> - Once set up as a production-ready instance, keep the Antora setup for >>>>> the project documentation. This means that the current website link: >>>>> https://tomee.apache.org/docs.html will be redirected to the Antora >>>>> awesomeness UI. >>>>> >>>>> keep Antora usage for what it was made for, docum
Re: Making Antora actionable
I’ve: - started an Antora UI bundle project for TomEE: tomee-antora-ui <https://github.com/djencks/tomee-antora-ui> It’s already built, but if you want to build it yourself, clone it, run npm i, and gulp. In order to track what is changed from the default UI, I used my slightly experimental UI builder. If we want to proceed on this path I can release it to npm; right now it’s in my space on AWS. I set header/footer colors/images to match the existing site and removed the cruft from the header. I didn’t try to match header/footer content with the existing site since I think it needs to be rethought for Antora. - started an Antora playbook project for TomEE: tomee-antora <https://github.com/djencks/tomee-antora> To build this, clone it, and run npm run clean-build. The site will be at build/site. I have not yet provided a maven project to run this. I removed the examples from what was previously in the Antora site. The results are visible at https://tomee-preview.s3-us-west-2.amazonaws.com/common/contribute.html <https://tomee-preview.s3-us-west-2.amazonaws.com/common/contribute.html> (a somewhat arbitrary start page). Since an AWS bucket isn’t a web server or a local file system, there are some strange things happening for some links. Comments: - In order to combine the playbook project with tomee-site-generator, I think tomee-site-generator needs to become a multi-module reactor maven project. Let’s make sure that is actually the most sensible approach before proceeding. - I believe this preview includes all of what I think people have been describing as the non-example non-doc content. I think this includes all the stuff previously buried in secret in, mostly, markdown and html in the CMS. IIUC there’s some objection to this being in the Antora part of the site. I would like a clear explanation of what is better for this to be non-Antora content. - IIRC the content for 7.0, 7.1, and 8 is identical (there might be slight differences, of a couple of pages). I’d suggest that since there is not enough interest to maintain the site at a high level, this be collapsed to one version. Small differences can be pointed out with “since 8.0” etc. If in the future new docs for 9.0 are actually written, that would be a good time to add another version. - I haven’t yet considered how this might be combined with non-Antora parts of the site. I pointed out a few messages ago that at least the Antora part can easily use ASF infrastructure to publish to the appropriate git repo. - I haven’t made any attempt to set up reasonable navigation in the site. I think all pages are present in navigation, but wouldn’t promise anything. I think this may relate to the “what needs to be generated” discussion. I think it would be really great if this could get enough attention so that we can end up with a new site soon. Thanks! David Jencks > On Jul 15, 2020, at 8:22 AM, David Jencks wrote: > > > >> On Jul 15, 2020, at 3:58 AM, Jonathan Gallimore >> wrote: >> >>> I recommend we first eliminate the Apache CMS so we have a hands-free >> setup. Then I recommend we make it so the `tomee-site-generator` maven >> project is the thing that kicks off and runs Antora. >> >> Sounds good to me. >> >>> I seriously don't care what we use for them as the majority of the issues >> are content, not tool. If we need to rollout a tool to motivate people to >> pay attention to the content, let's do it. As long as everything remains >> in Asciidoc we are free to switch at any time, so there's no harm in giving >> it a try. >> >> I agree. I recall there's been some discussion about the navigation >> hierarchy and splitting stuff into "admin" and "developer", and I don't >> think that went anywhere. If we have good content, then the right >> structure will follow. Some way of enumerating what we have so we can >> identify gaps, and review content feels like a potential starting point. >> Seeing what we have on the "old" site that isn't on the "new" site could be >> interesting - if I search for something, I usually get a page from the >> "old" site. >> > > AFAIK I’ve found all the “old content”, translated it to Asciidoc, and > included it in the preview Antora site. > > David Jencks >> Jon >> >> On Wed, Jul 15, 2020 at 3:35 AM David Blevins >> wrote: >> >>> Attempting to combine a few threads. >>> >>> - https://github.com/apache/tomee/pull/670#issuecomment-658452277 >>> >>> Antora-based website progress >>> - >>> https://lists.apache.org/thread.html/rfbd39e3db0509fe4b8f65e679774699c3b55ae1c3eee5adb72ae551e%40%3Cdev.tomee.apache.org%3E >&
Re: Making Antora actionable
> On Jul 15, 2020, at 3:58 AM, Jonathan Gallimore > wrote: > >> I recommend we first eliminate the Apache CMS so we have a hands-free > setup. Then I recommend we make it so the `tomee-site-generator` maven > project is the thing that kicks off and runs Antora. > > Sounds good to me. > >> I seriously don't care what we use for them as the majority of the issues > are content, not tool. If we need to rollout a tool to motivate people to > pay attention to the content, let's do it. As long as everything remains > in Asciidoc we are free to switch at any time, so there's no harm in giving > it a try. > > I agree. I recall there's been some discussion about the navigation > hierarchy and splitting stuff into "admin" and "developer", and I don't > think that went anywhere. If we have good content, then the right > structure will follow. Some way of enumerating what we have so we can > identify gaps, and review content feels like a potential starting point. > Seeing what we have on the "old" site that isn't on the "new" site could be > interesting - if I search for something, I usually get a page from the > "old" site. > AFAIK I’ve found all the “old content”, translated it to Asciidoc, and included it in the preview Antora site. David Jencks > Jon > > On Wed, Jul 15, 2020 at 3:35 AM David Blevins > wrote: > >> Attempting to combine a few threads. >> >> - https://github.com/apache/tomee/pull/670#issuecomment-658452277 >> >> Antora-based website progress >> - >> https://lists.apache.org/thread.html/rfbd39e3db0509fe4b8f65e679774699c3b55ae1c3eee5adb72ae551e%40%3Cdev.tomee.apache.org%3E >> >> The short version is there was doubt as to if the project was willing to >> consider using Antora. Cesar's feedback is closest to mine: >> >>> - Keep current tomee-site generator as the main content and website >> layout >>> - Once set up as a production-ready instance, keep the Antora setup for >>> the project documentation. This means that the current website link: >>> https://tomee.apache.org/docs.html will be redirected to the Antora >>> awesomeness UI. >>> >>> keep Antora usage for what it was made for, documentation. Keep JBake >> for the static website layout and content. >> >> I would simply amend that to "Keep JBake for the static website layout and >> content [and examples.]" >> >> I'm very in love with the examples and never was too happy when we >> switched to JBake and lost the features I had added to supply javadoc >> links, build instructions and in some cases provide an auto-generated pages >> for them. We're finally getting those features back into the fold and >> there are some other cool things I'd like to do such as adding >> contributor's faces to each example, cross-linking javadoc and examples. >> >> Our main docs, however, are a complete mess. >> >> I seriously don't care what we use for them as the majority of the issues >> are content, not tool. If we need to rollout a tool to motivate people to >> pay attention to the content, let's do it. As long as everything remains >> in Asciidoc we are free to switch at any time, so there's no harm in giving >> it a try. >> >> I think there are two gaps we need to understand to have a better >> conversation about using Antora >> >> - Eliminating the Apache CMS from our lives. This is the biggest blocker >> to any true progress. The only reason our site doesn't automatically >> update now is because we're using the Apache CMS which has a manual publish >> step that takes about an hour of machine time and periodic manual >> checking/poking during that time. >> >> - Understanding `tomee-site-generator` isn't an enemy to Antora and >> doesn't need to die or be eliminated. Among other things, we use it to >> generate asciidoc content when and where we can. It will most likely need >> to run just before Antora. Antora would be building some mix of manually >> created docs and some generated docs. If Antora is not capable of >> committing generated files to git, then `tomee-site-generator` is where we >> would do that work. >> >> I recommend we first eliminate the Apache CMS so we have a hands-free >> setup. Then I recommend we make it so the `tomee-site-generator` maven >> project is the thing that kicks off and runs Antora. >> >> >> Thoughts? >> >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> >>
Re: Making Antora actionable
> On Jul 14, 2020, at 7:34 PM, David Blevins wrote:
>
> Attempting to combine a few threads.
>
> - https://github.com/apache/tomee/pull/670#issuecomment-658452277
>
> Antora-based website progress
> -
> https://lists.apache.org/thread.html/rfbd39e3db0509fe4b8f65e679774699c3b55ae1c3eee5adb72ae551e%40%3Cdev.tomee.apache.org%3E
>
> The short version is there was doubt as to if the project was willing to
> consider using Antora. Cesar's feedback is closest to mine:
>
>> - Keep current tomee-site generator as the main content and website layout
>> - Once set up as a production-ready instance, keep the Antora setup for
>> the project documentation. This means that the current website link:
>> https://tomee.apache.org/docs.html will be redirected to the Antora
>> awesomeness UI.
>>
>> keep Antora usage for what it was made for, documentation. Keep JBake for
>> the static website layout and content.
>
> I would simply amend that to "Keep JBake for the static website layout and
> content [and examples.]"
>
> I'm very in love with the examples and never was too happy when we switched
> to JBake and lost the features I had added to supply javadoc links, build
> instructions and in some cases provide an auto-generated pages for them.
> We're finally getting those features back into the fold and there are some
> other cool things I'd like to do such as adding contributor's faces to each
> example, cross-linking javadoc and examples.
>
> Our main docs, however, are a complete mess.
>
> I seriously don't care what we use for them as the majority of the issues are
> content, not tool. If we need to rollout a tool to motivate people to pay
> attention to the content, let's do it. As long as everything remains in
> Asciidoc we are free to switch at any time, so there's no harm in giving it a
> try.
There’s a significant amount of content in markdown, that I converted to
asciidoc.
>
> I think there are two gaps we need to understand to have a better
> conversation about using Antora
>
> - Eliminating the Apache CMS from our lives. This is the biggest blocker to
> any true progress. The only reason our site doesn't automatically update now
> is because we're using the Apache CMS which has a manual publish step that
> takes about an hour of machine time and periodic manual checking/poking
> during that time.
>
> - Understanding `tomee-site-generator` isn't an enemy to Antora and doesn't
> need to die or be eliminated. Among other things, we use it to generate
> asciidoc content when and where we can. It will most likely need to run just
> before Antora. Antora would be building some mix of manually created docs
> and some generated docs. If Antora is not capable of committing generated
> files to git, then `tomee-site-generator` is where we would do that work.
>
> I recommend we first eliminate the Apache CMS so we have a hands-free setup.
> Then I recommend we make it so the `tomee-site-generator` maven project is
> the thing that kicks off and runs Antora.
>
I’m confused about what you envisage here. Do you want to deploy the current
site without Apache CMS? If so, what are you planning to do about the markdown
content hidden away? Or do you want to plan to deploy the content using
Antora? Or do you want to discuss and come up with a plan?
If we have a process for building the entire site into a directory, it’s pretty
easy to use ASF infrastructure to publish it. For instance, Camel uses a
Jenkinsfile to build the site, and then run this to publish it:
steps {
dir('deploy/staging') {
deleteDir()
sh 'git clone -b asf-site
https://gitbox.apache.org/repos/asf/camel-website.git .'
sh 'git rm -r *'
sh "cp -R $WORKSPACE/camel-website/public/. ."
sh 'git add .'
sh 'git commit -m "Website updated to $(git rev-parse --short HEAD)"'
sh 'git push origin asf-site'
}
}
The Antora part is easy for me to set up, I’m not sure how it would relate to
other parts, especially, if this isn’t done using Antora, the parts that are
currently hidden in CMS in markdown.
It’s easy to run Antora from Maven, for instance Camel does it, although not
for the Jenkinsfile. I’d suggest a separate maven subproject in the
tomee-site-generator repo.
A larger obstacle seems to me that I doubt we’d want to use the Antora default
UI as-is, so someone would have to make it more TomEE friendly. I can change
colors and do some things with header/footer content, but not a whole lot more
than that.
>
> Thoughts?
>
Thanks for engaging!
David Jencks
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
Re: Follow-Up: ORB Dependencies and Java 11
I’d be quite surprised if any new applications are developed using CORBA and
I’d suspect any existing applications are at companies with ${big} support
contracts and little interest in migrating. I don’t know much about users of
TomEE however.
Generally jax-rs is an easier to deal with solution nowadays.
David Jencks
> On Jul 7, 2020, at 12:40 PM, Daniel Dias Dos Santos
> wrote:
>
> Hello ,
>
> Thanks Richard for the information .
>
> But @David Jencks CORBA is important in TomEE ? has any impact?
>
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em ter., 7 de jul. de 2020 às 16:35, David Jencks
> escreveu:
>
>> BTW, supporting CORBA, no matter which orb you pick, is quite difficult
>> unless you happen to already be a CORBA expert, probably because you’ve
>> already implemented significant parts of an ORB. The CORBA documentation is
>> fairly opaque, and the semantics are quite different from what you are used
>> to in java. Even though Yoko was used to certify IBM Liberty, getting it
>> to work with TomEE is likely to be a significant and painful adventure.
>>
>> David Jencks
>>
>>> On Jul 7, 2020, at 9:53 AM, David Jencks
>> wrote:
>>>
>>> Apache Yoko (part of geronimo project) is probably also a viable
>> possibility, a few years ago it was the IBM Liberty corba implementation,
>> and is presumably still used in OpenLiberty. I think jacorb has an
>> incompatible license, which is why we didn’t use it in Geronimo. I don’t
>> know about the glassfish orb.
>>>
>>> David Jencks
>>>
>>>> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard <
>> richard.zowa...@hs-heilbronn.de> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I was digging around the GitHub Repo and noticed PR 664 [1], which
>>>> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
>>>> JDK 11.
>>>>
>>>> There was a disucssion 2 years ago about removing CORBA related access
>>>> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>>>>
>>>> If we want to build TomEE with JDK 11, we either need to (a) remove
>>>> CORBA dependencies (and check the implications as suggested in TOMEE-
>>>> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
>>>> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>>>>
>>>> What is the plan for this? Any opinions? :)
>>>>
>>>> Best,
>>>> Richard
>>>>
>>>>
>>>> [1] https://github.com/apache/tomee/pull/664
>>>> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
>>>> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
>>>> [4] https://www.jacorb.org/
>>>> [5] https://javaee.github.io/glassfish-corba/
>>>
>>
>>
Re: Follow-Up: ORB Dependencies and Java 11
BTW, supporting CORBA, no matter which orb you pick, is quite difficult unless
you happen to already be a CORBA expert, probably because you’ve already
implemented significant parts of an ORB. The CORBA documentation is fairly
opaque, and the semantics are quite different from what you are used to in
java. Even though Yoko was used to certify IBM Liberty, getting it to work
with TomEE is likely to be a significant and painful adventure.
David Jencks
> On Jul 7, 2020, at 9:53 AM, David Jencks wrote:
>
> Apache Yoko (part of geronimo project) is probably also a viable possibility,
> a few years ago it was the IBM Liberty corba implementation, and is
> presumably still used in OpenLiberty. I think jacorb has an incompatible
> license, which is why we didn’t use it in Geronimo. I don’t know about the
> glassfish orb.
>
> David Jencks
>
>> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard
>> wrote:
>>
>> Hi,
>>
>> I was digging around the GitHub Repo and noticed PR 664 [1], which
>> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
>> JDK 11.
>>
>> There was a disucssion 2 years ago about removing CORBA related access
>> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>>
>> If we want to build TomEE with JDK 11, we either need to (a) remove
>> CORBA dependencies (and check the implications as suggested in TOMEE-
>> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
>> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>>
>> What is the plan for this? Any opinions? :)
>>
>> Best,
>> Richard
>>
>>
>> [1] https://github.com/apache/tomee/pull/664
>> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
>> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
>> [4] https://www.jacorb.org/
>> [5] https://javaee.github.io/glassfish-corba/
>
Re: Follow-Up: ORB Dependencies and Java 11
Apache Yoko (part of geronimo project) is probably also a viable possibility, a
few years ago it was the IBM Liberty corba implementation, and is presumably
still used in OpenLiberty. I think jacorb has an incompatible license, which
is why we didn’t use it in Geronimo. I don’t know about the glassfish orb.
David Jencks
> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard
> wrote:
>
> Hi,
>
> I was digging around the GitHub Repo and noticed PR 664 [1], which
> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
> JDK 11.
>
> There was a disucssion 2 years ago about removing CORBA related access
> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>
> If we want to build TomEE with JDK 11, we either need to (a) remove
> CORBA dependencies (and check the implications as suggested in TOMEE-
> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>
> What is the plan for this? Any opinions? :)
>
> Best,
> Richard
>
>
> [1] https://github.com/apache/tomee/pull/664
> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
> [4] https://www.jacorb.org/
> [5] https://javaee.github.io/glassfish-corba/
Re: TOMEE-2341 - TomEE Site Generator
Hi Willes, It’s great to see someone interested in improving the state of the documentation! Earlier this year I spent a lot of time working on a proposal to move the TomEE documentation to an Antora based structure. I didn’t get much response from the community and left it for a while, but am considering working on it some more.I think structurally the work is pretty much done but there are a bunch of, basically, presentation issues that could use improvement. If this is adopted it’s likely to make many or most earlier doc issues somewhat obsolete. The last prototype site I came up with is at https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/docs.html <https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/docs.html>. Having some help with this would be great. With regard to the issue you mention here, here are my thoughts: - I don’t understand why the custom code is used to assemble the unified javadoc jar. I think the maven javadoc plugin can be configured to do it. - I thought the asciidoclet plugin was already configured, but it won’t do anything until someone writes some javadoc using asciidoc :-) - I’m not quite sure what David Blevins means by an index, but it might be trivial for the Antora built site. - 4 is done - Links from javadoc to actual class usage is a great idea, but how to do it is not so obvious. I left a small comment on the sub-task. Anyway, Welcome!! David Jencks > On Jun 27, 2020, at 10:15 PM, Willes Reis wrote: > > Hi David Blevins, > > Looking at the JIRA issue https://issues.apache.org/jira/browse/TOMEE-2341 on > which you are the reporter, I realized that there are 5 sub-tasks (2 closed > / 3 open) and I would like to help with something in this, but I don't know > if the proposal is still valid? If ok, could you please explain the > expectations? > > Any feedback is appreciated. > > Best regards and stay healthy! > Willes Reis
Re: [VOTE] Release Apache TomEE 9.0.0-M1 and Apache TomEE 8.0.3
Thanks! With these additions, +1 David Jencks > On Jun 19, 2020, at 11:13 PM, Jonathan Gallimore > wrote: > > I missed copying those from the staged Maven repo - here they are (the > .ascs, sha256s and sha512s are there too): > > TomEE: > https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/tomee-project-8.0.3-source-release.zip > Patch Plugin: > https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/tomee-patch-parent-0.1-source-release.zip > TomEE Jakarta Conversion: > https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/apache-tomee-9.0.0-M1-source-release.zip > > Jon > > On Sat, Jun 20, 2020 at 5:29 AM David Jencks > wrote: > >> Sorry to be sticky, but an apache release is source code, packaged >> sufficiently to be able to build the product. A git tag isn’t sufficient. >> Everything else, such as jars, are convenience artifacts. AFAICT there’s >> nothing to vote on here :-( >> >> It’s been many years but IIRC there’s a way to get maven to package up the >> clean source project just like a git checkout. That’s what I was expecting >> so I could look over the source and legal files. >> >> David Jencks >> >>> On Jun 19, 2020, at 9:20 PM, David Blevins >> wrote: >>> >>> Not 100% confident on this, but I think it's these tags built in this >> order: >>> >>> - >> https://github.com/apache/tomee-patch-plugin/tree/tomee-patch-parent-0.1 >>> - https://github.com/apache/tomee/tree/tomee-project-8.0.3 >>> - https://github.com/apache/tomee-jakarta/tree/apache-tomee-9.0.0-M1 >>> >>> Hopefully after this release we can eliminate the need for the >> tomee-jakarta repo and merge that into tomee/master. As well, ideally we >> can hopefully use the v0.1 of the TomEE Patch Plugin and release that >> separately as needed. >>> >>> >>> -David >>> >>> >>>> On Jun 19, 2020, at 8:38 PM, David Jencks >> wrote: >>>> >>>> I can’t find the source archive that I can build locally to get all >> those juicy binary artifacts in >> https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/ < >> https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/> >>>> >>>> ??? >>>> >>>> thanks >>>> david jencks >>>> >>>>> On Jun 19, 2020, at 6:01 AM, Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I am delighted to present a vote for Apache TomEE 9.0.0-M1 and Apache >> TomEE >>>>> 8.0.3. >>>>> >>>>> There's some background on this release here: >>>>> >> https://lists.apache.org/thread.html/r1d89e3c1cd9dba9695e059c96efc8af0d68f18e40c4d4c688801db8d%40%3Cdev.tomee.apache.org%3E >>>>> >>>>> The key points here are: >>>>> >>>>> * TomEE 8.0.3 is essentially identical to TomEE 8.0.2, bar some >> changes to >>>>> examples. Release notes are below. >>>>> >>>>> * TomEE 9.0.0-M1 is a transformed version of TomEE 8.0.3, to shift >> TomEE >>>>> and all its dependencies from the javax to jakarta namespace. >>>>> >>>>> * If you're targeting Jakarta EE 8, use TomEE 8.0.3. If you would like >> to >>>>> try out Jakarta EE 9, with the new namespace, try TomEE 9.0.0-M1. If >> you >>>>> build the examples, for most of them you should get a `javax` version >> and a >>>>> `jakarta` version. Moviefun is a good app to use to play around. >>>>> >>>>> * TomEE 8.0.3 is production-ready. TomEE 9.0.0-M1 is a milestone. We'd >> love >>>>> you to try it, kick the tyres and provide feedback. There will likely >> be a >>>>> few milestone releases before we get to a production-ready 9.0.0. >>>>> >>>>> * We expect things to not work with the 9.0.0-M1 version. Feedback is >>>>> gratefully received, but will be addressed with subsequent releases. >>>>> Genuine show-stopper issues, such as legal issues, should be voted -1, >> but >>>>> bugs or functionality in the 9.0.0-M1 should not prevent this release >> going >>>>> ahead. If you have questions around this, please let us know. >>>>> >>>>> * Both versions are built from the
Re: [VOTE] Release Apache TomEE 9.0.0-M1 and Apache TomEE 8.0.3
Sorry to be sticky, but an apache release is source code, packaged sufficiently to be able to build the product. A git tag isn’t sufficient. Everything else, such as jars, are convenience artifacts. AFAICT there’s nothing to vote on here :-( It’s been many years but IIRC there’s a way to get maven to package up the clean source project just like a git checkout. That’s what I was expecting so I could look over the source and legal files. David Jencks > On Jun 19, 2020, at 9:20 PM, David Blevins wrote: > > Not 100% confident on this, but I think it's these tags built in this order: > > - https://github.com/apache/tomee-patch-plugin/tree/tomee-patch-parent-0.1 > - https://github.com/apache/tomee/tree/tomee-project-8.0.3 > - https://github.com/apache/tomee-jakarta/tree/apache-tomee-9.0.0-M1 > > Hopefully after this release we can eliminate the need for the tomee-jakarta > repo and merge that into tomee/master. As well, ideally we can hopefully use > the v0.1 of the TomEE Patch Plugin and release that separately as needed. > > > -David > > >> On Jun 19, 2020, at 8:38 PM, David Jencks wrote: >> >> I can’t find the source archive that I can build locally to get all those >> juicy binary artifacts in >> https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/ >> <https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/> >> >> ??? >> >> thanks >> david jencks >> >>> On Jun 19, 2020, at 6:01 AM, Jonathan Gallimore >>> wrote: >>> >>> Hi All, >>> >>> I am delighted to present a vote for Apache TomEE 9.0.0-M1 and Apache TomEE >>> 8.0.3. >>> >>> There's some background on this release here: >>> https://lists.apache.org/thread.html/r1d89e3c1cd9dba9695e059c96efc8af0d68f18e40c4d4c688801db8d%40%3Cdev.tomee.apache.org%3E >>> >>> The key points here are: >>> >>> * TomEE 8.0.3 is essentially identical to TomEE 8.0.2, bar some changes to >>> examples. Release notes are below. >>> >>> * TomEE 9.0.0-M1 is a transformed version of TomEE 8.0.3, to shift TomEE >>> and all its dependencies from the javax to jakarta namespace. >>> >>> * If you're targeting Jakarta EE 8, use TomEE 8.0.3. If you would like to >>> try out Jakarta EE 9, with the new namespace, try TomEE 9.0.0-M1. If you >>> build the examples, for most of them you should get a `javax` version and a >>> `jakarta` version. Moviefun is a good app to use to play around. >>> >>> * TomEE 8.0.3 is production-ready. TomEE 9.0.0-M1 is a milestone. We'd love >>> you to try it, kick the tyres and provide feedback. There will likely be a >>> few milestone releases before we get to a production-ready 9.0.0. >>> >>> * We expect things to not work with the 9.0.0-M1 version. Feedback is >>> gratefully received, but will be addressed with subsequent releases. >>> Genuine show-stopper issues, such as legal issues, should be voted -1, but >>> bugs or functionality in the 9.0.0-M1 should not prevent this release going >>> ahead. If you have questions around this, please let us know. >>> >>> * Both versions are built from the same codebase, hence the single vote. >>> >>> * This vote includes the release of a patch plugin: >>> https://github.com/apache/tomee-patch-plugin, and one separate single >>> module to do the translation work for the jakarta version: >>> https://github.com/apache/tomee-jakarta. I'm expecting the >>> tomee-jakara repo to be removed and the module bought back under the tomee >>> tree when we can work out the build issues there. >>> >>> Maven Repo: >>> https://repository.apache.org/content/repositories/orgapachetomee-1172/ >>> >>> Binaries & Source: >>> https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/ >>> >>> Tags: >>> >>> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-project-8.0.3 >>> https://gitbox.apache.org/repos/asf?p=tomee-patch-plugin.git;a=tag;h=refs/tags/tomee-patch-parent-0.1 >>> https://gitbox.apache.org/repos/asf?p=tomee-jakarta.git;a=tag;h=refs/tags/apache-tomee-9.0.0-M1 >>> >>> Release notes: >>> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12348219 >>> >>> Please VOTE: >>> >>> [+1] Yes, release it >>> [+0] Not fussed >>> [-1] Don't release, there's a showstopper (please specify what the >>> showstopper is) >>> >>> Vote will be open for 72 hours. >>> >>> Here is my +1. >>> >>> Thanks >>> >>> Jon >> >
Re: [VOTE] Release Apache TomEE 9.0.0-M1 and Apache TomEE 8.0.3
I can’t find the source archive that I can build locally to get all those juicy binary artifacts in https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/ <https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/> ??? thanks david jencks > On Jun 19, 2020, at 6:01 AM, Jonathan Gallimore > wrote: > > Hi All, > > I am delighted to present a vote for Apache TomEE 9.0.0-M1 and Apache TomEE > 8.0.3. > > There's some background on this release here: > https://lists.apache.org/thread.html/r1d89e3c1cd9dba9695e059c96efc8af0d68f18e40c4d4c688801db8d%40%3Cdev.tomee.apache.org%3E > > The key points here are: > > * TomEE 8.0.3 is essentially identical to TomEE 8.0.2, bar some changes to > examples. Release notes are below. > > * TomEE 9.0.0-M1 is a transformed version of TomEE 8.0.3, to shift TomEE > and all its dependencies from the javax to jakarta namespace. > > * If you're targeting Jakarta EE 8, use TomEE 8.0.3. If you would like to > try out Jakarta EE 9, with the new namespace, try TomEE 9.0.0-M1. If you > build the examples, for most of them you should get a `javax` version and a > `jakarta` version. Moviefun is a good app to use to play around. > > * TomEE 8.0.3 is production-ready. TomEE 9.0.0-M1 is a milestone. We'd love > you to try it, kick the tyres and provide feedback. There will likely be a > few milestone releases before we get to a production-ready 9.0.0. > > * We expect things to not work with the 9.0.0-M1 version. Feedback is > gratefully received, but will be addressed with subsequent releases. > Genuine show-stopper issues, such as legal issues, should be voted -1, but > bugs or functionality in the 9.0.0-M1 should not prevent this release going > ahead. If you have questions around this, please let us know. > > * Both versions are built from the same codebase, hence the single vote. > > * This vote includes the release of a patch plugin: > https://github.com/apache/tomee-patch-plugin, and one separate single > module to do the translation work for the jakarta version: > https://github.com/apache/tomee-jakarta. I'm expecting the > tomee-jakara repo to be removed and the module bought back under the tomee > tree when we can work out the build issues there. > > Maven Repo: > https://repository.apache.org/content/repositories/orgapachetomee-1172/ > > Binaries & Source: > https://dist.apache.org/repos/dist/dev/tomee/staging-1172/tomee-8.0.3/ > > Tags: > > https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-project-8.0.3 > https://gitbox.apache.org/repos/asf?p=tomee-patch-plugin.git;a=tag;h=refs/tags/tomee-patch-parent-0.1 > https://gitbox.apache.org/repos/asf?p=tomee-jakarta.git;a=tag;h=refs/tags/apache-tomee-9.0.0-M1 > > Release notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12348219 > > Please VOTE: > > [+1] Yes, release it > [+0] Not fussed > [-1] Don't release, there's a showstopper (please specify what the > showstopper is) > > Vote will be open for 72 hours. > > Here is my +1. > > Thanks > > Jon
Re: Initial Jakarta EE 9 snapshot TCK results (90%-ish)
This is amazing! Go for it! +1 David Jencks > On Jun 18, 2020, at 8:13 PM, David Blevins wrote: > > I've done a run in EC2 and here are the results I'm getting with the > potential TomEE 9.0.0-M1 binaries. > > If you didn't read the 100+ emails in the last week, these binaries are > created by taking TomEE 8.0.3-SNAPSHOT and running through the bytecode > transformation tools we've been working on (Eclipse Transformer and TomEE > Patch Plugin) to change all the code that references `javax` to instead > reference `jakarta`. All this is done in the TomEE master branch. We're > hoping this means we can stay focused on TomEE 8 / Jakarta EE 8 while getting > Jakarta EE 9 compliance for free (no having to maintain two branches for code > that only differs by namespace). > > Enough of that, now the data: > > # Overall > > PASSED 23843 91% > FAILED2133 8% > TOTAL25976 > > > # Breakdown by Section > > section totalpassed failed percent > ejb30 2120 1780 340 83% > ejb32 801 675 126 84% > el 147 1461 99% > jaspic 68 4 64 5% > jaxrs 2417 2229 188 92% > jpa 10071 9932 139 98% > jsf5419 5252 167 96% > jsonb 236 224 12 94% > jsonp 744 708 36 95% > jsp 711 676 35 95% > jstl524 453 71 86% > jta 195 141 54 72% > securityapi 86 1 85 1% > servlet1698 1622 76 95% > websocket 739 0 739 0% > > > Bear in mind we don't actually know if anyone can pass the Jakarta EE 9 TCK > yet. With that in mind, I'd say these results are astronomically good. > > Given how behind we've been in the last few years I think it would be pretty > awesome to hustle to get a release up for vote ASAP so we can have binaries > people can try in time for the Jakarta EE 9 Milestone release Tuesday morning. > > With 72 hours to vote and 24 hours for mirrors to sync, if we rolled binaries > in the next 12 hours we could just make. > > If everyone bears in mind these two things, I think we can make it: > > 1. Any release we roll can immediately be fixed in a subsequent > release if there's a flaw; there's no time for rerolls. We could do > another release next week if we wanted. > > 2. Any discussion we want to have on how a Jakarta EE 9 effort > should go is still on the table. We can change literally anything > for potential future releases. Nothing is set in stone. > > > That said, let's give the world a taste of awesome. > > > -David > > > > > >
Re: [VOTE] Move javaee-api to Git.
+1 David Jencks > On Apr 29, 2020, at 2:50 PM, Jonathan Gallimore > wrote: > > +1 > > On Wed, Apr 29, 2020 at 10:40 PM Cesar Hernandez > wrote: > >> Hi, >> >> As a follow up from the `Javax -> Jakarta rename` thread [1] >> I would like to propose moving the existing SVN javaee-api repo [2] to >> Git[3] to enable wider visibility and collaboration either via GitHub or >> gitbox.apache.org. >> >> I will create the Apache JIRA Infra migration ticket after the vote has >> passed. >> >> [ ] +1 approve the release move javaee-api repo to Git >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> [1] >> >> https://lists.apache.org/thread.html/refb945e599cad66d8508a540fa5801fd2b04682424e9e29b4e6dd7b4%40%3Cdev.tomee.apache.org%3E >> [2] https://svn.apache.org/repos/asf/tomee/javaee-api/ >> [3] https://gitbox.apache.org/ >> -- >> Atentamente: >> César Hernández. >>
Antora-based website progress
this I can push them sooner. Embedding the javadoc in the site relies on code I’ve written as an Antora plugin, based on an experimental plugin system I wrote. The idea of a plugin system is accepted for Antora, but my implementation hasn’t been even reviewed yet. In-component organization So far I’ve concentrated on finding and fixing content. I think the next step is to organize the content within the components. The current site seems to use a jbake attribute to programmatically sort pages. While relational databases are great for some things, the AS400 file system has not caught on big time. I’m going to start organizing things by turning these attributes into topic directories or modules. I expect to organize at least some of the other “common” docs into topics or modules. Unless I find a way to easily automate synchronizing the 4 versions of most pages, I’m going to follow (1) and drop the 3 versioned copies. ——— Examples Currently my treatment of examples relies on a bash script to copy and rename the README.adocs. I’m not sure this is fundamentally worse than what the java code does, it does involve another system. I think it may be possible to write an Antora plugin to directly gather the example files. I suspect this plugin may be of general interest since, for example, most of the camel website is gathered together generated-from-code .adoc files. I haven’t looked much at the example READMEs, but many of them seem to have code copied from the example java files. I’d suggest replacing this with include:: directives. These can specify line numbers or tags in the included files, so we can arrange to leave out the Apache notice :-) Since presumably we want the README to work both in GitHub and in the site, some magic will be needed to get the include:: to work in both places. — Site appearance I’ve been ignoring site appearance until the basic content and organization questions are settled. Antora separates the appearance, or UI, for the site from the content, into a “UI bundle”. At the moment constructing a custom or modified UI bundle is much more difficult and less maintainable than it needs to be. I’m planning to prototype a more flexible system soon. I have a slightly modified default UI bundle for the javadoc content. If someone wants to help with that I can make it available now: otherwise I may wait until using it is simpler. To see what some Antora sites look like, based on customized UI bundles, take a look at the links in https://gitlab.com/antora/antora.org/issues/20 There’s marginally more customization involved, but https://blog.yuzutech.fr/blog/ is also nice. David Jencks
Re: Draft Proposal for overall website direction
Part of this discussion is about how to organize the website. I was just pointed to this, which I think has a very nice description of different purposes for different documentation, no matter what technology is used for the site: https://lisk.io/blog/announcement/lisk-documentation-migrated-asciidoc-and-antora David Jencks > >> On Feb 19, 2020, at 5:24 AM, gilbertoca wrote: >> >> David Blevins-2 wrote >>> There's an entire facet of this discussion we probably should be talking >>> about which is how to deal with our heaps of content in various states of >>> health; how did it get unhealthy, how do we deal with it, how do we >>> prevent it, how do we encourage more contribution to main docs. >>> >>> I think any tool in the hands of someone willing to lead an effort to >>> improve our main docs is a good tool. >>> >>> -David >> >> We could follow (again) apache friends and others [1] condensing all >> relevant content in something like a User Guide or Reference Guide - that >> would help the Maintenance and contribution. This organization can reduce >> the tooling and it easy integrate(asciidoctor-maven-plugin?) in build >> system[2]. >> >> [1] >> https://netbeans.apache.org/kb/docs/java/index.html >> https://ci.apache.org/projects/wicket/guide/8.x/single.html >> https://beanvalidation.org/2.0/spec/ >> https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html >> https://shiro.apache.org/reference.html >> >> [2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/ >> >> Regards, >> >> Gilberto >> >> >> >> -- >> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html >
Re: Can I begin TOMEE-2371
I’ve assigned it to you in Jira. Of course you can work on it! Thanks!! David Jencks > On Feb 23, 2020, at 4:29 PM, Yelken Ferreira wrote: > > Guys, > > Can I begin this TASK: https://issues.apache.org/jira/browse/TOMEE-2371? > Or exist any task with more priority? > > My focus will make documentation or translate > > Somebody can direct to me this task on JIRA? > > My user on JIRA is: yelken > > Thanks! > > -- > Yelken Heckman > > As informações existentes nesta mensagem e nos arquivos anexados são para > uso restrito, sendo seu sigilo protegido por lei. Caso não seja > destinatário, saiba que leitura, divulgação ou cópia são proibidas. Favor > apagar as informações e notificar o remetente. O uso impróprio será tratado > conforme a Legislação em vigor. > > The information in this message and attached files are restricted, and > their confidentiality protected by law. If not addressed, aware that > reading, copying or disclosure is prohibited. Please delete this message > and notify the sender. Improper use will be treated according to the > legislation in force.
Re: (new) website content sanity check :-)
I have a new idea for clarifying the website duplication.
Antora lets you include the same page in several components by using “include
stubs”, i.e. a page that only has an include:: preprocessor directive, pointing
to the single copy. (includes work in plain asciidoc, but there’s no practical
way to refer to the originating page without Antora page coordinates).
Intellij tools such as IDEA and WebStorm have a nice diff fe total.ature and
customizable live templates. I made a live template to insert the include:: to
the “actual copy” of the page.
My workflow is to compare a page in 8.0@tomee (i.e. my antora clone of master
of the tomee git repo) with the same page in the tomes-site antora branch using
WebStorm’s side-by-side diff. I combine the asciidoc to get something that is
more correct than either source, edit any other errors I see, put the corrected
version in tomee-site, and replace the tomee master copy with an include stub.
One of the edits is including the jbake attributes from master.
This reduces the number of duplicates by one, and indicates:
- on master that the page is duplicated in common
- on tomee-site that the page is duplicated in master, and edited to look OK.
I now have only 2 errors in 8.0@tomee, 367 in common, and 386 total.
David Jencks
> On Feb 17, 2020, at 4:39 PM, David Jencks wrote:
>
> I pushed another preview update. This has all the content I’ve found and
> except for a few pages from svn that seem to originate as html and some pages
> currently generated by the tomee-stie-generator I believe it has all the
> content that is supposed to be published.
>
> There are about 450 errors noted by Antora building this. These are asciidoc
> syntax errors (mostly section level errors) and broken links.
>
> AFAICT most of the content is duplicated in 4 places: what I’m calling
> “common”, 8.0, 7.1, and 7.0. Fixing only one copy would be considerably
> quicker than comparing and fixing 4.
>
> My extremely biased opinion is that the content is approximately as good
> shape as the live site. There is decidedly less organization and navigation.
> Some pages are worse, and some are better, but it’s all presented uniformly.
>
> TomEE Documentation AWS
> <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html>
>
> Thanks
> David Jencks
>
>> On Feb 16, 2020, at 7:41 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote:
>>
>> Thanks for the more info, and I have plenty to do so no hurry, if you do
>> have some time some quick questions…
>>
>> is https://svn.apache.org/repos/asf/tomee/site/trunk/content
>> <https://svn.apache.org/repos/asf/tomee/site/trunk/content> the “same as”
>> the website content, so modulo .md and mdtext > html conversion I can look
>> at it and act like that’s the website to mimic? (also module files that have
>> no source)
>>
>> Is all the source from tomee-site, tomee-site-generator (including
>> java-generated content), and tomee? So anything not present in some format
>> from one of these that’s in the above svn repo can be left out?
>>
>> I’d think there must be some configuration for the Builder
>> tomee-site-staging but I can’t find it.
>>
>> IMO the site in any form is in such a mess that it’s hard to know where to
>> work first. There are tons of broken formatting, both in the existing site
>> and the .adoc translations, and loads of broken links that have no plausible
>> target. For instance one of the pages you note has
>>
>> \{include:OPENEJBx30:Singleton Beans}
>>
>> I didn’t touch that one :-) It’s a bit confusing because there’s no
>> OPENEJBx30 anywhere in sight, but I expect it’s supposed to refer to the
>> same component/version. When I get to it it will turn into a redirect.
>>
>> I’m mostly concentrating on finding all the sources, getting them into some
>> sort of semi-coherent structure, and fixing formatting and links that
>> asciidoctor complains about. I thought I was nearly done, but now there are
>> a lot more files :-)
>>
>> After the automatically recognized problems are fixed, examining the pages
>> for other problems can start.
>>
>> Thanks for the hints!
>>
>> David Jencks
>>
>>
>>
>>> On Feb 16, 2020, at 6:58 PM, David Blevins >> <mailto:david.blev...@gmail.com>> wrote:
>>>
>>> Hi David,
>>>
>>> Looks like you got there in the end. I attempted to give a heads up on
>>> that in my first email about the Apache CMS, but all this is complicated.
>>> Read this then go back and read my first email on the "Documenta
Re: Draft Proposal for overall website direction
I was more or less assuming that before reorganizing the website content, organizing it was required. Otherwise, you could just drop all current content and start over, which admittedly might be faster and more satisfactory. The asciidoctor-maven-plugin is only usable if you want a site with only one version. All of the sites you note below indeed only have one version. Although primitive, what David Blevins came up with in tomee-site-generator at least allows multiple versions. For me, two hard requirements would be: - generate the entire site in one action. I think this is needed to track what is supposed to be there and avoid orphaned content like we have now. - support multiple components and versions with easy navigation between them. At a minimum, I think there can be general version less information and version specific information. Separating content into perhaps a User Guide and a Reference Guide would be even better. Here are some Antora generated sites: Customized UI: https://camel.apache.org/manual/latest/getting-started.html / https://github.com/apache/camel/tree/master/docs https://isis.apache.org/guides/ugfun/ugfun.html (using rather non-standard navigation; I find this confusing) /https://github.com/apache/isis/tree/master/antora (I think this is far too complicated, but it’s one approach to organizing a gigantic disorganized set of documentation) https://docs.couchbase.com/server/6.5/introduction/intro.html / https://github.com/couchbase/docs-site https://www.uyuni-project.org/uyuni-docs/uyuni/index.html / https://github.com/uyuni-project/uyuni-docs Unmodified UI https://books.japila.pl/apache-spark-internals/apache-spark-internals/latest/index.html / https://github.com/japila-books/apache-spark-internals There’s a list of more sites here: https://gitlab.com/antora/antora.org/issues/20 Some of these sites, for reasons I don’t understand, avoid making it clear that there are multiple components and versions. In the default UI, and several of these sites, at the lower left there’s a component selector allowing you to choose which component/version you want to look at. This is also visible in my preview site. I’m not aware of any other comparable system that provides built in this level of organization. David Jencks > On Feb 19, 2020, at 5:24 AM, gilbertoca wrote: > > David Blevins-2 wrote >> There's an entire facet of this discussion we probably should be talking >> about which is how to deal with our heaps of content in various states of >> health; how did it get unhealthy, how do we deal with it, how do we >> prevent it, how do we encourage more contribution to main docs. >> >> I think any tool in the hands of someone willing to lead an effort to >> improve our main docs is a good tool. >> >> -David > > We could follow (again) apache friends and others [1] condensing all > relevant content in something like a User Guide or Reference Guide - that > would help the Maintenance and contribution. This organization can reduce > the tooling and it easy integrate(asciidoctor-maven-plugin?) in build > system[2]. > > [1] > https://netbeans.apache.org/kb/docs/java/index.html > https://ci.apache.org/projects/wicket/guide/8.x/single.html > https://beanvalidation.org/2.0/spec/ > https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html > https://shiro.apache.org/reference.html > > [2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/ > > Regards, > > Gilberto > > > > -- > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
Re: Draft Proposal for overall website direction
Sorry for top posting… I might have a slightly different direction to look in. Thinking about some of the comments along the lines of “jbake is good enough” I’ve realized that, for me, the main benefit Antora brings over anything else I’m aware of is that it helps you organize your content in a sensible yet very flexible way. I’d like to draw an analogy to the ant-vs.-maven controversy, if anyone remembers that far back :-) They are both build tools that take your java source and use the java compiler to create class files. Aren’t they just the same then? Well, would you suggest taking TomEE to an ant-based build? Perhaps not…. maven suggests a project organization that makes good sense for most java projects, and does about 70-99% of the organizational work for you. Perhaps similarly, Antora more or less enforces a simple sensible documentation organization, and provides a simple consistent way to get a nice looking website out with almost no configuration needed. This documentation project is much larger than I anticipated at first, and the hard part is finding all the content and figuring out a plausible organization. I think I’ve found pretty much everything, and have a preliminary organization. Admittedly I’m strongly biased in favor of Antora, but I would never have considered the project of even collecting all the existing content without the organization Antora provides. That said, I’m fairly amazed at how much of Antora’s functionality David has compressed into the tomcat-site-generator. However, it’s incomplete, undocumented, unmaintained, and buggy. I suggest that maintaining something like that is not what anyone involved in TomEE wants to be spending their time on. One possible other factor to consider is that my interest here is primarily in finding out what it’s like to migrate a moderately complex disorganized website to Antora, and investigating what extensions or outside work (such as javadoc) are needed. I’m really not interested in participating in other solutions. I expect to continue until I get something I’m satisfied with or I get tired. I think I already have pretty much all the content as Asciidoctor, and I hope to get it to idiomatic error-free asciidoc. If the community wants a non-Antora solution it should be moderately straightforward to de-Antora-ize the content, but it’s not something I’m likely to be participating in. In partial answer to David’s last question, I think one reason for the doc decay was allowing too many choices, so that it quickly became too hard to figure out how to do anything. Thanks David Jencks > On Feb 18, 2020, at 1:27 PM, David Blevins wrote: > >> On Feb 18, 2020, at 12:57 PM, Guillermo García wrote: >> >> I don't want to open a difficult debate about which technology is the best, >> but in the worst case is it possible to call a committee for a votation? >> How the TomEE committers team defines which direction to take in these >> cases? > > We definitely still need much more discussion and participation to hammer out > all the topics on this. In ideal situations you can find agreement on parts > and then reduce the scope of what's being discussed so where people disagree > is more clear. That often allows it to be more easily addressed. > > When you've done a good job on all that and everyone feels they understand > what's being discussed and are all "talked out", it's a definite sign a vote > is the only remaining way to move forward and you hold one. > > Some projects are pretty strict about whose votes count. Some say just votes > from the PMC members count (small group). Some say just the committers > (slightly larger). We've typically been pretty open and say everyone's votes > count; it's hard to grow a project while telling people who are your future > growth, "your vote doesn't count." :) > > On this topic specifically, I also agree with David on several things and I > definitely don't feel "talked out", so at least for my perspective, we're > aways away from voting on anything. > > More participation will definitely help the discussion along. > > There's an entire facet of this discussion we probably should be talking > about which is how to deal with our heaps of content in various states of > health; how did it get unhealthy, how do we deal with it, how do we prevent > it, how do we encourage more contribution to main docs. > > I think any tool in the hands of someone willing to lead an effort to improve > our main docs is a good tool. > > > -David > > > > > > > >
Re: Draft Proposal for overall website direction
Antora already supports “edit this page". Some pages in the current site have a
button for it, but I don’t know if it works.
David Jencks
> On Feb 18, 2020, at 10:43 AM, gilbertoca wrote:
>
> I would stick with jvm tool (jbake) instead of add/learn one
> more(node-antora). Specially I would to suggest we adopt what our Apache
> Netbeans friends have done with jbake (jbake.org) in thier site
> (https://netbeans.apache.org/). There, in each page you have a button ("See
> this page in GitHub") where you/anyone can edit the original asciidoc file
> and make PR for contribution.
>
> Regards,
>
> Gilberto
>
>
> David Blevins-2 wrote
>> All,
>>
>> I have a draft of something we can kick around for our website overall.
>>
>> -
>> https://github.com/apache/tomee-site-generator/blob/master/WEBSITE-2020.adoc
>>
>> This took 3 hours to write so apologies for the size. Much of this is
>> experience from all the efforts of the past, some imagined improvements to
>> successful parts of the site, while paving the way for the Antora work.
>>
>> Food on the table, cranky wife! Must go!
>>
>> Sorry for the short email! :)
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>
>
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
Re: Draft Proposal for overall website direction
I wrote some overly long and unfocussed comments, and pushed them to my fork and opened a PR. I don’t seem to have permissions to merge…. did I follow the wrong procedure (e.g. should I make a branch and merge from that) or do I not have appropriate permissions? Maybe my GitHub identity is not appropriately lined up with my Apache identity? Thanks David Jencks > On Feb 17, 2020, at 3:50 PM, David Jencks wrote: > > Lets try all other imaginable, and some unimaginable, methods before we try > editing something this complicated on a mailing list :-) > I’m happy to try adding comments to the GitHub page. > > David Jencks > >> On Feb 17, 2020, at 2:48 PM, David Blevins wrote: >> >> Here’s a copy if you want to go that route. Anything works for me >> >> >> # Proposal: Website 2020 >> >> This will hopefully serve as the documentation for the website once/if >> executed. >> >> High-level plan >> >> - Kill all use and trace of the Apache CMS >> - Publish html directly to git >> - Allow for several sources to publish html >> >> The result will be several sources, that can be run and managed >> independently, feeding content into the git repo housing our live html >> website. >> >> This is a pragmatic perspective that sets us up to get a best-of-breed >> outcome acknowledging trends in all our website endevors: >> >> - All tools we've used have been heavily extended >> - Content takes a hit each tool change >> - All tools have limitations (strenghts/weaknesses) >> - Filling gaps involves extensions (bullet one) >> - Tools last on average 2-5 years >> - Many types of content actually exist: javadoc, release notes, download >> pages >> - We will always be in a hybrid situation >> >> Think of it as "microservices for content" and avoiding a monolith. >> >> Ideally this sets us up to acknowledge and embrace evolving our >> website tech without many of the above disadvantages. If we have a >> clean CSS and simple menu, we should be able to take HTML from >> anywhere. >> >> When we want to add a new content source we do not need to figure out >> how to get it to work "through" the existing generator or redo >> everything that already works, we simply have it generate content >> directly to html directly to our site git. >> >> As long as we maintain a common CSS and look and feel, we're good. >> >> ## Kill all use and trace of the Apache CMS >> >> TODO >> >> ## Publish html directly to git >> >> Apache allows a project to designate a git repository as their >> "website." All files in that repository are published as-is to the >> internet as the project's website. HTML must be committed to this >> repository as it does not offer any generation of any kind. >> >> TODO: what is the process for getting one of these repos? >> TODO: can we get Infra to do a svn-git migration of our current flat-html? >> >> ## Allow for several sources to publish html >> >> In the new architecture each content generator publishes rendered html >> directly to the site git. >> >> The following is a rough outline of the types of content: >> >> - Versioned documentation for a software distribution >> - Community/Developer documentation >> - Website front-page and "marketing" pages such as major features, >> benefits, etc >> - Examples >> - Javadoc >> - Release notes and download pages >> - Contributors page >> >> ### Versioned documentation for a software distribution >> >> All of our "product documentation" efforts to date have been in some >> way wiki-like in nature. They allow any kind of content to take any >> shape and do not encourage structure. >> >> As a result our content is all miscellaneous odds and ends that do not >> fit together in any significant chapters or flow. Said another way >> we're all "blog" and no "book." >> >> The proposal for this is to use Antora tied to an effort to create a >> documentation outline that encourages contribution on-rails. Gaps in >> the documentation should be obvious, which hopefully encourages >> contribution >> >> ### Community/Developer documentation >> >> Learning how our community works and how to contribute (be a >> developer) is also an experience that really needs to be on-rails. >> >> The proposal for this is to use Antora tied to an effort to create a >> deliberately
Re: (new) website content sanity check :-)
I pushed another preview update. This has all the content I’ve found and
except for a few pages from svn that seem to originate as html and some pages
currently generated by the tomee-stie-generator I believe it has all the
content that is supposed to be published.
There are about 450 errors noted by Antora building this. These are asciidoc
syntax errors (mostly section level errors) and broken links.
AFAICT most of the content is duplicated in 4 places: what I’m calling
“common”, 8.0, 7.1, and 7.0. Fixing only one copy would be considerably
quicker than comparing and fixing 4.
My extremely biased opinion is that the content is approximately as good shape
as the live site. There is decidedly less organization and navigation. Some
pages are worse, and some are better, but it’s all presented uniformly.
TomEE Documentation AWS
<https://tomee-preview.s3-us-west-2.amazonaws.com/index.html>
Thanks
David Jencks
> On Feb 16, 2020, at 7:41 PM, David Jencks wrote:
>
> Thanks for the more info, and I have plenty to do so no hurry, if you do have
> some time some quick questions…
>
> is https://svn.apache.org/repos/asf/tomee/site/trunk/content
> <https://svn.apache.org/repos/asf/tomee/site/trunk/content> the “same as” the
> website content, so modulo .md and mdtext > html conversion I can look at it
> and act like that’s the website to mimic? (also module files that have no
> source)
>
> Is all the source from tomee-site, tomee-site-generator (including
> java-generated content), and tomee? So anything not present in some format
> from one of these that’s in the above svn repo can be left out?
>
> I’d think there must be some configuration for the Builder tomee-site-staging
> but I can’t find it.
>
> IMO the site in any form is in such a mess that it’s hard to know where to
> work first. There are tons of broken formatting, both in the existing site
> and the .adoc translations, and loads of broken links that have no plausible
> target. For instance one of the pages you note has
>
> \{include:OPENEJBx30:Singleton Beans}
>
> I didn’t touch that one :-) It’s a bit confusing because there’s no
> OPENEJBx30 anywhere in sight, but I expect it’s supposed to refer to the same
> component/version. When I get to it it will turn into a redirect.
>
> I’m mostly concentrating on finding all the sources, getting them into some
> sort of semi-coherent structure, and fixing formatting and links that
> asciidoctor complains about. I thought I was nearly done, but now there are
> a lot more files :-)
>
> After the automatically recognized problems are fixed, examining the pages
> for other problems can start.
>
> Thanks for the hints!
>
> David Jencks
>
>
>
>> On Feb 16, 2020, at 6:58 PM, David Blevins > <mailto:david.blev...@gmail.com>> wrote:
>>
>> Hi David,
>>
>> Looks like you got there in the end. I attempted to give a heads up on that
>> in my first email about the Apache CMS, but all this is complicated. Read
>> this then go back and read my first email on the "Documentation Site" thread
>> and hopefully it makes more sense.
>>
>> It's very hard to describe it with magically the right level of detail.
>> Here's the way too short version.
>>
>> - https://github.com/apache/tomee-site-generator
>> <https://github.com/apache/tomee-site-generator> spits html into here
>> - https://svn.apache.org/repos/asf/tomee/site/trunk/content/
>> <https://svn.apache.org/repos/asf/tomee/site/trunk/content/> which triggers
>> this Apache CMS job
>> - https://ci.apache.org/builders/tomee-site-staging
>> <https://ci.apache.org/builders/tomee-site-staging> which takes any html and
>> also converts the mdtext and puts them here
>> - /usr/local/websites/tomee/trunk which is a private svn repo that publishes
>> to here
>> - http://tomee.staging.apache.org <http://tomee.staging.apache.org/> which
>> can only get published if a human visits here
>> - https://cms.apache.org/tomee/publish
>> <https://cms.apache.org/tomee/publish> and clicks the button so all html
>> (CMS and otherwise) get published here
>> - http://tomee.apache.org/ <http://tomee.apache.org/>
>>
>> What we truly need more than a switch from Jbake to Antora is to get rid of
>> the Apache CMS as that would cut out 4 of those 7 bullets leaving us with:
>>
>> - https://github.com/apache/tomee-site-generator
>> <https://github.com/apache/tomee-site-generator> spits html into here
>> - https://github.com/apache/tomee-
>> <https://github.com/apache/tomee-%3Csome-new-repo%3E> which causes A
Re: Draft Proposal for overall website direction
Lets try all other imaginable, and some unimaginable, methods before we try editing something this complicated on a mailing list :-) I’m happy to try adding comments to the GitHub page. David Jencks > On Feb 17, 2020, at 2:48 PM, David Blevins wrote: > > Here’s a copy if you want to go that route. Anything works for me > > > # Proposal: Website 2020 > > This will hopefully serve as the documentation for the website once/if > executed. > > High-level plan > > - Kill all use and trace of the Apache CMS > - Publish html directly to git > - Allow for several sources to publish html > > The result will be several sources, that can be run and managed > independently, feeding content into the git repo housing our live html > website. > > This is a pragmatic perspective that sets us up to get a best-of-breed > outcome acknowledging trends in all our website endevors: > > - All tools we've used have been heavily extended > - Content takes a hit each tool change > - All tools have limitations (strenghts/weaknesses) > - Filling gaps involves extensions (bullet one) > - Tools last on average 2-5 years > - Many types of content actually exist: javadoc, release notes, download pages > - We will always be in a hybrid situation > > Think of it as "microservices for content" and avoiding a monolith. > > Ideally this sets us up to acknowledge and embrace evolving our > website tech without many of the above disadvantages. If we have a > clean CSS and simple menu, we should be able to take HTML from > anywhere. > > When we want to add a new content source we do not need to figure out > how to get it to work "through" the existing generator or redo > everything that already works, we simply have it generate content > directly to html directly to our site git. > > As long as we maintain a common CSS and look and feel, we're good. > > ## Kill all use and trace of the Apache CMS > > TODO > > ## Publish html directly to git > > Apache allows a project to designate a git repository as their > "website." All files in that repository are published as-is to the > internet as the project's website. HTML must be committed to this > repository as it does not offer any generation of any kind. > > TODO: what is the process for getting one of these repos? > TODO: can we get Infra to do a svn-git migration of our current flat-html? > > ## Allow for several sources to publish html > > In the new architecture each content generator publishes rendered html > directly to the site git. > > The following is a rough outline of the types of content: > > - Versioned documentation for a software distribution > - Community/Developer documentation > - Website front-page and "marketing" pages such as major features, > benefits, etc > - Examples > - Javadoc > - Release notes and download pages > - Contributors page > > ### Versioned documentation for a software distribution > > All of our "product documentation" efforts to date have been in some > way wiki-like in nature. They allow any kind of content to take any > shape and do not encourage structure. > > As a result our content is all miscellaneous odds and ends that do not > fit together in any significant chapters or flow. Said another way > we're all "blog" and no "book." > > The proposal for this is to use Antora tied to an effort to create a > documentation outline that encourages contribution on-rails. Gaps in > the documentation should be obvious, which hopefully encourages > contribution > > ### Community/Developer documentation > > Learning how our community works and how to contribute (be a > developer) is also an experience that really needs to be on-rails. > > The proposal for this is to use Antora tied to an effort to create a > deliberately smaller outline of how to get involved. > > This content should be very focused on "developer onboarding", > something all open source projects must nail to grow. > > > ### Website front-page and "marketing" pages, features, etc > > When people come to the website they must get a human-perfect > orientation that gives them the most important information in > highlighted form with the least clicking. > > There is no proven structure for gaining someone's immediate > attention and not losing them. They need to know "why TomEE", > ideally with some pictures or video. There also needs to be > a very small handful of pages to highlight features and further > pull people in. > > The proposal for this is to use the existing Jbake setup as it is > free-form and
Re: Draft Proposal for overall website direction
What would you consider the best way of providing detailed comments on this? Perhaps editing the document adding subsections or sublist items with my initials? Thanks David Jencks > On Feb 16, 2020, at 9:23 PM, David Blevins wrote: > > All, > > I have a draft of something we can kick around for our website overall. > > - https://github.com/apache/tomee-site-generator/blob/master/WEBSITE-2020.adoc > > This took 3 hours to write so apologies for the size. Much of this is > experience from all the efforts of the past, some imagined improvements to > successful parts of the site, while paving the way for the Antora work. > > Food on the table, cranky wife! Must go! > > Sorry for the short email! :) > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com >
Re: (new) website content sanity check :-)
Thanks for the more info, and I have plenty to do so no hurry, if you do have
some time some quick questions…
is https://svn.apache.org/repos/asf/tomee/site/trunk/content the “same as” the
website content, so modulo .md and mdtext > html conversion I can look at it
and act like that’s the website to mimic? (also module files that have no
source)
Is all the source from tomee-site, tomee-site-generator (including
java-generated content), and tomee? So anything not present in some format
from one of these that’s in the above svn repo can be left out?
I’d think there must be some configuration for the Builder tomee-site-staging
but I can’t find it.
IMO the site in any form is in such a mess that it’s hard to know where to work
first. There are tons of broken formatting, both in the existing site and the
.adoc translations, and loads of broken links that have no plausible target.
For instance one of the pages you note has
\{include:OPENEJBx30:Singleton Beans}
I didn’t touch that one :-) It’s a bit confusing because there’s no OPENEJBx30
anywhere in sight, but I expect it’s supposed to refer to the same
component/version. When I get to it it will turn into a redirect.
I’m mostly concentrating on finding all the sources, getting them into some
sort of semi-coherent structure, and fixing formatting and links that
asciidoctor complains about. I thought I was nearly done, but now there are a
lot more files :-)
After the automatically recognized problems are fixed, examining the pages for
other problems can start.
Thanks for the hints!
David Jencks
> On Feb 16, 2020, at 6:58 PM, David Blevins wrote:
>
> Hi David,
>
> Looks like you got there in the end. I attempted to give a heads up on that
> in my first email about the Apache CMS, but all this is complicated. Read
> this then go back and read my first email on the "Documentation Site" thread
> and hopefully it makes more sense.
>
> It's very hard to describe it with magically the right level of detail.
> Here's the way too short version.
>
> - https://github.com/apache/tomee-site-generator
> <https://github.com/apache/tomee-site-generator> spits html into here
> - https://svn.apache.org/repos/asf/tomee/site/trunk/content/
> <https://svn.apache.org/repos/asf/tomee/site/trunk/content/> which triggers
> this Apache CMS job
> - https://ci.apache.org/builders/tomee-site-staging
> <https://ci.apache.org/builders/tomee-site-staging> which takes any html and
> also converts the mdtext and puts them here
> - /usr/local/websites/tomee/trunk which is a private svn repo that publishes
> to here
> - http://tomee.staging.apache.org <http://tomee.staging.apache.org/> which
> can only get published if a human visits here
> - https://cms.apache.org/tomee/publish <https://cms.apache.org/tomee/publish>
> and clicks the button so all html (CMS and otherwise) get published here
> - http://tomee.apache.org/ <http://tomee.apache.org/>
>
> What we truly need more than a switch from Jbake to Antora is to get rid of
> the Apache CMS as that would cut out 4 of those 7 bullets leaving us with:
>
> - https://github.com/apache/tomee-site-generator
> <https://github.com/apache/tomee-site-generator> spits html into here
> - https://github.com/apache/tomee-
> <https://github.com/apache/tomee-%3Csome-new-repo%3E> which causes Apache's
> new infra to publish here
> - http://tomee.apache.org/ <http://tomee.apache.org/>
>
> Unfortunately this repo appears to be a honeypot (dead end that can only
> confuse). It used to be a mirror of
> svn.apache.org/repos/asf/tomee/site/trunk/content
> <http://svn.apache.org/repos/asf/tomee/site/trunk/content>, but it looks like
> the sync stopped about 2 years ago.
>
>
> All the work of the last 10 days or so has been on replacing the Javadoc and
> Jbake parts, which have room for improvement and Antora can definitely be
> part of that improvement, but the big win is ditching the CMS, which
> technically could happen now.
>
> Replacing the CMS probably needs its own email.
>
> I mentioned this in the first email as well; the issue you pointed out at the
> start with the badly formatted page actually wasn't an issue with Jbake. It
> was one of many legacy CMS files that wasn't fully converted out of the
> specialized Markdown format. These issues exist in your Antora prototype as
> well:
>
> -
> https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/singleton-ejb.html
> <https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/singleton-ejb.html>
>
> And truthfully our content issues date back to our Confluence-based website
> days as there's still a very small bit of Confluence wiki markup hanging
>
Re: (new) website content sanity check :-)
I’ve discovered that the svn repo automatically converts .mdtext files to .html, so my conclusions about how much of tomee-site are currently published are wrong. I’ll redo my calculations. Thanks David Jencks > On Feb 16, 2020, at 8:40 AM, David Jencks wrote: > > Hi, > > I’d like some verification that my conclusions about content are reasonable…. > > The content sources I know about are: > > tomee (7-8 docs and examples) > > tomee-site-generator (older content) > > tomee-site (?) > > My understanding is the site is published using svnpubsub, so that svn repo > reflects what is actually visible on the site. > > After doing some set arithmetic I’ve discovered that there is no content on > the current site necessarily from tomee-site; there’s a lot of overlap in > content between tomee-site and tomee-site-generator, but nothing from > tomee-site that is missing from tomee-site-generator is on the website. > > Is this reasonable? > > Is there anything from tomee-site not currently published that _should_ be > added to the site? According to my calculations, there are about 445 pages > in tomee-site that aren’t currently published. > > If anyone wants to study the situation, I recommend looking at my git repos > where all the content I’ve found is similarly organized, and the summary in > comparison.json > <https://github.com/djencks/tomee/blob/antora/docs/comparison.json> > > calculated using old-new-compare.js > <https://github.com/djencks/tomee/blob/antora/docs/old-new-compare.js> > > There’s also quite a bit of content with no source; as I’ve mentioned before > I think this is a never-cleaned-up leftover from a previous version of the > site. > > Thanks > David Jencks > > ps. by “necessarily” I mean all the pages in svn that could have come from > tomee-site, could also have come from tomee-site-generator. I don’t really > know where they actually came from, although I could probably calculate it. > > pps. For nitpickers: there may appear to be two unique files at tomee-site. > One, security/index, is the same as security/security; I’ve provided a > redirect. The other, documentation, is some sort of site index or navigation > page, possibly generated. I heavily edited the version in my repo before > realizing it was not needed as-is.
(new) website content sanity check :-)
Hi, I’d like some verification that my conclusions about content are reasonable…. The content sources I know about are: tomee (7-8 docs and examples) tomee-site-generator (older content) tomee-site (?) My understanding is the site is published using svnpubsub, so that svn repo reflects what is actually visible on the site. After doing some set arithmetic I’ve discovered that there is no content on the current site necessarily from tomee-site; there’s a lot of overlap in content between tomee-site and tomee-site-generator, but nothing from tomee-site that is missing from tomee-site-generator is on the website. Is this reasonable? Is there anything from tomee-site not currently published that _should_ be added to the site? According to my calculations, there are about 445 pages in tomee-site that aren’t currently published. If anyone wants to study the situation, I recommend looking at my git repos where all the content I’ve found is similarly organized, and the summary in comparison.json <https://github.com/djencks/tomee/blob/antora/docs/comparison.json> calculated using old-new-compare.js <https://github.com/djencks/tomee/blob/antora/docs/old-new-compare.js> There’s also quite a bit of content with no source; as I’ve mentioned before I think this is a never-cleaned-up leftover from a previous version of the site. Thanks David Jencks ps. by “necessarily” I mean all the pages in svn that could have come from tomee-site, could also have come from tomee-site-generator. I don’t really know where they actually came from, although I could probably calculate it. pps. For nitpickers: there may appear to be two unique files at tomee-site. One, security/index, is the same as security/security; I’ve provided a redirect. The other, documentation, is some sort of site index or navigation page, possibly generated. I heavily edited the version in my repo before realizing it was not needed as-is.
Re: Redoing the website with Antora - status
I thought a bit more about the examples and versioning. I didn’t check history, but my impression is that once written an example doesn’t change; if there’s a new capability to demonstrate, that results in a new example. Of course an example might be improved or it’s documentation extended, but if it worked on one version of tomee I’d expect it to continue to work on all later versions. If this it true, then I think it would be easier to maintain and use the examples documentation if there was one version (“latest” or master) and each example had a “since version x.x.x” label. I think the examples documentation is presented with the non-example documentation on the current site, but it is not on my preview site, since the “main” documentation is english-only and the examples is multilingual. Thoughts? David Jencks > On Feb 15, 2020, at 6:55 PM, David Jencks wrote: > > Hi Cesar, > > Thanks for responding! I’ve been so involved with Antora for so long I > forget that not everyone is as familiar with it as I :-) > > If you haven’t already, taking a look at my preview site might help clarify > how Antora deals with components and versions - especially the component > selector in the lower left. > >> On Feb 15, 2020, at 5:45 PM, Cesar Hernandez > <mailto:cesargu...@gmail.com>> wrote: >> >> Hi David >> Thanks for your email and work you are doing. >> I have a couple of questions: >> >>>>>> Combine the remaining pages from tomee-site and tomee-site-generator >> into an unversioned component >> >> Can you expand please a little bit more what are you referring to as the >> Unversioned Component? Is this an in-memory process to generate the final >> source for Anfora? > > I really didn’t explain this! > > Currently the existing web site has some pages at "https://tomee.apache.org/ > <https://tomee.apache.org/>“ and some at e.g. > "https://tomee.apache.org/tomee-8.0/docs/ > <https://tomee.apache.org/tomee-8.0/docs/>“. I’m describing the former as > “unversioned” as opposed to the latter which are versioned. > > In an Antora site, a component is normally versioned (like the “tomee-8.0”, > although the URL is going to contain something like “tomee/8.0” instead). > However, by picking the special version “master” Antora will leave the > version segment out of the url, producing and unversioned component. You can > have more versions for that component, but I think that gets confusing. > > It seems to me that some of the documentation is definitely version-specific > and some isn’t. For example, description of the community, how to > participate, where git is, etc, aren’t versioned. So I think having an > unversioned component is a good idea. I was proposing to start off by > putting the content that currently isn’t versioned into it. How this happens > isn’t really relevant, but at the moment I’m planning on leaving it in the > git repos it is currently in. That’s probably not a good long term solution, > but I think it will make it easier to decide what content can be dropped. > > On the preview site, the “unversioned” content is showing up as tomee version > 0.0 and 0.1. I’m going to combine it into a new unversioned component, > perhaps “general”. I haven’t found a name I really like :-) > >> >>>>>> * Only have example documentation for 8.0. >> Does this mean that current documentation for 7.0 [1] and 7.1 [2] won't be >> available anymore in the website? >> >> In the ticket you mentioned "...Some versions are missing (primarily >> examples for 7.1 and 7.0).." >> The current TomEE website generator uses the TomEE branches for getting the >> examples readme files [3]. >> >> >> [1] https://tomee.apache.org/tomee-7.0/examples/ >> <https://tomee.apache.org/tomee-7.0/examples/> >> [2] https://tomee.apache.org/tomee-7.1/examples/ >> <https://tomee.apache.org/tomee-7.1/examples/> >> [3] https://github.com/apache/tomee/tree/tomee-7.0.x/examples >> <https://github.com/apache/tomee/tree/tomee-7.0.x/examples> >> > > Having worked for a couple weeks now on this, my opinion is that the biggest > problem the tomee site has is too much duplicated outdated useless content. > Maintaining the site has IMO not gone well, so reducing its size may be a > good idea. Certainly the examples documentation seems to be the best > maintained part of the documentation, but I think serious consideration > should be given to only showing the examples for the latest version. > > This is just an idea. If there’s general agreement that the 7.0 and 7.1 > examples docs
Re: Redoing the website with Antora - status
Hi Cesar, Thanks for responding! I’ve been so involved with Antora for so long I forget that not everyone is as familiar with it as I :-) If you haven’t already, taking a look at my preview site might help clarify how Antora deals with components and versions - especially the component selector in the lower left. > On Feb 15, 2020, at 5:45 PM, Cesar Hernandez wrote: > > Hi David > Thanks for your email and work you are doing. > I have a couple of questions: > >>>>> Combine the remaining pages from tomee-site and tomee-site-generator > into an unversioned component > > Can you expand please a little bit more what are you referring to as the > Unversioned Component? Is this an in-memory process to generate the final > source for Anfora? I really didn’t explain this! Currently the existing web site has some pages at "https://tomee.apache.org/ <https://tomee.apache.org/>“ and some at e.g. "https://tomee.apache.org/tomee-8.0/docs/ <https://tomee.apache.org/tomee-8.0/docs/>“. I’m describing the former as “unversioned” as opposed to the latter which are versioned. In an Antora site, a component is normally versioned (like the “tomee-8.0”, although the URL is going to contain something like “tomee/8.0” instead). However, by picking the special version “master” Antora will leave the version segment out of the url, producing and unversioned component. You can have more versions for that component, but I think that gets confusing. It seems to me that some of the documentation is definitely version-specific and some isn’t. For example, description of the community, how to participate, where git is, etc, aren’t versioned. So I think having an unversioned component is a good idea. I was proposing to start off by putting the content that currently isn’t versioned into it. How this happens isn’t really relevant, but at the moment I’m planning on leaving it in the git repos it is currently in. That’s probably not a good long term solution, but I think it will make it easier to decide what content can be dropped. On the preview site, the “unversioned” content is showing up as tomee version 0.0 and 0.1. I’m going to combine it into a new unversioned component, perhaps “general”. I haven’t found a name I really like :-) > >>>>> * Only have example documentation for 8.0. > Does this mean that current documentation for 7.0 [1] and 7.1 [2] won't be > available anymore in the website? > > In the ticket you mentioned "...Some versions are missing (primarily > examples for 7.1 and 7.0).." > The current TomEE website generator uses the TomEE branches for getting the > examples readme files [3]. > > > [1] https://tomee.apache.org/tomee-7.0/examples/ > [2] https://tomee.apache.org/tomee-7.1/examples/ > [3] https://github.com/apache/tomee/tree/tomee-7.0.x/examples > Having worked for a couple weeks now on this, my opinion is that the biggest problem the tomee site has is too much duplicated outdated useless content. Maintaining the site has IMO not gone well, so reducing its size may be a good idea. Certainly the examples documentation seems to be the best maintained part of the documentation, but I think serious consideration should be given to only showing the examples for the latest version. This is just an idea. If there’s general agreement that the 7.0 and 7.1 examples docs should stay on the site, I’m happy to put them in, although it may be some work as they are still in .md format. I have a pretty good md to adoc translator but checking the results is definitely needed. I’d likely do this in pieces after the other problems are more solved. For one thing, it’s really clear where the examples docs come from, and much of my work has been tracking down the source for much of the site! I hope this clarifies things, and feel free to ask more questions! David Jencks > > > On Sat, Feb 15, 2020 at 01:33 David Jencks wrote: > >> Hi, >> >> I’ve opened some issues (starting at >> https://issues.apache.org/jira/browse/TOMEE-2772 < >> https://issues.apache.org/jira/browse/TOMEE-2772>) about my attempts to >> build a nice TomEE website with Antora. There are quite a few questions I >> still have, and ideally I’ll get some feedback on them soon. However, I’m >> about ready to make unilateral decisions on some of them in order to make >> progress. At this point this is mostly around which content sources and >> which parts of these content sources should be included. >> >> In particular, I plan to: >> >> * Stop looking for the source for the files in svnpubsub not in any source >> I know about >> * Remove the pages from tomee-site that aren’t in svnpubsub >> * Combine the remaining pages from tomee-site and tomee-site-generator >> into an unversioned component >> * Only have example documentation for 8.0. >> >> Thanks >> David Jencks
Redoing the website with Antora - status
Hi, I’ve opened some issues (starting at https://issues.apache.org/jira/browse/TOMEE-2772 <https://issues.apache.org/jira/browse/TOMEE-2772>) about my attempts to build a nice TomEE website with Antora. There are quite a few questions I still have, and ideally I’ll get some feedback on them soon. However, I’m about ready to make unilateral decisions on some of them in order to make progress. At this point this is mostly around which content sources and which parts of these content sources should be included. In particular, I plan to: * Stop looking for the source for the files in svnpubsub not in any source I know about * Remove the pages from tomee-site that aren’t in svnpubsub * Combine the remaining pages from tomee-site and tomee-site-generator into an unversioned component * Only have example documentation for 8.0. Thanks David Jencks
Where did this documentation page come from?
https://tomee.apache.org/admin/configuration/application.html <https://tomee.apache.org/admin/configuration/application.html> is definitely on the website, and is in the svn pub-sub system. It’s rendering is somewhat like the currently-bake-rendered pages, but with noticeable differences, and there are corresponding pages in the tomee-8.0, tomee-7.1.0, etc docs. It’s not rendered by jbake/tomee-site-generator AFAICT, it’s not in tomee-site-generator resources, nor in tomes-site. Where did it come from? I’m not sure how to count exactly, but there might be around 80-90 of these pages that I haven’t found a source for. It’s been there for a while…. svn log admin/configuration/application.html r1811638 | andygumbrecht | 2017-10-09 21:50:03 -0700 (Mon, 09 Oct 2017) | 1 line Downloads, now with archive r1801643 | jgallimore | 2017-07-11 11:31:12 -0700 (Tue, 11 Jul 2017) | 1 line Updating site from tomee-site-generator r1801631 | jgallimore | 2017-07-11 09:17:24 -0700 (Tue, 11 Jul 2017) | 1 line Updating site from tomee-site-generator r1796252 | rmannibucau | 2017-05-26 01:06:29 -0700 (Fri, 26 May 2017) | 1 line starting to rewire examples properly r1780916 | rmannibucau | 2017-01-30 06:38:05 -0800 (Mon, 30 Jan 2017) | 1 line updating ng site to try to fix download page r1772522 | rmannibucau | 2016-12-04 03:01:40 -0800 (Sun, 04 Dec 2016) | 1 line attempting a mobile menu r1772515 | rmannibucau | 2016-12-04 02:20:37 -0800 (Sun, 04 Dec 2016) | 1 line first ng import as main site Looking at the history of the JBake class I rather suspect it was generated by an earlier version of the site-generator and the location was no longer targeted in this commit: Pull examples and docs from active branches <https://github.com/djencks/tomee-site-generator/commit/3c8d3037d12581fa02383ee2552146332871d385#diff-bc487c7f0ce74f2fc6e346520485e135> (nov 2018) I may not progress much farther on my antora experiment without knowing what to do about these mystery pages. Thanks! David Jencks
Re: Documentation site
Possibly there’s some duplication in the new site: individual addresses in sitemaps, without translations: old sitemap page count: 560 old-sitemap-addr.txt new sitemap page count: 1423 new-sitemap-addr-en-only.txt comparison of unique page names (without path, source, or version info): old-not-new count: 1 old-not-new-index.txt new-not-old count: 119 new-not-old-index.txt If anyone has ideas how to identify it, I’d like to hear them. Is the live-site sitemap actually accurate? thanks David Jencks > On Feb 9, 2020, at 11:55 AM, David Jencks wrote: > > I think I’ve found all the existing content sources and incorporated them in > to the Antora-built site. > > Sources: > > * tomee docs (moved to antora structure) (versions master = 8.0, 7.1, and > 7.0) > * tomee examples (script to copy/rename to antora structure for appropriate > language) (version master = 8.0 only) > * tomee-site-generator (converted to adoc and moved to antora structure) > (currently labeled version 0.1) > * tomee-site (converted to adoc and moved to antora structure) (currently > labeled version 0.0) > > Comparing the live site-map.xml and the ones generated for the Antora-built > site, there is one file missing (index-old.html > http://tomee.apache.org/examples/index-old.html > <http://tomee.apache.org/examples/index-old.html>) which I don’t think is > necessary or appropriate to move, and 119 new files that didn’t appear in the > existing site. They are listed in tomee@antora docs/new-not-old-index.txt. > > The old-new diffs are only whether some version of the file stem appears in > each site, I haven’t tried to figure out how to compare which versions each > page appears in. > > So far I’ve made no attempt to incorporate javadoc. > > If you are not quite familiar with Antora structure looking at the preview at > https://tomee-preview.s3-us-west-2.amazonaws.com/index.html > <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html> will probably > help understand the questions. In particular in the lower left corner > there’s the “component drawer” where you can select the component and version > to view. > > Questions: > > * How should the content be arranged into components and versions? > > ** current state: > > *** There are two components, tomee and examples. > > *** The tomee component has versions 8.0, 7.1, and 7.0 (from tomee/docs) and > 0.1 (from tomee-site-generator) and 0.0 (tomee-site) > > *** The examples component has versions 8.0-en, 8.0-sp, 8.0-pt for the > different languages > > ** Sub-questions: > > *** Is all of the content I’ve put under tomee actually version specific, or > is there some content that is conceptually unversioned (general information > about tomee, perhaps). This could be separated into a separate unversioned > component. > > *** Is some or all of the content I’ve put in 0.1 and 0.0 actually associated > with a real version such as 1.7 or OpenEJB v??? > > *** Is there a need to maintain earlier versions of the examples > documentation, or is just “current” enough? It looks like there are earlier > examples directories in the 7.1.x and 7.0.x branches, and it would certainly > be possible to convert them and include them in the site, but I think that > might make the site harder to use and less informative. > > * How should the content with a version be organized on the source tree and > in the navigation? The source-tree questions certainly don’t need immediate > answers. > > ** Source tree: Antora source structure is > modules//pages/. The ‘default’ module name is > ‘ROOT’, which is what I’ve used. Antora can deal directly with content in > subfolders of ‘pages’ (some of which has appeared reflecting the original > arrangement) and additional modules (useful to keep each module a manageable > size). > > *** To what extent would it be useful to break the content up into modules? > > *** The examples are grouped in the navigation but are flat in the file > system. Would it be appropriate to reflect the doc grouping in the file > system layout? > > ** Navigation current state: > > *** The 8.0, 7.1, and 7.0 tomee versions have navigation adapted from > documentation.adoc This seems more or less reasonable for now. > > *** The 0.1 and 0.0 tomee versions have navigation generated by just listing > all the pages. > > *** The examples have navigation adapted from the existing examples > navigation. > > ** Sub-questions: > > *** How should the 0.1 and 0.0 be organized? Is there an existing page that > is a starting point, as documentation.adoc is for more current content? > > *** What other changes or ref
Re: Documentation site
I think I’ve found all the existing content sources and incorporated them in to the Antora-built site. Sources: * tomee docs (moved to antora structure) (versions master = 8.0, 7.1, and 7.0) * tomee examples (script to copy/rename to antora structure for appropriate language) (version master = 8.0 only) * tomee-site-generator (converted to adoc and moved to antora structure) (currently labeled version 0.1) * tomee-site (converted to adoc and moved to antora structure) (currently labeled version 0.0) Comparing the live site-map.xml and the ones generated for the Antora-built site, there is one file missing (index-old.html http://tomee.apache.org/examples/index-old.html) which I don’t think is necessary or appropriate to move, and 119 new files that didn’t appear in the existing site. They are listed in tomee@antora docs/new-not-old-index.txt. The old-new diffs are only whether some version of the file stem appears in each site, I haven’t tried to figure out how to compare which versions each page appears in. So far I’ve made no attempt to incorporate javadoc. If you are not quite familiar with Antora structure looking at the preview at https://tomee-preview.s3-us-west-2.amazonaws.com/index.html <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html> will probably help understand the questions. In particular in the lower left corner there’s the “component drawer” where you can select the component and version to view. Questions: * How should the content be arranged into components and versions? ** current state: *** There are two components, tomee and examples. *** The tomee component has versions 8.0, 7.1, and 7.0 (from tomee/docs) and 0.1 (from tomee-site-generator) and 0.0 (tomee-site) *** The examples component has versions 8.0-en, 8.0-sp, 8.0-pt for the different languages ** Sub-questions: *** Is all of the content I’ve put under tomee actually version specific, or is there some content that is conceptually unversioned (general information about tomee, perhaps). This could be separated into a separate unversioned component. *** Is some or all of the content I’ve put in 0.1 and 0.0 actually associated with a real version such as 1.7 or OpenEJB v??? *** Is there a need to maintain earlier versions of the examples documentation, or is just “current” enough? It looks like there are earlier examples directories in the 7.1.x and 7.0.x branches, and it would certainly be possible to convert them and include them in the site, but I think that might make the site harder to use and less informative. * How should the content with a version be organized on the source tree and in the navigation? The source-tree questions certainly don’t need immediate answers. ** Source tree: Antora source structure is modules//pages/. The ‘default’ module name is ‘ROOT’, which is what I’ve used. Antora can deal directly with content in subfolders of ‘pages’ (some of which has appeared reflecting the original arrangement) and additional modules (useful to keep each module a manageable size). *** To what extent would it be useful to break the content up into modules? *** The examples are grouped in the navigation but are flat in the file system. Would it be appropriate to reflect the doc grouping in the file system layout? ** Navigation current state: *** The 8.0, 7.1, and 7.0 tomee versions have navigation adapted from documentation.adoc This seems more or less reasonable for now. *** The 0.1 and 0.0 tomee versions have navigation generated by just listing all the pages. *** The examples have navigation adapted from the existing examples navigation. ** Sub-questions: *** How should the 0.1 and 0.0 be organized? Is there an existing page that is a starting point, as documentation.adoc is for more current content? *** What other changes or refinements are appropriate? ** Other: *** can the conglomerated javadoc be generated by maven rather than the custom script now used? Starting with a javadoc jar seems simpler than building it as part of the site generation. = Where is it? preview: https://tomee-preview.s3-us-west-2.amazonaws.com/index.html <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html> git repos: tomee <https://github.com/djencks/tomee> (antora, antora-tomee-7.1.x, antora-tomee-7.0.x) Some instructions are in docs/INSTRUCTIONS.adoc tomee-site-generator <https://github.com/djencks/tomee-site-generator> (antora) tomee-site <https://github.com/djencks/tomee-site> (antora) Thanks! David Jencks > On Feb 8, 2020, at 10:32 PM, David Jencks wrote: > > I now have the adoc content from master, 7.1.0.x, 7.0.0.x, the example > README.adoc from master (sorted by language), and the formerly .md files from > tomee-site-generator. > >
Re: Documentation site
http://tomee.apache.org/download/openejb-3.1.1.html openejb-3.1.2.htmlhttp://tomee.apache.org/download/openejb-3.1.2.html openejb-3.1.htmlhttp://tomee.apache.org/download/openejb-3.1.html project_info.htmlhttp://tomee.apache.org/index.page/project_info.html simple-stateful-example.html http://tomee.apache.org/simple-stateful-example.html simple-stateless-example.html http://tomee.apache.org/simple-stateless-example.html singleton-example.htmlhttp://tomee.apache.org/singleton-example.html testcase-with-testbean-inner-class.html http://tomee.apache.org/testcase-with-testbean-inner-class.html testing-security-example.html http://tomee.apache.org/testing-security-example.html testing-transactions-example.html http://tomee.apache.org/testing-transactions-example.html tomee-1.5.3-snapshot.html http://tomee.apache.org/download/tomee-1.5.3-snapshot.html tomee-1.6.0-snapshot.html http://tomee.apache.org/download/tomee-1.6.0-snapshot.html tomee-1.7.x-snapshot.html http://tomee.apache.org/download/tomee-1.7.x-snapshot.html tomee-7.0.0-snapshot.html http://tomee.apache.org/download/tomee-7.0.0-snapshot.html whoweare.htmlhttp://tomee.apache.org/misc/whoweare.html I looked in tomee-site-generator master, tomee-master, tomee-7.1.0.x, tomee-7.0.0.x, tomee-1.7.x, and something that might be tomee-1.6.0 although it says it’s a detached head (see other email tonight). I looked for any file with the stem of the html files. Thanks, David Jencks > On Feb 7, 2020, at 11:39 PM, David Jencks wrote: > > > >> On Feb 7, 2020, at 3:50 PM, David Blevins wrote: >> >>> On Feb 7, 2020, at 2:47 PM, David Jencks wrote: >>> >>> That’s great info and good points! >>> >>> To build a site with Antora you basically need to be able to write a little >>> yaml :-) >> >> Famous last words :) > > Indeed! > > >> >>> Lets see how far I get with a bit of effort. Is there a way to find all >>> the source for the live CMS (and nothing that’s been replaced)? > > Perhaps there are better tools now…. I ran kramdown-asciidoc on the .md files > in tomee-site-generator, moved them into antora structure, came up with a nav > file that just lists them alphabetically, and now they are another component > in the preview. They still need a little sed-based TLC and perhaps even > human editing, but they mostly look OK (with a few problems). > > Several pages look like someone had a great idea and stopped after writing > the title… e.g. azure.adoc. I’m not sure what to do with those. > > I haven’t identified the existing navigation to these pages, and I don’t > understand yet how it relates to the already-adoc content. > > I think my next steps are to clean up the adoc and start to understand the > desired organization. > > In terms of organization, the existing docs look like there are versions for > each 7+ tomee version but I’ve only found the git master branch with I > presume the latest. > > Anyway, the preview now shows a little bit how Antora can show different > versions, although in this case I’m abusing the feature because the content > is completely different. > > Hints welcome! > > David Jencks > >> >> This is now the bulk of what would have to be replaced: >> >> - https://github.com/apache/tomee-site-generator >> >> The main entry point is here: >> >> - >> https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/JBake.java#L32 >> >> The main exit point and integration with the CMS is here: >> >> - >> https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/SvnPub.java#L87 >> >> That will generate HTML and put it here. >> >> - https://svn.apache.org/repos/asf/tomee/site/trunk/content/ >> >> However, everything that says '.mdtext' is rendered by the CMS and shows up >> on the internet using our old black and white Twitter bootstrap look and >> feel. This happens when you go to here and click publish: >> >> - https://cms.apache.org/tomee/publish >> >> Once that is done there is html generated and sitting an an svn repository >> somewhere (I can't remember where). >> >> Apache will publish sites from git. Ultimately, we need to get to a place >> where we're doing either Jbake->HTML->Git or Antora->HTML->Git. No SVN or >> CMS. >> >> Almost all of the '.mdtext' files have been committed here: >> >> - >> https://github.com/apache/tomee-site-generator/tree/master/src/main/
1.6.0 might be in a bad state
While searching for some website content I can’t find I checked out tomee-1.6.0 and got this message: MacBook-Pro-2:tomee david$ git checkout tomee-1.6.0 Checking out files: 100% (5347/5347), done. Note: checking out 'tomee-1.6.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 556ccad21d [release-tools] creating tag for tomee-1.6.0 I’m not sure exactly what it means, but if someone does and knows how to fix it, great! David Jencks
Re: Documentation site
Hi Guillermo, I’m not yet at the point of thinking about css or even UI changes. If you want to you and you aren’t already familiar with Antora UI bundles you could take a look. I think the I18n Asciidoc proposal would be too inconvenient for Tomee…. my experience with related systems was pretty horrible. As I understand, Tomee has the (normally english) original adoc file in the same directory as any contributed translations. I think this is going to continue to work well, as it’s really easy to understand what to do…. just take the adoc file and translate it, keeping the structure if appropriate. I suppose it might be possible to, for each untranslated page and each language, generate a page saying “translate me” and perhaps with a google-translate rendition. That seems a bit in the future though. I was just thinking about the problems of how to organize and present the translations in Antora. Thanks! David Jencks > On Feb 7, 2020, at 11:16 AM, Guillermo García wrote: > > On Thu, Feb 6, 2020 at 11:14 PM David Jencks > wrote: >> >> After building myself a couple of tiny websites using Antora ( > https://antora.org) I’ve become somewhat interested in site generation from > asciidoc >> Does this seem like a direction worth pursuing? I’m willing to spend a > few days organizing stuff better, fixing the warnings and errors, and > sprucing up the UI (I can change colors and remove the irrelevant stuff > from the header, but advanced css is beyond me at this point). > > Hi David, > > It's a great approach. Count with me in CSS related changes. Just create > the corresponding JIRA ticket and assign it to my JIRA user: bitcoder. > >> There are also a couple of directions of experimentation I might like to > pursue: >> >> — Antora doesn’t have a good strategy for multi-language sites. Since > there’s at least some translation going on here, this seems like a good > place to try out solutions. I haven’t found the translations yet :-) > Provisionally my first idea would be to represent languages as versions: > 8.0 is english, 8.0-sp, 8.0-pt, 8.0-ru etc are the other languages. You > could pick your language in the lower left component-version selector (on > the preview only tomee/8.0 is present) > > > Not sure how i18n is being provided for TomEE documentation. We could find > a way to track which parts of a translation need to be updated when the > source document changes by using a localization management tool, like the > po4a [1] perl module. > > Besides, there's some interesting proposal [2] to use localization in the > AsciiDoc project coming in next releases. > >> >> ... >> >> thanks >> David Jencks >> >> ps. My google search for the docs brought up this: >> >> https://tomee.apache.org/latest/docs/documentation.html >> >> which doesn’t look good. >> > > It was my first impression too when I was reached the TomEE documentation. > I already fixed some weird characters for the documentation.adoc in > TOMEE-2767 [3], I am just waiting for changes to be deployed. > > -- > Guillermo Garcia > > > [1] https://github.com/mquinson/po4a > [2] https://github.com/asciidoctor/asciidoctor/wiki/Design-Doc:-i18n > [3] https://issues.apache.org/jira/browse/TOMEE-2767
Re: Documentation site
> On Feb 7, 2020, at 3:50 PM, David Blevins wrote: > >> On Feb 7, 2020, at 2:47 PM, David Jencks wrote: >> >> That’s great info and good points! >> >> To build a site with Antora you basically need to be able to write a little >> yaml :-) > > Famous last words :) Indeed! > >> Lets see how far I get with a bit of effort. Is there a way to find all the >> source for the live CMS (and nothing that’s been replaced)? Perhaps there are better tools now…. I ran kramdown-asciidoc on the .md files in tomee-site-generator, moved them into antora structure, came up with a nav file that just lists them alphabetically, and now they are another component in the preview. They still need a little sed-based TLC and perhaps even human editing, but they mostly look OK (with a few problems). Several pages look like someone had a great idea and stopped after writing the title… e.g. azure.adoc. I’m not sure what to do with those. I haven’t identified the existing navigation to these pages, and I don’t understand yet how it relates to the already-adoc content. I think my next steps are to clean up the adoc and start to understand the desired organization. In terms of organization, the existing docs look like there are versions for each 7+ tomee version but I’ve only found the git master branch with I presume the latest. Anyway, the preview now shows a little bit how Antora can show different versions, although in this case I’m abusing the feature because the content is completely different. Hints welcome! David Jencks > > This is now the bulk of what would have to be replaced: > > - https://github.com/apache/tomee-site-generator > > The main entry point is here: > > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/JBake.java#L32 > > The main exit point and integration with the CMS is here: > > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/SvnPub.java#L87 > > That will generate HTML and put it here. > > - https://svn.apache.org/repos/asf/tomee/site/trunk/content/ > > However, everything that says '.mdtext' is rendered by the CMS and shows up > on the internet using our old black and white Twitter bootstrap look and > feel. This happens when you go to here and click publish: > > - https://cms.apache.org/tomee/publish > > Once that is done there is html generated and sitting an an svn repository > somewhere (I can't remember where). > > Apache will publish sites from git. Ultimately, we need to get to a place > where we're doing either Jbake->HTML->Git or Antora->HTML->Git. No SVN or > CMS. > > Almost all of the '.mdtext' files have been committed here: > > - > https://github.com/apache/tomee-site-generator/tree/master/src/main/jbake/content > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/comparison.md > > That page doesn't render by JBake as it's missing the appropriate JBake > header, so this CMS page still lives: > > - https://svn.apache.org/repos/asf/tomee/site/trunk/content/comparison.mdtext > > Among the complexities is the fact that we're pulling documentation from a > few repositories: > > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Configuration.java#L20 > > We collapse all the source code down to one directory so we can generate one > big javadoc tree: > > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Javadocs.java#L54 > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Javadocs.java#L144 > > There's code to attempt to get a list of contributors, including their > pictures: > > - > https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Contributors.java#L47 > - http://tomee.apache.org/community/contributors.html > > That code really needs to be replaced with something that pulls that data > from Github because the list of contributors is way way higher: > > - https://github.com/apache/tomee/graphs/contributors > > > Anyway, at least some pointers. > > Not entirely sure I answered the question. > > > -David >
Re: Documentation site
That’s great info and good points! To build a site with Antora you basically need to be able to write a little yaml :-) Lets see how far I get with a bit of effort. Is there a way to find all the source for the live CMS (and nothing that’s been replaced)? Thanks, David Jencks > On Feb 7, 2020, at 2:34 PM, David Blevins wrote: > > Here's the status of the site in general. > > The original site was written using the Apache CMS (2011). Several > extensions were made to it to get functionality it didn't have. The CMS and > the extensions were written in Perl which nobody knows. Much of the > extensions were around our examples. Others were to hint css so some pages > could leverage twitter bootstrap capabilities. I knew enough to write the > extensions, but eventually I became too busy and that left nobody knowing how > it all works. > > Work on a new site started using JBake (Dec 2016, early 2017). Some custom > code was written to replace features of the CMS and extensions. The site > went live with around 30% of the content migrated and the rest left as-is, > still live and online being served by the CMS. The justification being it > was all old content anyway and not worth migrating. It was not deleted > either. That left us with two live sites indexed by Google and confused > users who couldn't really understand what was current and what was not and > why some pages looked different than others. The momentum behind the new > site stopped, considering the job done. > > Work restarted on the JBake setup (Dec 2018, early 2019) to try and eliminate > the CMS further, fix issues with the site, add versioning of content, add > support for new languages and publish the Javadoc. We overall went from 30% > JBake and 70% CMS to 90% Jbake and 10% CMS. Some of the CMS content, > however, still needs significant love. We still have CMS pages indexed on > Google that need to be replaced. > > So our overall status is we still have live CMS content. Here's one example: > > - http://tomee.apache.org/comparison.html > > We have some pages that use CMS formatting and therefore don't render and > need to be manually addressed: > > - https://tomee.apache.org/latest/docs/documentation.html > > > > My personal perspective is that anything is a good idea as long as there's a > person there to make it real. It doesn't matter what technology we use to > build the site as much as it matters that there's a person there willing to > do the work till it's 100% done. > > If someone wants to add a third site building framework on top of the other > two, leaving or losing interest before 100% of all content completely > converted over. I would probably not be a fan. > > If someone wants to completely transition us onto one single system including > all content, without exception, leaving no trace of any past site building > tech. Sounds good. > > Using something non-Java does eliminate most people's ability to help which > is what killed the CMS. I have looked at Antora and its features are great > and so is Dan. But not being written in Java made it just out of reach for > me and I know I would not be able to help at all. > > I definitely would not support going live on a third website-building setup > with the other two in any way still serving content. Our well-intentioned > plans to finish the transitions later have never worked out in practice. > > I definitely would *love* to have one fabulous David Jencks active on the > project, so despite our past failures I'd support the attempt because getting > you active on the project is way bigger than any website. If this is what > you're passionate about, then giddy-up. :) > > > -- > David Blevins > http://twitter.com/dblevins > http://www.tomitribe.com > >> On Feb 6, 2020, at 8:14 PM, David Jencks wrote: >> >> After building myself a couple of tiny websites using Antora >> (https://antora.org) I’ve become somewhat interested in site generation from >> asciidoc. >> >> I looked at the current TomEE documentation site and am not entirely >> thrilled with the appearance. >> >> I spent a couple of hours finding things, arranging the docs into an antora >> structure, and setting up some configuration. >> >> You can see the results here: >> >> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html >> <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html> >> >> The source for this is at https://github.com/djencks/tomee, antora branch. >> >> This makes no attempt to be a reasonable structure: I just found >> documentation.adoc, converte
Re: Documentation site
Thanks for the pointers! David > On Feb 7, 2020, at 1:26 AM, Daniel Dias Dos Santos > wrote: > > Hello David, > > fantastic your experiment. : ) > > the translation are in the examples folder: > > https://github.com/apache/tomee/tree/master/examples > > and about the site of documentation is in address : > > https://tomee.apache.org/docs.html > > : ) > -- > > *Daniel Dias dos Santos* > Java Developer > SouJava & JCP Member > GitHub: https://github.com/Daniel-Dos > Linkedin: www.linkedin.com/in/danieldiasjava > Twitter: http://twitter.com/danieldiasjava > > > Em sex., 7 de fev. de 2020 às 01:14, David Jencks > escreveu: > >> After building myself a couple of tiny websites using Antora ( >> https://antora.org) I’ve become somewhat interested in site generation >> from asciidoc. >> >> I looked at the current TomEE documentation site and am not entirely >> thrilled with the appearance. >> >> I spent a couple of hours finding things, arranging the docs into an >> antora structure, and setting up some configuration. >> >> You can see the results here: >> >> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html < >> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html> >> >> The source for this is at https://github.com/djencks/tomee, antora branch. >> >> This makes no attempt to be a reasonable structure: I just found >> documentation.adoc, converted it to an Antora nav file, and picked >> docs.adoc for the home page. >> >> Does this seem like a direction worth pursuing? I’m willing to spend a >> few days organizing stuff better, fixing the warnings and errors, and >> sprucing up the UI (I can change colors and remove the irrelevant stuff >> from the header, but advanced css is beyond me at this point). >> >> There are also a couple of directions of experimentation I might like to >> pursue: >> >> — Antora doesn’t have a good strategy for multi-language sites. Since >> there’s at least some translation going on here, this seems like a good >> place to try out solutions. I haven’t found the translations yet :-) >> Provisionally my first idea would be to represent languages as versions: >> 8.0 is english, 8.0-sp, 8.0-pt, 8.0-ru etc are the other languages. You >> could pick your language in the lower left component-version selector (on >> the preview only tomee/8.0 is present) >> >> - I think there might be some javadoc somewhere :-) Antora also doesn’t >> have a good strategy for including externally generated content. I have an >> idea around this that just might work :-) >> >> On my GitHub clone I only see a master branch, which I assume is the tomee >> 8 line. Where are the earlier versions? Where is their documentation? >> Antora is really good at building sites with many versions of the docs (as >> long as the source is in asciidoc). >> >> thanks >> David Jencks >> >> ps. My google search for the docs brought up this: >> >> https://tomee.apache.org/latest/docs/documentation.html >> >> which doesn’t look good. >> >> >>
Documentation site
After building myself a couple of tiny websites using Antora (https://antora.org) I’ve become somewhat interested in site generation from asciidoc. I looked at the current TomEE documentation site and am not entirely thrilled with the appearance. I spent a couple of hours finding things, arranging the docs into an antora structure, and setting up some configuration. You can see the results here: https://tomee-preview.s3-us-west-2.amazonaws.com/index.html <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html> The source for this is at https://github.com/djencks/tomee, antora branch. This makes no attempt to be a reasonable structure: I just found documentation.adoc, converted it to an Antora nav file, and picked docs.adoc for the home page. Does this seem like a direction worth pursuing? I’m willing to spend a few days organizing stuff better, fixing the warnings and errors, and sprucing up the UI (I can change colors and remove the irrelevant stuff from the header, but advanced css is beyond me at this point). There are also a couple of directions of experimentation I might like to pursue: — Antora doesn’t have a good strategy for multi-language sites. Since there’s at least some translation going on here, this seems like a good place to try out solutions. I haven’t found the translations yet :-) Provisionally my first idea would be to represent languages as versions: 8.0 is english, 8.0-sp, 8.0-pt, 8.0-ru etc are the other languages. You could pick your language in the lower left component-version selector (on the preview only tomee/8.0 is present) - I think there might be some javadoc somewhere :-) Antora also doesn’t have a good strategy for including externally generated content. I have an idea around this that just might work :-) On my GitHub clone I only see a master branch, which I assume is the tomee 8 line. Where are the earlier versions? Where is their documentation? Antora is really good at building sites with many versions of the docs (as long as the source is in asciidoc). thanks David Jencks ps. My google search for the docs brought up this: https://tomee.apache.org/latest/docs/documentation.html which doesn’t look good.
Re: 7.1.x and 7.0.x releases
Could you explain this scenario further? Are there multiple activemq managed connections to different brokers but associated with the same connection handle? Or one managed connection associated with more than one “physical” connection? I’d expect that transaction caching in the pooling would result in all connection handles being associated with one managed connection in one transaction. Thanks David Jencks Sent from my iPhone > On Sep 30, 2019, at 10:10 AM, Jonathan S. Fisher wrote: > > It was 5.15.9 that was causing problems with the failover transport (Which > is a best practice to use). Essentially you memory leak when two or more > physical activemq connections get involved in an XA transaction > > On Fri, Sep 27, 2019 at 3:55 AM Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > >> I'm not against updating ActiveMQ on 7.0.x, but I suspect that might mean >> we lose compatibility with Java 7. I forget which version Jonathan (Fisher) >> is running, but I suspect that's not an issue for him. >> >> I'll take a look at the versions, and start a thread so the community can >> decide what to do. >> >> Jon >> >> On Fri, Sep 27, 2019 at 9:39 AM Zowalla, Richard < >> richard.zowa...@hs-heilbronn.de> wrote: >> >>> Hi Jonathan, >>> >>> current 7.1.1-SNAPSHOT branch is on ActiveMQ 5.15.10 >>> >>> This update was conducted due to several CVE's related to its transient >>> jackson-databind dependency. >>> >>> But, if I am right, you are still on 7.0.x - which has not been updated >>> yet :) >>> >>> Best, >>> Richard >>> >>> Am Dienstag, den 24.09.2019, 10:57 -0500 schrieb Jonathan S. Fisher: >>> >>> So I've got a test case, but it will likely just be isolated to us. We were >>> >>> upgrading the ActiveMQ RAR to 5.15.9 to enable strict host checking on TLS >>> >>> certificates. If we keep the stock ActiveMQ rar/jar we don't see the >>> >>> problem. >>> >>> >>> So I guess take note of that if someone ever asks for an upgrade, the >>> >>> failover protocol will collapse a 32m JVM after about 10k messages. >>> >>> >>> On Mon, Sep 23, 2019 at 5:20 PM Jean-Louis Monteiro < >>> >>> jlmonte...@tomitribe.com> wrote: >>> >>> >>> I have opened this ticket and pushed a fix on both Java EE 7 and 8 API jar. >>> >>> New snapshot deployed. >>> >>> >>> I'm waiting for the full build on master to pass and then I'll close the >>> >>> ticket and fire up the 2 releases so you can move on with TomEE >>> >>> >>> -- >>> >>> Jean-Louis Monteiro >>> >>> http://twitter.com/jlouismonteiro >>> >>> http://www.tomitribe.com >>> >>> >>> >>> On Mon, Sep 23, 2019 at 3:03 PM Jonathan Gallimore < >>> >>> jonathan.gallim...@gmail.com> wrote: >>> >>> >>> Oh wow, that would be amazing! >>> >>> >>> On Mon, Sep 23, 2019 at 10:49 PM Jonathan S. Fisher >>> >>> wrote: >>> >>> >>> I'll get a reproducer project put together that demos the bug. >>> >>> >>> On Mon, Sep 23, 2019 at 4:32 PM Jonathan Gallimore < >>> >>> jonathan.gallim...@gmail.com> wrote: >>> >>> >>> If we can come up with some good tests for it, I don't see why not. >>> >>> >>> Jon >>> >>> >>> On Mon, Sep 23, 2019 at 10:25 PM Jonathan S. Fisher < >>> >>> exabr...@gmail.com> >>> >>> wrote: >>> >>> >>> We've been running 7.0.x latest in prod for a few weeks with no >>> >>> issues >>> >>> other than the ActiveMQ Failover protocol memory leak issue (which >>> >>> affects >>> >>> all versions of TomEE). >>> >>> https://issues.apache.org/jira/browse/AMQ-6391 This is an issue >>> >>> now >>> >>> because >>> >>> our JMS Context / Connection Factories will actually be >>> >>> transactional >>> >>> >>> Should/Could we patch the ActiveMQ jar? >>> >>> >>> >>> >>> On Mon, Sep 23, 2019 at 3:24 PM Jean-Louis Monteiro
Re: [VOTE] Release Apache TomEE 8.0.0 (take 1)
I haven’t tried anything like this in years, but I think there’s a maven dependency plugin command that produces a graph; grepping this for the problem child may show all the paths to it. Hope this might help... David Jencks Sent from my iPhone > On Sep 12, 2019, at 4:07 PM, Jonathan Gallimore > wrote: > > That's a good suggestion, thank you. Must admit, I'm surprised. I thought > the whole bom thing was meant to make this easier. I must be missing > something. > > Jon > > On Fri, Sep 13, 2019 at 12:00 AM David Blevins > wrote: > >> If you find it too difficult a plan b could be to hack the Setup (or >> whatever it’s called) java code that turns the war files into the assembly. >> >> I.e. add a line to delete it. >> >> On Thu, Sep 12, 2019 at 3:46 PM Jonathan Gallimore < >> jonathan.gallim...@gmail.com> wrote: >> >>> If anyone knows how to exclude jakarta.activation-api in the new bom >>> module, I'd sure appreciate the help. I'd expect >>> >>> >>>jakarta.activation >>>jakarta.activation-api >>> >>> >>> to work, but it seems like no matter where I exclude it, it keeps popping >>> up. >>> >>> Jon >>> >>> On Thu, Sep 12, 2019 at 10:03 PM Jonathan Gallimore < >>> jonathan.gallim...@gmail.com> wrote: >>> >>>> Awesome, thanks for the detail. I'm working on the PR now. I post >> updates >>>> here as I have them. Intention is to have take 2 rolled by the end of >> the >>>> evening. >>>> >>>> Have a safe flight! >>>> >>>> Jon >>>> >>>> On Thu, Sep 12, 2019 at 9:55 PM David Blevins >>>> wrote: >>>> >>>>> Plane, but planet works too — although a slight exaggeration :) >>>>> >>>>> On Thu, Sep 12, 2019 at 1:53 PM David Blevins >> >>>>> wrote: >>>>> >>>>>> Had a longer response but the planet started boarding and now I have >>> to >>>>>> start again on cell :) >>>>>> >>>>>> Agree with all your removals. Note on Jakarta activation 1.2, we’ll >>>>> want >>>>>> to eventually switch to Geronimo Activation 1.2 when we get that >>> ready. >>>>>> >>>>>> We need to update the LICENSE and NOTICE files of each dust to add >> the >>>>> EPL >>>>>> v2. When I looked at this a few days ago, I also noticed only some >> of >>>>> them >>>>>> had the EPL v1, so that should get fixed as well; all our dists have >>> the >>>>>> ecj jar so need the EPL v1. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Sep 12, 2019 at 1:38 PM Jonathan Gallimore < >>>>>> jonathan.gallim...@gmail.com> wrote: >>>>>> >>>>>>> Here's the same analysis on TomEE 7.0.6: >>>>>>> >>>>>>> javax.activation: >>>>>>> - lib/activation-1.1.jar >>>>>>> - lib/javaee-api-7.0-1.jar >>>>>>> >>>>>>> javax.xml.stream: >>>>>>> - lib/stax-api-1.0-2.jar >>>>>>> - lib/javaee-api-7.0-1.jar >>>>>>> >>>>>>> javax/xml/ws/EndpointReference.class, >>>>> javax/xml/ws/WebServiceFeature.class >>>>>>> and javax/xml/ws/wsaddressing/W3CEndpointReference.class: >>>>>>> - lib/openejb-client-7.0.6.jar >>>>>>> - lib/javaee-api-7.0-1.jar >>>>>>> >>>>>>> So I think removing the following is the way to go: >>>>>>> >>>>>>> geronimo-activation_1.1_spec-1.1.jar (covered by >>>>>>> jakarta.activation-1.2.1.jar) >>>>>>> jakarta.activation-api-1.2.1.jar (covered by >>>>>>> jakarta.activation-1.2.1.jar) >>>>>>> geronimo-interceptor_1.2_spec-1.0.jar (covered by >>> javaee-api-8.0-2.jar) >>>>>>> geronimo-javamail_1.4_spec-1.7.1.jar (covered by >>>>>>> geronimo-javamail_1.4_mail-1.9.0-alpha-2.jar) >>>>>>> geronimo-jpa_2.2_spec-1.0.jar (covered by javaee-api-8.0-2.jar) >>>>>>> jakarta.xml.soap-api-1.4.1.jar (covered by javaee-api-8.0-2.jar) >>>>>>> >>>>>>> I'll get started, but please do shout if that looks wrong. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On Thu, Sep 12, 2019 at 9:19 PM David Blevins < >>> david.blev...@gmail.com >>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>>> On Sep 12, 2019, at 1:03 PM, Jonathan Gallimore < >>>>>>>> jonathan.gallim...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Also, I'll take a look at openejb-client, but I'm not too sure >>>>> what do >>>>>>>> with >>>>>>>>> this conflict: >>>>>>>>> >>>>>>>>> javax/xml/ws/EndpointReference.class, >>>>>>>> javax/xml/ws/WebServiceFeature.class >>>>>>>>> and javax/xml/ws/wsaddressing/W3CEndpointReference.class: >>>>>>>>> >>>>>>>>> - javaee-api-8.0-2.jar >>>>>>>>> - openejb-client-8.0.0.jar >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> Only suspecting it might have already been there in a past >> release. >>>>>>>> >>>>>>>> If that's the case, IMO, any conflicts that were there in 7.x, we >>>>> ignore >>>>>>>> for now. So if this one is status quo, it's fine. >>>>>>>> >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Sent from Gmail Mobile >>>>>> >>>>> -- >>>>> Sent from Gmail Mobile >>>>> >>>> >>> >> -- >> Sent from Gmail Mobile >>
Re: svn commit: r1866736 - in /tomee/site/trunk/content/tomee-8.0/docs: TCK/ TCK/jakarta-annotations.html index.html
copyright year? David Jencks > On Sep 10, 2019, at 3:58 AM, jgallim...@apache.org wrote: > > + Copyright 1999-2016 The > Apache Software Foundation, Licensed under the Apache License, Version 2.0. > Apache
Re: New committer Cesar Hernandez
Well deserved indeed! I don’t think I’ve ever seen anyone as active helping others in a project! I’ve been extremely impressed for a long time! David Jencks > On Sep 5, 2019, at 5:25 PM, David Blevins wrote: > > Congratulations, Cesar!! Well deserved. > > You set an excellent example helping so many people become contributors. A > simple "good job" doesn't cut it. > >> On Sep 5, 2019, at 12:53 AM, Jean-Louis Monteiro >> wrote: >> >> When I started 10 years ago, a good friend of mine told me that in open >> source projects, it's 50% contributor's responsibility to do well, and 50% >> our responsibility committers and PMC to make sure they can. > > :) > >> I must say Cesar over performed in this area. > > Completely agree. > > Cesar, if we had 4 more of you, there'd be 150+ people as contributors in our > github stats. Beyond numbers, you need to understand the impact you have on > people's lives. Hopefully they'll be as kind as Jean-Louis to quote you some > day :) > > Your announcement email is 14 people long and it's not even been 24 hours. > That's more than most votes for TomEE release! > > I love the example you set helping others into this project. Everyone needs > to understand and respect, you were never asked or trained to do it and you > didn't get any special permission. You just did it. Everyone should be as > brave and jump in, come what may. > > Few people learn more as those who help others. Be generous with your time > to others and you'll be rewarded with both knowledge and a friend. > > Keep up the great work enabling others and let's make more of these > announcements :) > > > -David > >
Re: JTA JMS Spec question, connection leakage
Thanks for the explanation; I think your change should be good for everyone, not just amq. Iirc it used to be common (very bad) practice to get a connection handle and cache it in a non Singleton session bean and expect the connection infrastructure to associate it to whatever managed connection was associated to the current transaction. If that worked this certainly ought to! Thanks David Jencks Sent from my iPhone > On Sep 3, 2019, at 6:43 PM, Jonathan S. Fisher wrote: > > Ahhh... The CDI spec for JMSContext says it's either scoped to either the > current RequestScope, or in our case TransactionScope. I'll take an > educated guess and bet TransactionScoped beans are destroyed using a > [Transaction] Synchronization's afterCompletion() call. When the > TransactionScope is destroyed is when the JMSContext is destroyed, and it's > at that point it closes the connection. I'm guessing AutoConnectionTracker > was probably written before this was possible, so users were calling > connection.close() ergo handleClosed() before beforeCompletion(). Now the > CDI Extension for JMS2.0 in TomEE is calling close() much later. > > My PR moves what was in beforeCompletion() into afterCompletion(). For > ActiveMQ I'm fairly certain this won't be an issue, as they allow you to > really abuse when you open connections and even how man sessions per > connection you open :) > > On Tue, Sep 3, 2019 at 7:50 PM David Jencks > wrote: > >> Well, beforeCompletion() is called as a result of commit() being called on >> the transaction, presumably by an EJB “interceptor”, and handleClosed() is >> called as a result of the “user level” connection being closed. I’m used to >> the latter being called by user code... perhaps with all the CDI and >> dependency injection I haven’t kept up with this is no longer the case? >> >> Thanks. >> David Jencks >> Sent from my iPhone >> >>> On Sep 3, 2019, at 3:25 PM, Jonathan S. Fisher >> wrote: >>> >>> Honestly I have no idea. And the interface specification is silent >>> unfortunately: >>> >> https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTracker.java >>> >>> On Tue, Sep 3, 2019 at 3:32 PM David Jencks >>> wrote: >>> >>>> You might have already explained this, but… why is beforeCompletion() >>>> called before handleReleased()? If that’s happening, I’d expect >> something >>>> is wrong. However, I haven’t looked at this code in years. >>>> >>>> thanks! >>>> David Jencks >>>> >>>>> On Sep 3, 2019, at 12:27 PM, Jonathan S. Fisher >>>> wrote: >>>>> >>>>> Two more updates: >>>>> >>>>> For the log message, it looks like beforeCompletion() Is being called >>>>> before handleReleased(), leading to that warning. I ran a couple >> thousand >>>>> messages through and took a heap dump and didn't get any leak suspects, >>>> so >>>>> I think it's working correctly despite the warning. I'll add that to my >>>>> existing PR with your tests. >>>>> >>>>> Second, on my 10K messages test, it looks like it might be Arquillian >>>>> crashing, not TomEE. I'm going to try the same test but without >>>> Arquillian, >>>>> just deploy those classes to a server and see what happens. >>>>> >>>>> On Tue, Sep 3, 2019 at 10:54 AM Jonathan S. Fisher >> >>>>> wrote: >>>>> >>>>>> If I bump the number of messages up to 10k or so I get a VM Crash... I >>>>>> cannot figure out how to get arquillian to give me a heap dump on exit >>>>>> though. >>>>>> >>>>>> On Tue, Sep 3, 2019 at 10:01 AM Jonathan S. Fisher < >> exabr...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> https://github.com/apache/tomee/pull/546/files >>>>>>> >>>>>>> This passes consistently for me with no issues >>>>>>> >>>>>>> On Tue, Sep 3, 2019 at 9:08 AM Jonathan S. Fisher < >> exabr...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> There are actually a few log messages we regularly ignore all the >> time >>>>>>>> from the transaction manager ::wince face:: I'm not sure if we >> shou
Re: JTA JMS Spec question, connection leakage
Well, beforeCompletion() is called as a result of commit() being called on the transaction, presumably by an EJB “interceptor”, and handleClosed() is called as a result of the “user level” connection being closed. I’m used to the latter being called by user code... perhaps with all the CDI and dependency injection I haven’t kept up with this is no longer the case? Thanks. David Jencks Sent from my iPhone > On Sep 3, 2019, at 3:25 PM, Jonathan S. Fisher wrote: > > Honestly I have no idea. And the interface specification is silent > unfortunately: > https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-connector/src/main/java/org/apache/geronimo/connector/outbound/connectiontracking/ConnectionTracker.java > > On Tue, Sep 3, 2019 at 3:32 PM David Jencks > wrote: > >> You might have already explained this, but… why is beforeCompletion() >> called before handleReleased()? If that’s happening, I’d expect something >> is wrong. However, I haven’t looked at this code in years. >> >> thanks! >> David Jencks >> >>> On Sep 3, 2019, at 12:27 PM, Jonathan S. Fisher >> wrote: >>> >>> Two more updates: >>> >>> For the log message, it looks like beforeCompletion() Is being called >>> before handleReleased(), leading to that warning. I ran a couple thousand >>> messages through and took a heap dump and didn't get any leak suspects, >> so >>> I think it's working correctly despite the warning. I'll add that to my >>> existing PR with your tests. >>> >>> Second, on my 10K messages test, it looks like it might be Arquillian >>> crashing, not TomEE. I'm going to try the same test but without >> Arquillian, >>> just deploy those classes to a server and see what happens. >>> >>> On Tue, Sep 3, 2019 at 10:54 AM Jonathan S. Fisher >>> wrote: >>> >>>> If I bump the number of messages up to 10k or so I get a VM Crash... I >>>> cannot figure out how to get arquillian to give me a heap dump on exit >>>> though. >>>> >>>> On Tue, Sep 3, 2019 at 10:01 AM Jonathan S. Fisher >>>> wrote: >>>> >>>>> https://github.com/apache/tomee/pull/546/files >>>>> >>>>> This passes consistently for me with no issues >>>>> >>>>> On Tue, Sep 3, 2019 at 9:08 AM Jonathan S. Fisher >>>>> wrote: >>>>> >>>>>> There are actually a few log messages we regularly ignore all the time >>>>>> from the transaction manager ::wince face:: I'm not sure if we should >> be >>>>>> concerned with that one. >>>>>> >>>>>> On your test, first, how is the broker xml declared? Often something >>>>>> that trips our newbies up to TomEE is having a persistent broker that >> is >>>>>> storing messages between TomEE runs. The tricky thing is that the >> broker >>>>>> store does always appear in /target, so it might not get cleaned up >> with >>>>>> mvn clean install. As such, for local development we use this >>>>>> URL: >> broker:(vm://localhost)?persistent=falsedeleteAllMessagesOnStartup=true. >>>>>> Next, on JMSReceiverBean, you're missing transactionAttribute. >> Technically >>>>>> it should work without it, but I'd add it just in case. Finally, I'd >> add a >>>>>> small thread.sleep, or check to the queue length == 0 before doing >> your >>>>>> assert on messagecounter. It could be you're beating the receiver >> bean to >>>>>> the finish line. The default messaging mode is auto-ack, so >> technically the >>>>>> message just has to be on the broker, it doesn't have to be processed >>>>>> before your sender bean will return. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 2, 2019 at 2:28 PM Jonathan Gallimore < >>>>>> jonathan.gallim...@gmail.com> wrote: >>>>>> >>>>>>> In case it means anything to anyone, the unexpected output I'm >> getting >>>>>>> is >>>>>>> an abandoned connection notification: >>>>>>> >>>>>>> WARNING: Transaction complete, but connection still has handles >>>>>>> associated: >>>>>>> ManagedConnectionInfo: >>>&g
Re: JTA JMS Spec question, connection leakage
You might have already explained this, but… why is beforeCompletion() called
before handleReleased()? If that’s happening, I’d expect something is wrong.
However, I haven’t looked at this code in years.
thanks!
David Jencks
> On Sep 3, 2019, at 12:27 PM, Jonathan S. Fisher wrote:
>
> Two more updates:
>
> For the log message, it looks like beforeCompletion() Is being called
> before handleReleased(), leading to that warning. I ran a couple thousand
> messages through and took a heap dump and didn't get any leak suspects, so
> I think it's working correctly despite the warning. I'll add that to my
> existing PR with your tests.
>
> Second, on my 10K messages test, it looks like it might be Arquillian
> crashing, not TomEE. I'm going to try the same test but without Arquillian,
> just deploy those classes to a server and see what happens.
>
> On Tue, Sep 3, 2019 at 10:54 AM Jonathan S. Fisher
> wrote:
>
>> If I bump the number of messages up to 10k or so I get a VM Crash... I
>> cannot figure out how to get arquillian to give me a heap dump on exit
>> though.
>>
>> On Tue, Sep 3, 2019 at 10:01 AM Jonathan S. Fisher
>> wrote:
>>
>>> https://github.com/apache/tomee/pull/546/files
>>>
>>> This passes consistently for me with no issues
>>>
>>> On Tue, Sep 3, 2019 at 9:08 AM Jonathan S. Fisher
>>> wrote:
>>>
>>>> There are actually a few log messages we regularly ignore all the time
>>>> from the transaction manager ::wince face:: I'm not sure if we should be
>>>> concerned with that one.
>>>>
>>>> On your test, first, how is the broker xml declared? Often something
>>>> that trips our newbies up to TomEE is having a persistent broker that is
>>>> storing messages between TomEE runs. The tricky thing is that the broker
>>>> store does always appear in /target, so it might not get cleaned up with
>>>> mvn clean install. As such, for local development we use this
>>>> URL:
>>>> broker:(vm://localhost)?persistent=falsedeleteAllMessagesOnStartup=true.
>>>> Next, on JMSReceiverBean, you're missing transactionAttribute. Technically
>>>> it should work without it, but I'd add it just in case. Finally, I'd add a
>>>> small thread.sleep, or check to the queue length == 0 before doing your
>>>> assert on messagecounter. It could be you're beating the receiver bean to
>>>> the finish line. The default messaging mode is auto-ack, so technically the
>>>> message just has to be on the broker, it doesn't have to be processed
>>>> before your sender bean will return.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 2, 2019 at 2:28 PM Jonathan Gallimore <
>>>> jonathan.gallim...@gmail.com> wrote:
>>>>
>>>>> In case it means anything to anyone, the unexpected output I'm getting
>>>>> is
>>>>> an abandoned connection notification:
>>>>>
>>>>> WARNING: Transaction complete, but connection still has handles
>>>>> associated:
>>>>> ManagedConnectionInfo:
>>>>> org.apache.geronimo.connector.outbound.ManagedConnectionInfo@5b5a4aed.
>>>>> mc:
>>>>>
>>>>> [org.apache.openejb.resource.activemq.jms2.TomEEManagedConnection@37e69c43
>>>>> ,ActiveMQConnection
>>>>>
>>>>> {id=ID:MacBook-Pro.jlpsoftwareltd.net-50025-1567452049768-7:1,clientId=ID:MacBook-Pro.jlpsoftwareltd.net-50025-1567452049768-6:1,started=false}]]
>>>>> Abandoned connection information:
>>>>> Connection handle opened at
>>>>>
>>>>> org.apache.geronimo.connector.outbound.ConnectionInfo.setTrace(ConnectionInfo.java:119),
>>>>>
>>>>> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:57),
>>>>>
>>>>> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39),
>>>>>
>>>>> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66),
>>>>>
>>>>> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:81),
>>>>>
>>>>> org.apache.activemq.ra.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:94),
>>>>>
>>>>>
Re: JTA JMS Spec question, connection leakage
I checked the Open Liberty TransactionSynchronizationRegistry, and it interprets “active transaction” to mean “any transaction on the thread, no matter it’s state”. So I think that it would be best to decide to do the same in the Geronimo TM, deciding that the java doc is ambiguous as to the meaning of “active” and the most useful meaning can be picked rather than the most literal. Whether this is practical for the next TomEE, I don’t know. David Jencks > On Aug 27, 2019, at 8:25 AM, David Jencks wrote: > > I think the java doc for getResource might have been written thoughtlessly, > and more appropriate behavior would be an ISE only for STATUS_NO_TRANSACTION; > literally the geronimo implementation is too lax, as “marked rollback” is not > status “active”. Is there anyone who’s opinion we might ask? > > I rather thought the “ignore session type” logic was supposed to be put into > the RA, but I don’t recall if or how I dealt with this in Geronimo. > > So I’d prefer these issues be dealt with elsewhere but don’t see much > practical alternative to your implementation. > > Nice to see someone working on XA:-) > > thanks! > David Jencks > >> On Aug 26, 2019, at 1:45 PM, Jonathan S. Fisher wrote: >> >> I've narrowed down the problem to AutoConnectionTracker. It's not >> completing, which isn't allowing the connections to be returned to the pool. >> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/resource/AutoConnectionTracker.java#L174 >> >> getResource() is throwing an IllegalStateException. The JavaDoc ( >> https://docs.oracle.com/javaee/7/api/javax/transaction/TransactionSynchronizationRegistry.html#getResource-java.lang.Object-) >> states it should throw an ISE if a current transaction is not Active. The >> transaction is in the state ROLLED_BACK when AutoConnectionTracker tries to >> call getResource(). >> >> I think the Geronimo implementation ( >> https://github.com/apache/geronimo-txmanager/blame/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#L203) >> maybe be a little too strict. The JTA Spec pdf doesn't offer exact hints of >> which statuses ( >> https://docs.oracle.com/javaee/7/api/javax/transaction/Status.html) should >> be have getResource _not_ throw an ISE unfortunately. I was thinking of >> changing Geronimo's implementation to check for anything >> but STATUS_UNKNOWN, and STATUS_NO_TRANSACTION. >> >> The other way is to cast Transaction to the Geronimo implementation and use >> Geronimo specific APIs to get call getResource(). Do you guys have any >> preference which route I should take to fix? >> >> >> On Mon, Aug 26, 2019 at 9:15 AM Jonathan S. Fisher >> wrote: >> >>> https://github.com/exabrial/tomee-jms2-bug/tree/connection-pool-leak >>> >>> Here's a project that reproduces the bug. This project intentionally >>> exceeds the transaction timeout (of 1s). Each invocation, the connection is >>> not returned to the pool and eventually you run out, causing your >>> application to freeze. >>> >>> >>> >>> On Fri, Aug 23, 2019 at 2:37 PM Jonathan S. Fisher >>> wrote: >>> >>>> Hello Apache friends :) I have a question about the JTA and JMS/RA specs: >>>> >>>> If you borrow something from a RA, like a JMS Connection, and you're in >>>> XA Transaction, is it necessary to call connection.close()? It would seem >>>> JTA should be smart enough to know the connection is enrolled for 2 phase >>>> commit and should be smart enough to close it, but I'm not sure if that's >>>> part of the spec. >>>> >>>> In TomEE 7.0.6 we're noticing that if you borrow a JMS Connection with >>>> connectionFactory.createConnection(), and your code fails to call close() >>>> before the transaction completion, the connection leaks. (And >>>> unfortunately, calling close() after the transaction completes doesn't >>>> mitigate the problem). It took awhile for us to track this down. >>>> >>>> This becomes a huge problem if you're calling external services in your >>>> transaction. Let's say you have a reasonable transaction timeout of 30s >>>> set. You call three services, and they end up taking 15s a piece. Even if >>>> you're doing the right thing and you have connection.close() in a finally >>>> block, because your transaction isn't active when you call close, it leaks >>>> and it just gets "stuck"
Re: JTA JMS Spec question, connection leakage
I think the java doc for getResource might have been written thoughtlessly, and more appropriate behavior would be an ISE only for STATUS_NO_TRANSACTION; literally the geronimo implementation is too lax, as “marked rollback” is not status “active”. Is there anyone who’s opinion we might ask? I rather thought the “ignore session type” logic was supposed to be put into the RA, but I don’t recall if or how I dealt with this in Geronimo. So I’d prefer these issues be dealt with elsewhere but don’t see much practical alternative to your implementation. Nice to see someone working on XA:-) thanks! David Jencks > On Aug 26, 2019, at 1:45 PM, Jonathan S. Fisher wrote: > > I've narrowed down the problem to AutoConnectionTracker. It's not > completing, which isn't allowing the connections to be returned to the pool. > https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/resource/AutoConnectionTracker.java#L174 > > getResource() is throwing an IllegalStateException. The JavaDoc ( > https://docs.oracle.com/javaee/7/api/javax/transaction/TransactionSynchronizationRegistry.html#getResource-java.lang.Object-) > states it should throw an ISE if a current transaction is not Active. The > transaction is in the state ROLLED_BACK when AutoConnectionTracker tries to > call getResource(). > > I think the Geronimo implementation ( > https://github.com/apache/geronimo-txmanager/blame/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#L203) > maybe be a little too strict. The JTA Spec pdf doesn't offer exact hints of > which statuses ( > https://docs.oracle.com/javaee/7/api/javax/transaction/Status.html) should > be have getResource _not_ throw an ISE unfortunately. I was thinking of > changing Geronimo's implementation to check for anything > but STATUS_UNKNOWN, and STATUS_NO_TRANSACTION. > > The other way is to cast Transaction to the Geronimo implementation and use > Geronimo specific APIs to get call getResource(). Do you guys have any > preference which route I should take to fix? > > > On Mon, Aug 26, 2019 at 9:15 AM Jonathan S. Fisher > wrote: > >> https://github.com/exabrial/tomee-jms2-bug/tree/connection-pool-leak >> >> Here's a project that reproduces the bug. This project intentionally >> exceeds the transaction timeout (of 1s). Each invocation, the connection is >> not returned to the pool and eventually you run out, causing your >> application to freeze. >> >> >> >> On Fri, Aug 23, 2019 at 2:37 PM Jonathan S. Fisher >> wrote: >> >>> Hello Apache friends :) I have a question about the JTA and JMS/RA specs: >>> >>> If you borrow something from a RA, like a JMS Connection, and you're in >>> XA Transaction, is it necessary to call connection.close()? It would seem >>> JTA should be smart enough to know the connection is enrolled for 2 phase >>> commit and should be smart enough to close it, but I'm not sure if that's >>> part of the spec. >>> >>> In TomEE 7.0.6 we're noticing that if you borrow a JMS Connection with >>> connectionFactory.createConnection(), and your code fails to call close() >>> before the transaction completion, the connection leaks. (And >>> unfortunately, calling close() after the transaction completes doesn't >>> mitigate the problem). It took awhile for us to track this down. >>> >>> This becomes a huge problem if you're calling external services in your >>> transaction. Let's say you have a reasonable transaction timeout of 30s >>> set. You call three services, and they end up taking 15s a piece. Even if >>> you're doing the right thing and you have connection.close() in a finally >>> block, because your transaction isn't active when you call close, it leaks >>> and it just gets "stuck" as an active connection, which eventually you hit >>> the pool limit and your app freezes. >>> >>> On a separate note, we noticed if you open a connection outside of the >>> scope of a transaction, then start a transaction, then create a session >>> with session_transacted option, the session does not participate in the JTA >>> (which seems out of spec). One most open the connection inside the >>> transaction, AND open the session in the transaction, and close the >>> connection in the transaction for everything to work. >>> >>> I'll get a reproducing project created, but I was curious if anyone knew >>> offhand what the spec says. >>> >>> cheers, and thanks, >>> -[the other] Jonathan >>> >
Re: New Issue and PR
DavidCount++; //Dropping by to say hi… David Jencks > On May 26, 2019, at 10:04 PM, David Blevins wrote: > >> On May 26, 2019, at 3:53 AM, David Salter >> wrote: >> >> Thanks. That makes sense. >> >> As long as I’m on track, I’ll keep going. I’ve got a few more updates I’ll >> create issues and PRs for :) > > That sounds fantastic! On this example, I regenerated and did a manual tweak > of the resulting html -- this seems to be what's required on "stuck" pages > for some reason. Does this look good? > > - http://localhost:8080/tomee-8.0/docs/activemqresourceadapter-config.html > > Side note, it's fun to have another David on the project again :) People > used to mistake me for David Jencks quite regularly. > > I wonder how many Davids we can get on this thread :) > > > -David >
Re: how to debug TCK tests?
H i Cesar, I don’t see the javatest.log? Have you found the command line that starts the app client, including the debug options? I don’t think “listen mode” was available when I was working on this, I sure didn’t know about it! The app client test harness is definitely involved, but I was wondering what was being started to be debugged… as I recall I sometimes needed to step through various test harnesses and sometimes through geronimo or test app code. I remember all the options being quite confusing. David Jencks > On Jan 28, 2019, at 4:07 PM, César Hernández Mendoza > wrote: > > Hi David, > Thanks for the reply! > > Responding in line: > > Is the app client container starting? > Yes, > > Does it suspend for the debugger attachment? If not, it probably runs to > completion before you can attach-I definitely remember this happening to me! > I don't suspend at all, the following command just runs and then crashess > (you can check the attached javatest.log): > ./runtests --web tomee-plume -c -sql active -da > com/sun/ts/tests/appclient/deploy/ejblink/single/Client#testCMP11 > > Because it's doesn't suspend, I configure in the IDE [Listen to Remote JVM at > port: 5003] instead of [Attach to Remote JVM at port: 5003]. > But that didn't work either. > > Is the test harness or appclient test harness (I don’t recall if these are > separate) suspended waiting for attachment? > Base on the naming convention [1] from the test, I think it's an appclient > tests harness. How can I verify this? > > [1] > https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/appclient/deploy/ejblink/single/Client.java > > <https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/appclient/deploy/ejblink/single/Client.java> > > > El lun., 28 ene. 2019 a las 17:23, David Jencks ( <mailto:david.a.jen...@gmail.com>>) escribió: > From the distant past, I recall it being tricky to debug the app client > tests. Can you tell what is happening? > Is the app client container starting? > Does it suspend for the debugger attachment? If not, it probably runs to > completion before you can attach-I definitely remember this happening to me! > Does it suspend but not allow attachment? > Is the test harness or appclient test harness (I don’t recall if these are > separate) suspended waiting for attachment? > > Hope this helps! > David Jencks > > Sent from my iPhone > > > On Jan 28, 2019, at 2:31 PM, César Hernández Mendoza > <mailto:cesargu...@gmail.com>> wrote: > > > > Hi, > > > > I created the following document to track my TCK related work. > > https://docs.google.com/spreadsheets/d/1oYO0RN-rg4Z7TgSLJ2u4iK4hOFHOXA49ech2y0N3kVw/edit?usp=sharing > > > > <https://docs.google.com/spreadsheets/d/1oYO0RN-rg4Z7TgSLJ2u4iK4hOFHOXA49ech2y0N3kVw/edit?usp=sharing> > > > > As you can see I executed today the tests from the "appclient" category. > > > > One of the failing test is: > > com/sun/ts/tests/appclient/deploy/ejblink/single/Client#testCMP11 > > > > The way I'm executing just that tests is with the following command: > > ./runtests --web tomee-plume -c -sql active -da > > com/sun/ts/tests/appclient/deploy/ejblink/single/Client#testCMP11 > > > > Notice that I'm adding: > > -sql to enable (according to with runtests script code [1]) required > > databases to be created. > > -da to enable TCK appclient debug options (port 5003) > > > > Then on my IntelliJ, I opened Jakarta-tck project [3] and set up a remote > > debug configuration for Listen to Remote JVM at port: 5003 > > > > Unfortunately, I'm not able to make this to work and degub the failing test. > > > > > > [1] https://github.com/apache/tomee-tck/blob/master/runtests#L30 > > <https://github.com/apache/tomee-tck/blob/master/runtests#L30> > > [2] https://github.com/apache/tomee-tck/blob/master/runtests#L38 > > <https://github.com/apache/tomee-tck/blob/master/runtests#L38> > > [3] https://jenkins.eclipse.org/jakartaee-tck/ > > <https://jenkins.eclipse.org/jakartaee-tck/> > > > > -- > > Atentamente: > > César Hernández Mendoza. > > > -- > Atentamente: > César Hernández Mendoza.
Re: how to debug TCK tests?
From the distant past, I recall it being tricky to debug the app client tests. Can you tell what is happening? Is the app client container starting? Does it suspend for the debugger attachment? If not, it probably runs to completion before you can attach-I definitely remember this happening to me! Does it suspend but not allow attachment? Is the test harness or appclient test harness (I don’t recall if these are separate) suspended waiting for attachment? Hope this helps! David Jencks Sent from my iPhone > On Jan 28, 2019, at 2:31 PM, César Hernández Mendoza > wrote: > > Hi, > > I created the following document to track my TCK related work. > https://docs.google.com/spreadsheets/d/1oYO0RN-rg4Z7TgSLJ2u4iK4hOFHOXA49ech2y0N3kVw/edit?usp=sharing > > As you can see I executed today the tests from the "appclient" category. > > One of the failing test is: > com/sun/ts/tests/appclient/deploy/ejblink/single/Client#testCMP11 > > The way I'm executing just that tests is with the following command: > ./runtests --web tomee-plume -c -sql active -da > com/sun/ts/tests/appclient/deploy/ejblink/single/Client#testCMP11 > > Notice that I'm adding: > -sql to enable (according to with runtests script code [1]) required > databases to be created. > -da to enable TCK appclient debug options (port 5003) > > Then on my IntelliJ, I opened Jakarta-tck project [3] and set up a remote > debug configuration for Listen to Remote JVM at port: 5003 > > Unfortunately, I'm not able to make this to work and degub the failing test. > > > [1] https://github.com/apache/tomee-tck/blob/master/runtests#L30 > [2] https://github.com/apache/tomee-tck/blob/master/runtests#L38 > [3] https://jenkins.eclipse.org/jakartaee-tck/ > > -- > Atentamente: > César Hernández Mendoza.
Re: Java EE Security API for EE 8
Perhaps I didn’t recall correctly, or perhaps I implemented it for Jetty (at eclipse). The code I’ve found at http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/ <http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/> includes a FormAuthenticator and a JaspiAuthenticator. I don’t recall any details of how I modified tomcat’s auth setup: I might have made one that was more adapted to JASPIC and the geronimo security framework than the plain tomcat one. If this code is of any use to you, great, otherwise, good luck! many thanks David Jencks > On Dec 28, 2018, at 1:47 AM, Roberto Cortez > wrote: > > Hi David, > > Actually, the EE 8 Security spec tells you to use a JASPIC bridge underneath > the implementation, so your code might be a good fit. Can you point me out to > the sources so I can have a look? > > Thank you! > > Cheers, > Roberto > >> On 28 Dec 2018, at 03:40, David Jencks wrote: >> >> IIRC I wrote a JASPIC form authentication for the geronimo server long ago. >> Although the JASPIC deployment model was somewhat incomprehensibly bizarre, >> the conversation model was very nice. Depending on what the EE 8 api is (I >> haven’t looked) the JASPIC implementation might be a source for >> webserver-independent code for from authentication that could be easily >> adapted. >> >> David Jencks >> >>> On Dec 27, 2018, at 3:53 PM, Roberto Cortez >>> wrote: >>> >>> Update: >>> >>> I’ve started the implementation of the FormAuthenticationMechanism. Is not >>> as easy as it sounds, since it requires some conversation chat across >>> requests. I thought about wrapping all the logic and use the Tomcat >>> FormAuthenticator, since it does exactly what we need. Unfortunately, it is >>> too tied to the Tomcat code and it would require to instantiate a lot to >>> Tomcat objects to be able to use it. I’m not sure if it would be worth it. >>> I ended up following the spec suggestion to use a CDI interceptor and I’m >>> copying / reusing some pieces of the FormAuthentication when possible. >>> >>> PR updated: >>> https://github.com/apache/tomee/pull/277 >>> <https://github.com/apache/tomee/pull/277> >>> >>> Cheers, >>> Roberto >>> >>>> On 26 Dec 2018, at 22:11, Roberto Cortez >>>> wrote: >>>> >>>> Hi folks, >>>> >>>> I’ve updated the PR with new changes: >>>> >>>> - I’ve implemented a CDI Extension to create AuthenticationMechanism beans >>>> and a CDI class to keep track of the mapping between the authentication >>>> mechanism and the servlet that should be checked. When a Servlet is >>>> executed the mapping is checked and if there is and associated >>>> AuthenticationMechanism, we validate the request with the associated type >>>> (Basic, Form, etc). >>>> >>>> - Implemented the BasicAuthenticationMechanism and all the plumbing >>>> required to be executed. This required an HttpMessageContext to pass >>>> information around, plus store some state to make decisions on things to >>>> do, including the CallbackHandler to pass in additional Callbacks to >>>> create the Principal and Groups >>>> >>>> - A default IdentityStore, using the Tomcat UserDatabase, that reads user >>>> data from tomcat-users.xml >>>> >>>> I’ll probably move to implement the missing AuthenticationMechanisms (FORM >>>> and Custom) next. >>>> >>>> Any feedback, always welcomed :) >>>> >>>> Cheers, >>>> Roberto >>>> >>>>> On 19 Dec 2018, at 10:00, Bruno Baptista wrote: >>>>> >>>>> TomEE Security works for me. >>>>> >>>>> Bruno Baptista >>>>> https://twitter.com/brunobat_ >>>>> >>>>> >>>>> On 19/12/18 00:20, Roberto Cortez wrote: >>>>>> Hi folks, >>>>>> >>>>>> Work is progressing. >>>>>> >>>>>> I’ve added a good chunk of the API (as needed) to allow me to proceed. >>>>>> I’ve tried to use the Jakarta Security API jar. Unfortunately, it is >>>>>> full of
Re: Java EE Security API for EE 8
IIRC I wrote a JASPIC form authentication for the geronimo server long ago. Although the JASPIC deployment model was somewhat incomprehensibly bizarre, the conversation model was very nice. Depending on what the EE 8 api is (I haven’t looked) the JASPIC implementation might be a source for webserver-independent code for from authentication that could be easily adapted. David Jencks > On Dec 27, 2018, at 3:53 PM, Roberto Cortez > wrote: > > Update: > > I’ve started the implementation of the FormAuthenticationMechanism. Is not as > easy as it sounds, since it requires some conversation chat across requests. > I thought about wrapping all the logic and use the Tomcat FormAuthenticator, > since it does exactly what we need. Unfortunately, it is too tied to the > Tomcat code and it would require to instantiate a lot to Tomcat objects to be > able to use it. I’m not sure if it would be worth it. I ended up following > the spec suggestion to use a CDI interceptor and I’m copying / reusing some > pieces of the FormAuthentication when possible. > > PR updated: > https://github.com/apache/tomee/pull/277 > <https://github.com/apache/tomee/pull/277> > > Cheers, > Roberto > >> On 26 Dec 2018, at 22:11, Roberto Cortez wrote: >> >> Hi folks, >> >> I’ve updated the PR with new changes: >> >> - I’ve implemented a CDI Extension to create AuthenticationMechanism beans >> and a CDI class to keep track of the mapping between the authentication >> mechanism and the servlet that should be checked. When a Servlet is executed >> the mapping is checked and if there is and associated >> AuthenticationMechanism, we validate the request with the associated type >> (Basic, Form, etc). >> >> - Implemented the BasicAuthenticationMechanism and all the plumbing required >> to be executed. This required an HttpMessageContext to pass information >> around, plus store some state to make decisions on things to do, including >> the CallbackHandler to pass in additional Callbacks to create the Principal >> and Groups >> >> - A default IdentityStore, using the Tomcat UserDatabase, that reads user >> data from tomcat-users.xml >> >> I’ll probably move to implement the missing AuthenticationMechanisms (FORM >> and Custom) next. >> >> Any feedback, always welcomed :) >> >> Cheers, >> Roberto >> >>> On 19 Dec 2018, at 10:00, Bruno Baptista wrote: >>> >>> TomEE Security works for me. >>> >>> Bruno Baptista >>> https://twitter.com/brunobat_ >>> >>> >>> On 19/12/18 00:20, Roberto Cortez wrote: >>>> Hi folks, >>>> >>>> Work is progressing. >>>> >>>> I’ve added a good chunk of the API (as needed) to allow me to proceed. >>>> I’ve tried to use the Jakarta Security API jar. Unfortunately, it is full >>>> of dependencies to the other Jakarta dependent projects, some not in >>>> central yet, so I couldn’t even build the project. >>>> >>>> At the moment, I’ve added the structure to register a JASPIC provider to >>>> serve as a bride to the Security implementation code. With a CDI >>>> extension, we can register the required AuthenticationMechanisms and then >>>> look them up to delegate the authentication code. >>>> >>>> I’ve also wrote a default IdentityStoreHandler to validate user >>>> credentials and retrieve user groups. This is just going through the >>>> container registered IdentityStores and using the spec rules to identify >>>> the credentials. >>>> >>>> Right now, I’m just calling this TomEE Security. If someone has a more >>>> fancy idea for a name, feel free to suggest it :) >>>> >>>> Cheers, >>>> Roberto >>>> >>>>> On 14 Dec 2018, at 23:44, Roberto Cortez >>>>> wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> I’ve now created a PR to push the work: >>>>> https://github.com/apache/tomee/pull/277 >>>>> <https://github.com/apache/tomee/pull/277> >>>>> >>>>> It is still in the early stages. I’ve just spent a good amount of time >>>>> trying to understand the spec. The ideia here is that with a >>>>> ServerAuthModule we could verify each of the spec authentication >>>>> mechanisms that will be implemented with a CDI Bean and use a CDI >>>>> Extension to create the bean depending on the annotation you use. >>>>> >>>>> Cheers, >>>>> Roberto >>>>> >>>>>> On 13 Dec 2018, at 16:06, Roberto Cortez >>>>>> wrote: >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> I’ve created https://jira.apache.org/jira/browse/TOMEE-2365 >>>>>> <https://jira.apache.org/jira/browse/TOMEE-2365> to implement the Java >>>>>> EE Security API that came up in EE 8. We are missing this spec >>>>>> implementation, and until we have it we cannot even say we are EE 8 >>>>>> compatible. >>>>>> >>>>>> I plan to start working on this. If anyone wants to collaborate with me, >>>>>> let me know. >>>>>> >>>>>> Cheers, >>>>>> Roberto >> >
Re: New Java EE Schemas for Java EE Deployment Descriptors
It’s been a very long time since I worked with these, but I do remember that switching to the openejb customized classes was a very big improvement. I think it’s definitely worth having an object tree representing the deployment descriptor where the objects make sense. David Jencks Sent from my iPhone On Dec 2, 2018, at 3:33 PM, David Blevins wrote: >> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu wrote: >> >> Hi folks, >> I am working on the Java EE schema update to support Java EE 7 and Java EE8 >> schemas which are specified in >> https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html >> >> Seems that two modules openejb-jee and openejb-jee-accessor modules are >> mostly updated by manually after generated by xjc compiler. Moreover, I did >> not able to find the any XJB binding file. >> >> In pom.xml, there is a plugin (jaxb2-maven-plugin) but seems that it is not >> working correctly. >> Do you have any comment on these modules? We need to generate codes >> automatically without updating any manual intervention. >> >> Currently we only support Java EE 6 schemas and using the trick (updating >> newer namespaces to Java EE 6 old namespace) and do not support Java EE7 >> and 8 deployment descriptors. >> >> Here is the JIRA Issue: >> https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2306 > > Hi Gurkan, > > I've added David Jencks to the thread in case he's around and wants to give > some of his historical perspective. He is retired and enjoying life, so I > suspect he won't, but it never hurts. > > There's long pro-customization and anti-customization history on this topic > between OpenEJB/Geronimo. We've done it both ways in both projects, this is > a rough timeline -- years are approximate: > > - OpenEJB & Geronimo anti-customization: 2003 - 2006 > - OpenEJB pro-customization, Geronimo anti-customization 2006-2009 > - OpenEJB & Geronimo pro-customization: 2009 onward > > There really is no easy answers without pain points. Both project started as > you say, generating automatically without any customizations, and committers > on both projects eventually shifted away from it. There's a trade-off and it > comes down to where you want the benefits and where you're willing to live > with the cost. This is a high-level perspective of what we all noticed. > > - Read-only generated tree: >- pro: easy when schemas change once every 2-3 years >- con: inability to customize pushes complexity into consuming code > year-round > > - Generated then customized tree: >- pro: increasingly easier to to consume year-round >- con: hard when schemas change once every 2-3 years > > The con of "Generated then customized tree" really only applies to existing > schemas that change. New schemas introduced can easily be generated. > > The story arch of this goes basically both OpenEJB and Geronimo used > generated trees that were not checked into the source. The pain points > associated with that resulted in OpenEJB trying it differently when OpenEJB 3 > was launched in 2006. Geronimo kept with generated trees believing manually > changing them was a mistake. After a few years on both projects and everyone > having the experience with both approaches, Geronimo eventually removed it's > generated tree and switched the whole server over to using the optimized > OpenEJB JAXB tree. > > This topic comes up every few years when it is time to update the > descriptors, which is completely natural. > > The topic of customized or not is particularly challenging when you don't > control the schema. There are a few terrible aspects of the Java EE schemas > that make it really hard to work with "pure." > > - Created it's own String type > - No polymorphism/reuse for types like SessionBean, EntityBean, > MessageDrivenBean > - Doesn't use enums many places where it should > > These are only a few highlights. Some of the decisions made around the Java > EE schemas in 1999 wouldn't be considered best practice today, but will never > be changed due to backwards compatibility reasons. So we have the double > challenge of it being a schema we don't control on top of it being a schema > that is not written with tools like JAXB in mind that hadn't been invented. > > In practice how this played out for the Java EE schemas is that your code > that consumed it didn't feel like "java" code. > > - It was strongly-typed, but none of those types had any relationship to each > other so you're duplicating the same logic over and over again. You get the > cost of Java's type system, but non
Re: Classloader woes: EAR containing an RAR
Does the CDI approach support consuming a message inside a transaction? Looking at one of the Kafka cdi examples, I didn’t immediately see how it would. Being able to roll back the consumption of a message always seemed one of the main points of jca to me. Thanks David Jencks Sent from my iPhone > On Jul 31, 2018, at 9:59 PM, Romain Manni-Bucau wrote: > > I am happy to help you using the rar if you can setup a reproducer project > but for kafka gain is pretty low and being cdi based opens more doors like > composing with decorators, getting a better error handling than EJB, > getting rid of some useless layer for kafka etc...but we can still do the > exercise technically :) > > Le mer. 1 août 2018 02:00, ChrisOwens a écrit : > >> Romain Manni-Bucau wrote >>> If your goal is really to interact with kafka - and you dont care of rar >>> by >>> themselves - i would recommand to use a cdi extension, >>> you can find several on the net like >>> https://github.com/bgjug/kafka-cdi-extension and >>> https://github.com/aerogear/kafka-cdi >> >> >> Thank you. I was hoping to use the message-driven-bean abstraction, but I >> will look into these cdi extensions instead. >> >> >> >> >> -- >> Sent from: >> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html >>
Re: Classloader woes: EAR containing an RAR
I was actually thinking of putting the entire classes jar from inside the rar into the ear lib module, not exploding the rar. There weren’t any annotations in the last rar spec I worked with… David Jencks > On Jul 30, 2018, at 12:33 PM, Romain Manni-Bucau > wrote: > > Hi > > The api part of the rar should be shared so put it in tomee/lib (or the ear > lib module). Worse case, David's trick of exploding the rar in the ear can > work if it uses annotations (just put it in any scanned module). > > Le lun. 30 juil. 2018 21:09, David Jencks a > écrit : > >> Hopefully someone who actually knows something will speak up soon… >> You might try putting the rar classes in a lib jar in the ear. I don’t >> recall if you have to do something with the manifest class path in the ejb >> module and rar to get this to work. >> >> David Jencks >> >>> On Jul 30, 2018, at 11:16 AM, ChrisOwens wrote: >>> >>> I am deploying (tomEE-plus 7.0.5) an EAR file that contains two modules: >> a >>> JCA connector defined in a rar file, and a JAR full of ejbs. The EJBs >>> contain classes that depend upon classes packaged in the RAR. >>> >>> Whether or not I set "initialize-in-order" to true, I get the same >> behavior: >>> The logs show no evidence that the server has tried to deploy the RAR, >>> instead it begins deploying the ejb module, and fails with >>> NoClassDefFoundError. >>> >>> If I delete the ejb module from the ear, leaving only the rar module, and >>> deploy the ear, the server appears to deploy the rar module happily. >>> >>> Jonathan Gallimore posted something a while back that I thought was >> related >>> to this problem, something about resource adapter class loading being >> lazy; >>> I thought there was even a pull request for it, but I can't seem to find >> any >>> of that now. >>> >>> Is there a workaround? >>> >>> >>> >>> >>> >>> >>> -- >>> Sent from: >> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html >> >>
Re: Classloader woes: EAR containing an RAR
Hopefully someone who actually knows something will speak up soon… You might try putting the rar classes in a lib jar in the ear. I don’t recall if you have to do something with the manifest class path in the ejb module and rar to get this to work. David Jencks > On Jul 30, 2018, at 11:16 AM, ChrisOwens wrote: > > I am deploying (tomEE-plus 7.0.5) an EAR file that contains two modules: a > JCA connector defined in a rar file, and a JAR full of ejbs. The EJBs > contain classes that depend upon classes packaged in the RAR. > > Whether or not I set "initialize-in-order" to true, I get the same behavior: > The logs show no evidence that the server has tried to deploy the RAR, > instead it begins deploying the ejb module, and fails with > NoClassDefFoundError. > > If I delete the ejb module from the ear, leaving only the rar module, and > deploy the ear, the server appears to deploy the rar module happily. > > Jonathan Gallimore posted something a while back that I thought was related > to this problem, something about resource adapter class loading being lazy; > I thought there was even a pull request for it, but I can't seem to find any > of that now. > > Is there a workaround? > > > > > > > -- > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
Re: tomee site slogan
I agree with Ivan. David Jencks > On Apr 27, 2018, at 1:59 PM, Ivan Junckes Filho <ivanjunc...@gmail.com> wrote: > > I agree with Mark and +1 to Dani's description. > > On Fri, Apr 27, 2018 at 5:34 PM, Mark Struberg <strub...@yahoo.de.invalid> > wrote: > >> Also fine. >> It's just the 'Remote EE Server' which is kind of weird ;) >> >> LieGrue, >> strub >> >>> Am 27.04.2018 um 22:32 schrieb Daniel Cunha <daniels...@apache.org>: >>> >>> I'll prefer something like: >>> "The Embedded or Standalone Enterprise Tomcat Server" >>> >>> 2018-04-27 17:19 GMT-03:00 Mark Struberg <strub...@yahoo.de.invalid>: >>> >>>> Hi folks! >>>> >>>> I really like the new TomEE site. >>>> >>>> Just one thing which we might want to improve: >>>> The main slogan currently says >>>> "The Embedded or Remote EE Application Server" >>>> >>>> Trust me, reading "Remote EE Application Server" doesn't give people a >>>> good feeling ;) >>>> This reminds me a bit too much about Remote EJBs... >>>> >>>> >>>> What about the following: >>>> "The Embedded or Standalone Tomcat Server on Enterprise Stereoides" >>>> >>>> ? >>>> >>>> LieGrue, >>>> strub >>> >>> >>> >>> >>> -- >>> Daniel "soro" Cunha >>> https://twitter.com/dvlc_ >> >>
Re: Unable to use two XA Datasource in a same transaction
I’m not very familiar with this configuration, but I don’t see any indication that the two datasources are connecting to different databases. If they connect to the same database I think that is likely the source of the problem. There might possibly be an Oracle setting to allow this. It might possibly be called something like loose coupling or tight coupling. It would be better to change to one datasource per target database, however, as you would be making the database work much less with one xid rather than two. david jencks > On Apr 24, 2017, at 1:56 AM, Dignesh <dgo...@opentext.com> wrote: > > I created two XA datasource and getting connection from both datasource in > same transaction. I'm getting below exeception when i try to get connection > from second data source > > Caused by: java.sql.SQLException: Unable to enlist connection in > transaction: enlistResource returns 'false'. > at > org.apache.openejb.resource.jdbc.managed.local.ManagedConnection.invoke(ManagedConnection.java:136) > at com.sun.proxy.$Proxy82.prepareStatement(Unknown Source) > > TomEE Version: 7.0.2 > Database: Oracle > > Here are the datasource configurations > > > XaDataSource XA/Datasource > UserName $UserName$ > Password $Password$ > PasswordCipher TestCipher > maxActive = 40 > minIdle = 2 > validationQuery = select 1 from dual > testOnBorrow = true > validationInterval = 3 > > > > XaDataSource XA/Datasource > UserName $UserName$ > Password $Password$ > PasswordCipher TestCipher > maxActive = 20 > minIdle = 2 > validationQuery = select 1 from dual > testOnBorrow = true > validationInterval = 3 > > >class-name="oracle.jdbc.xa.client.OracleXADataSource"> > Url $JdbcUrl$ > > > Note: I'm not seeing this issue when i use PostgreSQL database > > Thank You. > > > > -- > View this message in context: > http://tomee-openejb.979440.n4.nabble.com/Unable-to-use-two-XA-Datasource-in-a-same-transaction-tp4681579.html > Sent from the TomEE Dev mailing list archive at Nabble.com.
Re: Example+request
Hi Nilesh, I too would like to know exactly what you need from the ejb remote protocol. I think I did the majority of the work getting CORBA to work in Geronimo, and I’m almost a CORBA fan :-) It’s very hard to get IIOP transport to work and even harder to keep it working :-). (for instance there are a bunch of java language features that need support added to Yoko to work with ee7) We never implemented actual distributed transactions, just the support for throwing an exception when you tried to do something that actually required transmitting the existence of a transaction from one orb to another. csiv2 security is (IMO) pretty amazing and wonderful, but I haven’t really found anyone who understands what it does and uses it effectively. If you actually need the capabilities it offers it would be much easier to extend the tomee ejbd protocol than integrate IIOP. thanks david jencks > On Jan 5, 2016, at 3:50 PM, David Blevins <david.blev...@gmail.com> wrote: > > Hi Nilesh! > > CORBA is not supported in the current TomEE distributions, however remote > EJBs definitely are. We support a custom EJB protocol going back to the > early days of OpenEJB (1999). It is significantly lighter and faster, > designed to compete against WebLogic T3 which was quite hot in the old days. > > Are you using IIOP for any of the following? > > - Communication with non-Java clients > - Distributed transactions > - Distributed security > > I’ll note we did add CORBA support to Geronimo via Yoko and in the 8+ years > of the project, we never saw anyone use it. The topic of deprecating CORBA > came up in the Java EE expert group and was almost unanimously agreed on. > Seeing a request for it makes me wonder if that was the right decision. I’m > quite interested in your use case. > > Any details you have are very welcome. Also, Cc’ing you directly as you did > get a response, but if you’re not subscribed to the list you probably missed > it. > > Happy new year! > > -- > David Blevins > http://twitter.com/dblevins <http://twitter.com/dblevins> > http://www.tomitribe.com > >> On Jan 4, 2016, at 4:36 AM, Nilesh Chauhan <nileshbchau...@gmail.com >> <mailto:nileshbchau...@gmail.com>> wrote: >> >> Any inputs from tomee dev team for example requested in email chain below. >> >> any help on the same is highly appreciated. >> >> Regards, >> Nilesh Chauhan >> >> On Wed, Dec 30, 2015 at 11:06 AM, Nilesh Chauhan <nileshbchau...@gmail.com >> <mailto:nileshbchau...@gmail.com>> >> wrote: >> >>> Hi, >>> >>> >>> >>> I am looking for some hint or possibly an example on exposing EJB3 as >>> IIOP/CORBA compliant and accessing the EJB3 with IIOP/CORBA client. >>> >>> >>> >>> Our current application is designed as such that it’s EJBs(EJB3) are >>> exposed to IIOP client and all our WEB and standalone clients are using >>> those EJBs using IIOP/CORBA clients. >>> >>> >>> >>> As Glassfish fully supports that, we are using the same as our application >>> server but as there are no commercial support from Oracle from next >>> versions; we are looking for suitable candidate for replacement of >>> Glassfish. >>> >>> >>> >>> Any inputs or help on the same will leads to us in deciding to select >>> Tomee as the suitable candidate for our applications server in place of >>> Glassfish. >>> >>> >>> >>> Thanks, >>> >>> Nilesh Chauhan >>> >> >> >> >> -- >> Thanks and Regards, >> Nilesh Chauhan >
Re: Could anyone tell the new links?
I thought these were xml namespaces rather than actual working urls. There is no requirement that an xml namespace in the form of a url actually link to anything, and I don't think these ever did. Where did you find them used? thanks david jencks On Oct 8, 2013, at 7:43 PM, Zhi Xie daxie...@gmail.com wrote: Hi,David. The straightforward way is to add those 2 xsds in openejb, or we upload in geronimo site, openejb provide those 2 links to redirect to geronimo site. Because the 2 links have been for a long time. Many users have refered them in their applications. Many technotes and documents have included them. 2013/10/9 Zhi Xie daxie...@gmail.com Thanks,David.As I know, you are a great committer in GERONIMO, so do you have any suggestion for the next step in geronimo? I have also sent a question in Geronimo community. Maybe we could discuss this issue in Geronimo community. 2013/10/9 David Blevins david.blev...@gmail.com Hi Gary, Those links have never been valid. I seem to recall the xsds were in Geronimo source somewhere in Geronimo 1.x and gone from subsequent releases after Geronimo stopped using xmlbeans. It's been quite a while -- I don't recall the details. -David On Oct 8, 2013, at 1:38 AM, Zhi Xie daxie...@gmail.com wrote: It is very important for apache geronimo project. I'm appreciated to see any comments. Thanks. 2013/10/8 Zhi Xie daxie...@gmail.com http://openejb.apache.org/xml/ns/openejb-jar-2.2 http://openejb.apache.org/xml/ns/pkgen-2.1 I find these links above are invalid now. -- Best Regards Gary -- Best Regards Gary -- Best Regards Gary -- Best Regards Gary
