You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-dev@incubator.apache.org by Adelita Padilla <ap...@maestrodev.com> on 2011/04/01 03:22:55 UTC
Re: Weird dependency resolving issues
The Visual Studio dependencies were originally deployed to
http://repo.npanday.org/archiva/repository/3rdparty/.
But we removed them because of license issues.
If those dependencies were not installed on your locally repository,
building trunk would actually fail.
What I normally do to get pass it, I manually install those artifacts to my
local repo.
Thanks,
--
liit
On Tue, Mar 29, 2011 at 1:54 PM, Lars Corneliussen <me...@lcorneliussen.de>wrote:
> Am 28.03.11 17:12, schrieb Brett Porter:
>
> On 28/03/2011, at 6:24 PM, Lars Corneliussen wrote:
>>
>> Hi,
>>>
>>> I get lots of these:
>>>
>>> 28.03.2011 09:21:38 npanday.dao.impl.ProjectDaoImpl
>>> storeProjectAndResolveDependencies
>>> WARNUNG: NPANDAY-180-018: Not found in local repository, now
>>> retrieving artifact from
>>> wagon:npanday.model:NPanday.Model.Settings:library:2.0-SNAPSHOT,
>>> Failed Path Check =
>>> C:\Workbench\NPanday\svn-trunk\target\NPanday.Model.Settings.dll
>>>
>>>
>>> Any idea?
>>>
>> The ProjectDaoImpl is incredibly fragile for these sorts of things. I
>> don't think the RDF repository will be happy with developing multiple
>> versions at a time - I usually flush it before switching (as you got 2.0
>> here).
>>
>>
>> I'll try again after deleting the rdf-repos.
>
> Also lately the build slowed down, because maven is trying to resolve
>>> dependencies for Visual Studio (but build is not failing):
>>>
>> This is in the repository builder? It seems like something recent affected
>> it - not sure how it was before, but those POMs aren't in the remote repo
>> now. e.g.
>> http://repo.npanday.org/archiva/repository/npanday-group/VsWebSite/Interop/VsWebSite.Interop/
>>
> No. In the normal build. mvn install on npanday trunk root.
>
> Anyone know whether they were ever there?
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>
Re: Weird dependency resolving issues
Posted by Lars Corneliussen <me...@lcorneliussen.de>.
ok. then we have to fix that for 1.3.1 :)
--
Message sent from mobile device
Am 01.04.2011 um 07:25 schrieb Josimpson Ocaba <jo...@maestrodev.com>:
> Yes, the actual dll were also deployed because when building npanday and
> trying to resolve the dependencies it is looking for a .dll from the remote
> repository.
>
> As what Adelita mentioned if those dependencies are not yet installed it
> what cause a failure :(
Re: Weird dependency resolving issues
Posted by Josimpson Ocaba <jo...@maestrodev.com>.
Yes, the actual dll were also deployed because when building npanday and
trying to resolve the dependencies it is looking for a .dll from the remote
repository.
As what Adelita mentioned if those dependencies are not yet installed it
what cause a failure :(
Re: Weird dependency resolving issues
Posted by Brett Porter <br...@apache.org>.
On 01/04/2011, at 2:22 PM, Adelita Padilla wrote:
> The Visual Studio dependencies were originally deployed to
> http://repo.npanday.org/archiva/repository/3rdparty/.
>
> But we removed them because of license issues.
>
> If those dependencies were not installed on your locally repository,
> building trunk would actually fail.
>
> What I normally do to get pass it, I manually install those artifacts to my
> local repo.
Is that true? I thought only the POMs we created for them were up there, but that the dependencies were always resolved the GAC (as all of them are marked that way). The only dependency we have that isn't a platform requirement is NUnit...
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter