source and javadoc jars lack the library name

[Eric Hansen]

All my source and javadoc jars are getting named something generic
like:

source-0.9.0RC3.zip source-1.1.1.zip source-1.5.3.zip source-2.1.1.zip
source-2.4.1.zip source-2.7.7.zip source-3.2.6.zip
source-0.9.1.2.zip source-1.2.3.zip source-1.6.1.zip source-2.1.3.zip
source-2.6.2.zip source-2.9.1.zip source-3.7.0.zip

javadoc-0.9.0RC3.zip javadoc-1.1.1.zip javadoc-1.5.3.zip
javadoc-2.1.3.zip javadoc-2.9.1.zip javadoc-3.7.0.zip javadoc-
xerces2-2.9.1.zip javadoc-xs-2.9.1.zip
javadoc-0.9.1.2.zip javadoc-1.2.3.zip javadoc-2.1.1.zip
javadoc-2.4.1.zip javadoc-3.2.6.zip javadoc-other-2.9.1.zip javadoc-
xni-2.9.1.zip

This not only results in some conflicts but also means I can't easily
see what the names of the source and javadocs are.

Any thoughts?

This is the output when I did the build. Just trying to pull in the
hibernate dependency for now:

eric-hansens-macbook-pro:trunk ehansen$ ant resolve
Buildfile: build.xml

resolve:
No ivy:settings found for the default reference 'ivy.instance'. A
default instance will be used
[ivy:retrieve] :: Ivy 2.0.0-rc2 - 20081028224207 :: http://ant.apache.org/ivy/
::
:: loading settings :: file = /Users/ehansen/sprout/java/trunk/
ivysettings.xml
[ivy:retrieve] :: resolving dependencies :: org.apache#hello-
ivy;wor...@eric-hansens-macbook-pro.local
[ivy:retrieve] confs: [default]
[ivy:retrieve] found org.hibernate#hibernate;3.2.6 in ivyroundup
[ivy:retrieve] found org.apache.commons#commons-collections;2.1.1 in
ivyroundup
[ivy:retrieve] [2.1.1] org.apache.commons#commons-collections;
[2.1.1,3.0[
[ivy:retrieve] found org.apache.commons#commons-logging;1.1.1 in
ivyroundup
[ivy:retrieve] [1.1.1] org.apache.commons#commons-logging;[1.0.4,1.2[
[ivy:retrieve] found org.dom4j#dom4j;1.6.1 in ivyroundup
[ivy:retrieve] found org.apache.xerces#xerces;2.9.1 in ivyroundup
[ivy:retrieve] [2.9.1] org.apache.xerces#xerces;[2.5,3.0[
[ivy:retrieve] found org.antlr#antlr;2.7.7 in ivyroundup
[ivy:retrieve] [2.7.7] org.antlr#antlr;[2.7.6,2.8[
[ivy:retrieve] found net.sourceforge.ehcache#ehcache;1.2.3 in
ivyroundup
[ivy:retrieve] found org.apache.commons#commons-logging;1.1.1 in
ivyroundup
[ivy:retrieve] [1.1.1] org.apache.commons#commons-logging;1.1+
[ivy:retrieve] found net.sourceforge.c3p0#c3p0;0.9.1.2 in ivyroundup
[ivy:retrieve] [0.9.1.2] net.sourceforge.c3p0#c3p0;[0.9.1,2.0[
[ivy:retrieve] found net.sourceforge.proxool#proxool;0.9.0RC3 in
ivyroundup
[ivy:retrieve] [0.9.0RC3] net.sourceforge.proxool#proxool;[0.8.3,1.1[
[ivy:retrieve] found com.opensymphony#oscache;2.4.1 in ivyroundup
[ivy:retrieve] [2.4.1] com.opensymphony#oscache;[2.1,3.0[
[ivy:retrieve] found org.apache.commons#commons-logging;1.1.1 in
ivyroundup
[ivy:retrieve] [1.1.1] org.apache.commons#commons-logging;[1.1,2.0[
[ivy:retrieve] found org.jgroups#jgroups;2.6.2 in ivyroundup
[ivy:retrieve] [2.6.2] org.jgroups#jgroups;[2.2,3.0[
[ivy:retrieve] found net.sourceforge.swarmcache#swarmcache;1.0RC2 in
ivyroundup
[ivy:retrieve] [1.0RC2] net.sourceforge.swarmcache#swarmcache;
[1.0RC2,2.0[
[ivy:retrieve] found org.apache.commons#commons-collections;2.1.1 in
ivyroundup
[ivy:retrieve] [2.1.1] org.apache.commons#commons-collections;[2.1,3.0
[
[ivy:retrieve] found org.jgroups#jgroups;2.6.2 in ivyroundup
[ivy:retrieve] [2.6.2] org.jgroups#jgroups;[2.2.8,3.0[
[ivy:retrieve] found net.sourceforge.cglib#cglib;2.1.3 in ivyroundup
[ivy:retrieve] [2.1.3] net.sourceforge.cglib#cglib;2.1.3+
[ivy:retrieve] found org.objectweb.asm#asm;1.5.3 in ivyroundup
[ivy:retrieve] found org.jboss#javassist;3.7.0 in ivyroundup
[ivy:retrieve] [3.7.0] org.jboss#javassist;[3.4,4.0[
[ivy:retrieve] found org.codehaus.jaxen#jaxen;1.1.1 in ivyroundup
[ivy:retrieve] [1.1.1] org.codehaus.jaxen#jaxen;[1.1,1.2[
[ivy:retrieve] :: resolution report :: resolve 22229ms :: artifacts dl
44ms
---------------------------------------------------------------------
| | modules || artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
---------------------------------------------------------------------
| default | 16 | 12 | 0 | 0 || 53 | 0 |
---------------------------------------------------------------------
[ivy:retrieve] :: retrieving :: org.apache#hello-ivy
[ivy:retrieve] confs: [default]
[ivy:retrieve] conflict on /Users/ehansen/sprout/java/trunk/lib/
source-1.1.1.zip in [default]: 1.1.1 won
[ivy:retrieve] conflict on /Users/ehansen/sprout/java/trunk/lib/
javadoc-1.1.1.zip in [default]: 1.1.1 won
[ivy:retrieve] 0 artifacts copied, 51 already retrieved (0kB/76ms)

BUILD SUCCESSFUL
Total time: 23 seconds

[Archie Cobbs]

On Fri, Nov 14, 2008 at 3:50 PM, Eric Hansen <ehans...@gmail.com> wrote:

All my source and javadoc jars are getting named something generic

This is intentional... the thought was that it shouldn't cause any problems because they go into separate directories.

And, in theory, it's not possible to guarantee unique names anyway without some kind of official scheme.

If this turns out to be a big problem in practice we can change the names fairly easily. But I'm curious... what application or process are you using that puts them all into the same directory?

-Archie

--
Archie L. Cobbs

[Nicolas Lalevée]

Le 14 nov. 08 à 23:26, Archie Cobbs a écrit :

As usually the artifact name is the module name, the retrieve pattern
often look like "lib/[type]s/[artifact]-[revision].[ext]", so this
could lead to some messy folder. For IvyRoundUp a better pattern would
be: "lib/[type]s/[module]-[artifact]-[revision].[ext]"

Though I think it would be a good idea to change that in IvyRoundup,
as IvyDE is relying on the artifact names to attach sources to binary
jars.

Nicolas

[Archie Cobbs]

On Sat, Nov 15, 2008 at 6:28 AM, Nicolas Lalevée <nicolas...@hibnet.org> wrote:

Though I think it would be a good idea to change that in IvyRoundup,
as IvyDE is relying on the artifact names to attach sources to binary
jars.

Can you explain this further? What happens if the source and binary JARs don't correspond?

E.g.:  "foo-main.jar" and "foo-optional.jar" with combined sources in "foo-sources.zip" ?

Why does IvyDE assume that JARs and source ZIPs have a 1:1 correspondence?

Sorry for the questions, I'm just trying to understand the underlying assumptions.

-Archie

--
Archie L. Cobbs

[Nicolas Lalevée]

Archie Cobbs a écrit :

> On Sat, Nov 15, 2008 at 6:28 AM, Nicolas Lalevée
> <nicolas...@hibnet.org <mailto:nicolas...@hibnet.org>> wrote:
>
> Though I think it would be a good idea to change that in IvyRoundup,
> as IvyDE is relying on the artifact names to attach sources to binary
> jars.
>
>
> Can you explain this further? What happens if the source and binary
> JARs don't correspond?
>
> E.g.: "foo-main.jar" and "foo-optional.jar" with combined sources in
> "foo-sources.zip" ?
>
> Why does IvyDE assume that JARs and source ZIPs have a 1:1 correspondence?

yes it does, and the one to one correspondence is computed from the
artifact names.
foo.jar (type=jar (actually one of the type declared in the
configuration of IvyDE as "Accepted types")) will have attached as
source foo.zip if its type is source (or one of the types declared in
"Sources types").
If no artifact name match, then IvyDE tries some suffixes declared in
"Sources suffixes". For a foo.jar, it will try foo-source.jar,
foo-sources.jar, foo-src.jar.

So today there is no way IvyDE can understand that "foo-main.jar" and
"foo-optional.jar" have as source "foo-sources.zip". It probably needs
improvement on that case, even if there still the workaround to attach
sources manually.

Nicolas