Le 19 août 2010 à 03:15, Carl Myers a écrit :

> Thanks Jason, that info is very helpful.
> 
> The reason why this is appropriate for the dev list is, I think, I am asking 
> "shouldn't Ivy/IvyDE do this natively?"
> 
> I guess you could call this a feature request (which I would be willing to 
> implement myself) to make Ivy better support non-jars.  I don't want myself 
> (and others) to have to write stuff in our build scripts to handle this if it 
> could be done by ivy itself.  So the discussion I want to start is, "is there 
> a reason why this isn't already included?  are people deadset against 
> supporting non-jar dependencies?"
> 
> Many java projects depend upon things which are not jars, so it seems like it 
> should be innate functionality, not something for which "a workaround happens 
> to exist, with some work".

I think Ivy and IvyDE already do support non-jar dependencies, as explained 
Jason. Ivy basically manage artifacts of any type, 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, I'll try to improve this soon), so it tries to managed artifacts that it 
can do something about it: jars to be added to some classpath, attach sources 
and javadocs. Other than that it cannot do much than Ivy does, resolve and 
retrieve in some place.

The problem about non well known typed artifact, is that they are unknown, then 
we don't really know what to do about them.

What exactly are your non-jar artifacts, and what do you do with them ? Is 
there really a common and reusable pattern, then yes we can add this feature to 
IvyDE.

Nicolas

> Thoughts?
> 
> Thanks!
> -Carl
> 
> On 08/15/2010 02:28 PM, Jason Trump wrote:
>> Hi Carl,
>> 
>> Not to nit-pick, but this is probably better a question for the users
>> mailing list than the dev mailing list.
>> 
>> I haven't tried this myself, but here's an idea:
>> 
>> 1) You can configure IvyDE to retrieve your dependencies into the
>> workspace on resolve.   It might be useful to create a special Ivy
>> configuration like 'ide' for these extra dependencies so that they go
>> into 'lib/ide/**'.
>> 2) You could then add an Ant Builder to your project, which executes a
>> specified ant target whenever the 'lib/ide' folder changes.  The Ant
>> Builder can also be configured to refresh the target directories in your
>> eclipse workspace where the resources have been unpacked.
>> 
>> here's some aging-but-still-relevant eclipse docs on setting up Ant
>> Builder:
>> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-93_project_builder.htm
>> 
>> 
>> HTH
>> jason
>> 
>> On Fri, Aug 13, 2010 at 5:23 PM, Carl Myers <cmy...@palantir.com
>> <mailto:cmy...@palantir.com>> wrote:
>> 
>>    Hey all,
>> 
>>    We use ivy for dependency management but now we need to depend on
>>    things that are not jars (as an example, a java keystore, a text
>>    file containing a license, a .sql file describing a db schema).
>> 
>>    Currently we have a custom build system in ant which leverages ivy
>>    ant tasks, but we also have developers using IvyDE in Eclipse.  I
>>    want to be able to publish, and consume, non-jar dependencies in
>>    both places.  This means Ivy would need to be able to "unbundle" the
>>    contents of a jar/zip/whatever to a specific location on resolve.
>> 
>>    I know that ant hooks exist to do things like this, but will they
>>    work in IvyDE?  Is that the way to go?  If this does require dev
>>    work, how would you expect it to be done to be most likely to be
>>    accepted as a patch?
>> 
>>    Thanks!
>>    --
>>    Carl Myers
>>    Palantir Technologies | Internal Tools Software Engineer
>>    cmy...@palantir.com <mailto:cmy...@palantir.com>
>> 
>>    ---------------------------------------------------------------------
>>    To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>>    <mailto:dev-unsubscr...@ant.apache.org>
>>    For additional commands, e-mail: dev-h...@ant.apache.org
>>    <mailto:dev-h...@ant.apache.org>
>> 
>> 
> 
> -- 
> Carl Myers
> Palantir Technologies | Internal Tools Software Engineer
> cmy...@palantir.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Reply via email to