Java Mail API artifact is missing

[Tom Mack]

http://ivyroundup.googlecode.com/svn/trunk/repo/modules/javax.mail/javamail/1.4.3/ivy.xml

I tried to use the "api" configuration and am getting an error about
"download failed: javax.mail#javamail;1.4.3!mailapi.jar". When I look
in the repository (local, build with install task), I can see all of
the JARs that the ivy.xml file declares except for mailapi.jar.

I may just use the "default" (I think pre-Ivy I was just using a
single "mail.jar"). But, I was trying to find a way to just declare a
dependency on the mail sending (i.e. "smtp" not "imap" or "pop3")
artifacts.

Since this module requires manual download, I was sure if I did
something wrong or the ivy.xml file is just incorrect. I didn't
receive any errors when the package was resolved.

[Archie Cobbs]

The mailapi jar is not included in the "default" configuration for javamail (because Java EE already provides it).

So you just need to add the "api" javamail configuration to your javamail dependency, e.g.: conf="*->default,api".

-Archie

--
You received this message because you are subscribed to the Google Groups "ivyroundup" group.
To post to this group, send email to ivyro...@googlegroups.com.
To unsubscribe from this group, send email to ivyroundup+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ivyroundup?hl=en.

--
Archie L. Cobbs

[Tom Mack]

I'm talking about the actual mailapi.jar artifact. When I installed
the module to a local repository, that particular artifact was missing.

[Archie Cobbs]

I thought I was talking about the actual mailapi.jar too :-) I guess I don't understand your question.

Here are some possibly relevant facts:

1. The javamail archive has to be downloaded manually.
2. Assuming that it's downloading OK, then the mailapi.jar artifact will get resolved only if you depend on the "api" configuration.
   

If these don't help, can you provide a simple test case?

-Archie

On Sun, Jan 9, 2011 at 10:54 PM, Tom Mack <t...@tom-mack.com> wrote:

I'm talking about the actual mailapi.jar artifact. When I installed
the module to a local repository, that particular artifact was missing.

--

You received this message because you are subscribed to the Google Groups "ivyroundup" group.
To post to this group, send email to ivyro...@googlegroups.com.
To unsubscribe from this group, send email to ivyroundup+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ivyroundup?hl=en.

--
Archie L. Cobbs

[Tom Mack]

Ok, this isn't quite as I described it.

I thought I had specifically "installed" the javamail module into my
local repository. But it looks like it was actually pulled in as a
transitive dependency on some other module that I installed. So, when
I needed to declare a direct dependency on javamail for my project, I
saw it in my local repository and just started using it. I looked at
the ivy.xml file, decided that the "api" was the configuration I
wanted to use, and then found that the artifact tied to that
dependency didn't actually exist in my folder structure. Just now when
I explicitly ran an install task for that module, the mailapi.jar
showed up.

So I guess there is just some confusion on my part about how
dependencies are pulled in when doing an install task with
transitive="true". I would have thought that I would get a full and
correct version of the module even if only a subset of it was
required. Maybe that's just not how it works.

When I say "install" I'm talking about the ivy:install task with from
set to "roundup" and to set to "local", where roundup and local are
defined as:

<filesystem name="local">
<ivy pattern="${temp.repo.root}/[organisation]/[module]/
[revision]/ivy.xml" />
<artifact pattern="${temp.repo.root}/[organisation]/
[module]/[revision]/[type]s/[artifact].[ext]" />
</filesystem>
<packager name="roundup" buildRoot="${user.home}/.ivy2/
packager/build" resourceCache="${user.home}/.ivy2/packager/cache">
<ivy pattern="http://ivyroundup.googlecode.com/svn/trunk/
repo/modules/[organisation]/[module]/[revision]/ivy.xml"/>
<artifact pattern="http://ivyroundup.googlecode.com/svn/
trunk/repo/modules/[organisation]/[module]/[revision]/packager.xml"/>
</packager>

On Jan 10, 11:50 am, Archie Cobbs <arc...@dellroad.org> wrote:
> I thought I was talking about the actual mailapi.jar too :-) I guess I don't
> understand your question.
>
> Here are some possibly relevant facts:
>

>    1. The javamail archive has to be downloaded
> manually<http://code.google.com/p/ivyroundup/wiki/ManuallyDownloadedSoftware>
>    .
>    2. Assuming that it's downloading OK, then the mailapi.jar artifact will

>    get resolved only if you depend on the "api" configuration.
>
> If these don't help, can you provide a simple test case?
>
> -Archie
>
> On Sun, Jan 9, 2011 at 10:54 PM, Tom Mack <t...@tom-mack.com> wrote:
> > I'm talking about the actual mailapi.jar artifact. When I installed
> > the module to a local repository, that particular artifact was missing.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ivyroundup" group.
> > To post to this group, send email to ivyro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > ivyroundup+...@googlegroups.com<ivyroundup%2Bunsubscribe@googlegrou ps.com>
> > .

[Archie Cobbs]

On Mon, Jan 10, 2011 at 12:19 PM, Tom Mack <t...@tom-mack.com> wrote:

I thought I had specifically "installed" the javamail module into my
local repository. But it looks like it was actually pulled in as a
transitive dependency on some other module that I installed. So, when
I needed to declare a direct dependency on javamail for my project, I
saw it in my local repository and just started using it. I looked at
the ivy.xml file, decided that the "api" was the configuration I
wanted to use, and then found that the artifact tied to that
dependency didn't actually exist in my folder structure. Just now when
I explicitly ran an install task for that module, the mailapi.jar
showed up.

So I guess there is just some confusion on my part about how
dependencies are pulled in when doing an install task with
transitive="true". I would have thought that I would get a full and
correct version of the module even if only a subset of it was
required. Maybe that's just not how it works.

Hmm, in reading the documentation it doesn't really specify whether all artifacts or just the required artifacts of transitively dependent modules are pulled in.

Guess the answer is the latter...

-Archie

--
Archie L. Cobbs

[al...@mechnicality.com]

Hi Archie and Tom

This actually overlaps with an issue that I raised a few days ago about the xml-apis where different versions of the same jar appeared in different modules and the conflict resolution appeared to be ignoring them.

My experience seems to be the reverse - that you get *all* the artifacts of the module and the transitive dependency resolution can't evict conflicts because the conflicts are done at 'module level'. Maybe one of the developers could comment?

Regards


Alan