Proposal: Link Sources to Classes by Artifact Type in Classpath Container

• Key: IVYDE-12
• Type: New Feature
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Xavier Hanin
• Reporter: Andreas Schildbach
• Component/s: classpath container

Description

Currently, IvyDE puts all artifacts into the classpath container (see http://jayasoft.org/node/560).

My proposal is to let the user configure types for both "jar" artifacts (classes) and "src" artifacts (the source for the classes). Only those should be used for the classpath container, and corresponding jar and src artifacts should be combined into a single entry in the container with sources attached to the classes.

Comments

[Xavier Hanin]

The idea is good, however I don't think we will address it ourself at jayasoft for the moment, since we use another solution: WOJ (http://www.worldofjava.org/), and our time is limited.

But if someone submits a patch addressing this issue, we will be glad to integrate it.

[Jeff Turner]

This is content of my email to Xavier:

Hi Xavier

I would like to discuss the problem of adding support for Java sources to IvyDE (Ivy).
I would like to ask you on your opinion about the good solution.

At first something about maven2 support.
Maven2 works in this way (I think, but I am not the maven2 expert . Maven2 has groupId ("equivalent" of organization and module in Ivy) and artifactId (equivalent of artifact name in Ivy). In fact, there is separate descriptor for every artifact (artifactId). So, in directory coresponding to groupId and artifactId are some desription info files (xml, sha, pom), one jar file containing classes and optionaly one jar file containing java sources and optionally one jar file containing javadoc (optional jar files corespond to artifact classes jar file automatically).
It looks like maven2 supposes that artifact "is always" java jar file, which may have automatically coresponding sources and javadoc jar files.
That was what I know about maven2 , not much, maybe its not truth.

I think, that having java sources for libraries is problem of development (coding), not building. Thus, it implies that adding support for sources should impact only IDE (in this case only IvyDE, not Ivy). I see 2 base solutions, how to get support for sources to IvyDE (Ivy): The second solution may be implemented in many ways (I sketch some subsolutions .

1)
Make Ivy to support sources jar files automatically (in way similar to maven2).
This means that every artifact may have optional (automatically associated) sources and javadoc jars. This would impact Ivy itself. not only IvyDE. I did not think much this solution over, because I think it is not good - it would require changes in Ivy and probably it would be in contradiction wiht Ivy philosophy ... (I mention this solution just to be more complete ... and maybe you will have other meaning).

2)
Sources and javadoc will be regular artifacts, which may or amy not be present in module (presence of sources and javadoc jars will be
optional and will depend only on module creator).
The problem here is only how to distinquish these types of jars and how to associate them together (sources and javadoc jars with
coresponding "classes" jar).
As I mention before, this association is needed to be known only for IDE (in our case Eclipse, so IvyDE). IvyDE will add to classpath only classes jars. Sources and javadoc jars will be downloaded to cache and associated to corresponding classes jars classpath entries (if present).
Sources and javadoc jars will be downloaded in regular manner by resolve "task". So it may happens that sources will be present in repository but will not be downloaded to cache, because of choosing configuration, which will not contain sources ...
The way for associating corresponding files together are here:

2a)
Association of coresponding jar files will be done by name of artifact (they will have the same name of artifact). They will differ only
by type of the artifact. There will be conventional type for sources and javadoc or the type may be customized or both (conventional
default, which will be able to be overriden by custom types for sources and javadocs).

2b)
Same as 2a) (artifact name will be the same). There will be new special attribute of artifact, which will distinguish between classes,
sources and javadoc jars. Attribute may be custom attribute (not in DTD for ivy.xml) or regular one (in new DTD for ivy.xml)

2c)
Corresponding classes, sources and javadoc jar files will have different names, but following convention like this:
classes jar artifact name: artifact
sources jar artifact name: artifact-sources
javadoc jar artifact name: artifact-javadoc

I would choose solution 2a). Xavier, what solution would you prefer ? May be, there is no solution acceptable ...

[Maarten Coene]

Peter,
thanks a lot for your contribution

I think a combination of solution 2a and 2c would allow for more flexibility.

• source/javadoc artifacts have a special type to identify them as being a source/javadoc artifact
• source/javadoc artifacts have a (configurable) naming pattern (default could be [artifact].jar, but you could specify for instance [artifact]-src.zip and [artfiact]-doc.zip as pattern)

In addition, even more flexibility could be achieved if different types/patterns could be defined for different repositories.
For instance, say I have a local repository and a Maven2 repository. Suppose my local repository has the following naming-convention for source artifacts: [artifact]-src.zip and the maven2 repository has the convention [artifact]-sources.jar. Being able to specify different patterns would allow me to have automatically source attached for both repositories.

In addition, if maven2 must be supported, I think Ivy will have to be modified as well to assign a custom type to source/javadoc artifacts...

regards,
Maarten

[balvan]

This is the answer:

Hi Peter,

Solution 2a has my preference too, I agree with all your arguments! Sharing the e-mail on jira is a good idea too, you should have access to jira again.

Xavier

[balvan]

I have implemented the first working draft of sources and javadoc support... (solution 2a)
It works.

[balvan]

I would like to improve it today evening (I hope)

• better names for added staff ... (in java sources)
• add workspace and project configuration for what types should be considered as source and javadoc files

If you have any comment / notice, get it to me.

Thanks

[balvan]

All the solution 2 implemented. Code review needed.

[balvan]

Maarten, does JIRA IVY-324 and IVY-325 address issues you point out?

[Maarten Coene]

At first sight, this seems to be the case

regards,
Maarten

[Xavier Hanin]

I've finally applied your patch Peter, sorry for the delay.

I'll try to release a new version of IvyDE tomorrow, thus your contribution will then be part of an official release. Thanks a lot for your contribution and for your patience.