ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: questions on ivy usage/setup
Date Thu, 09 Jun 2011 20:26:49 GMT
On Thu, Jun 9, 2011 at 3:10 PM, Garner, Shawn
<Garner.Shawn@principal.com> wrote:
> Your comments were immensely helpful.

Since I spent a good bit of time on that email, glad to hear it.  ;)

> I used filesystem resolver to resolve the Websphere jars.  I pointed it to the 3 different
directories and listed all the jars we needed.
> I used a separate cache and set the useOrigin to true which causes the cache to use symbolic
links instead of the jars.
>
>
> I tried to use a retrieve with symlink="true" but it didn't seem to make any difference.
>
> Is there anything special you need to do to get symlink="true" to work on a retrieve?

I didn't even realize the retrieve task would do this.  If you can
create a self-contained structure exhibiting your problem and feel it
demonstrates a bug, by all means submit it to the ASF JIRA instance.
Or if you want to create such just for examination purposes and can
make it available someplace I or anyone else reading might be
interested to see the problem in action.

Matt

>
> The documentation says something about useOrigin which I have set to true on the cache.
>
>
> I still would like to get the symlink to work on the retrieve but I did cachefileset
to work after a resolve.  I don't see why a symlink in the resolve should work any different
than a symlink in the cache that the cachefileset resolves by.
>
>
> Shawn
>
>
> -----Original Message-----
> From: Matt Benson [mailto:gudnabrsam@gmail.com]
> Sent: Thursday, June 09, 2011 10:13 AM
> To: ivy-user@ant.apache.org
> Subject: Re: questions on ivy usage/setup
>
> Hi, Shawn.  Not sure how much help I can provide, but bear with me and
> we'll see.  Comments inline:
>
> On Tue, Jun 7, 2011 at 11:14 AM, Garner, Shawn
> <Garner.Shawn@principal.com> wrote:
>> I am doing a sample evaluation of Ivy and seeing how we can incorporate it into both
our continuous integration build which uses ANT scripts today and also we'll need it to work
for developer's IDE (RAD) on their workstations.
>> We have some custom ant tasks which do quite a bit of work of dependency and classpath
resolution already but I'm not sure if custom ant tasks are the best thing.
>> I have a few questions on use of Ivy.
>>
>> Question 1.
>> We use Websphere
>
> My condolences.  :(
>
>> and a lot of our apps either depend on one of the runtimes of 6.1 or 7.0 and/or one
of it's JDK's 1.5 or 1.6.
>
> Ouch, beyond using WAS itself you're depending on its specific
> internals?  No wonder you're having trouble, afloat in these
> shark-infested and sparsely traveled waters.  As much as I might feel
> therefore that some of your questions are based on a landscape which I
> wouldn't work in to begin with, I will try to answer your questions
> with as little such commentary as possible.
>
>> I wrote an ivy file and installed it in my ivy repository (artifactory) which works
however:
>> 1) I don't like that it copies the JARs to my provided configuration directory (also
the cache) for each project.
>
> You don't like it copying jars to the cache, or just your local
> project directory?  Most often I see no reason to retrieve
> dependencies at all.  I just use cachepaths.
>
>> 2) I don't want to re-publish it to my repository (artifactory) if we apply patches
to the runtimes or jdks.
>
> I'm not sure I follow this.  Surely you're only compiling against the
> WAS runtime, so how often do their patches actually affect the public
> API?  This is an example of why you don't want to depend on
> proprietary APIs for your application server.  Since they don't make
> these publicly available in any kind of repository (last I checked
> anyway, which thankfully continues to recede into the haze of my aging
> mnemonic faculties), you take on the responsibility of managing this
> yourself.  I point this out because it's not that the work doesn't
> have to be done in any case, but now it's you--and every other team in
> the same boat, independently--who has to do it.
>
>> I'd like to use the FileSystemResolver and use symbolic links however it doesn't
seem like it's setup to use something that's organized in an Ivy repository layout which Websphere
does not obey whatsoever.
>
> I can't quite parse the above, but it smells like you're on the trail
> of something doable...
>
>> Do I have to write a custom resolver to do this?  If so is there any documentation
on how to do this?
>
> I would doubt that you'd have to go so far.  I don't know of any
> specific "how to write a custom resolver" tutorial, but at the end of
> the day I'm mostly just a "top-layer" Ivy user myself; maybe someone
> else knows of such.
>
>>
>> Question 2.
>> Currently we build EJB, Web Projects, and Utility Jars that depend on Jars in the
EAR file.
>> Sometimes it's just Jars that contain properties files or generated content that
is generated from a temporary project then jar'd up and no formal project is kept.
>> Is there any way to find (resolve, retrieve) those jars without publishing them?
 It seems kind of silly to publish/resolve/retrieve them to the repository if they are only
ever used in building one ear.
>
> Create the simplest possible temporary filesystem repository as part
> of your build, populate it, and include it in your ivy-settings when
> you resolve?  You can use caches:cache:ttl to more or less disable
> caching for the artifacts.  Or (probably what I would do) bypass Ivy
> for this step.  You can build the ear with whatever jars you like,
> from Ivy or otherwise, no?
>
>>
>> Question 3.
>> How do others handle modifying the MANIFEST.MF file for Class-Path attribute?
>
> Again, ugh.  I don't do much with EARs; is Class-Path necessary in
> that world?  I don't believe in manifest classpaths myself.  That
> said...
>
>> My understanding is unless the EJB, War, or utility jar in the EAR declare it in
their manifest file that Websphere won't load it.
>> With the dynamic nature of ivy I expected there to be something to help with this
but didn't find it.
>> Sometimes you need a runtime jar declared in there and sometimes you need a compile
or default config jar in there.
>> It would be nice if there were a manifest section and you could generate the manifest
from the dependencies somehow.
>
> Like with Ant's jar:manifest element, manifest task, and manifestclasspath task?
>
>>
>> Question 4.
>> I have my artifactory repository installed locally I'm sure everything is cached
in my local cache and also in artifactory.
>> However if I disconnect my laptop from the internet (I know it's weird today) I would
like it to retrieve everything from the cache if it can't connect.
>> It seemed like my builds would fail if I was disconnected.
>> Is there a way to do this if there is no internet connectivity?  I wasn't seeing
any configurations to say default to local cache if it's there.
>> Currently I'm using the URL  resolver pointing to artifactory for local projects
(internal projects) and another ibiblio resolver point to artifactory for remote repositories.
>>
>
> I'm pretty sure there are ways to use Ivy in offline mode, but I've
> never gotten around to finding out what they are personally.  :|
>
> HTH,
> Matt
>
>>
>> I appreciate any help or advice others have on this.
>> Shawn
>>
>>
>> </pre><br>-----Message Disclaimer-----<br><br>This e-mail
message is intended only for the use of the individual or entity to which it is addressed,
and may contain information that is privileged, confidential and exempt from disclosure under
applicable law.  If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received this communication
in error, please notify us immediately by reply email to Connect@principal.com and delete
or destroy all copies of the original message and attachments thereto.  Email sent to or
from the Principal Financial Group or any of its member companies may be retained as required
by law or regulation.<br><br> Nothing in this message is intended to constitute
an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or
the Electronic Signatures in Global and National Commerce Act (&quot;E-Sign&quot;)
unless a specific statement to the contrary is included in this message.<br><br>While
this communication may be used to promote or market a transaction or an idea that is discussed
in the publication, it is intended to provide general information about the subject matter
covered and is provided with the understanding that The Principal is not rendering legal,
accounting, or tax advice. It is not a marketed opinion and may not be used to avoid penalties
under the Internal Revenue Code. You should consult with appropriate counsel or other advisors
on all matters pertaining to legal, tax, or accounting obligations and requirements.<br><pre>
>>
>

Mime
View raw message