ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Publishing non-jar artifacts
Date Thu, 19 Aug 2010 20:00:45 GMT

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 <cmyers@palantir.com
>> <mailto:cmyers@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
>>    cmyers@palantir.com <mailto:cmyers@palantir.com>
>> 
>>    ---------------------------------------------------------------------
>>    To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>    <mailto:dev-unsubscribe@ant.apache.org>
>>    For additional commands, e-mail: dev-help@ant.apache.org
>>    <mailto: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
> 


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


Mime
View raw message