You have to be a little more careful testing this.
As I said, although startup.properties contains mvn urls, they are not
interpreted using the aether url handler, there's some code that directly finds
the files in the system repo.
So anything in startup.properties won't be copied into the local maven repo and
needs to be in system repo.
Stuff in other features will get copied into the local maven repo aether is
configured for.
And of course you have to switch the aether configuration from how it was in
trunk to how you want it to be, with the local maven repo being configured as
aether's local maven repo.
------
I have no problem with encouraging people to use aether for easy provisioning
but I think there should be a way beyond startup bundles to avoid dragging
aether in for every bundle you start and just use the bundles you have already
put in the system repo without looking anywhere else.
-----
I also think that these "fake" mvn urls in startup.properties are too confusing
and we should use a different prefix. I put them in and they are better than
using the path in the system repo but I think they have successfully confused
you :-) I don't really see what would be wrong with a flat system repo so
you'd just give the file name and then using mvn urls for stuff that is fetches
through aether and stays in the local maven repo.
thanks
david jencks
On Mar 7, 2012, at 2:48 AM, Jean-Baptiste Onofré wrote:
> I was quite surprised with the latest David's e-mail, and quite sceptic
> regarding the pax-url-aether code.
>
> So I decided to make a test.
>
> I removed all Karaf artifact from my .m2/repository:
>
> rm -fr ~/.m2/repository/org/apache/karaf
>
> In a fresh Karaf trunk build, I can see the Karaf artifact in the system
> directory:
>
> ls -l system/org/apache/karaf/
> total 36
> drwxr-xr-x 5 jbonofre jbonofre 4096 2012-03-07 07:35 deployer
> drwxr-xr-x 6 jbonofre jbonofre 4096 2012-03-07 07:35 diagnostic
> drwxr-xr-x 9 jbonofre jbonofre 4096 2012-03-07 07:35 features
> drwxr-xr-x 5 jbonofre jbonofre 4096 2012-03-07 07:35 instance
> drwxr-xr-x 5 jbonofre jbonofre 4096 2012-03-07 07:35 jaas
> drwxr-xr-x 4 jbonofre jbonofre 4096 2012-03-07 07:35 management
> drwxr-xr-x 5 jbonofre jbonofre 4096 2012-03-07 07:35 region
> drwxr-xr-x 10 jbonofre jbonofre 4096 2012-03-07 07:35 shell
> drwxr-xr-x 5 jbonofre jbonofre 4096 2012-03-07 07:35 system
>
> In the etc/org.ops4j.pax.url.mvn.cfg, I setup:
>
> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false
>
> And I started my Karaf:
>
> cd bin
> ./karaf
> __ __ ____
> / //_/____ __________ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
>
> Apache Karaf (3.0.0-SNAPSHOT)
>
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or 'system:shutdown' to shutdown Karaf.
>
> karaf@root()> la
> START LEVEL 100 , List Threshold: 0
> ID State Blueprint Level Name
> [ 0] [Active ] [ ] [ 0] System Bundle (4.0.2)
> [ 1] [Active ] [ ] [ 5] OPS4J Pax Url - wrap:
> (1.4.0.SNAPSHOT)
> [ 2] [Active ] [ ] [ 5] OPS4J Pax Url - aether:
> (1.4.0.SNAPSHOT)
> [ 3] [Active ] [ ] [ 5] OPS4J Pax Swissbox :: Bnd Utils
> (1.5.0)
> ....
> [ 69] [Active ] [Created ] [ 30] Apache Karaf :: Jaas :: Command
> (3.0.0.SNAPSHOT)
> karaf@root()>
>
> So all is started correctly.
>
> Now I take a look in my .m2/repository:
>
> ls -l ~/.m2/repository/org/apache/karaf
> ls: cannot access /home/jbonofre/.m2/repository/org/apache/karaf: No such
> file or directory
>
> No it means that NO artifact has been copied from the system repository to
> the local repository.
>
> So, I don't see any duplication here, and not requirement to have a local
> repo even using the defaultLocalRepoAsRemote set to false.
>
> I removed all maven-metadata-local.xml from the system repo:
>
> cd system
> find . -name "maven-metadata-local.xml" -exec rm {} \;
>
> and restarted Karaf.
>
> In that case, the local repo has not been updated (org/apache/karaf is still
> not present), but the Karaf system repo has been updated with the SNAPSHOT
> from Central (which the expected behavior).
>
> Now, I populated my local repo (with a complete mvn clean install -DskipTests
> in the Karaf workspace).
>
> I removed the Karaf artifacts from the system repo:
>
> rm -fr system/org/apache/karaf
>
> and Karaf doesn't start:
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.shell/org.apache.karaf.shell.commands/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.system/org.apache.karaf.system.core/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.features/org.apache.karaf.features.core/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.region/org.apache.karaf.region.core/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.config/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.features/org.apache.karaf.features.command/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.modules/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.shell/org.apache.karaf.shell.console/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.shell/org.apache.karaf.shell.services/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.system/org.apache.karaf.system.commands/3.0.0-SNAPSHOT
> Bundle listed in startup.properties configuration not found:
> mvn:org.apache.karaf.shell/org.apache.karaf.shell.bundles/3.0.0-SNAPSHOT
> Could not create framework: java.lang.Exception: Aborting due to missing
> startup bundles
> java.lang.Exception: Aborting due to missing startup bundles
>
> So I tried to remove artifacts no in the startup.properties:
>
> rm -fr system/org/apache/karaf/shell/org.apache.karaf.shell.dev
>
> and restart Karaf:
>
> dev:watch command is there
>
> the system repo has been updated with the artifact from central (I have to
> check if it's really the case o does it took the one from local repo).
>
> Maybe I'm wrong, but my conclusion is that:
> - we can stay with pax-url-aether
> - we have a "correct" behavior as it means that we have a kind of "merge"
> between the system repo and the local repo
> - the defaultLocalRepoAsRemote could be set to false by default
>
> I'm digging around that and send you an update asap.
>
> Regardss
> JB
>
> On 03/07/2012 08:49 AM, Christian Schneider wrote:
>> I think it makes sense to stay with aether. It makes our artifact
>> resolution more standard. So people with maven knowledge understand what
>> happens.
>> Another reason why I would like to stay with aether is that it minimizes
>> the code we have to maintain and that we automatically participate in
>> advancements in
>> new maven versions.
>>
>> I did not realize that all artifacts are copied to the local repo but on
>> the other hand I don´t think it is a big problem. We are only talking
>> about 10 MB after all.
>> We could propose an enhancement to aether to mark a repository as "near"
>> or "do not cache". This could allow to mark the system dir in that way
>> and should
>> then trigger maven to just use the artifacts from there. Perhaps aether
>> could even detect automatically that a repo is on a file location and
>> default to that setting.
>> Till we have this enhancement I think it would be ok to live with the
>> copied artifacts.
>>
>> Yesterday JB and I discussed that using the default local repo allows to
>> build a kind of network distribution that is very small. For companies
>> that have their
>> own maven repo this is probably very interesting.
>>
>> Christian
>>
>> Am 07.03.2012 07:48, schrieb Guillaume Nodet:
>>> The maven url handler has been deprecated because there was no foreseen
>>> problems with it and aether seemed a good replacement for it. We could
>>> easily say we want to maintain it and I think that would un-deprecate
>>> it ;-)
>>>
>>>
>>
>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
