I updated https://issues.apache.org/jira/browse/IVY-209 with comments that
enumerate a number of use cases for directory structure.
On 1/4/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
The hierarchy is just a part of my artifact. I could do extra work
bundling and unbundling things, but its really working around the issue and
creating extra work in my case.
I did try John's approach out, and it actually does seem to work. I'm able
to do things like:
<artifact name="ext${file.separator}jetty-ajp" type="lib" ext="jar"/>
<artifact name="override${file.separator}configuration" type="conf"
ext="xml"/>
Which it really nice. It's letting me do exactly what I want to do and
seems to be handled correctly.
I'm not sure its actually intended by design, but it would be great to
preserve this in 2.0. This works extremely well for artifacts that you
store within Ivy that you don't intend to compile against, like config. It's
also great for artifacts you *do* compile against. In particular c++
artifacts, like header files, in ivy to build with the cc task to compile
native code. For these, the directory layout is important.
---
The permissions portion is another related issue. I think it'd be very
handy to store permissions - my main use-case being script artifacts.
One approach might be some metadata in the ivy.xml that let you mark an
artifact as executable and a helper in the retrieve/cache code that would
attempt to run cacls, or chmod or whatever. Another might be to look at
artifacts and store whatever properties about the file are available and
restore them on retrieve/cache is the user asked for it. I think the
metadata might be faster and more effective ultimately.
On 1/4/07, John Gill <[EMAIL PROTECTED]> wrote:
>
> I use this to get dependencies
>
> <dependency org="jboss" name="jboss" rev="3.2.7.cots">
> <artifact name="jbossall-client" type="client" ext="jar"/>
> </dependency>
>
> and I seem to remember using this once before
>
> <dependency org="jboss" name="jboss" rev="3.2.7.cots">
> <artifact name="someotherlib" type="server/all" ext="jar"/>
> </dependency>
>
> Not sure if you can publish like that though.
>
>
> On 1/4/07, easyproglife <[EMAIL PROTECTED] > wrote:
> >
> > I want to suggest a simple yet powerful idea:
> >
> > store all of your directory structure inside a ZIP file (Ant already
> has
> > core zip task) and publish it as a single artifact.
> >
> > This keeps both your project design and ivy design simpler.
> >
> > In your project, you don't have to deal with many configurations, and
> nor
> > with many retrieves when you use the published module. In my
> suggestion
> > you
> > just get the zip file the standard way (by ivy:retrieve or directly by
>
> > using
> > ivy:cachefileset) and unzip it using standard Ant task.
> >
> > easyproglife.
> >
> >
> > On 1/4/07, Xavier Hanin < [EMAIL PROTECTED] > wrote:
> > >
> > > Ivy does not support this kind of thing, but there's already an
> issue
> > > about
> > > directory publication, what could also be done is allow artifact
> names
> > > with
> > > slashes. You can submit an issue for that if you want.
> > >
> > > Xavier
> > >
> > > On 1/4/07, Eric Crahen <[EMAIL PROTECTED] > wrote:
> > > >
> > > > If I wanted to store some artifacts and preserve a directory
> > structure,
> > > is
> > > > there someway to do this?
> > > > For instance, I might have some ".xml" artifacts that have to live
> in
> > > > certain directories:
> > > >
> > > > conf/
> > > > base.xml
> > > > ext/
> > > > ext.xml
> > > >
> > > > I have several configuration packages that depend on one another
> and
> > > > ultimately, the
> > > > leaf nodes of the tree build different jars of configuration,
> where
> > some
> > > > config is shared.
> > > >
> > > > It seems that the closest I can get is to use a series of
> > > publish/resolve,
> > > > where I need
> > > > to change the patterns each time. Or I'd need to jar everything
> and
> > > > unjar/rejar when I
> > > > compile everything in the end.
> > > >
> > > > I tried just including /'s in the artifact names but Ivy does not
> > > respect
> > > > that as a file separator.
> > > >
> > > > --
> > > >
> > > > - Eric
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> --
> Regards,
> John Gill
>
>
--
- Eric
--
- Eric
