You are viewing a plain text version of this content. The canonical link for it is here.
Posted to npanday-commits@incubator.apache.org by "Paul Gribben (JIRA)" <ji...@apache.org> on 2010/11/30 09:11:11 UTC

[jira] Created: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Inconsistent use of repository and GAC when using Archiva
---------------------------------------------------------

                 Key: NPANDAY-353
                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
             Project: NPanday
          Issue Type: Bug
    Affects Versions: 1.2.1
         Environment: Windows
            Reporter: Paul Gribben


I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.

Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Paul G (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965685#action_12965685 ] 

Paul G commented on NPANDAY-353:
--------------------------------

Next I checked to see if it would spot snapshot updates that have been posted to archiva from a different PC - unfortunately it doesn't. The VisualStudio.Addin's ReferenceManager.cs is a bit over-simplistic: it simply checks for the presence of a snapshot artifact file in the local repo, and if it's present it copies it to the project's reference folder. No attempt to check the remote snapshot state :(

I'll start putting a hack together for this. Please let me know if there's already a fix for this. Thanks

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Brett Porter (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965503#action_12965503 ] 

Brett Porter commented on NPANDAY-353:
--------------------------------------

it sounds correct, and this definitely works - I'm not sure which piece is missing in your description.

are the versions involved always snapshots?

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Paul G (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965694#action_12965694 ] 

Paul G commented on NPANDAY-353:
--------------------------------

Looks like the following change fixes that problem:

In ReferenceManager.cs line 94, replace:
    if (!artifact.FileInfo.Exists)
with
    if (!artifact.FileInfo.Exists || artifact.Version.EndsWith("SNAPSHOT"))

Should I raise all these issues as separate bugs?

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Paul G (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965710#action_12965710 ] 

Paul G commented on NPANDAY-353:
--------------------------------

Ok - I've created 3 bugs from this:

https://issues.apache.org/jira/browse/NPANDAY-354
https://issues.apache.org/jira/browse/NPANDAY-355
https://issues.apache.org/jira/browse/NPANDAY-356

I'll close this bug.
Thanks

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Wendy Smoak (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965696#action_12965696 ] 

Wendy Smoak commented on NPANDAY-353:
-------------------------------------

Separate issues would be nice, so the release notes will have a good description of what got fixed.  (You may want to start a discussion on the mailing list first for help sorting out the "am I doing it wrong or is it a bug" part, then open issues a things get clearer.)  Thanks!

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Paul G (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965678#action_12965678 ] 

Paul G commented on NPANDAY-353:
--------------------------------

Hi Brett. I'm looking at snapshot handling for now as this will be a common use-case for us.

Ok - I've done some further digging. I followed the "Debugging the Visual Studio Add-in" guide to see what was going on in there, and found the following issues:

1. When I built the DLLs from the 1.2.1 source I found that the snapshot resync between two projects running on the same PC (i.e. using local repo) works fine. Not sure why there's a different behaviour because I installed the 1.2.1 from the MSI installer image.
2. There are two reasons for the 'fails immediately' behaviour shown above:
   a) I didn't have a 'mirrors' section in my settings.xml, causing ProjectImporterEngine's Reference.cs to throw an NPE (line 283 'foreach (Mirror mirror in settings.mirrors)'). For now I've just added an empty section.
   b) In the same file at line 292 the repo 'http://repo1.maven.org/maven2' is hard-wired be added to the list of repos to lookup. As soon as an attempt is made to access this site I get a network access issue (because of our network config). In my opinion this should not be forced into the repos collection. In my case I want to use archiva (and only archiva) as my artifact source. For now I've just commented this line out and that problem is resolved.

So now I seem to have the basic features working. Any chance of getting these worked into the next release?

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (NPANDAY-353) Inconsistent use of repository and GAC when using Archiva

Posted by "Paul G (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NPANDAY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul G closed NPANDAY-353.
--------------------------

    Resolution: Duplicate

3 separate bugs raised (see notes)

> Inconsistent use of repository and GAC when using Archiva
> ---------------------------------------------------------
>
>                 Key: NPANDAY-353
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-353
>             Project: NPanday
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>         Environment: Windows
>            Reporter: Paul G
>
> I've created a Visual Studio project A (which generates a class library) and project B (a console app which depends on project A's library). If I run 'install' goal for project A then I see the library in the "%M2_HOME%/repository" area as expected. Since I have archiva configured I then try running 'deploy' for project A and all is well: the library DLL is written to archiva correctly. I then create a new version of library A and deploy to archiva, but on a different PC to where I'm working on project B. I then update project B's dependency entry for project A's library to reference the new version. When I try 'resync references' for project B it fails immediately and does not attempt to pull the library in from Archiva. However if I run "maven install" from the command shell for project B then it does pull the library from Archiva, but strangely it get's written to the "%M2_HOME%/uac/gac_msil" area instead of the "%M2_HOME%/repository" area.
> Unfortunately for large team development this makes NPanday currently not suitable. Am I using it incorrectly or is this a bug?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.