Re: New to Ivy question

When it comes to third-party dependencies, I hate to be reinventing the wheel, or at least reinventing the wheel from scratch. So I would look to do either of two things: * Depend on a public repository directly for those dependencies. * Create an enterprise repository whose third-party dependencie

dealing with potentially redundant resolves & paths

Gosh, I like to think I'm quite the Ivy expert, but I'm getting stumped by something pretty basic. I'm trying to avoid hard-coding the name of an Ivy configuration in my Ant build file when I do an ivy:resolve and an ivy:cachepath. Look at the "resolve-compile" target below for the property placeho

Re: dealing with potentially redundant resolves & paths

notice that I end up having to depend on another target which, as suggested by its name, sets my runtime dependencies classpath to the value of the compile dependencies classpath in the case where I do want to reuse. On Thu, Oct 23, 2008 at 10:10 PM, Mitch Gitman <[EMAIL PROTECTED]> wrote:

Re: copying a complete dependency hierarchy

Shawn, at the risk of not addressing your immediate question, I would take a step back and ask whether you're really doing the right thing by doing an ivy:install on a release. What an ivy:install gives you is a whole other Ivy repository. Every time you do another install, you wind up with another

Re: copying a complete dependency hierarchy

Ah, I had been assuming that you were creating a new Ivy repository on every ivy:install, not that you were installing to an existing repository. Sorry for my confusion. So let me (as a member of the community) attempt *an *answer to your question, even if it's not the *best *answer: "How can I ge

Re: No organisation provided error ??

Just guessing here... Go to the ivy.xml file for your project and check if the /ivy-module/info element specifies an organisation attribute. On Wed, Oct 29, 2008 at 1:22 AM, ferry97 <[EMAIL PROTECTED]> wrote: > > Hi, > I'm new with Ivy ... > > I'm trying to do a simple publish task and got the f

Re: Resolver or dependency

If project B depends on project A, then the only knowledge B has of the latest version of A is what's in the Ivy repository that the Ivy resolver is using. When you get right down to it, the extra functionality you're looking for is really the work of a continuous integration system. The sequence

Re: Resolver or dependency

> to test their code changes in both projects locally. > Changed project A is not published yet (even locally), but developer is > executing "ant test" of project B. Now it fails. > > > - Original Message > From: Mitch Gitman <[EMAIL PROTECTED]> > To: iv

Re: buildnumber Ant task & automated updates of ivy.xml

*Warning: really long post.* Jonathan, I can give some insight based on my experience. First off, just for perspective, the top-level decision at play is how to deal with integration versions, as covered in Best Practices. The two choices are: - "use a naming convention like a special suffix,

Re: buildnumber Ant task & automated updates of ivy.xml

Thanks again for the insights. Few brief comments inline below. On Thu, Nov 20, 2008 at 3:10 AM, Jonathan Oulds <[EMAIL PROTECTED]> wrote: > Let me try and deal with each of your points one by one and explain how I > am trying to solve each issue. > > - How to make ivy work differently when proje

Re: buildnumber Ant task & automated updates of ivy.xml

Shawn, I think you just offered much the same solution that I was trying to describe, just far more verbosely. Good to see people coalescing on the same wavelength. One small difference. While I had talked about creating a separate properties file just to hold the Subversion version number, you de

Re: buildnumber Ant task & automated updates of ivy.xml

Oh no, I wasn't referring to anything you were doing, Jonathan. I was making a general point, and really going back to what I was wanting to do in my original post: to modify the /ivy-module/[EMAIL PROTECTED] attribute in the ivy.xml file *in project source*. When you get right down to it, I should

Re: Noobie publishing question

OK, this answer is bailing on the way you're trynig to do things. You may want to try creating a second Ivy resolver in your ivysettings.xml just for publishing. Instead of a URL resolver, make this a filesystem resolver. This is presuming that the machine doing the ivy:publish has filesystem acces

Re: Noobie publishing question

No, not at all. Kirby's approach of using SFTP (or FTP) is fine. As for filesystem access, here's one possible ecosystem where a filesystem resolver would work fine: - The Ivy repository is on a Linux box. The permissions are to allow anonymous browsing but prevent anonymous uploads. - Th

buildnumber Ant task ignoring prefix attribute

Please forgive the prolific posting lately. I'm setting the prefix attribute on the *buildnumber *Ant task: But when I go to manually output the properties that are set, I see: ivy-buildnumber: [echo] ivy:buildnumber output: [echo] ivy.revision=1.1 [echo] repo.revision=${repo.r

Re: buildnumber Ant task ignoring prefix attribute

ease create a JIRA ticket including your build.xml and Ant > console output illustrating the problem. > > Maarten > > > > ----- Original Message > From: Mitch Gitman <[EMAIL PROTECTED]> > To: ivy-user@ant.apache.org > Sent: Sunday, November 23, 2008 12:23:08

not an Ivy problem per se—Subversion client Ant tasks

I've been wanting to incorporate some minimal Subversion interaction into my build script. To do so, I've been trying to get my build script to invoke the *svn *Ant task in the SvnAnt antlib. SvnAntis a sub-project of the Subclipse

Re: What configurations are selected when no configuration mapping is set in ivy.xml

Just for sanity's sake, let's suppose your modA has two configurations, default and test. As a practical matter, it's going to be highly unusual for you to want to leave out the conf attribute of the dependency element. The ivy.xml for modA might have a dependency: You're starting from defaul

Re: Using ivy.xml files to describe common module information

Jeff: At the risk of not directly answering your question, let me take a step back and make sure you really need to do what you want to. Let's say you have a Java project *coolweblayer *that will produce a module with organisation="coolteam" and module="coolweblayer". Let's say the info element of

Re: Using ivy.xml files to describe common module information

One small correction to what I just wrote. Noted inline below. On Sun, Dec 14, 2008 at 8:04 AM, Mitch Gitman wrote: > Jeff: > At the risk of not directly answering your question, let me take a step > back and make sure you really need to do what you want to. > > Let's

Re: Using ivy.xml files to describe common module information

ema to capture > common meta-data amongst releases for a given project. > > I was wondering if: > > - it makes sense to store common project information in an ivy.xml. > - Ivy will happily generate a ModuleDescriptor from such an ivy.xml file > (since I don't want to have

Re: Noob Question, Transitive Dependencies?

If you're putting those other JARs in the same location in your Ivy repository, then the easiest approach is to also make them publications in the ivy.xml in that location. Something like: ... Note that when your dependency specifies name="hibernate"-

Re: Noob Question, Transitive Dependencies?

The publications passage you cite below would go in the ivy.xml for your hibernate/hibernate module. The dependency element you cite below would go in the ivy.xml for the *dependent *module. I think that's the part of the equation you weren't getting. On Thu, Dec 18, 2008 at 1:23 PM, Griffith, Mic

trying to Ivy-fy the Ant script task

I'm trying to do some inline Ant scripting via the Ant *script *task. The same could go for the Ant *scriptdef *task . And I'm trying to make Ivy be the provider of all the libraries

Re: trying to Ivy-fy the Ant script task

uot;${user.home}/.ant/lib/[artifact].[ext] I tried to set the configuration so that only the commons-logging JAR gets copied over. On Thu, Dec 18, 2008 at 9:59 PM, Mitch Gitman wrote: > I'm trying to do some inline Ant scripting via the Ant *script > *task<http://ant.apache.org/m

Re: trying to Ivy-fy the Ant script task

give for this working now is that somehow I did. Consider the original query a false alarm. On Fri, Dec 19, 2008 at 4:26 PM, Mitch Gitman wrote: > Just had a "Well duh, no kidding" moment. I'm used to using the *ivy:cachepath > *task for establishing my classpaths from Ivy

Re: Clean way to differ between runtime and compile time dependencies? (So I do not include runtime deps in my war)

I haven't bothered to test this, so I may have gotten a detail wrong, but here are some small additions to your ivy.xml file to filter out the servlet API JAR: You'll notice that I introduced a couple configurations. O

Re: Clean way to differ between runtime and compile time dependencies? (So I do not include runtime deps in my war)

Few quick responses inline. On Sun, Jan 11, 2009 at 4:33 PM, Kent Larsson wrote: > Thank you for helping me out Mitch, I appreciate it! > > I see what you did with those two configurations. I'll retrieve them > all and create classpaths from their config directories then. I guess > one directory

Re: Best practices for setting up an ivy repository server

To the best of my knowledge, the closest thing I can think of to such a tutorial is a piece of advice on the "Best Practices" page in the Ivy docs. See the section "Use your own enterprise repository:" http://ant.apache.org/ivy/history/trunk/bestpractices.html What might be helpful, in an indirect

Re: IvyDE cache location

If you want to give each individual developer the ability to customize the location of their Ivy cache, one approach is to add the following line to your global ivysettings.xml: Then the user can define their own Ivy settings to their heart's content in USER_HOME/.ivy2/ivysettings.xml. Note: if

Re: IvyDE cache location

Nicolas, correct me if I'm misstating something, but I look at an ivy:retrieve-like capability as a nice-to-have but not necessary feature for IvyDE. IvyDE itself really just exists as a nice convenience, so that classpaths resolve correctly in Eclipse. How it does that--whether with ivy:cachepath

classpath issues: trying to consume Ivy API in an Ant task

I have a very, very simple Ant task that consumes the Ivy API. That is, in the Java code for my Ant task, I'm using Ivy classes. One class I had been trying to use was IvyAntSettings. Well, look what happened when I tried to cast a reference I found in the Ant project to an actual IvyAntSettings ob

Re: classpath issues: trying to consume Ivy API in an Ant task

51 PM, Mitch Gitman wrote: > I have a very, very simple Ant task that consumes the Ivy API. That is, in > the Java code for my Ant task, I'm using Ivy classes. One class I had been > trying to use was IvyAntSettings. Well, look what happened when I tried to > cast a reference I fo

Re: classpath issues: trying to consume Ivy API in an Ant task

gs in this classloader For now, I'm following the advice, "or redeclare your ivy:settings in this classloader." On Thu, Jan 22, 2009 at 8:12 AM, Mitch Gitman wrote: > Actually, let me try restating this query as a simpler question. Has anyone > tried writing their own Ant task t

Re: classpath issues: trying to consume Ivy API in an Ant task

> > > uri="antlib:org.apache.ivy.ant" loaderRef="ivy.loader" > classPathRef="ivy.classpath" /> > > > > This way, you can more or less choose where you put the jars I think... > > Maarten > > > > > - Original Message

Re: How to promote a set of artifacts

When I think of "promoting a build," I think of preparing a release. And when I think of preparing a release, it's hard not to think of it in terms of the version control system I'm using. Suppose I'm using Subversion and I'm using the typical Subversion single-project layout: * branches * tags * t

Re: IvyDE 2.0.0.beta1 does not download sources nor javadocs

I'd be curious how you were able to download the source and Javadoc in the first place. I'm not the best expert on what has changed with IvyDE, but ultimately, the Eclipse IvyDE is just an interface to Ivy, so it's a matter of making sure that, for a given module, you have a configuration that obta

Re: IvyDE 2.0.0.beta1 does not download sources nor javadocs

It looks like I know a little less than you do on this matter, but I'm guessing that this has something to do with the "Sources suffixes:" and "Javadoc suffixes:" entries in the Ivy preferences of Eclipse. My preferences show these as, respectively: -source,-sources,-src -javadoc,-javadocs,-doc,-do

Re: IvyDE 2.0.0.beta1 does not download sources nor javadocs

this configuration could be more flexible in the future - for > example to associate a single source ZIP with multiple JAR artifacts, > or specify a subdirectories as source or Javadoc roots. > For now, I can live with repackaging to resolove these issues. > > > Mitch Gitma

Re: IvyDE 2.0.0.beta1 does not download sources nor javadocs

That makes perfect sense now. The point that hadn't occurred to me was that, while the source artifact now has to be declared in the ivy.xml, the suffix is still needed to associate source artifacts with their corresponding classes artifacts. Thanks, Nicolas, for the detailed explanation. On Thu,

trying to configure the Hudson Ivy plugin

I realize I might better be posting this query to the Hudson users mailing list. And I probably will. I've installed the Hudson Ivy plugin on Hudson, the CI server. When I want to configure a particular job (project) to use the Ivy plugin, I go to the "Post-build Actions" section and check "Trigg

Re: configuration help

Shawn, I know this is not the answer you're looking for, and I would be curious to see a more "technical" answer than I'm giving, but if I were tackling your problem, I would actually create separate Ivy modules for client and server. client-vs.-server becomes a more fundamental splitting-off point

registering an Ivy listener

I'm interested in registering an *IvyListener *implementation to listen for an *IvyEvent *of some sort. Assume we're working within an Ant script. Now, I see that it's easy enough to register an *IvyListener ** programmatically*. Just obtain an *EventManager *like so: IvyContext.getContext().getEv

Re: registering an Ivy listener

er.java > > MyTrigger implements Trigger { > ... > } > > In ivysettings.xml > > > > > > > > I hope it will work, I haven't tried it out yet. > > Regards, > Garima. > > > On Mon, May 4, 2009 at 10:29 PM, Mitch Gitman wrote: >

Re: Published jars for test, pilot, and production environments?

Don't consider this an authoritative answer, and I know this isn't the answer you want to hear. But I tend to believe that the "best practice" approach to distinguishing between different statuses of the same module is to literally use different repositories. So you would have an integration repos

Re: Published jars for test, pilot, and production environments?

Alan, I agree that configurations are a powerful--indeed a necessary--feature of Ivy. But I would also maintain that Ivy confs are about features, not about the problem Paul is trying to address, which is distinguishing between integration and release builds. For that problem I believe the techniqu

Re: Published jars for test, pilot, and production environments?

Few responses inline. On Thu, May 21, 2009 at 10:37 AM, Vonnahme, Paul < vonnahme.p...@principal.com> wrote: > [OT] I wasn't aware you could use ant variables in the ivy.xml files. Very > good to know, and I'm sure it will come in handy as I continue to experiment > with ivy. > Small correction

Re: ivy settings, include, and offline mode

Offering a little different perspective from Geoff... I'm presuming you're using Ivy from within Ant. In that case, remember that you can put ${} Ant property placeholders in your ivysettings.xml file. You should know when you're online and when you're offline, so define an Ant property in the mas

Re: Multi-module dependency configuration

Gareth, I haven't fully digested you situation, but a sensible way to organize the confs would be to have your webapp's dependency on your library look something like so: Here, you're clearly separating the chain of dependencies for compilation from the chain of dependencies for packaging. On

Re: [ANNOUNCE] Apache IvyDE 2.0.0-final released

I'm trying to understand the use case for the "Resolve in workspace" feature. Let me take a guess at a use case and illustrate what I do now without this feature, and perhaps Nicolas or someone else can fill in how this feature could be an alternative, or whether I'm completely off-track. Let's sa

Re: [ANNOUNCE] Apache IvyDE 2.0.0-final released

posing that the superlibrary project would have to be open in Eclipse for the workspace resolve to work? 2009/7/15 Nicolas Lalevée > > > On Tue, 14 Jul 2009 20:54:22 -0700, Mitch Gitman > wrote: > > I'm trying to understand the use case for the "Resolve in workspace"

Re: multiple artifact confs: wanting AND instead of OR

Shawn, these are some great insights you're offering, but I don't see how configuration groupings would help in the situation Garima's describing. See the example with the JIRA issue: https://issues.apache.org/jira/browse/IVY-1097 Quote: "In this ivy file, *[axis=platform] is equivalent to windows

Re: multiple artifact confs: wanting AND instead of OR

ty > configurations in B to all configurations in C, the quality configurations > do not have to exist in C. > > > I realize this is very hard to understand over an email description. I > find this to be very useful and applicable in many situations. I have > tested this in t

Re: ivy promotion levels?

Shawn, from what I've seen and heard, I would say that #1 above is a bare minimum but #2 above is also recommended. However, I would rephrase #2 from: "set up separate resolvers so that each promotion level has its own top level directory such that promoting a module from one level to the next is l

Re: feature request: configuration intersections only implemented halfway

I would heartily second Garima's feature request. I'll describe below a potential error condition with the way configuration intersections are implemented now. It looks to me like adding what she's asking for in no way compromises the functionality Shawn already enjoys. It just more explicitly, cl

Re: feature request: configuration intersections only implemented halfway

Shawn, I think your last paragraph really captures the fundamental difference between your use case and the one I'm facing (which parallels the use case Garima broached): I don't understand Garima's request as putting the intersection logic into the section of the ivy.xml file like: means that t

Re: Ivy not downloading src / javadoc zips

Sky, that is not so. Gareth, since you're using Artifactory and hence a Maven repository, I know there are some extra hurdles to leap to get Ivy to recognize the weird way Maven locates source. If I recall correctly, Maven names the source and javadoc archives the same name as the binary. But I co

Re: Solution to native dependencies with Ivy

Jeffrey: I love the way you’ve presented this idea, but this is one idea I would be opposed to. The problem is that it confuses Ivy module descriptors with one particular application of Ivy module descriptors. Right now, the ivy.xml XML schema provides a powerful, expressive general-purpose langua

Re: Solution to native dependencies with Ivy

I'm not really familiar with this problem space, but adding a peer to source and javadoc for IvyDE integration--that sounds sensible to me. Regarding the additional description that would need to be present in an Ivy module descriptor to fully support a native library, again I've got to believe th

Re: Ivy feedback mechanisms for spawning builds...

Kevin, it sounds like you're thinking about the problem in the wrong way. Leaving aside the case of the Ivysvn resolver where Subversion is doubling as an Ivy resolver, your CI server should really be the party responsible for publishing to your shared Ivy repository. The thing that's triggering th

Re: Ivy feedback mechanisms for spawning builds...

ould > > configure Hudson to use a "build trigger" and build after another build > > takes place and utilize latest.integration (or similar) for the > > revision. > > > > Like I said... it feels wrong to have Hudson hold that configuration, > > but I >

I suspect I'm doing something I shouldn't

I have an ivy.xml file with some confs like so: Note that I have a public Ivy conf extending a private one. Can anyone say if I'm doing something valid or invalid--and then explain conceptually why? I suspect the answer is invalid because when I attempt to do an Ivy resolve on this published Iv

Re: I suspect I'm doing something I shouldn't

ation in Ivy's own ivy.xml will cause this: configuration not public in org.apache.ant#ivy;2.1.0-rc2: 'test'. It was required from org.apache.ant#ivy-caller;working test I'm beginning to suspect that there's something misconfigured about how I'm resolving. On Mon, Aug

Re: I suspect I'm doing something I shouldn't

e distinction here between a published ivy.xml and the working ivy.xml for the current project. On Tue, Aug 18, 2009 at 1:08 AM, Maarten Coene wrote: > And could you also tell us how you resolve? > > Maarten > > > > > - Original Message > From: Mitch Gitm

Re: I suspect I'm doing something I shouldn't

ion to publish a private conf. In my situation though, I think the answer is no. On Tue, Aug 18, 2009 at 8:19 AM, Mitch Gitman wrote: > Maarten, I'm essentially resolving against an Ivy module that I expect was > already published. And here's where I realize now that I'm doing s

Re: How to specify latest.any status correctly?

Martin, I can vouch that "latest.[any status]", as documented, does work. As for the 2), 3), 4) you cite, I imagine the reason Ivy allows any arbitrary text to work is because it allows arbitrary statuses and it doesn't know the full set of statuses at the time the dependency revision is parsed. I

Re: IvyDE automatically include javadoc and source

Speaking as someone who had struggled to grasp how IvyDE went about automatically finding source and Javadoc, I would agree that it's a lot easier to put the -source and -javadoc artifacts in the same Ivy conf as the binary--rather than giving them their own special Ivy confs. There's one ramifica

Re: How to specify latest.any status correctly?

both. On Mon, Aug 24, 2009 at 7:44 AM, Martin Weber wrote: > Tom Widmer schrieb: > > Martin Weber wrote: > >> Mitch Gitman schrieb: > >>> Martin, I can vouch that "latest.[any status]", as documented, does > >>> work. > > > >

Re: How to specify latest.any status correctly?

y supporting something like "latest" or "latest.*" would still be a nice shortcut. And there may be cases where you don't know your full set of statuses so you don't know if "latest.integration" is your "lowest" status. On Mon, Aug 24, 2009 at 9:06 AM

Re: checkModified and changing pattern

Carlton, since no one else has gotten back yet on your question, I would ask you, why not just run an experiment and see if changingPattern behaves any differently with or without lastmodified="true"? Actually, I'd be curious myself. The documentation is ambiguous on this score. My intuition says:

caching strategies--is there room for a new one?

Carlton's question came at a time when I was pondering the caching strategies Ivy implicitly offers. I can identify four: 1. Always trust the cache. 2. For a given resolver, never trust the cache, i.e. lastmodified="true" by itself. This makes sense if you can split your repositories into

Re: caching strategies--is there room for a new one?

know is what is the issue with promiscuous > versioning and what problem does tagging everything with -SNAPSHOT provide? > > I have a sneaking suspicion that the "changing" attribute is really a hack > to > cover a problem in repository management. > > -steve > > St

Re: Use of conf in a complex project

Travis, is it true that your master and subsystem confs are unrelated to each other, i.e. neither extends the other? If that's the case, you might have a simplified ivy.xml like this. Note that this is the ivy.xml for an EAR project but it could just as well apply to a WAR or JAR project:

Re: Use of conf in a complex project

Travis, you write: "The base level of the subsystem calls the build of each of its subprojects and publishes artifacts that are a merge of its subprojects." The idea of a "merge" kinda smells bad to me. >From the standpoint of Ivy, there is no such thing as a subsystem, even though there may be mo

Re: Ivy and Maven Repository with nth-level transitive dependencies in POMs

Jim, there are two approaches you can take to integrating your Maven repository. To build on what Geoff wrote, one is just to consume it directly, as if it were an Ivy repository, without converting it to an Ivy repository. So in your ivysettings.xml, you would have an entry like so, replacing the

Re: Use of the "branch" attribute with "info" tag

Gareth, let me speak as someone who does not have experience using Ivy-based branching because I have experience considering it and then thinking better of it for my particular needs. I can tell you, branching is a really sophisticated feature that demands the right use case. If you don't have a s

Re: sources as conf or type

I think it's fair to say that the established best practice is to NOT make a separate Ivy conf for things like source or Javadoc. For one thing, it becomes a transitive dependency nightmare to keep on having to create a source conf in your Ivy module and then have your source conf depend on its de

Re: sources as conf or type

Answers inline prefaced by MG: On Wed, Oct 28, 2009 at 2:15 PM, Niklas Matthies wrote: > On Wed 2009-10-28 at 13:29h, Mitch Gitman wrote on ivy-user: > > I think it's fair to say that the established best practice is to NOT > make a > > separate Ivy conf for things

Re: sources as conf or type

--regardless of whether they're in the same conf as the associated binaries. I would still go with the "make source a type" approach rather than the "make source a conf" approach, but certainly the latter approach is perfectly valid. On Thu, Oct 29, 2009 at 5:38 PM, Stephen Haber

Re: sources as conf or type

Question for Nicolas Lalevée. And Nicolas, please forgive me for putting you on the spot. (Actually, there's nothing stopping anyone else from taking a shot at this.) Set aside the whole matter of translating a POM. Nicolas, I know you're an advocate of the "source as type" approach in general as

Re: Help understanding dependency element include w/ matcher

Pete, one thing odd I notice about your dependency snippet is that you're specifying name="com.sun.jersey" but you're not specifying an org attribute. And actually, it looks like "com.sun.jersey" is really your org in this case, not the module as specified by the name attribute you're using. Just

Re: Help understanding dependency element include w/ matcher

Pete, I'm speaking a little off-the-cuff here because I don't quite have a handle on your constraints, but this strikes me as a case where you're using Ivy but you're not quite trusting Ivy. For one thing, if the WAR in question is being built by your own build system, then you have control over i

Re: Using Ivy to automate build

Jonathan, there's one statement from you that doesn't make sense: "...however in this particular case I need to build without access to the artefact [sic] repository." Maybe I'm misunderstanding what you mean, but you can't really use Ivy to build if you're not accessing an Ivy repository. I can

Re: Using Ivy to automate build

technique like the special buildlist Ivy conf I describe is something you don't need. Reason: you're already able to establish build order from the existing Ivy confs. On Wed, Nov 25, 2009 at 3:09 AM, Jonathan Oulds wrote: > Thank you for your reply, let me explain the raison d'etr

install task from Maven repo misses TRANSITIVE source artifacts

I've been trying to run ivy:install where the source repository is a Maven repository. I'm cognizant of the problem of binary, source, and Javodoc artifacts for the same module overwriting each other unless you take special care to distinguish them. So I made sure to incorporate a [type] entry in

Re: install task from Maven repo misses TRANSITIVE source artifacts

everything else just had: * jars I wouldn't be surprised if, upon doing an ivy:resolve directly against the Maven repository, the cache would experience the same information loss. On Fri, Nov 27, 2009 at 9:14 PM, Mitch Gitman wrote: > I've been trying to run ivy:install where the sour

Re: install task from Maven repo misses TRANSITIVE source artifacts

s. Anyway, if anyone has had any success in transitively retrieving source and Javadoc doing an ivy:install from a Maven repo, I'd be curious to hear how you accomplished it. On Fri, Nov 27, 2009 at 10:31 PM, Mitch Gitman wrote: > One other observation. I decided to associate the source ib

Re: install task from Maven repo misses TRANSITIVE source artifacts

ld be made configurable? This may go back to some of the technical issues with Maven integration raised in the "sources as conf or type" thread on this list, some of which I didn't fully grasp at the time. On Mon, Nov 30, 2009 at 4:15 PM, Mitch Gitman wrote: > Here's a little fu

Re: install task from Maven repo misses TRANSITIVE source artifacts

/old.nabble.com/pom2ivy-and-transitive-source-retrieving-to25112985.html#a25112985 On Wed, Dec 2, 2009 at 10:48 AM, Mitch Gitman wrote: > Well, this is one of those moments when I just want to slap myself on the > forehead. It should have been obvious why Ivy wasn't getting source an

Re: Preferred local repository?

Andreas, just to get the terminology straight, there are really three broad categories of repository: * local * shared/enterprise * public The term "local" in this context refers to a location on the developer/tool/client's own machine. I think you're using the word "local" to talk about shared re

Re: Preferred local repository?

Typing too fast. Meant: * filesystem (perhaps a Samba share or NAS mount) On Mon, Dec 21, 2009 at 9:14 AM, Mitch Gitman wrote: > Andreas, just to get the terminology straight, there are really three broad > categories of repository: > * local > * shared/enterprise > * public >

Re: Redundant JAR files in configuration groups

Burt, you wrote: "I personally think it would be nice if Ivy setup/provided ANT path elements behind the scenes based on the Ivy configuration groups." Ivy does offer this, just not behind the scenes. Look at the ivy:cachepath Ant task: http://ant.apache.org/ivy/history/trunk/use/cachepath.html T

Re: Transient dependency or specified dependency?

Alex, it sounds like you're getting JUnit 4.7 from a public repository and on that public repo JUnit 4.7 depends on the 1.1 version of Hamcrest matchers. If you always want to get Hamcrest 1.2, one thing you can do is specify an override as a sibling of the JUnit dependency: http://ant.apache.org/

Re: Getting a module's artifacts for build

Carl, no need to set special properties. Ivy's pattern matching takes care of finding the correct origin artifacts. Suppose in your project's ivy.xml you say you want to publish foo.jar like so: And suppose that, in the course of your build, you create a foo-1.0.jar in your dist directo

Re: Getting a module's artifacts for build

Carl, interesting use case. I can't think of any existing Ivy task that accomplishes what you're looking for. And I can't say I'd be motivated myself to go to the lengths you're going to to avoid redundancy. However, I can attest that I have run into trouble where I've changed the name of an artif

Re: Ivy repository strategies for Javascript artifact

Marco: If it's a versioned artifact that needs to be shared, then it's a good fit for Ivy. As to the question of whether to publish each individual file or the entire archive, once you get into supporting a directory layout where this file goes here and that file goes there and some files go in a c

Re: Publish ivydata for source type

Claudio, it's a really strange practice to be having one's Ivy cache double as an Ivy repository. It's almost like you're asking Ivy to blow up. You can avoid a whole lot of complexity by simply using a local repository that is distinct from your cache. The default Ivy settings--which are used if

Re: advanced ivy retrieve syntax

dek577, since no one else has gotten back to you yet, let me take a stab at this. I'm one to argue that, even though there's nothing literally wrong with using ivy:retrieve, its use suggests that you haven't quite fully embraced Ivy. The ivy:retrieve task is creating duplicate copies of your artif

Re: advanced ivy retrieve syntax

Replies inline. If it sounds like I'm going back and forth on what you're suggesting, I am a little bit. On Tue, Mar 2, 2010 at 2:14 PM, dek577 wrote: > > I'm not worried about the duplicate artifact issue. ivy:retrieve supports > the > symlink attribute that prevents duplicate copies. If the ob

Re: advanced ivy retrieve syntax

Juha, suppose you have an mymbeansmodule ivy.xml with the following passages: Then in your module that depends on mbeansmodule, you would have a dependency: The dev-only+mbeantypes configuration intersection will only get dev-only-or-mbeans.jar and not the other two jars. Does this work fo

  1   2   >