Hosting executable .jar files in BitBucket repo or automate packaging executable .jar files from git into local folder

I am trying to create a launcher application in Java that can invoke executable .jar files. An easy way for this is to host the executable .jar files in a cloud instance and the launcher application would just download the .jar files from there into the user's local folder. The dilemma is the absence of the cloud service or a server that can host the jar files.

As a workaround, I thought I can just host the jar files in BitBucket and that is where the launcher application will download the executable files from. Though, I think this is a little unconventional since it is mostly used to version source codes (please correct me if I am wrong). Also, I am not sure if it would be possible to invoke FTP or download files from there (perhaps through BitBucket API, maybe?).

Another option is that it could be possible to make the launcher app to create executable jar files from the git repo and download the package executable jar files into the user's folder and invoke from there. If this is possible, I would appreciate any leads towards this option.

Thanks!

yes you can push your binaries to github (getting raw content is difficult from bitbuket your request need to have authentication and stuff).

here is how to for that

copying here as well in case get's removed.

> How to create a maven repository for your github project step by step
Clone your project in a separate folder
(note: replace ORGANIZATION and PROJECT)

> git clone git clone git@github.com:ORGANIZATION/PROJECT.git my-repository

> cd into it
> cd my-repository

> Create a new branch (here named repository)
> git branch repository

> Switch to that branch
> git checkout repository

> Remove all files
> rm -rf file1 file2 file3 .. etc

> Install your jar in that directory
> (note: replace YOUR_GROUP, YOUR_ARTIFACT, YOUR_VERSION and YOUR_JAR_FILE)

> mvn install:install-file -DgroupId=YOUR_GROUP -DartifactId=YOUR_ARTIFACT -Dversion=YOUR_VERSION -Dfile=YOUR_JAR_FILE -Dpackaging=jar -DgeneratePom=true -DlocalRepositoryPath=. -DcreateChecksum=true
YOUR_JAR_FILE should point to an existent jar file, this is why it's best to create your repository branch in a different folder, so you can reference the existing jar in /your/project/path/target/artifact-x.y.z.jar

> Add all generated files, commit and push
> git add -A . && git commit -m "released version X.Y.Z"

> git push origin repository

> Reference your jar from a different project
> The repository url you just created is > https://raw.github.com/YOUR_ORGANIZATION/YOUR_ARTIFACT/repository/

2nd option is also a good approach as you user will get always the updated content but that will add building time into it, depends on your use case.

In general, it's not a good idea to store build products in a Git repository. Generally build products are large, tend to compress poorly (especially JAR files, which are already compressed), and don't need to be versioned. This is exactly the behavior you don't want from your Git repository.

While you can indeed do this, you're likely going to find that Bitbucket is not going to want to host your Git repository for this purpose, and then you'll have to find an alternative solution. You'd be better off hosting these assets in a cloud storage bucket or even on a static server and downloading using HTTPS. If this isn't achievable, you need to consider why that is, and look into solving it.

If these JAR files are build products for a release of software you're already hosting on Bitbucket, then it's probably fine to use the standard release asset functionality of Bitbucket for that purpose. You just don't want to use a Git repository, which is significantly more expensive to serve than static assets.

You also don't want to use FTP because (a) it's slower than HTTPS and (b) due to people not complying with the spec, it's impossible to use TLS with it consistently. Your software will have an exploitable security bug if you download data over an unencrypted connection without integrity checking and then execute that data.