On Thu, Jun 9, 2011 at 3:10 PM, Garner, Shawn
<[email protected]> 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:[email protected]]
> Sent: Thursday, June 09, 2011 10:13 AM
> To: [email protected]
> 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
> <[email protected]> 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 [email protected] 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>
>>
>

Reply via email to