Hi,
This seems to work:
I created a new configuration ivy-only for which nothing is published.
When I publish that configuration, only the ivy.xml file is published and
no artifacts.
(Only disadvantage is that I will have to update all our ivy-files).
Thanks for the advice !
Marc
Tha
2013/5/30
Could give a little bit more information about your environment ?
For example:
how does your ivysettings file look like ?
What command do you use to fetch these dependencies ? (please provide an
extract of your build file).
Regards,
Marc
2013/6/24 Colin Surprenant colin.surpren...@gmail.com
-core Maven project has not been properly constructed or are we
looking at a possible Ivy limitation here?
Thanks,
Colin
On Tue, Jun 25, 2013 at 8:22 AM, Marc De Boeck mdeb...@gmail.com wrote:
I think that ivy doesn't recognize the native classifier.
I've set your chained resolver in my
Out of curiosity I ran the same command as you (with my own ivysettings),
and I got the same problem.
I am not an expert of Maven or pom-files, but I think the problem is in the
definition of the parent pom of apache.flume:
You cannot use the ant-tasks ivy:resolve or ivy:retrieve to copy
module-artifacts from one repo to another.
Instead, you could use the task ivy:install for this purpose. But in your
case, I don't think this is really necessary.
You should know that Ivy has a concept of a cache (the ivy-cache),
As explained in
http://ant.apache.org/ivy/history/latest-milestone/ivyfile.html, it seems
you always need a real ivy.xml to describe the module you are building. So
pom.xml will not be possible for in this case.
Regards,
Marc
2014/1/13 KARR, DAVID dk0...@att.com
I can see that when Ivy uses
To group a number of artifacts together, we sometimes define a virtual
component which contains all the dependencies for such framework. A virtual
component in our terminology, has an ivy.xml file containing the required
dependencies, but does not contain any publications (you must specify
You could use the conflict-manager all for this purpose.
We are using ivy.branches however to retrieve different versions (releases)
of the same module.
Marc
2014/1/13 KARR, DAVID dk0...@att.com
In our big Ant build, another team provides a jar which is associated with
a version of a WSDL.
Did you update the artifactpattern of your ivy-cache ? You should add your
extra attribute in the same way as you have to update the patterns in your
resolvers.
See http://ant.apache.org/ivy/history/latest-milestone/settings/caches.html
Regards,
Marc
2014/1/16 opatry olivier.pa...@gmail.com
Sure, have a look at the ant-task ivy:buildlist.
Furthermore, you can use the properties module, leaf and restartfrom
to tune and trim the list of buildfiles that you can then execute in a
subant task.
Regards,
Marc
2014-01-29 KARR, DAVID dk0...@att.com
With Maven, the modules listed in an
What does your resolver (of artifactory-snapshot-uploads) and cache
settings look like ?
Maybe they contain [module] and not [artifact] in their path.
But I don't find it a good idea to publish two different artifacts and two
different pom-files in one publish command.
Normally, one ivy.xml file
Rick,
Resolving latest.integration versions in IvyDE works fine for us.
I assume that these are modules that you've built via Ant. So maybe a
trivial question, but have these modules actually been published to a repo
? If they are, is this repo added to the repos that you use to resolve your
You could add in the ivy.xml of jupiter-XMLInterface an exclude statement
inside the dependency for jaxb-impl:
dependency org=com.sun.xml.bind name=jaxb-impl rev=2.2.7
exclude module=jaxb-api /
/dependency
Alternatively, you can also change the ivy.xml of
Hi Adrian,
I experienced the same behaviour. In my case, I had created a configuration
ivy_only. The purpose of this configuration was to resolve and retrieve
published ivy-files. The resolved ivy-file was downloaded to my cache and
could be retrieved to another location. But when calling the
As far as I know, the exclude element works fine for us, also in the case
of such transitive dependencies.
Maybe you received javax.servlet via another dependency ?
As a workaround (or a test), you could add your exclude element(s)
directly under (but at bottom of) the dependencies element of
First of all, I would remove log=quiet when calling ivy:resolve and
ivy:cachepath.
This may give you some feedback (because resolving transitive dependencies
normally works fine).
Check that your core-entities are published correctly to the right
ivy-repository. And that your ProjB resolves
Perhaps the override rule is what you are looking for:
http://ant.apache.org/ivy/history/latest-milestone/ivyfile/override.html
Regards,
Marc
2014-07-10 18:24 GMT+02:00 Greene, Hugh hgre...@tmvse.com:
Hi all,
I'm looking for a way to enforce a particular kind of check on versions in
a
liability for any delays. If you have
received this message in error, please contact the sender and delete the
message.
-Original Message-
From: Marc De Boeck [mailto:mdeb...@gmail.com]
Sent: 10 July 2014 20:57
To: ivy-user@ant.apache.org
Subject: Re: Optional/conditional strict
I suppose that in the description of the unlessset attribute, 'not' should
be removed:
unlessset: the variable will be set unless the provided 'unlessset'
variable is set (Since 2.4)
Which is the same as your interpretation: variable will only be set if the
provided 'unlessset' variable is not
I see that you have defined four different repositories with the same name
alfresco-public.
Maybe that's the reason why it doesn't resolve properly ?
Marc
2014-12-30 22:44 GMT+01:00 André-John Mas andrejohn@gmail.com:
I am trying to build a project based on the Alfresco One CMS (
Please have a look at the paragraphs Dealing with integration versions in
http://ant.apache.org/ivy/history/latest-milestone/bestpractices.html:
The typical developer workflow using SNAPSHOT builds of a release, has
become popular because it is the standard in Maven. A disadvantage of using
It's an interesting problem to investigate, and I understand your
frustration. But since we don't have exactly the same setup as you, it's
not evident to tell exactly what the problem is and how you can solve it.
We also have an environment with a local and a central repo, but we don't
use the
We have similar virtual modules and it works for us: with IvyDE and with an
ant-build.
The only difference I see, is that we have an explicit closing tag for the
empty publication element of our virtual modules:
publications
/publications
Regards,
Marc
2015-08-10 21:56 GMT+02:00 Douglas
I agree mostly with hkaiserl, but I'd like to add some extra thoughts.
When we started using Ivy, we were also using ClearCase. Initially we
decided to put 3rd party libraries etc also in ClearCase. Our own built
artifacts were stored on a shared drive (not version controlled). This
worked not so
We are using the second approach: use Ivy classpath to compile.
For me it is the most efficient and elegant way to work with Ivy and the
Ivy-cache.
Regards,
Marc
2015-11-04 7:46 GMT+01:00 Jammy Chen :
> Hello IVY users/developers,
>
> I am now immigrating my project to with
hkais...@googlemail.com <hkais...@gmail.com>:
> On 04.11.2015 14:41, Marc De Boeck wrote:
>
>>
>> Later on, we moved to Git and to Artifactory. We chose Artifactory above
>> Nexus, because we found that Nexus was too much focused on the maven
>> eco-system. I a
oc" ext="zip" type="native"
> conf="cortex-m4_iar_withLoc"
> packaging="zip" />
> e:locInfo="withoutLoc" ext="zip" type="native"
> conf="cortex-m
Can you tell us the cache pattern that you have configured ?
Maybe you can also try to retrieve the same artifacts but with a module
descriptor (ivy-file) where the packaging attribute is not set.
This way, you could find out if it is related to the packaging attribute,
or related to something
Ivy is a flexible tool and also the release process can be tuned according
to your own needs.
Personally, I think that you should not try to copy the "release process"
used in the maven world.
I believe more in a continuous build process where builds are promoted to
releases when they have been
>
>
>
> *From Ant Build File*
> artifactspattern="[artifact].[ext]"
> resolver="${pub-resolver}"
> pubrevision="publish-integration"
> forcedeliver="true"
> status="integration"
> overwrite="tru
Since branches often refer to versions or releases, it is not unusual that
they contain dots in their names.
We also have dots in the name of our branches and don't have any problems
with it.
Maybe you can execute your repreport with debugging enabled ?
Regards
Marc
2016-12-02 16:54 GMT+01:00
ince I'm getting matches on plain
> branch names and no matches on the ones that contain one or more dot
> characters.
>
> Any ideas? I'll gladly run any additional tests.
>
> Thank you,
> Gabriel
>
>
> On Fri, Dec 2, 2016 at 3:52 PM, Marc De Boeck <mdeb...@gmail.com> wrote:
32 matches
Mail list logo