Stale plugin.xml of inline plugin problems

[alxndrsn]

plugin.xml seems to be regenerated only if the file is missing.

We've just run into a problem with our team where different people
have older or newer plugin.xml files in inplace plugins.  This has
caused some strange and inconsistent bugs on different machines.

1. should we be committing plugin.xml to version control?
2. is there a standard way to force plugin.xml to be regenerated
regularly/when necessary?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[alxndrsn]

On 2 August 2012 11:06, Alex Anderson
<[hidden email]> wrote:
> 1. should we be committing plugin.xml to version control?
> 2. is there a standard way to force plugin.xml to be regenerated regularly/when necessary?

For now, we're doing the following in our build script (gant):

    target(clearPluginXmls: 'Delete plugin.xml from all in-place plugins') {
             delete {
                    fileset dir:'..', includes:'*/plugin.xml'
            }
    }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Göran Ehrsson]

I have also been hit by this a few times. The command "grails package-plugin" will re-generate plugin.xml.

I have a feeling that it also finds future potential problems with plugin packaging so I do it regularly for my in-place plugins. I have not yet put it in a build script, but I should really do that.

/Göran

2 aug 2012 kl. 10:06 skrev Alex Anderson <[hidden email]>:

> plugin.xml seems to be regenerated only if the file is missing.
>
> We've just run into a problem with our team where different people
> have older or newer plugin.xml files in inplace plugins.  This has
> caused some strange and inconsistent bugs on different machines.
>
> 1. should we be committing plugin.xml to version control?
> 2. is there a standard way to force plugin.xml to be regenerated
> regularly/when necessary?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[alxndrsn]

On 8 August 2012 11:49, Göran Ehrsson <[hidden email]> wrote:
> I have also been hit by this a few times. The command "grails package-plugin" will re-generate plugin.xml.
>
> I have a feeling that it also finds future potential problems with plugin packaging so I do it regularly for my in-place plugins. I have not yet put it in a build script, but I should really do that.

Interesting.  We rarely run "package-plugin" as the plugins are always
used in-place, but maybe forcing this into our build process for
in-place plugins would be an alternative solution.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Göran Ehrsson]

If I remember correctly the problems I've had with in-place plugins that got corrected by package-plugin was (I really hope I remember correct now):

1. Dependency related, wrong external plugin version pulled in by *someoone*.
2. When generating war with in-place plugins, some GSP templates could not be found <g:render template="foo" plugin="bar"/>

After package-plugin inside the in-place plugin (bar) containing the GSP template (_foo.gsp), the problem was solved.
I think my problems are related to me generating war file for staging/test with in-place plugins present. Maybe someone with deeper knowledge can clarify.

Next time it happens I will write down the steps I take to solve it (yeah, don't we always?)

/Göran


8 aug 2012 kl. 13:15 skrev Alex Anderson <[hidden email]>:

> On 8 August 2012 11:49, Göran Ehrsson <[hidden email]> wrote:
>> I have also been hit by this a few times. The command "grails package-plugin" will re-generate plugin.xml.
>>
>> I have a feeling that it also finds future potential problems with plugin packaging so I do it regularly for my in-place plugins. I have not yet put it in a build script, but I should really do that.
>
> Interesting.  We rarely run "package-plugin" as the plugins are always
> used in-place, but maybe forcing this into our build process for
> in-place plugins would be an alternative solution.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[alxndrsn]

On 8 August 2012 09:33, Alex Anderson
<[hidden email]> wrote:

> On 2 August 2012 11:06, Alex Anderson
> <[hidden email]> wrote:
>> 1. should we be committing plugin.xml to version control?
>> 2. is there a standard way to force plugin.xml to be regenerated regularly/when necessary?
>
> For now, we're doing the following in our build script (gant):
>
>     target(clearPluginXmls: 'Delete plugin.xml from all in-place plugins') {
>              delete {
>                     fileset dir:'..', includes:'*/plugin.xml'
>             }
>     }

N.B. this approach DOES NOT WORK - the plugin's version is read from
the old plugin.xml before it is deleted.  When the new plugin.xml is
created, the stale version read from the old file is then inserted
into the new file.

Still looking for a fix.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email