Yes I have got javadoc working with IvyDE.
The "trick" with IvyDE is to make sure the names of the binary jar, source
jar and javadoc zip all have the same name, but different types (jar, src,
and javadoc respectively).
As an example I recently started using xstream, so I created an ivy file
(which I don't actually have right now, as it is at work), but I can guess
what it would have looked like from the based on the dependency declared in
the ivy.xml file in the project that uses it (which I do have on me).
This is my guess at the ivy.xml for xtream. NOTE: I don't think the conf
sections will matter (you can remove them).
<?xml version="1.0" encoding="ISO-8859-1"?>
<ivy-module version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="ivy.xsd">
<info
organisation="thoughtworks"
module="xstream"
revision="1.2.2"
status="release">
</info>
<configurations>
<conf name="api" description="The binary." />
<conf name="api-src" description="The API source and javadoc." />
</configurations>
<publications>
<artifact name="xstream" type="jar" conf="api" />
<artifact name="xstream" type="src" ext="jar" conf="api-src" />
<artifact name="xstream" type="javadoc" ext="zip" conf="api-src" />
</publications>
</ivy-module>
This is the section of my ivy.xml that depends on xsteam. Again, I don't
think the confs will matter (you can remove them).
<dependency org="thoughtworks" name="xstream" rev="1.2.2"
conf="build->api-src; ejb->api">
<artifact name="xstream" type="jar" conf="ejb"/>
<artifact name="xstream" type="src" ext="jar" conf="build"/>
<artifact name="xstream" type="javadoc" ext="zip" conf="build"/>
</dependency>
Then in Eclipse in the Ivy properties, make sure you have specified the
types for the in the properties like so:
Accepted Types: jar
Source Types: src
Javadoc Types: javadoc
Also Note, I am using ivy 1.4.1 and IvyDE 1.2.0.
Hope that helps. If it doesn't then let me know, and I'll check that I
didn't get anything wrong in the above example when I get to work tomorrow.
P.S.: Don't worry about the spelling mistakes, English is my native
language, but that doesn't automatically make me a good speller :-)
On 6/4/07, Frank Kemmer <[EMAIL PROTECTED]> wrote:
I am trying to build an enterprise repository for a customer. Usually
I try to bring new Ivy Modules via <ivy:install> into the enterprise
repository. I am using the <ibiblio>-Resolver in m2-compatibility
mode, since <ivyrep> does not describe the artifacts and JARs I need
and the fallback uses Maven1 instead of Maven2 compatibility mode.
The dependency resolution work's fine most of the time but I don't
understand some details in the retrieved or generated Ivy-Files, resp.
First the status is always status="integration". Why isn't it
status="release"? Can I modify this behaviour?
Where do the many configurations come from?
Another problem I experienced: Some projects have Source Attachments
defined in Maven2 for their binary distribution jar. I think, the
source artifact description can be found in the Maven POM. How can I
/convince/ Ivy to use this information, to add the source artifacts to
the given Ivy module at hand?
And even worse: what have I todo, if I want to add the source
artifacts by hand if they are not described in the Maven2 Repository?
Does anybody have some solutions to add sources automatically or do I
really need to modify the generated Ivy file by hand?
Personally I would prefer a solution where I write a second Ivy file
for the source artifacts, which says that it contains the sources for
another Ivy module and publish this Ivy /source/ module to the
enterprise repository in addition. And the most important thing: this
description should help IvyDE to find the source artifacts if a
project has described a dependeny on the corresponding binary
artifact.
Any ideas? I really appreciate your support. Thanx for any help in
advance.
By the way, could anybody successfully attach Javadocs via the IvyDE
plugin in Eclipse? I failed miserably ... :)
P.S.: Forgive me my spelling mistakes, since English is not my native
language.
--
Regards,
John Gill
