ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: Ivy repository strategies for Javascript artifact
Date Tue, 23 Feb 2010 16:31:06 GMT
If it's a versioned artifact that needs to be shared, then it's a good fit
for Ivy. As to the question of whether to publish each individual file or
the entire archive, once you get into supporting a directory layout where
this file goes here and that file goes there and some files go in a certain
directory, making each file a published artifact becomes unsustainable. Your
published artifact really becomes the ZIP.

Just this sort of paradigm is already automatically supported with .war
files and web containers. The WAR is the artifact, not its individual

For your libraries, the exploding of the files into their destination
location becomes an extra build/deployment step. Probably, this is going to
involve the use of two Ant tasks, ivy:resolve and then ivy:cachefileset, to
obtain the ZIP and do something with it.

On Tue, Feb 23, 2010 at 6:38 AM, Arcozen <> wrote:

> Hi everybody.
> In our company we need to share some javascript libraries.
> At this moment, we have some zip files containing a lot of js, css, images
> and resources.
> Well, we know that it's not just right:
> 1) download zip from our repository with ivy
> 2) extract from zip archive every file needed and put it into the codeline
> 3) continue build process
> In fact, we know that the "real" artifacts are js files (and every other
> resource in the zip file) and not their zip archive, but to put them in
> exploded or flat tree could be a problem (e.g. a lot of files to publish
> into a module).
> So, I would ask if there's a best approach to publish in the repository
> this
> kind of artifacts or if is it better keep them out of a central repository
> and use an other strategy to share them.
> Best regards
> Marco

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message