Awesome. That should work for my case.

Thanks!
Jordan




On 7/21/16, 3:02 PM, "Ron Wheeler" <[email protected]> wrote:

>http://stackoverflow.com/questions/9123004/maven-is-it-possible-to-override-location-of-local-repository-via-the-use-of-co
>Even easier - run-time argument to Maven
>
>On 21/07/2016 2:49 PM, Jordan Lewis wrote:
>>> Still not sure why anyone would need an index file. What are they going
>>> to use it for?
>> We have an OSGi runtime and use OBR to deploy our bundles. OBR needs 
>> artifacts to be indexed so it can find them to satisfy the dependencies of 
>> our bundles. That is what I’m building the index file for. If it contained 
>> paths to my local repositories, it wouldn’t mean anything to people on 
>> different machines.
>>
>>> Is there some way to override  system.resolveArtifact's understanding of
>>> where to find the local repo.
>>> Then you could give it an empty directory and your problem would be
>>> solved without touching your "real" repo cache.
>> Very true. I did something like that, but it required changing the indexer 
>> code. Is there a way to change my local repository path using a pom 
>> attribute or settings.xml change?
>>
>> Thanks,
>> Jordan
>>
>>> On 21/07/2016 2:10 PM, Jordan Lewis wrote:
>>>>> Looks like it might be easier to just delete your local repo!
>>>> I know that this approach works. It’s just a bit inconvenient to have to 
>>>> do that.
>>>>
>>>>> Perhaps you might want to revisit your ultimate goal.
>>>>> Describe the use that people will make of the index  and see if anyone
>>>>> has a different way to get what you want.
>>>> My ultimate goal is to try to resolve artifacts from a specific remote 
>>>> repository and ignore the local repository. The URIs in the generated 
>>>> index file then won’t depend on the local repository path of the machine 
>>>> where the index file was generated.
>>>>
>>>>> Why is your need so different from the normal case that no one else has
>>>>> ever run into this problem?
>>>> I don’t think people are usually concerned with where artifacts are 
>>>> resolved from because they aren’t building index files that anyone should 
>>>> be able to use. I know that others have mentioned this problem with the 
>>>> index plugin, but after looking at the code a bit, it appears like they 
>>>> can’t do anything about it because the Aether code doesn’t have any 
>>>> options for resolving artifacts without first checking the local 
>>>> repository manager. I think it would be beneficial if Aether overloaded 
>>>> the method so that you could pass a parameter to not check that local 
>>>> repository or provide a new method which accepts a remote repository and 
>>>> the artifact request, and then tries to resolve the artifact with that 
>>>> remote repository only.
>>>>
>>>> My real hope was that I was overlooking some code that would already 
>>>> accomplish what I just described which is what led me to the mailing 
>>>> lists. Is ther another way to resolve artifacts other than 
>>>> system.resolveArtifact(..) which always checks the LocalRepositoryManager 
>>>> first?
>>>>
>>>> Thanks,
>>>> Jordan
>>>>
>>>>> On 21/07/2016 11:46 AM, Jordan Lewis wrote:
>>>>>> Is this, <https://github.com/eclipse/aether-core>, still the code base? 
>>>>>> I could make a pull request that would show exactly the part I’m talking 
>>>>>> about with a possible solution.
>>>>>>
>>>>>> Thanks,
>>>>>> Jordan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/20/16, 1:53 PM, "Jordan Lewis" <[email protected]> wrote:
>>>>>>
>>>>>>> Any update on what mailing list I should be using?
>>>>>>>
>>>>>>> Jordan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/19/16, 2:26 PM, "Jordan Lewis" <[email protected]> wrote:
>>>>>>>
>>>>>>>> Here is the email I received from them about it.
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Jordan,
>>>>>>>>
>>>>>>>> …
>>>>>>>>
>>>>>>>>
>>>>>>>>> Does anyone have any suggestions for me to resolve this or is there
>>>>>>>>> another email list where this question would fit better?
>>>>>>>> sadly, Aether has left Eclipse for Apache, to be developed there in
>>>>>>>> closer collaboration with the Maven core. See [1] here for the details.
>>>>>>>>
>>>>>>>> I am not aware of an aether-users list at Apache, so I would suggest
>>>>>>>> asking on [email protected] or maybe [email protected]. 
>>>>>>>> Neither
>>>>>>>> list seems to be a perfect fit though, as you are neither end user or
>>>>>>>> developer of Maven itself.
>>>>>>>>
>>>>>>>> Anyway, it would be great if you could reply which list ultimately
>>>>>>>> answered your question, so future developers can find the answer in the
>>>>>>>> archives.
>>>>>>>>
>>>>>>>> Hope that helps.
>>>>>>>>
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> <https://projects.eclipse.org/projects/technology.aether/reviews/termination-review>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Codetrails GmbH
>>>>>>>> The knowledge transfer company
>>>>>>>>
>>>>>>>> Robert-Bosch-Str. 7, 64293 Darmstadt
>>>>>>>> Phone: +49-6151-276-7092
>>>>>>>> Mobile: +49-170-811-3791
>>>>>>>> http://www.codetrails.com/
>>>>>>>>
>>>>>>>> Managing Director: Dr. Marcel Bruch
>>>>>>>> Handelsregister: Darmstadt HRB 91940
>>>>>>>> _______________________________________________
>>>>>>>> aether-users mailing list
>>>>>>>> [email protected]
>>>>>>>> To change your delivery options, retrieve your password, or 
>>>>>>>> unsubscribe from this list, visit
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/aether-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/19/16, 10:27 AM, "Jordan Lewis" <[email protected]> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Correct. However, I used that mailing list that you listed and they 
>>>>>>>>> pointed me to your list because you have taken the project over, 
>>>>>>>>> correct?
>>>>>>>>>
>>>>>>>>> Jordan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7/19/16, 10:25 AM, "Ron Wheeler" <[email protected]> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>> It does seem that you do not have a Maven problem but have an Aether 
>>>>>>>>>> problem
>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/aether-users
>>>>>>>>>>
>>>>>>>>>> Ron
>>>>>>>>>>
>>>>>>>>>> On 19/07/2016 9:54 AM, Jordan Lewis wrote:
>>>>>>>>>>> Does that all make sense or do you need anything else to make it 
>>>>>>>>>>> clearer?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Jordan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 7/18/16, 3:56 PM, "Jordan Lewis" <[email protected]> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> The plug-in does have a configuration that tries to ignore the 
>>>>>>>>>>>> local repo, but whenever it resolves an artifact using 
>>>>>>>>>>>> system.resolveArtifact(..), it always checks the local repo first.
>>>>>>>>>>>>
>>>>>>>>>>>> What is the code to ignore the local repo? Or is there some code 
>>>>>>>>>>>> that could try to resolve an artifact from a specific repo?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Jordan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/18/16, 3:22 PM, "Ron Wheeler" 
>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Can you just patch the existing plug-in to create a new plug-in 
>>>>>>>>>>>>> that
>>>>>>>>>>>>> ignores the local repo?
>>>>>>>>>>>>> Or add a configuration flag to ignore the local repo and submit 
>>>>>>>>>>>>> your
>>>>>>>>>>>>> improvement as an enhancement.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ron
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 18/07/2016 2:29 PM, Jordan Lewis wrote:
>>>>>>>>>>>>>> Nexus.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Our remote Nexus repository is available to others, but my local 
>>>>>>>>>>>>>> repository is obviously not. So whenever I generate the index 
>>>>>>>>>>>>>> file, I need to make sure that my local paths to the artifacts 
>>>>>>>>>>>>>> are never used which they are if the artifact can be resolved 
>>>>>>>>>>>>>> both locally and remotely. I need it to only resolve from the 
>>>>>>>>>>>>>> remote repository.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Jordan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/18/16, 2:21 PM, "Ron Wheeler" 
>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What repo are you using locally - Nexus, Artifactory,....?
>>>>>>>>>>>>>>> Why is it not available to others?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ron
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18/07/2016 2:04 PM, Jordan Lewis wrote:
>>>>>>>>>>>>>>>> Is this question in the wrong mailing list? Is there a 
>>>>>>>>>>>>>>>> specific Aether mailing list?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Jordan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/14/16, 9:41 AM, "Jordan Lewis" 
>>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is a question about the Aether API. I’m working on 
>>>>>>>>>>>>>>>>> building an index file which will point to the resolved 
>>>>>>>>>>>>>>>>> artifact using bnd-indexer-maven-plugin. The indexer has an 
>>>>>>>>>>>>>>>>> option to forbid the use of local URIs and that works fine as 
>>>>>>>>>>>>>>>>> long as I don’t have the artifact in my local repository. I 
>>>>>>>>>>>>>>>>> need the artifact to resolve to the remote repository so that 
>>>>>>>>>>>>>>>>> anyone can use this index file and it won’t depend on my 
>>>>>>>>>>>>>>>>> local repository. If the artifact is in my local repository 
>>>>>>>>>>>>>>>>> though, it resolves to that artifact whenever the indexer 
>>>>>>>>>>>>>>>>> code call system.resolveArtifact(..). I can get around this 
>>>>>>>>>>>>>>>>> by clearing my local repository and then the artifact will 
>>>>>>>>>>>>>>>>> resolve to the remote repository location just fine. I did 
>>>>>>>>>>>>>>>>> some digging and it appears like you are always checking the 
>>>>>>>>>>>>>>>>> localRepositoryManager first and then you check remote 
>>>>>>>>>>>>>>>>> repositories.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is there a way to make it ignore the local repository 
>>>>>>>>>>>>>>>>> resolution or set a repository priority order where it would 
>>>>>>>>>>>>>>>>> check the remote repository before the local repository?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Jordan
>>>>>>>>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Ron Wheeler
>>>>>>>>>> President
>>>>>>>>>> Artifact Software Inc
>>>>>>>>>> email: [email protected]
>>>>>>>>>> skype: ronaldmwheeler
>>>>>>>>>> phone: 866-970-2435, ext 102
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>>
>>>>> -- 
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: [email protected]
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> -- 
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: [email protected]
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>-- 
>Ron Wheeler
>President
>Artifact Software Inc
>email: [email protected]
>skype: ronaldmwheeler
>phone: 866-970-2435, ext 102
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to