incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <dkhayw...@gmail.com>
Subject Re: Why does isis build fetch isis dependencies from repositories?
Date Sat, 11 Jun 2011 11:21:12 GMT
Hi Kevin,
OK, here's the deal.

After RC3 I've made some changes to dependencies - specifically:
* removing the dependency on xom and replacing it with jdom
* replacing some missed javax.* dependencies with geronimo equivalents
* replacing resteasy 1.0.2 (LGPL licensed) with resteasy 2.2 (ALv2 licensed)

All of which means that it's necessary to build Isis at some point 
without the -o (offline) flag, in order to pull down those new dependencies.

When you did this what you then saw was Maven pulling down dependencies 
from the apache.snapshot repo.  That's fine.  Note that those 
dependencies are also accompanied by a 
maven-metadata-apache.snapshots.https.xml (eg in each of the 
subdirectories under ~/.m2/repository/org/apache/isis) file. This holds 
the timestamps of each of those remote artifacts.  However, running "mvn 
clean install" will *still* also build the Isis artifacts locally; you 
should see a maven-metadata-local.xml file.

What this means is that we do, indeed, end up with more than one 
artifact in our local repo that purports to be 
0.1.2-incubating-SNAPSHOT, (one from apache.snapshots repo and one built 
locally), but Maven will compare the timestamps in the respective 
maven-metadata-[repo].xml files and use the latest one, ie that built 
locally.

This, at least, is what I understand.  I did some googling and found a 
JIRA issue [1] that seems to confirm this.

To sum up:
if you just do "mvn clean install", then all should be good (and 
thereafter you can go back to "mvn clean install -o").  Any downloaded 
Isis apache.snapshot artifacts will be ignored.

Alternatively, you could do "mvn clean install" to bring down the new 
Isis dependencies, then do your "rm -rf 
~/.m2/repository/org/apache/isis" to zap the artifacts downloaded from 
apache.snapshots, and then do a "mvn clean install -o".

Hope that makes sense,

Cheers
Dan

[1] http://jira.codehaus.org/browse/MNG-5008



On 11/06/2011 10:57, Kevin Meyer - KMZ wrote:
> Hi Dan,
>
> The first thing I did after svnup was an
> "rm -r ~/.m2/repository/org/apache/isis"
>
> Thereafter, "mvn -o" wouldn't build Isis in trunk, with failures (missing
> dependencies) on isis modules.
>
> I have since, through a tedious process of building packages one at a
> time (allowing 1 or two isis snapshot downloads), and the few other
> external downloads (org.apache.geronimo), been able to build the
> whole 0.1.2-incubating-snapshot system.
>
> I'm in the middle of a critical project delivery period, so don't want to
> take a chance with deleting the repository/org/apache/isis and trying
> again (took about an hour to sort out last night) - perhaps it was the
> missing external dependencies that were causing the Isis modules to
> fail - but the reported dependency was an Isis one, not the external
> ones.
>
> Regards,
> Kevin
>
>
> On 11 Jun 2011 at 8:01, Dan Haywood wrote:
>
>> Hi Kevin,
>>
>> I can't reproduce this on my current workspace, but I'm just pulling
>> down isis afresh (onto that spare laptop I leant you at the code
>> retreat), and see if I can reproduce there.
>> I'll report back presently.
>>
>> DAn
>>
>>
>>
>>
>> On 10/06/2011 18:10, Kevin Meyer - KMZ wrote:
>>> Hi,
>>>
>>> Is it just me, or is there something really strange happening in trunk at
>>> the moment:
>>>
>>> In trunk:
>>>
>>> I'm trying to do a "mvn -o clean install", which fails because of missing
>>> isis dependencies!
>>>
>>> When I do a "mvn clean install", maven starts fetching snapshots from
>>> repositories:
>>> dflt-0.1.2-incubating-20110609.154158-3.jar
>>> dflt-0.1.2-incubating-20110609.154158-3-tests.jar
>>>
>>> etc
>>>
>>> Surely this is backwards? I'm trying to build the Isis framework, from
>>> my local trunk, so it shouldn't fetch anything!?!?
>>>
>>> Anyone?
>>>
>>> Regards,
>>> Kevin
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message