lf of the required
> artifacts. The artifacts for the "other" JRE wouldn't be available to
> publish. I'd prefer not to make changes to the build process to build &
> package two completely separate artifact sets. Ideally running Ant with
> the appropriate JAVA_HO
It seems to me this is a classic use case for Ivy confs. So your ivy.xml
might specify:
< configurations>
This way you can have everything in the same Ivy module with the same
version and the same branch in the same repository--because, in fact,
Since no one else is fielding this question just yet, I'll go ahead. Ivy
has three predefined statuses, where the status attribute appears
/ivy-module/info in an ivy.xml file:
integration
milestone
release
Even though Ivy in no way enforces this, the presumption is that the
integration status repr
If no one else is biting, I'll try to field these questions.
You ask: " Does (Ivy) check online what tha latest version is in the range,
or does it
check if there is an compatible version available in the local Ivy repo?"
First some terminology. When you say local Ivy repo, what you're really
tal
ize later. And even then, you should only be
creating a cache and trusting it for those dependencies (like third-party
libraries) that never change within the same version.
On Thu, Nov 29, 2012 at 11:18 PM, David Weintraub wrote:
> On Nov 29, 2012, at 12:32 PM, Mitch Gitman wrote:
&g
Let me take a stab at addressing your immediate problem, even though I
don't have a direct answer. But then I'm going to suggest a different
approach that avoids that problem.
Frankly, I've never used configure, only settings. The configure
documentation explains the primary difference (basically
If A and B and C are all their own Ivy modules with their own ivy.xml
files, then you should look into using the ivy:buildlist Ant task to do the
parent multimodule build. However, even then, you're letting the parent
build build everything unless you state otherwise. Since you're building
from sou
Your question is a bit ambiguous, so let me not so much answer it as make
two points to get the terminology and concepts straight.
When you talk about skipping the resolution of the external artifacts, what
you really should be saying is that you're still doing an ivy:resolve, just
you're trusting
Nicolas is reminding me of some context I left out of my original answer.
Certainly, Ivy settings should be reusable in IvyDE or the equivalent
plugins for other IDEs. Certainly, Ivy settings should be able to stand on
their own independent of "the build."
For this, I've found that it's best to ex
For this life of me, I can't find this in the Ivy documentation,
but--assuming you're using Ant and the ivy:settings Ant task--Ivy will
consume all the containing Ant Project's properties as Ivy variables, as
needed.
So what you could do is define just the following in your ivysettings.xml:
http:/
A good practice is to have the fact that a version can change, even if
rarely, be reflected in the version number itself. So you might have a
-SNAPSHOT or -dev suffix or a -_timestamp_ suffix.
Beyond that, it's a good idea to publish the module with a status that
indicates that it is an integratio
27;s a
final 2.3.0 release.
I will file a JIRA issue for this. I'm still trying to produce a pared-down
use case for the buildlist+extends issue. Once I have that, I'll produce a
JIRA issue for that.
On Mon, Jun 11, 2012 at 10:07 PM, Mitch Gitman wrote:
> I adapted src/example/
ork. Not that this is a desired state of
> affairs, but at least it isolates the problem to the interaction between
> buildlist and extends.
>
>
> On Thu, Jun 21, 2012 at 9:23 PM, Mitch Gitman wrote:
>
>> Over a week ago, I'd sent out a message to this list, "b
problem to the interaction between
buildlist and extends.
On Thu, Jun 21, 2012 at 9:23 PM, Mitch Gitman wrote:
> Over a week ago, I'd sent out a message to this list, "buildlist task
> chokes on absolute path to parent Ivy module." I'd found that the extends
> feat
Over a week ago, I'd sent out a message to this list, "buildlist task
chokes on absolute path to parent Ivy module." I'd found that the extends
feature worked fine with an absolute path to the parent ivy.xml if I was
building any single Ivy module, but the buildlist task would fail to find
the abso
See: "I'm seeing this with Ivy 2.2.0." I'll see what happens with 2.3.0-rc1.
On Wed, Jun 20, 2012 at 12:13 AM, Jean-Louis Boudart <
jeanlouis.boud...@gmail.com> wrote:
> Which version of ivy are you using ? Work as been donne on 2.3 to fix those
> kind of problem. As far as i know 2.3 is not yet
manually."
On Tue, Jun 19, 2012 at 4:19 PM, Mitch Gitman wrote:
> Answers inline prefaced with MG:
>
> On Tue, Jun 19, 2012 at 3:48 PM, Joel Dice wrote:
>
>> Hi Mitch,
>>
>> Thanks for your response. Please see my comments below.
>>
>>
>>
Answers inline prefaced with MG:
On Tue, Jun 19, 2012 at 3:48 PM, Joel Dice wrote:
> Hi Mitch,
>
> Thanks for your response. Please see my comments below.
>
>
>
> Yes, that's what happens on the CI server. Are you suggesting that each
> developer run a CI server on his or her development machi
So many of these issues are taken care of with best-practice use of a
continuous integration server that publishes integration versions of the
various modules to a shared Ivy repository. The Ivy caching strategy for
integration versions should be to never trust the local cache and always
check for
ut if this rings any bells, I'd be glad to hear.
On Mon, Jun 11, 2012 at 11:13 AM, Mitch Gitman wrote:
> I'm using the parent Ivy module feature with the ivy.xml
> /ivy-module/info/extends element. This works just fine whether I use a
> relative path or an absolute path for the
I'm using the parent Ivy module feature with the ivy.xml
/ivy-module/info/extends element. This works just fine whether I use a
relative path or an absolute path for the location attribute that locates
the parent ivy.xml. When I go to run ivy:buildlist, however, it only works
with the relative path
Two steps here. And there are many variations on these two steps, some
potentially better than what I describe here.
First, just as a general rule, it's a good idea to configure your
continuous integration (CI) server builds consistently with how you
configure your local developer builds. This pri
Quick reply. It is possible to associate a particular organisation or
module with a particular resolver, but it's a really advanced bit of
configuration, and I don't recall offhand what it is. I remember having to
do this once myself, but it was for a certain module or org for which I had
no choice
On Project1, you could make use of the ivy:resolve Ant task to get
Project1's dependencies. Then there's an ivy:cachefileset Ant task which
could be used to get all the files belonging to the dependencies. You'd
probably want to set transitive="false" to only get the direct
dependencies. From here
I'm using IvyDE 2.1.0. I'm defining Ivy settings on a per-Eclipse-project
basis, and in doing so, I'm filling in the "Property files:" field with a
sequence of comma-separated properties file paths. I'd been expecting that
the ordering of the properties files would have significance and that the
de
You want the artifact's simple name and the extension separate because, for
one thing, typically when you go to publish the artifact you'll be
inserting the revision into the filename. The actual filename won't be
foo.jar, it will be something like foo-1.0-20111201114253.jar.
Also, there's the add
Ah, I think I found a possible cause of my latest problem. I go to open up
the source JAR and all I see is .class files.
On Tue, Oct 18, 2011 at 3:01 PM, Mitch Gitman wrote:
> Great. Thanks, Nicolas.
>
> Another IvyDE question comes up. There are some Ivy modules which I do
> contro
27;ivy.xml[*]' which dose not
allow modifications to source attachments on its entries."
Anyone recall what that is a sign of?
2011/10/18 Nicolas Lalevée
>
> Le 18 oct. 2011 à 23:00, Mitch Gitman a écrit :
>
> > Archie, thanks for the alternate approach. In case I stil
what you want to do would be an easy
> specific case.
>
> -Archie
>
> On Tue, Oct 18, 2011 at 12:27 PM, Mitch Gitman wrote:
>
> > It looks like I'm going to have to write a custom Ivy resolver. I want to
> > consume modules that contain both a *.jar file an
It looks like I'm going to have to write a custom Ivy resolver. I want to
consume modules that contain both a *.jar file and a *.src.zip file but
where the ivy.xml doesn't specify any publications. Unfortunately, these
modules are already published to a shared location and I can't just go and
blow
27;re
prepending.
2011/10/14 Nicolas Lalevée
>
> Le 14 oct. 2011 à 07:05, Mitch Gitman a écrit :
>
> > I'm having some interesting experiences with IvyDE 2.1.0 while trying to
> > apply properties files to the Ivy settings I want to use.
> > First the merely annoyi
I'm having some interesting experiences with IvyDE 2.1.0 while trying to
apply properties files to the Ivy settings I want to use.
First the merely annoying interesting experience. If I go to click the File
System... button under "Property files:", the dialog box that shows up
filters by *.xml file
Following up Keith's response...
Certainly, it's a good practice to use a revision suffix to distinguish
integration builds from milestone/release builds. For example:
1.0-SNAPSHOT as opposed to 1.0-alpha1 or 1.0 (release)
And technically, you can make a property placeholder part of a
dependency@
The best and most common approach I'm aware of for handling this is to have
your Ivy settings including three different Ivy settings files, one for each
stage/status. Which settings to include is determined by a property. The
default value, and the one developers and the dev CI server would use, wo
NamespaceSchemaLocation="
> http://ant.apache.org/ivy/schemas/ivy.xsd";>
>
>
>
>
> If that fails, I don't know how anybody is using this successfully.
>
> -Kent
>
> -Original Message-
> From: Mitch Gitman [mailto:mgit...@gma
mmon libraries like junit.
> That is the one I tried to make Jenkins+Ivy build solo, and failed with the
> stack trace I just sent out.
>
> So Ivy is throwing the exception on the simplest possible ivy.xml I can
> provide, with or without the revision included.
>
> -Kent
>
&
15
> According to http://wiki.jenkins-ci.org/display/JENKINS/Ivy+Plugin this
> uses ivy 2.1.0 internally.
>
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:noNamespaceSchemaLocation="
> http://ant.apache.org/ivy/schemas/ivy.xsd";
>xmlns:e="http://ant.apache.org/ivy/extra";>
&
.innerRun(FutureTask.java:269) at
> java.util.concurrent.FutureTask.run(FutureTask.java:123) at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
> at java.lang.Thread.
First a little devil's advocacy that I'm going to contradict soon enough. If
all you have is six projects, you might find it easier to manually configure
the build order using Jenkins's own triggering configuration. You're
introducing some moving parts--and demanding some extra expertise on your
en
On your resolver, in addition to checkmodified="true", specify:
changingPattern="*" changingMatcher="glob"
This will check if your published artifacts have changed even if your
ivy.xml hasn't. No guarantee this will do the trick, but worth a shot.
Your attempt to control this with overwriteMode="
Let me share some of my own notes, if this helps.
The checkmodified attribute only applies to the Ivy file (or, my
understanding is, the POM as well)--and to the timestamp of the file.
The checkmodified feature, in itself, checks the metadata only (the ivy.xml)
because the ivy.xml might be gettin
uot;
> changingMatcher="regexp"
> checkmodified="true"
> m2compatible="true">
>
> But sadly, as you suspected, Ivy does not treats pom.xml like ivy.xml in
> this regards...
>
>
> On 14 January 2011 17:21, Mitch Gitman wrote:
&
t;>
> ...
>
> Did I miss something here or ?
>
> Also, you mentions there would be several way to do so, would mind
> elaborate
> (quickly) ? I think it would help me have a better grasp of Ivy (at least
> regarding how I use it).
>
> Thanks !
>
> On 13 January
There are a few different ways to do this. The way I would recommend is to
specify the following attributes on the resolver in question in your Ivy
settings:
changingPattern="*-SNAPSHOT" changingMatcher="glob"
This way Ivy doesn't trust its cache for anything with a -SNAPSHOT suffix.
On Thu, Jan
Yes, I’m briefly making the distinction between the Maven model of a main
artifact plus classifier artifacts and Ivy’s ability to publish any number
of arbitrary artifacts. And I’m pointing out how dependent projects are
depending on Ivy modules rather than artifacts, and how the actual artifacts
a
Thanks to Maarten. Apologies to Martin. I did misinterpret Martin's answer
after all. Yes, this is a critical feature. Certainly when you're
prolifically versioning CI builds (whether with a timestamp or buildnumber),
you should be replacing dynamic revisions. And no, I don't recall off the
top of
Martin, at the risk of turning this into the maven-user list, you can indeed
specify dynamic version constraints on Maven dependencies. See:
http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-version-ranges.html
Here's how you might specify the equivalent of 4.+ in Maven, th
Good point. The potential to decouple metadata and actual artifacts is a
nice feature. Might also be worth mentioning the url attribute of the
/ivy-module/publications/artifact element in ivy.xml module descriptors.
On Tue, Jan 4, 2011 at 11:39 AM, Archie Cobbs wrote:
>
> I think a nice feature
I’m doing a presentation on Ivy for my local Java user group. The intended
target audience: developers who are new to Ivy but have hands-on experience
with Maven dependency management. Actually, I’m pairing this talk with a
colleague’s talk on Maven 3. See:
http://seajug.org/
Of course, I’m making
Here's something I was able to quick slap together for moduleB. I can't
vouch that this is precisely what will work, but at least it should be a
starting point that someone else can refine:
http://www.w3.org/2001/XMLSchema-instance";
version="2.0"
xsi:noNamespaceSchemaLocation="http://ant.apache
You can specify transitive="false" on a dependency. Alternatively, you can
specify transitive="false" on a conf such that all the dependencies that are
depended upon via that conf will not be resolved transitively.
By the way, it's better to think of any Ivy module not literally as a JAR
but truly
It looks like your problem has to do with your specifying this in your
dependent projects:
As opposed to this:
I'm kinda puzzled that Ivy is finding anything for the artifact you're
specifying. It's not like you're secifying a file called
jboss-compile-all.
when you only need a subset of dependencies for compiling your main
code.
Even then, there's got to be a bit of a slow-machine factor here, as you
indicate.
On Thu, Nov 18, 2010 at 5:40 AM, Ole Langbehn
wrote:
> Hi Mitch (et al),
>
> thanks for the answer. Let me give you some mo
I would recommend using ivy:cachepath over ivy:retrieve. With retrieve,
you're doing an extra copy of the dependencies, which leaves you vulnerable
to the files getting out of sync. Without seeing your Ivy settings, I can't
say why things are slower on cachepath or retrieve. If I understand
correct
I would recommend doing a combination of the first and second approaches.
Suppose you go by Ivy's three default publication statuses:
* integration
* milestone
* release
Then you can have separate integration, milestone, and release repositories.
This way you're assured that there's no way tha
interested me in Ivy in the first place.
>
> Any other notions? Anyone?
>
> David Sills
>
>
> -Original Message-
> From: Mitch Gitman [mailto:mgit...@gmail.com]
> Sent: Friday, October 22, 2010 12:29 PM
> To: ivy-user@ant.apache.org
> Subject: Re: Multipl
My guess is what's going on is it's settling into a default behavior where
it's just publishing the artifact that has the same name as the module.
What I notice about your artifact elements that's a little off is that
they're not specifying a type attribute or (this may be the real problem) a
conf
I recall suggesting on this list the introduction of an exclude-type
attribute on post-resolve tasks (retrieve, cachepath, cachefileset). But
certainly, the type attribute, which implicitly does an include, works as
long as you know what types you want to include.
I do have to take issue one part
This is something I stumbled on myself, but depending on
"latest.integration" actually resolves a module with a status of integration
OR GREATER. So, using the default set of statuses, "latest.integration" will
get the latest module, whether its status is release or milestone or
integration.
The d
Well, I'm kinda shifting from "opposed" to "open to it." The more I think
about it, the more I can see that Archie's use case isn't a case of Ivy
being overly helpful.
But Archie, can you or anyone else articulate in your own words the rules of
latest-compatible? The current brief description in t
Please forgive the tangent. Here's what the documentation has to say about
"latest-compatible":
this conflict manager selects the latest version in the conflicts which can
result in a compatible set of dependencies. This means that in the end this
conflict manager does not allow any conflict (like
Fortunately, we're not arguing here whether there should be a
"latest-compatible" strategy. It's already there.
Frankly, I'm very happy that "latest-revision" is the default. I like it
when a framework or component does the "dumb" or literal thing rather than
the "smart" or magical thing. If you'r
Scott, if you're getting something from repository A and pushing it out to
repository B, you don't want to cut out the middleman that is the Ivy client
and the Ivy cache.
So I would recommend:
1. Do an ivy:resolve of the module you care about in repository A. I imagine
this would be with transitiv
I’m using Ivy 2.2.0-rc1. I have a filesystem resolver on which I’ve
specified checkmodified=”true” so Ivy checks the timestamp. I want to place
this resolver inside a chain resolver where the one other child resolver in
the chain does trust the cache. Here’s what I want:
I
And what does ${ivy.revision.something} show you? Not ${ivy.revision}.
On Wed, Aug 25, 2010 at 11:42 AM, Timothy Aston wrote:
> Tried setting the resolveId, still no workie. :(
>
> The result is the same, ${ivy.revision} is "working".
>
>
> -Tim
>
> [image: Inac
On the ivy:resolve, try specifying resolveId="something". Then echo
${ivy.revision.something}.
The ivy.revision property is referring to your current working module, not
the one being depended upon and which you're resolving against.
On Wed, Aug 25, 2010 at 10:17 AM, Timothy Aston wrote:
>
>
> I
Bumping this to the top to see if I can get any takers. I'm particularly
interested in seeing how anyone was able to work a timestamp or buildnumber
into the mix and whether that needed a custom revision strategy.
On Sun, Aug 22, 2010 at 4:19 PM, Mitch Gitman wrote:
> I'm grappling
I'm grappling with some of the choices surrounding integration versions.
One assumption I want to make is that non-integration versions—versions that
represent releases—do not have any special suffixes. So I would release
version 2.0 of something rather than 2.0-FINAL or 2.0-RELEASE or something
l
Nate's got a better answer than I do for the situation where the various
different platforms' artifacts belong in the same Ivy module. So maybe the
question comes down to whether (A) the different platforms represent the
same Ivy module that gets published together and versioned as one and can
coex
Not sure of this, but it's worth a shot. I'm presuming that you did one
ivy:resolve with the one Ivy settings and another ivy:resolve with the other
Ivy settings. Try giving both these resolves their own unique resolveId
attribute value. Then specify the respective resolveId attribute values in
the
One best practice, I believe, is to coordinate the
/ivy-module/i...@statusattribute with your environment. The typical
status values are:
integration
milestone
release
This means that, when you're invoking ivy:deliver and ivy:publish, you're
publishing with the status appropriate for the environme
Forgive me for nitpicking terminology, but JIRA usage aside, this is not so
much a bug to be fixed as a feature request. And I would argue against this
feature request for the same reason I'd argued almost exactly a year ago
against making "platform" a first-class citizen in the Ivy module descript
Stephen:
It's good to keep in mind what's meant by "newer." I'm assuming you haven't
modified Ivy's latest strategy. The default latest strategy is the built-in
"latest-revision", so by default Ivy looks only at the revision, not the
timestamp. There is a built-in latest strategy called "latest-tim
This reminds me. If there is one "repository" (in the broader sense of the
word) that really embraces the intersection of OSGi and Ivy--not to mention
Maven--it is the SpringSource Enterprise Bundle Repository:
http://www.springsource.com/repository/app/
Every JAR in the SpringSource EBR is an OSG
Scott:
I can offer some perspective on your second item. If you're considering
having two separate caches on the same client just to distinguish between
two different resolvers, that's a bit like wanting to put legs on a car, or
wheels on a horse. Better to ask how to get things working under the
e
Thomas, your provided conf does specify transitive="false", correct? It
should.
Side note. Not that this is your problem and not that there's anything
literally wrong about what you're doing, but I'd recommend using a
combination of ivy:cachepath and ivy:cachefileset instead of ivy:retrieve.
Then
Nick, forgive the semantics point, but when you talk about flushing the Ivy
cache, you're really talking about cleaning it. And cleaning is something
you do either through the brute-force ivy:cleancache task or, more
precisely, manually yourself or via a custom script. There's no real concept
of fl
Nathan, try sticking [type] somewhere in your artifact and ivy patterns and
see if that works. If you don't want [type] in your ultimate destination
pattern, you would have to settle for your ivy:install destination being a
kind of intermediate repo.
On Thu, May 27, 2010 at 9:26 AM, Nathan Franzen
Valerie, the solution I like for this problem uses the include and property
elements of the Ivy settings schema, and actually it's not far off from what
you describe, despite your misgivings. So you might specify in your
ivysettings.xml:
So by default, you include the Ivy settings for you
As long as we're talking about public Ivy repositories, this is a good
opportunity to give a shout-out to the SpringSource Enterprise Bundle
Repository:
http://www.springsource.com/repository/app/
Do note that the various non-Spring artifacts published on Spring's Ivy repo
are not literally the or
se "*(public)"
> for publishing.
> Cfr. https://issues.apache.org/jira/browse/IVY-1171
>
> I did a quick test and it seems to work without specifying the visibility
> on the configurations...
>
> regards,
> Maarten
>
>
>
> - Original Message ---
I'm trying to figure out if this is the expected behavior or it's a bug. If
it is a bug, please forgive me for reporting what may already be well-known.
I'm using Ivy 2.1.0.
In an ivy.xml file, the conf element's visibility attribute has a default
value of "public". See:
http://ant.apache.org/ivy/
Maarten, great point. The wonderful thing about Ivy as a framework is that
it is accommodating of so many different philosophies towards using it.
Certainly, there's no absolute justification for having a special Ivy module
as a wrapper around your build dependencies. In some sense, declaring thos
Marc:
The approach I've seen and I like is to use one Ivy module descriptor for
the project proper and another one for the build. So, if you're just calling
your ivy.xml ivy.xml, you might have:
* ivy.xml: project-proper dependencies
* build-ivy.xml: build dependencies
To me, the really compelling
lters attribute.
I'm sure I'm missing something critical.
On Thu, Mar 4, 2010 at 2:11 PM, Mitch Gitman wrote:
> Shawn, this feature request is subtly different from configuration
> intersection in that it's being specified on the depended-upon module rather
> than on the
Shawn, this feature request is subtly different from configuration
intersection in that it's being specified on the depended-upon module rather
than on the dependent, which is the case with configuration intersection.
Remember last year there had been some discussion of introducing
configuration i
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
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
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
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
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
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
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
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/
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
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
>
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
/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
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
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
1 - 100 of 186 matches
Mail list logo
