You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Arcozen <ar...@gmail.com> on 2010/02/23 15:38:08 UTC
Ivy repository strategies for Javascript artifact
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
Re: Ivy repository strategies for Javascript artifact
Posted by Matt Benson <gu...@gmail.com>.
It's also possible you could deploy your zip directly and use e.g.
org.springframework.js.resource.ResourceServlet to serve up the
individual files. -Matt
On Feb 23, 2010, at 10:31 AM, Mitch Gitman wrote:
> Marco:
> 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
> contents.
>
> 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 <ar...@gmail.com> 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
>>
Re: Ivy repository strategies for Javascript artifact
Posted by Niklas Matthies <ml...@nmhq.net>.
On Tue 2010-02-23 at 08:31h, Mitch Gitman wrote on ivy-user:
> Marco:
:
> Just this sort of paradigm is already automatically supported with .war
> files and web containers. The WAR is the artifact, not its individual
> contents.
On the other hand Marco wrote:
> > 2) extract from zip archive every file needed and put it into the codeline
It might make sense to publish finer-grained artifacts if you want to
make them available in different pre-defined combinations/configurations.
-- Niklas Matthies
Re: Ivy repository strategies for Javascript artifact
Posted by Maarten Coene <ma...@yahoo.com>.
If you keep them as zip files in the repository, you can make Ivy unzip them automatically after a resolve using triggers.
Cfr. http://ant.apache.org/ivy/history/latest-milestone/settings/triggers.html
This way the repository zip files will also automatically get unzipped when running Ivy from within an IDE plugin, like IvyDE for instance.
Maarten
----- Original Message ----
From: Arcozen <ar...@gmail.com>
To: ivy-user@ant.apache.org
Sent: Tue, February 23, 2010 5:50:32 PM
Subject: Re: Ivy repository strategies for Javascript artifact
Thanks a lot Mitch! :)
I agree about your considerations.
Additional steps with Ant could help us during the build process, leaving
zip files in the repository.
2010/2/23 Mitch Gitman <mg...@gmail.com>
> Marco:
> 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
> contents.
>
> 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 <ar...@gmail.com> 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
> >
>
--
Le nuvole non possono nascondere per sempre il Sole
"Il passato è passato, il futuro è di là da venire. Fra
questi due nulla, uomo, alzati e conquista il tuo presente: l'unico tempo
che tu hai a disposizione".
Re: Ivy repository strategies for Javascript artifact
Posted by Arcozen <ar...@gmail.com>.
Thanks a lot Mitch! :)
I agree about your considerations.
Additional steps with Ant could help us during the build process, leaving
zip files in the repository.
2010/2/23 Mitch Gitman <mg...@gmail.com>
> Marco:
> 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
> contents.
>
> 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 <ar...@gmail.com> 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
> >
>
--
Le nuvole non possono nascondere per sempre il Sole
"Il passato è passato, il futuro è di là da venire. Fra
questi due nulla, uomo, alzati e conquista il tuo presente: l'unico tempo
che tu hai a disposizione".
Re: Ivy repository strategies for Javascript artifact
Posted by Mitch Gitman <mg...@gmail.com>.
Marco:
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
contents.
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 <ar...@gmail.com> 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
>