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 Lars Corneliussen <me...@lcorneliussen.de> on 2010/10/12 06:36:55 UTC

Re: separate releases for Maven plugins & VS integration

Am 12.10.10 03:37, schrieb Josimpson Ocaba:
> ----- "Brett Porter"<br...@apache.org>  wrote:
>
>    
>> On 12/10/2010, at 11:50 AM, Josimpson Ocaba wrote:
>>
>>      
>>>> How about splitting the VS integration and the Maven plugins into
>>>>          
>> two
>>      
>>>> separate releases / trunks? Can't remember if I brought that up
>>>> before, or if it were already ruled out - if so, just point me to
>>>>          
>> the
>>      
>>>> thread :)
>>>>          
>>> I don't recall this being brought up before. I'm not really sure if
>>>        
>> this would be a good idea since there are certain functionalities that
>> would cross over from plugins to VS integration.
>>      
>>>        
>> Which functionality is that? I'm not hugely familiar with developing
>> on the VS addin, but it seemed that many fixes for it are isolated to
>> it's codebase (and the project importer assemblies), and not the maven
>> plugins, core libraries, and .net-authored maven plugins and their
>> assemblies.
>>
>> Part of the reason I was thinking this is that in some situations the
>> addin operates separately, by working with Maven projects that have
>> POMs referencing earlier NPanday plugin versions.
>>
>>      
> Functionality may have been the wrong choice of word. I mean't behavior. Let's say you are developing on supporting a new project type this may entail a modification of existing plugins or the creation of a new one. Although it can still be done if we decide to split the releases but I was oringnally thinking that during development it could take longer but thinking about it again, the building time should be relatively the same since it is sort of split up now anyway. :)
>    
I think it is ok, that old plugins do not support newer npanday 
features. We should offer auto-update through the visual studio gallery, 
though :-)

+1 for splitting it up in two projects. The UI is also less "important" 
- hence it can be in "permanent beta", since it doesn't run on servers 
and the user has to double-check what it does anyway - which shouldn't 
be an excuse for bad quality....

- Lars