This project was developed, as the need arose, to develop and deploy software I've created and as a result, has only been developed as necessary. I develop until I can switch to another task, so it may seem like there are lots of little projects, however it ia actually just the start to one big .jar file. So if something doesn't work at present, you can always email and ask when I might be able to get to another aspect of it, or even better, when "THEY" can get to it. They're gonna have to sort.
I agree that documentation should be as necessary or as convenient, as the developer should be able to explain themselves, as requested, and primarily to be helpful. It is best to be able to view the debugging output to trace the applications flow, so I tend to produce more output than most programs as I enable and disable tracing and variable exposure.
It has been developed with the intent of making software easier for the people that do it. So basically, you'd want to use it in conjunction with an IDE and your own custom tools, not instead of. I'm not trying to reinvent the wheel, just make it easier to do. It's just that code makes it so much easier, so knowing that should be 2nd in position after seeking God. That's my order. Sorry, not sorry. Jesus Christ. First. All ways. Eternal. Yes, I agree. Amen!
This software is both open source, meaning anyone can contribute (the hope is you would get paid to contribute) and subscription based, so there is a fee, however it's very low at $10/year/machine and you may try the software out for a while (say 3 months) and see if it's something you want to use or not.
Although I try to make it right and well, please be aware, this is a Work-In-Progress. I'd like to get a diff set up where a user can scroll between two versions and the changes made illustrated with color, if anyone wants a spot to try to contribute.This software may not work as intended or for a given task. You are always encouraged to review the code for yourself and make the necessary changes, if any, for your purpose.You can request features be added if you're not comfortable coding. You can simply request an addition to todo.txt in the default package for now, the ability to do it from the web is a new task.
Okay, so this isn't GitHub but I'll try to get it on there one of these days. For now, if you have changes that you think should be made, submit the .jar or link (preferably) and comments, to firstname.lastname@example.org and follow up, as necessary.
At present, this package is primarily for developer use. Once 'Backup' is working, it should open up to all users of a computer and Internet. I'll try to use terms that someone could 'google' and achieve satisfactory results.
You will notice that I trail directories with a
File.separator. I do that In order to distinguish from a file or a directory, because if it doesn't end with a
File.separator (/|\|\\), then it is a file, regardless of preceding dot or not. Therefore /path/./ and /path/../ will resolve to system dependant paths.
Within the Launcher, the default package is listed first, as it is in Netbeans, then packages within the main project directory. The main project directory should be [user.home]\Documents\java, or [user.home]/Documents/java, where [user.home] is your 'home' directory. Mine, with my name being tim is /home/tim/ on Linux, /Users/tim/ on Mac and C:\Users\tim\ on Windows.
Files without a package name, such as ca.tecreations or com.example, are intended for most users, so I've placed those files in the default package. Some files a user may not want to use, for example, DoSSLExampleSetup or InstallRootChains. Some of the files are for developers and some are for general users. Editing on the fly, including the website are features to be developed, so there's lots of opportunity to contribute, be paid and be recognized.
The Installer is located in the default package and the Launcher is in ca.tecreations.
Data files, whether .properties, .ser, or graphics files are all contained within the most appropriate location. So image files will typically be kept in ca.tecreations.apps.appname.images, whereas serialization (.ser) files are usually in ca.tecreations.apps. Properties files for a computer platform are contained within the folder of the project path, the install directory (typically /Users/<you>/Documents/java) or as referred to in the code:
Global.getProjectPath(). Application properties files are in [INSTALL_PATH]/properties. If you installed to a directory other than the default, you will need to update the file
ca.tecreations.Global.java to reflect the correct directory.
Above all, a developer should do whatever they deem necessary or reasonable, given a certain mindset. Feel free to do whatever you want. That is the point, isn't it? Fork as much or little as you like. Yes, follow good coding guidelines, but don't be afraid to break the rules. Show us what you've got!!! Here. I'll go first.
On Windows, double clicking the downloaded signed-Deployed.jar will execute the main class Launcher program. On Mac, you need to right click on the .jar file and then click Open.
On all platforms you can also run it two different ways using the command line.
To run the Launcher, use the following command in the directory you downloaded signed-Deployed.jar:
java -jar signed-Deployed.jar
Alternatively, you may also run it with the ClassPathAgent like this:
java -javaagent:signed-Deployed.jar -jar signed-Deployed.jar
Please note that running without the ClassPathAgent requires the application to re-launch itself in order to perform dependency injection. The use of
-javaagent:signed-Deployed.jar is recommended and its' use allows the jar to just "Load" the dependencies.
Click on Installer, then click "Launch"
Click on "Install", select the directory [user.home]/Documents/java and click "OK".
The app will display a progress bar of completion (it will jump around, particularly when installing the .jar files). Once finished the Installer will exit.
At this point, you may run any application listed within the Launcher. Some (those listed below) will produce UI Frames (Like Launcher, Installer) and some will be for command line or IDE use only. This is where being able to read code is helpful.
Close the launcher and proceed to your IDE to make an existing project from the sources installed.
Open your IDE. I'll be using Netbeans, so your steps may vary. If you can't figure it out, email me and I'll make a howto for your platform.
Create a project from existing sources and point it to: /Users/yourname/java, and if prompted, ignore .class files.
Add the jars in /Users/yourname/java/jars to the library search path.
Decrypt your code signing and client keystores if you want to sign or deploy to a remote host.
At this point, you could create a simple HelloWorld app and if it has a
public static void main(String args) method it will be available to launch from the Launcher.
Choose BuildAll.java and run that within the IDE.
And now you can deploy and have a system running alongside ca.tecreations.
Okay, so the idea is to have a working copy all the time. We all know, software breaks. The clean-build-deploy system relies on the .class files being in the correct place in the jar.
BuildAll takes care of compiling all the .java files into .class files whereas
Clean removes them all. You only need to
BuildAll once before deploying. It takes about 5 minutes at present, on an i7-3Ghz machine and it should be done in the IDE. So while it will probably work from the Launcher, that isn't the recommended way to try to approach this task. The IDE maintains a cache of the classes involved, so when you do a
Clean. They're gone from the Project Path. Now you need to restart. So, in the terminal window (Command for Windows), those classes that the code relies on are gone. You can circumvent that failure by doing a
java BuildAll false
from the [user.home]/Documents/java directory, but that's a bit much. Note that
BuildAll also generates the JavaDocs for the ca.tecreations package and all sub-packages, ie, ca.tecreations.apps*. You will need to either disable it or modify it to suit your package if you want JavaDocs or no processing in that area. Because the expectation is that you may need to alter the
ca.tecreations.* package, you may also want to alter the docs to remind yourself. That's what this is for.
Another option, if you don't want the class files left there, is to do a
new Clean() at the end of the deploy cycle, so that they are only there when needed. I'm not that fussy, so I just leave them there.
Maybe something that should be said is that you should feel confident in changing the code within the
ca.tecreations.* package as it really is fairly basic stuff. It's written at about a Grade 7 to Grade 10 level, so should be fairly easy for high school students to use and modify. As always, if help is needed you may email me: email@example.com.
The following examples demonstrate some of the power 'under the hood' of the Java platform. I will do what I can to improve these as I go.
ca.tecreations.apps.Deploy(Maintained / In Progress)
DailyCodeBackup(Stalled for Tasks)
SystemLauncher(Stalled for Requirements Analysis)
ca.tecreations.ClassPathAgent- Running Agents for better performance.
I won't mention any of the other samples, except for that they are worthy, working examples of code and should be studied by the developer for their educational or experimental use only.
These documentation pages probably won't change much with the exception of Deploy, as JPackage is adopted.