[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ant-dev
Subject:    Re: Publishing non-jar artifacts
From:       Carl Myers <cmyers () palantir ! com>
Date:       2010-08-27 20:55:55
Message-ID: 4C78265B.9040009 () palantir ! com
[Download RAW message or body]

Nicolas - Thanks, this info is very helpful.  I will investigate and be 
sure to let you know if I have any feedback.

-Carl

On 08/24/2010 02:03 AM, Nicolas Lalevée wrote:
> 
> Le 24 août 2010 à 00:47, Carl Myers a écrit :
> 
> > The "common and reusable" pattern is "I have a mess of files".  Why does it need \
> > to be more specific? 
> > Some examples:
> > 
> > 1. Our custom build system consists of several xml and properties files.  We \
> > would like to version our build system itself so that just a small ant script is \
> > used to pull the build system, then it is used to perform the rest of the build.  \
> > We would like to have the build system cached, then extracted to a certain \
> > location, after an ivy resolve, but this must work within the eclipse workflow \
> > and the CLI workflow (but, I suppose, either way it will be the dev. running an \
> > ant script probably, so maybe IvyDE doesn't need to support it explicitly)
> 
> quite off topic, but this is amazingly exactly what I want to put in place for my \
> projects. I think Easyant can help with that, but it is not yet there, so my recent \
> long mail on easyant dev mailing list. 
> > 
> > 2. Sql files, or other generated artifacts that are not Jars.  I have a directory \
> > full of Sql files that several packages need to depend upon. What I really want \
> > to do is "build" these sql files (run tests, validate them), then publish them \
> > using ivy.  But when other things depend on them, they need the files in a \
> > certain location, not on their classpath.  I want to be able to use a construct \
> > where I say "resolve this package and place its contents here". 
> > 3. Configuration only packages.  This makes sense once your codebase gets big \
> > enough - and similar to #2 above, you want to have a bunch of xml or properties \
> > files or whatever and you want them to end up in a location on disk, not in the \
> > ether. 
> > I think this is a very general (and useful) case for Ivy to solve.
> 
> So you need IvyDE to launch a resolve of some ivy.xml file, and then retrieve the \
> appropriate files in some defined place. IvyDE can already do that: \
> http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/retrieve.html 
> As I wrote, it is tied to the Java nature of a project, and an IvyDE classpath \
> container has to exist even if you don't use it. It should be useable though. 
> But for IvyDE 2.2, I have just implemented a retrieve mechanism for non java \
> project. So you would be able to right click on a project, select the Ivy menu and \
> then select "Retrieve 'sql files'". And with Clint Burghduff patch I integrated \
> too, the files get properly refreshed in Eclipse. I wouldn't consider the 2.2 as \
> production ready, but an early feedback on that would be appreciated. 
> Nicolas
> 
> 
> > 
> > -Carl
> > 
> > On 08/19/2010 01:00 PM, Nicolas Lalevée wrote:
> > > pe, Ivy doesn't care. I have been able to make Ivy manage dependencies between \
> > > flex projects. IvyDE on his side is mainly intended to be used in a Java \
> > > projects (probably too tied to Java,
> > 
> > --
> > Carl Myers
> > Palantir Technologies | Internal Tools Software Engineer
> > cmyers@palantir.com
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 

-- 
Carl Myers
Palantir Technologies | Internal Tools Software Engineer
cmyers@palantir.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]