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(a)redhat.com> wrote:
Hi,
WRT WINDUP-459 <
https://issues.jboss.org/browse/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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."