1) Eventually yes, but for now I think it's fine to tie this information to our releases. Don't worry about this for now. Businesses don't typically use the newest JARs in the legacy apps they are trying to migrate ;) We'd probably even be fine with data from 3 years ago.

2) Just put it in our main windup/windup repo for now, in the same module as the addon you're building.

3) Bundle it in the same addon that provides the functionality for now, it will be easier to include in our build. We can worry about externalizing it later. This will also allow us to create a separate distribution just in case people are worried about file size. (With Maven JAR identification / Without Maven JAR identification)

4) Better to access on the classpath because you know its location within the classloader. We can worry about externalizing it later.

45 MB is not terrible. Nice job.

On Thu, Jan 22, 2015 at 5:00 AM, Ondrej Zizka <ozizka@redhat.com> wrote:

Hi,

WRT WINDUP-459 Rules request: Identify archives by their hash:

I guess this need (for bulk data from an external source) will appear in more rulesets.

We agreed that the best way to build, store and distribute the offline data will be best through artifacts, resp. through a maven repo.

1) Should it have independent release cycle? IMO it should.
2) If so - which git repo to put it to?
3) Can Forge/Furnace work well with ZIP artifacts? I.e, if there's a <packaging>zip</packaging>, can that be an addon?
4) If something is an addon, is it better to access it as a resource on classpath, or as a zip file, after figuring out where it is on local FS?

FYI, currently I just create a zip assembly windup-nexusindexreader-mappings-<V>.jar, next to windup-nexusindexreader-<V>.jar
The artifact size is 45 MB.

Regards,
Ondra

_______________________________________________
windup-dev mailing list
windup-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev

Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."