Add ability to retrieve offilner file from coordiates

[jfdenise]

It would allow to directly create a maven repository from offliner file coordinates.

[jdcasey]

In the original design, we were trying to keep offliner very simple so we could avoid too much need for updates (it was planned for use in customer environments). Adding the ability to parse POM files and retrieve things based on that would add a LOT of extra moving parts.

If you're only talking about adding a list of GAVTC coordinates in a file and having offliner just retrieve those exact files (or maybe those and associated checksums like it does now), then I think that would be trivial to add. If you want to start with one coordinate and have it download all the stuff its POM references, then we're talking about a much harder problem, and one that might be better suited to using an adapted version of Maven or something.

[jfdenise]

@jdcasey , currently I will download the offliner file from maven then use it. Having the GAV to the offliner file is really not a critical requirement.

[psakar]

it's mean that instead of
java -jar offliner.jar [OPTIONS] FILE
you would be able to run
java -jar offliner.jar [OPTIONS] maven://G:A:V:C:T
eg.
java -jar offliner.jar [OPTIONS] maven://org:wildfly:17.0.0.Final:artifact-list:txt
which would download the artifact manifest from given coordinates and download artifacts specified in

That's an interesting idea. I think that would be pretty easy to do, actually.

…

On Thu, Apr 18, 2019 at 4:48 PM psakar ***@***.***> wrote: it's mean that instead of java -jar offliner.jar [OPTIONS] FILE you would be able to run java -jar offliner.jar [OPTIONS] maven://G:A:V:C:T eg. java -jar offliner.jar [OPTIONS] maven://org:wildfly:17.0.0.Final:artifact-list:txt which would download the artifact manifest from given coordinates and download artifacts specified in — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC4DFNETOKRKCIH5GQYHDCLPRDUCTANCNFSM4HG3MOLQ> .

[jdcasey]

Would you recommend we use the repository list given in the options to retrieve this? And I guess we would just use the first artifact-list.txt we found, and not merge results from all repos?

[jfdenise]

Yes, the first artifact we find. BTW, would that be possible to use a settings file instead of providing a list of repositories (this implies duplicating information we already have in the settings.xml file)? Something like:
java -jar offliner.jar --settings=my-settings.xml -Dcom.redhat.xpaas.repo.jbossorg maven://org:wildfly:17.0.0.Final:artifact-list:txt
Note: we would need to allow to provide a system property to enable a profile.

[psakar]

Would it be possible to use user maven settings by default if they exist ?
Re profiles activation may be just adding an optional option to specify list of names of profiles which are not active by default, but should be activated, would be more error prone and easier to understand for user ?

[jfdenise]

@psakar , I would like to control the path to the settings.xml in use. So an option to override the "default user one". I am fine with a list of profiles to activate.

[psakar]

@jfdenise it was ment in a sense
"use user maven settings ($USER_HOME/.m2/repository if exists and settings are not provided on command line". Only if not found and not provided on command line via --setings use urls from command line if specified or default ones (central + redhat ga)

[jfdenise]

@psakar , OK, just one point, why the default URLs are not: jboss-community-repository and securecentral ? Seems to make sense for community project. ga repo is product right?

[psakar]

@jfdenise up to @jdcasey to respond. I suppose because this project came into life because of EAP and other products

[jdcasey]

The project was originally designed to be used by customers to download offline-capable repositories using definition files that we would publish alongside the product release deliverables. The defaults reflect that use case.

WRT using Maven settings.xml, see #5. It's something we talked about doing, but it wasn't clear that anyone would be using this tool, much less need that feature. It was never supposed to be the plan that I would own this tool forever either, but here we are.