[
https://issues.apache.org/jira/browse/IVY-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Louis Boudart updated IVY-1248:
------------------------------------
Description:
I recently discovered a bug in Module Inheritance feature (i.e. extends).
{code:xml}
<extends organisation="net.foo" module="bar" revision="latest.integration"
location="../myParent" extendTypes="configurations,dependencies"/>
{code}
The feature works fine if the parent descriptor is already published in your
repository, it will use the MRID to retrieve the parent module.
We also can use a "location" attribute (for dev mode) which defines where to
find the parent descriptor. This can make particular sense if you need to share
metadatas (dependencies, configurations, whatever) across many subprojects.
If we get into technical details when "extend" element is found ivy will :
* check on filesystem if parent module exists (based on location attribute). If
no location attribute is found ivy will look in the default one "../ivy.xml".
* if not found, it will check in the cache using MRID. However it just ignore
the version attribute. To be exact it ask for WorkingRevision.
* if not found it will query repositories using the real MRID (here the version
attribute is taken in consideration)
* if found it will try to flush the parent descriptor in the cache
Everything works :)
But when you invoke ivy:deliver (directly or through ivy:publish) ivy parse the
resolved module descriptor in the cache. And the complication comes here.
Imagine you never publish the "parent module" in the repository. When you will
invoke ivy:deliver / ivy:publish ivy will :
* parse your module descriptor (the one <extend>ing your parent) from the cache
* while parsing ivy will find the <extend> element and will try to locate the
parent descriptor
* check the location attribute <-- fail because cache pattern is fully
configurable in ivy and almost never match with the default value "../ivy.xml"
* check the cache with the given MRID (organisation="net.foo" module="bar" but
with working revision ) <-- almost never find it
* check the repositories with the real mrid (organisation="net.foo"
module="bar" revision="latest.revision") <-- fail as we never published our
parent descriptor.
* deliver process will fail !
We never really encoutered the problem as this feature was developped in
easyant context and we were doing a lot of stuff around this feature. In almost
all cases parent descriptor was published by an other mechanism of easyant in
a "build scoped repository" (kind of filesystem based repository local to the
project).
While refactoring the code in easyant i just realized that somethings was wrong.
was:
I recently discovered a bug in Module Inheritance feature (i.e. extends).
{code:xml}
<extends organisation="net.foo" module="bar" revision="latest.integration"
location="../myParent" extendTypes="configurations,dependencies"/>
{code}
The feature works fine if the parent descriptor is already published in your
repository, it will use the MRID to retrieve the parent module.
We also can use a "location" attribute (for dev mode) which defines where to
find the parent descriptor. This can make particular sense if you need to share
metadatas (dependencies, configurations, whatever) across many subprojects.
If we get into technical details when "extend" element is found ivy will :
* check on filesystem if parent module exists (based on location attribute). If
no location attribute is found ivy will look in the default one "../ivy.xml".
* if not found, it will check in the cache using MRID. However it just ignore
the version attribute. To be exact it ask for WorkingRevision.
* if not found it will query repositories using the real MRID (here the version
attribute is taken in consideration)
Everything works :)
But when you invoke ivy:deliver (directly or through ivy:publish) ivy parse the
resolved module descriptor in the cache. And the complication comes here.
Imagine you never publish the "parent module" in the repository. When you will
invoke ivy:deliver / ivy:publish ivy will :
* parse your module descriptor (the one <extend>ing your parent) from the cache
* while parsing ivy will find the <extend> element and will try to locate the
parent descriptor
* check the location attribute <-- fail because cache pattern is fully
configurable in ivy and almost never match with the default value "../ivy.xml"
* check the cache with the given MRID (organisation="net.foo" module="bar" but
with working revision ) <-- almost never find
* check the repositories with the real mrid (organisation="net.foo"
module="bar" revision="latest.revision") <-- fail as we never published our
parent descriptor.
* deliver process will fail !
We never really encoutered the problem as this feature was developped in
easyant context and we were doing a lot of stuff around this feature. In almost
all cases parent descriptor was published by an other mechanism of easyant in
a "build scoped repository" (kind of filesystem based repository local to the
project).
While refactoring the code in easyant i just realized that somethings was wrong.
> Module inheritance sometimes fails to locate parent descriptor in deliver
> process
> ---------------------------------------------------------------------------------
>
> Key: IVY-1248
> URL: https://issues.apache.org/jira/browse/IVY-1248
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.2.0
> Reporter: Jean-Louis Boudart
> Priority: Minor
>
> I recently discovered a bug in Module Inheritance feature (i.e. extends).
> {code:xml}
> <extends organisation="net.foo" module="bar" revision="latest.integration"
> location="../myParent" extendTypes="configurations,dependencies"/>
> {code}
> The feature works fine if the parent descriptor is already published in your
> repository, it will use the MRID to retrieve the parent module.
> We also can use a "location" attribute (for dev mode) which defines where to
> find the parent descriptor. This can make particular sense if you need to
> share metadatas (dependencies, configurations, whatever) across many
> subprojects.
> If we get into technical details when "extend" element is found ivy will :
> * check on filesystem if parent module exists (based on location attribute).
> If no location attribute is found ivy will look in the default one
> "../ivy.xml".
> * if not found, it will check in the cache using MRID. However it just ignore
> the version attribute. To be exact it ask for WorkingRevision.
> * if not found it will query repositories using the real MRID (here the
> version attribute is taken in consideration)
> * if found it will try to flush the parent descriptor in the cache
> Everything works :)
> But when you invoke ivy:deliver (directly or through ivy:publish) ivy parse
> the resolved module descriptor in the cache. And the complication comes here.
> Imagine you never publish the "parent module" in the repository. When you
> will invoke ivy:deliver / ivy:publish ivy will :
> * parse your module descriptor (the one <extend>ing your parent) from the
> cache
> * while parsing ivy will find the <extend> element and will try to locate the
> parent descriptor
> * check the location attribute <-- fail because cache pattern is fully
> configurable in ivy and almost never match with the default value "../ivy.xml"
> * check the cache with the given MRID (organisation="net.foo" module="bar"
> but with working revision ) <-- almost never find it
> * check the repositories with the real mrid (organisation="net.foo"
> module="bar" revision="latest.revision") <-- fail as we never published our
> parent descriptor.
> * deliver process will fail !
> We never really encoutered the problem as this feature was developped in
> easyant context and we were doing a lot of stuff around this feature. In
> almost all cases parent descriptor was published by an other mechanism of
> easyant in a "build scoped repository" (kind of filesystem based repository
> local to the project).
> While refactoring the code in easyant i just realized that somethings was
> wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
