IvyDE workspace resolver & classpath container not playing well with AndroidDependencies classpath container...

[Brian Anderson]

I am using Ivy 2.3.0 and IvyDE (2.2.0beta1) together with the Android
SDK (rev 19) to manage dependencies in a collection of Android projects.

I have multiple Android projects, each with an ivy.xml file describing
dependencies.  Some of these Android projects are so-called Android
library projects, others are Android application projects.  My goal is
to produce artifacts from Android library projects that can be published
and subsequently used in another Android project as a dependency via
Ivy.  (Strictly speaking, Android library projects currently have no
exportable jar artifact.  The claim is that this will be supported in
future revs of the Android SDK.  None the less, the SDK does produce a
"classes.jar" file that I am using as the library project artifact.  
This is working for my purposes.)  I have more or less been successful
in accomplishing this...I can produce artifacts from library projects
(i.e. "foo.jar"), publish them to a Nexus repo and subsequently use
these artifacts in another Android project by declaring an appropriate
dependency in ivy.xml associated with the referring Android project.  I
have a small Ant build wrapper that resolves dependencies and retrieves
the resolved dependencies, placeing them into the proper place in the
referring Android project (libs/) such that the stock Android SDK Ant
build can pick them up and use them.  All is well.

Of course, I would like all of this to work in Eclipse via IvyDE when I
am working on a collection of Android projects and library projects that
they depend on within a workspace.  Having recently discovered the IvyDE
workspace resolver, I elected to try this to manage dependencies between
Android projects and dependent library projects.  Note that I am trying
to avoid having the Android project declare its dependency on a library
project using the stock Android SDK mechanism (via project.properties).  
If I can avoid having to declare Android project library dependencies
via the stock Android SDK mechanisms I can avoid having to modify my
project files when working in Eclipse versus when working with the
command line build.

I have setup IvyDE to retrieve dependencies into the libs/ directory.  I
have done this by editing the Ivy classpath container configuration as
follows:

   - Build the classpath with: retrieved artifacts
   - Retrieve pattern: libs/[artifact]-[revision].[ext]
   - Delete old retrieved artifacts: true
   - Types: *

I have also enabled "Resolve dependencies in workspace" and ensured that
my ivy.xml files have a status="integration" per the IvyDE workspace
resolver instructions.

This configuration ensures that the AndroidDependencies classpath
container (provided by the Android SDK) will properly pickup project
dependencies from the libs/ directory.  This works fine for external
dependencies (given that there is an actual artifact that can be copied
into the libs/ directory for the AndroidDependencies classpath container
to pick up), but not with Android library project dependencies that the
workspace resolver deals with.  The IvyDE workspace resolver appears to
be working correctly as far as placing workspace dependencies into the
Ivy classpath container, but there is no apparent way to insert a
reference into the AndroidDependencies classpath container so that the
project will build correctly with the library project dependencies.

I suppose one might suggest that this is a deficiency with the
AndroidDependencies classpath container.  Another way would be to have
the workspace resolver somehow inject an artifact from the workspace
dependency that can be "retrieved" and copied via a retrieve pattern
into the libs/ directory for the AndroidDependencies classpath container
to pickup.  I'm not clear what the kind of reference the workspace
resolver injects into the Ivy classpath container.

Any insight appreciated.

ba

[Nicolas Lalevée]

Le 16 mai 2012 à 19:18, Brian Anderson a écrit :

> I am using Ivy 2.3.0 and IvyDE (2.2.0beta1) together with the Android SDK (rev 19) to manage dependencies in a collection of Android projects.
>
> I have multiple Android projects, each with an ivy.xml file describing dependencies.  Some of these Android projects are so-called Android library projects, others are Android application projects.  My goal is to produce artifacts from Android library projects that can be published and subsequently used in another Android project as a dependency via Ivy.  (Strictly speaking, Android library projects currently have no exportable jar artifact.  The claim is that this will be supported in future revs of the Android SDK.  None the less, the SDK does produce a "classes.jar" file that I am using as the library project artifact.  This is working for my purposes.)  I have more or less been successful in accomplishing this...I can produce artifacts from library projects (i.e. "foo.jar"), publish them to a Nexus repo and subsequently use these artifacts in another Android project by declaring an appropriate dependency in ivy.xml associated with the referring Android project.  I have a small Ant build wrapper that resolves dependencies and retrieves the resolved dependencies, placeing them into the proper place in the referring Android project (libs/) such that the stock Android SDK Ant build can pick them up and use them.  All is well.
>
> Of course, I would like all of this to work in Eclipse via IvyDE when I am working on a collection of Android projects and library projects that they depend on within a workspace.  Having recently discovered the IvyDE workspace resolver, I elected to try this to manage dependencies between Android projects and dependent library projects.  Note that I am trying to avoid having the Android project declare its dependency on a library project using the stock Android SDK mechanism (via project.properties).  If I can avoid having to declare Android project library dependencies via the stock Android SDK mechanisms I can avoid having to modify my project files when working in Eclipse versus when working with the command line build.
>
> I have setup IvyDE to retrieve dependencies into the libs/ directory.  I have done this by editing the Ivy classpath container configuration as follows:
>
>  - Build the classpath with: retrieved artifacts
>  - Retrieve pattern: libs/[artifact]-[revision].[ext]
>  - Delete old retrieved artifacts: true
>  - Types: *
>
> I have also enabled "Resolve dependencies in workspace" and ensured that my ivy.xml files have a status="integration" per the IvyDE workspace resolver instructions.
>
> This configuration ensures that the AndroidDependencies classpath container (provided by the Android SDK) will properly pickup project dependencies from the libs/ directory.  This works fine for external dependencies (given that there is an actual artifact that can be copied into the libs/ directory for the AndroidDependencies classpath container to pick up), but not with Android library project dependencies that the workspace resolver deals with.  The IvyDE workspace resolver appears to be working correctly as far as placing workspace dependencies into the Ivy classpath container, but there is no apparent way to insert a reference into the AndroidDependencies classpath container so that the project will build correctly with the library project dependencies.
>
> I suppose one might suggest that this is a deficiency with the AndroidDependencies classpath container.

This is indeed not possible. The classpath container of Android is managed by the Android plugin, it cannot be modified by an external plugin. At least I checked, the Android plugin doesn't offer any extension point to do so.

> Another way would be to have the workspace resolver somehow inject an artifact from the workspace dependency that can be "retrieved" and copied via a retrieve pattern into the libs/ directory for the AndroidDependencies classpath container to pickup.

What would be that artifact ? There is no way to be sure how to package an Eclipse project, some build is involved. IvyDE cannot do that either.

>  I'm not clear what the kind of reference the workspace resolver injects into the Ivy classpath container.

IvyDE use the JDT API, it add a reference to the dependent project, just like you would do manually in the "Java Build Path". It is then the responsibility of the JDT to properly build the classpath with that.

I don't know the Android SDK, but isn't it possible to let the classpath be managed by the IvyDE container ? Let you dependency be in the IvyDE container and not in the Android container ?

Nicolas

[Brian Anderson]

Nicolas Lalevée wrote:

> Another way would be to have the workspace resolver somehow inject an artifact from the workspace dependency that can be "retrieved" and copied via a retrieve pattern into the libs/ directory for the AndroidDependencies classpath container to pickup.

What would be that artifact ? There is no way to be sure how to package an Eclipse project, some build is involved. IvyDE cannot do that either.

The only thing I can think of is to somehow specify the artifact produced by the dependent workspace project that would be eligible to be retrieved by the retrieve pattern specified for the Ivy classpath container just as Ivy now does for artifacts retrieved from external repos.

In a manner of speaking, whats missing is a way for the dependent workspace project to "publish" an artifact...that is publish in a way that the workspace resolver could pick it up and put it in the Ivy cache like other resolvers know how to do for external repo dependencies.

Another idea is to somehow use a linked resource that the workspace resolver could use to identify the published artifact.  The dependent project would have to declare this in the Ivy classpath container configuration.

Either way, this would allow the retrieve pattern specified for the Ivy classpath container in the project declaring the dependency to work transparently with artifacts gathered from artifacts/resources "published" by dependent workspace projects or external repos as they all would be in the Ivy cache so they can be "retrieved".

The above might be specified as an alternative to placing the dependent projects on the Java Build path as the Ivy classpath container now does.  I'm assuming that the workspace resolver knows how to put references to dependent workspace projects into the Ivy classpath container...are these simply source references?  (Sorry, I'm not all that familiar with the inner workings of Eclipse.)

Nicolas Lalevée wrote:

>  I'm not clear what the kind of reference the workspace resolver injects into the Ivy classpath container.

IvyDE use the JDT API, it add a reference to the dependent project, just like you would do manually in the "Java Build Path". It is then the responsibility of the JDT to properly build the classpath with that.

I don't know the Android SDK, but isn't it possible to let the classpath be managed by the IvyDE container ? Let you dependency be in the IvyDE container and not in the Android container ?

No, I don't think so.  Android SDK wants to manage the classpath for Android projects.  The AndroidDependencies classpath container is what the Android Eclipse plugin uses to satisfy external dependencies when it is building the Android project.  This is why I've had to specify retrieve patterns in my Android projects that copy dependent artifacts resolved from external repos into a location where the AndroidDependencies classpath container expects them to be (the libs/ directory) so the Android Eclipse plugin can build the Android project.

Thanks for the answer!

ba

[Nicolas Lalevée]

Le 19 mai 2012 à 05:16, Brian Anderson a écrit :

>
>
> Nicolas Lalevée wrote:
>>
>>
>>> Another way would be to have the workspace resolver somehow inject an
>>> artifact from the workspace dependency that can be "retrieved" and copied
>>> via a retrieve pattern into the libs/ directory for the
>>> AndroidDependencies classpath container to pickup.
>>
>> What would be that artifact ? There is no way to be sure how to package an
>> Eclipse project, some build is involved. IvyDE cannot do that either.
>>
>>
>
> The only thing I can think of is to somehow specify the artifact produced by
> the dependent workspace project that would be eligible to be retrieved by
> the retrieve pattern specified for the Ivy classpath container just as Ivy
> now does for artifacts retrieved from external repos.
>
> In a manner of speaking, whats missing is a way for the dependent workspace
> project to "publish" an artifact...that is publish in a way that the
> workspace resolver could pick it up and put it in the Ivy cache like other
> resolvers know how to do for external repo dependencies.
>
> Another idea is to somehow use a linked resource that the workspace resolver
> could use to identify the published artifact.  The dependent project would
> have to declare this in the Ivy classpath container configuration.
>
> Either way, this would allow the retrieve pattern specified for the Ivy
> classpath container in the project declaring the dependency to work
> transparently with artifacts gathered from artifacts/resources "published"
> by dependent workspace projects or external repos as they all would be in
> the Ivy cache so they can be "retrieved".
>
> The above might be specified as an alternative to placing the dependent
> projects on the Java Build path as the Ivy classpath container now does.
> I'm assuming that the workspace resolver knows how to put references to
> dependent workspace projects into the Ivy classpath container...are these
> simply source references?  (Sorry, I'm not all that familiar with the inner
> workings of Eclipse.)

In Ivy every resolver manipulates artifacts. For every of them, artifacts are files, apart from the workspace resolver where the artifacts are symbolic reference to the Eclipse project in the workspace. IvyDE gather all the artifacts required with an Ivy resolve. Each time it find a jar in the resolved files, it put it in the classpath container. Each time it finds a project reference, it tells Eclipse to add a project to the classpath container.

What your asking here it to replace the symbolic reference of the project by the jar of that project. But how would this jar be build ? There is no way IvyDE could do a such thing. It would mean that each time you save a file in a dependent project, Eclipse compiles it, then IvyDE would have to jar that project (I bypass here the question about what should be jared, the tests classes ?), it would have to put that jar in a repository, trigger a resolved of every dependent project, with the consequence of changing the classpath of every dependent project which make Eclipse recompile everything. I don't think that's a good idea.

Nicolas

>
>
> Nicolas Lalevée wrote:
>>
>>
>>> I'm not clear what the kind of reference the workspace resolver injects
>>> into the Ivy classpath container.
>>
>> IvyDE use the JDT API, it add a reference to the dependent project, just
>> like you would do manually in the "Java Build Path". It is then the
>> responsibility of the JDT to properly build the classpath with that.
>>
>> I don't know the Android SDK, but isn't it possible to let the classpath
>> be managed by the IvyDE container ? Let you dependency be in the IvyDE
>> container and not in the Android container ?
>>
>>
>
> No, I don't think so.  Android SDK wants to manage the classpath for Android
> projects.  The AndroidDependencies classpath container is what the Android
> Eclipse plugin uses to satisfy external dependencies when it is building the
> Android project.  This is why I've had to specify retrieve patterns in my
> Android projects that copy dependent artifacts resolved from external repos
> into a location where the AndroidDependencies classpath container expects
> them to be (the libs/ directory) so the Android Eclipse plugin can build the
> Android project.
>
> Thanks for the answer!
>
> ba
>
>
> --
> View this message in context: http://old.nabble.com/IvyDE-workspace-resolver---classpath-container-not-playing-well-with-AndroidDependencies-classpath-container...-tp33862327p33873485.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>