On 3/20/2012 10:51 AM, David Sills wrote:
What an interesting problem. I still haven't been able to publish source
files correctly. You indicated that the file name must be
someproject-src.jar
Does "someproject" include the version number? I'm trying every
combination I can think of to get the source file (which of course I
have easily assembled) published, and nothing at all is working, with
version number or without.
Thanks for your help!
The publications element could look something like:
<publications>
<artifact/>
<artifact type="source" ext="zip"/>
</publications>
By default, this will give you someproject-1.2.3.zip if the revision is
1.2.3. The publications pattern is controlled by 'artifactspattern' in
the publish task - default is: ${ivy.publish.src.artifacts.pattern} -
see Ivy docs:
http://ant.apache.org/ivy/history/2.2.0/use/publish.html
Alan
David Sills
-----Original Message-----
From: Alan Chaney [mailto:a...@writingshow.com]
Sent: Tuesday, March 20, 2012 1:12 PM
To: ivy-user@ant.apache.org
Subject: Re: 2 Questions for ivyIDE
Hi,
I can't comment on the first part of your answer, but I have commented
in line on the sources issue.
On 3/20/2012 9:56 AM, David Sills wrote:
All:
I love working with Eclipse and ivyIDE with 2 exceptions, and I wonder
if I am just missing something.
My environment consists of a company-wide repository, where I place
the results of building my projects, and of course a local repository,
which sometimes though not always has folders for some of the same
projects.
As an example, let's assume that my project, say, "xxx-encryption"
depends on "xxx-common". All is well and Ivy does well with it.
However, I add some functionality to "xxx-common", up the build
number, and rebuild. Great. Using Eclipse, I resolve "xxx-encryption"
and it gets the correct updated value for the version number. In order
to update the "xxx-encryption" Ivy files, I build "xxx-encryption"
even though there have not been any changes to the project itself,
only its dependencies. The company-wide repository's version of
ivy.xml is correctly updated with the appropriate dependency on the
new version of "xxx-common". However, the local repository's version
of ivy.xml is not!
This means that when I have a third project, say "xxx-web", that
depends on "xxx-encryption" and try to resolve that project, the old
(now
incorrect) version of "xxx-common" is taken, since the local
repository's version is read first if it exists.
What am I missing? I find myself constantly manually updating the
files in the local repository in order to get the transitive
dependencies right.
Also, can someone explain to me why my Ivy container in ivyIDE doesn't
allow me to put source code locations on the JARs? That would be
hugely helpful in debugging, especially in a situation where I have a
lot of smaller projects that depend on each other and I assemble them
as needed for a specific requirement. Or do I have to create source
JAR files for each project using Ivy to make that happen? And will it
happen if I do make source JAR files?
I don't quite understand what you mean by "source code locations on the
JARs". Its possible to publish Ivy artifacts for sources and javadocs
(or anything else for that matter.) You need to add them to the
publications section of your Ivy module.
Also, see this thread:
http://old.nabble.com/Ivyde%2C-ivy-roundup-and-%27source%27-td33388096.h
tml
With the current released version you need to have the source and
javadocs artifacts named with a pattern like:
someproject-src.jar
or
someproject-src.zip
However, there are a lot of ivy files out there which define the sources
as source.jar or source.zip. The next release of ivyde will, hopefully,
rectify this by adding in some additional metadata.
In the mean time, if you have a corporate repository, you can simply
arrange a folder structure that complies with existing mechanism and
update your third party ivy files correspondingly. I've done this for
one client using XSLT and an ant script.
HTH
ALan
Many thanks for anyone who can answer either or both of these
questions.
David Sills
