Fix download links - wherever referenced

[shroffk]

reference #5

For the time being, the simplest solution would be to point to maven central where the latest releases are available.
for caj (https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.epics%22%20AND%20a%3A%22caj%22)
for jca
(https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.epics%22%20AND%20a%3A%22jca%22)

• fix epics/extension weblink
• fix archiver appliance web link

[shroffk]

The above links are only valid provided we agree that maven central is the place to deploy, if the epics main repo is the maven repository hosted on sourceforge then we should use links to that repo.

[kasemir]

Since the jca and caj binaries are already published to maven central, using that as a place to download, not just for maven users but also for people who manually download a binary, is good.

I don't mean to endorse Maven in general. The 'ant' build files for jca and caj are still a good idea, and people should be free to download the jar files from maven central and then use them with non-maven builds. Still, would be silly to also publish the binary on additional web sites when Maven central already has a copy and allows direct download.

[anjohnson]

For my Extensions page I am actually looking for a project webpage I can link to that contains human-readable text about JCA/CAJ, maybe the JavaDoc output, instructions on where to download it from, links to GitHub for developers and issue-tracking etc, not just a pointer for the file downloads. Murali might want a similar destination too, but I haven't checked.

[ralphlange]

+1 for pointing download links to Maven Central.
The EPICS Maven repo on SF is deprecated (at least for Base use) and should not be advertised.

For a project website I would suggest using the generated Maven site, which with little effort can be made to match all of Andrew's requests.
Since we moved the sources to GitHub, I would host that site there, too.
We should probably consider moving all EPICS related project web sites to the new web server once we have the new web server.

[slominskir]

Obtaining the Channel Access Client API for Java is still incredibly confusing. Googling around you find references to JCA, CAJ, and CA and you can find various versions on jcenter, maven central, github, APS, and source forge.

Maybe we need to ask previous maintainers to take down distracting old webpages:

• https://epics.anl.gov/bcda/jca/jca/2.1.2/index.html
• http://epics-jca.sourceforge.net/

Would be helpful to update the Readme for this project to link to latest release download (could just be link to github release page), plus provide coordinates for Maven / Gradle, perhaps:

• https://bintray.com/bintray/jcenter/org.epics%3Ajca
• https://search.maven.org/search?q=g:org.epics%20AND%20a:jca

Having a second client API that is nearly identical in function (and is based on same code) adds to the confusion: https://github.com/channelaccess/ca. Can these projects be merged together? Do we need two?

[shroffk]

@slominskir this is a very valid point.

I will try to follow up with the owners of the above two links to redirect their pages to the new epics-base/jca

Additionally, the readme will be updated with instructions on how to get the jca libraries via maven or directly download links.

ca vs jca

I had started writing comparison tests between the two.
It seems like ca is a much easier library to read and manage. However, jca is used in a lot of places and has a lot of legacy associated with it.

[shroffk]

We have added ca vs jca to the core developers meeting at agenda...so hopefully we will have an update during the epics meeting.

[anjohnson]

I just wrote to BCDA so hopefully their page(s) will get changed or removed soon, I suggested a redirect to this GH project.

[slominskir]

Also consider consolidating / merging with EPICS 7 project as a sub-module: epics-base/epicsCoreJava#26

[anjohnson]

The above BCDA link has now been fixed to redirect to this project, as have others in the same area that are high up the Google search results.