Generate configuration and deploy from command line about update4j

[mordechaim]

Thanks for reaching out and contributing to this project.

The idea to make a maven plugin sounds a great idea, and hope to have one for my project. But let me bounce off some thoughts.

First of all, by using the builder pattern in this project all over, you can easily add files through a DirectoryStream iterating all paths one by one; or by Files.walkFileTree() to iterate recursively all sub-directories and add them to the builder object (you won't use method chaining in this approach). Once all files are listed in the builder just invoke build() and everything gets done itself.

Now, I come from fxlauncher and I know its vulnerabilities, of which I tried to improve. One of them is that instead of making it as abstract as possible allowing unlimited extensions, everything is a "feature" instead (think of ignoressl or stop-on-update-errors). With this philosophy you are limited to the features the project has to offer. Limiting the power in this library to what the plugin offers partially defeats the purpose.

If someone really wants something automated they can create some sort of utility that uses the directory stream solution and customize the builder to the extent of their needs. (although this won't automatically run when maven builds the project, I know.)

I'm open for the idea though, what do you think?

[mordechaim]

Added an example in wiki how to list all files in a directory.

[philno]

I can see why you don't want to copy fxlauncher 1:1 and that security is important.

Limiting the power in this library to what the plugin offers partially defeats the purpose.

I believe you don't have to sacrifice extensibility for usability. After all, people are looking for this project because they want a prebuilt solution to keep their project updated.

Most people will end up looping over files with something like you added in the example. But where would the dev write this code in a common use case? It seems like it would be stupid to include the code in the project that should be updated - it is only used by the dev at build time and never needed by an end user. Ironically, you could bring up that very same argument against my proposal.

Creating a seperate project just to generate my update config is not that great either. Can you somehow include code in your project that will not be included in the resulting jar? Or what would you recommend instead?

[mordechaim]

I need some time to think about it, will try to come back soon.

[mordechaim]

After hours of thought I've finally come up with a creative solution that makes a perfect auto-generator and still remains with its full power.

The only limitation I can think of now is that currently you may have 2 libraries with exact same path if they target different operating systems; with this solution they will need distinct paths (optimally with -win, -mac, or -linux appended to the filename before the file extension).

I can create a new maven plugin, calling it something like configsync-maven-plugin. Or I might just use exec-maven-plugin as fxldemo does.

The key idea behind is that it won't generate config files, but instead sync them. The user will provide an existing config and it will just update the timestamp, size, checksum and if applicable, the signature attributes on every build. All other attributes remains untouched.

Here's the specifications:

• configuration: The existing config file; the only required property, all others are optional.

• basePath: Optionally override the base-path in the config to locate the files to sync with. This will usually be used to point to the Maven output directory. Libraries listed with an absolute path will not be affected. If this property isn't set, it will use the config's base-path to locate them.

• keystore: Optionally provide a properties file that lists these properties according to the standard properties format:

  • keystore: The location of a JKS keystore.
  • keystorePassword: The keystore's password, or empty if non.
  • alias: The alias of the private key.
  • aliasPassword: The alias' password, or empty if non.

  We have this info in a separate file so they should never end up on a remote git repository.

• addMissing: Whether files present under the basePath but are not listed in the config should be added automatically. If false, only libraries listed (even if just the path as set) will be synchronized. The configuration file itself will never be added. If the new file's name ends with -win, -mac or -linux before the extension, the os attribute will be set accordingly. Default is false.

• fileFilter: A regex string or some other file filtering scheme (as you suggested) to match against the library's path if addMissing is set to true. Ignored if addMissing is false.

• implication: New paths should be probed for a valid placeholder (using Configuration::implyPlaceholder), unless both the library and the property are os specific and target different systems. Valid values are the elements of the ImplicationType enum. Ignored if addMissing is false. Default is WHOLE_WORD. Ignored if addMissing is false. If supporting placeholders get overly complicated with mixed OS's, I might just drop supprot for auto added libraries (i.e. you'll have to do it yourself for the first time the library is added.)

• removeUnmatched: Whether files listed in the config but couldn't be located on the local machine should be removed from the config. If an os specific library's path uses an os specific property on a foreign system in a way that it can't be resolved, a warning should be emitted and not be synced but never removed. Default is false.

Let me know what you think about this, I'm passionate to get this done.

[philno]

I'm sorry for the delay, I didn't have much time this week. The specs look good; I think it is a great addition to the dev cycle to be able to sync existing configs.

The only thing unclear to me is the implication field. Is this for use with the properties placeholders as described in the wiki? So that you convert absolute paths/file names to representations that use existing placeholders? I would recommend naming that field something like usePlaceholders, probeForPlaceholders or placeholderMode then... The first 2 could be mistaken for boolean fields, though.

About exec vs own maven plugin: I think that with a standalone maven plugin it will be more simple to use / drop in an existing project, but you might need an own plugin for gradle then, too.

[mordechaim]

implication refers to the ImplicationType enum, which works in tandem with Configuration::implyPlaceholders. The naming might not be the best choice as I couldn't settle for something better.

It only applies for substituting a value with a key, so placeholderMode might be a slight misconception that it also applies the other way around. I can eventually change the name in a future release if it confuses people.

[mordechaim]

I'm currently busy on a contract and hadn't got any time to work on this. Will get to it as soon I'm done.

[mordechaim]

I keep getting stuck working on this because the Maven plugin development framework isn't really ready for java 9 modules. I keep on getting "split package" errors.

Although I can make it work using the classpath, I rely on package org.update4j.binding which has been explicitly exported for module org.update4j.maven so i can only access it as a named module.

Last resort is to export it as part of the API.

[mordechaim]

With release 1.2.2 that added FileMetadata::streamDirectory it should be easiest to use just Java code and maven-exec-plugin. Closing this issue.