GRAILS-5400 - Potential blocker for 1.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

GRAILS-5400 - Potential blocker for 1.2

ld@ldaley.com
http://jira.codehaus.org/browse/GRAILS-5400 - In place plugins cannot depend on other in place plugins.

Introduced by http://github.com/grails/grails/commit/89ff66f3300e87dcd40bd7dd3eda507d77a35220
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-5400 - Potential blocker for 1.2

pledbrook
> http://jira.codehaus.org/browse/GRAILS-5400 - In place plugins cannot depend on other in place plugins.

I don't think Grails recognises such dependencies either. If your app
depends on in-place plugin A , which depends on in-place plugin B,
then Grails will complain if your app doesn't explicitly depend on B.
As far as I can tell anyway.

The compilation issue is very tricky. Grails depends heavily on
plugin.xml, but you cannot accurately generate it without compiling
the plugin first. Unfortunately, there is no easy way to say "please
run compile in this project first", so we have a hack.

I'm not sure this is a blocker because you should be able to add
plugin B as a dependency before the plugin A dependency. It's a
workaround, yes, but until there's a significant refactor around
plugins to properly support in-place ones, I don't think we can do
much more. I guess we may be able to recursively call the
compileInplacePlugin on in-place plugins. Whether we can get that into
1.2 though is another matter.

Cheers,

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-5400 - Potential blocker for 1.2

ld@ldaley.com

On 19/11/2009, at 10:49 PM, Peter Ledbrook wrote:

>> http://jira.codehaus.org/browse/GRAILS-5400 - In place plugins cannot depend on other in place plugins.
>
> I don't think Grails recognises such dependencies either. If your app
> depends on in-place plugin A , which depends on in-place plugin B,
> then Grails will complain if your app doesn't explicitly depend on B.
> As far as I can tell anyway.
>
> The compilation issue is very tricky. Grails depends heavily on
> plugin.xml, but you cannot accurately generate it without compiling
> the plugin first. Unfortunately, there is no easy way to say "please
> run compile in this project first", so we have a hack.

Why do you need to compile the project to generate the plugin.xml?

> I'm not sure this is a blocker because you should be able to add
> plugin B as a dependency before the plugin A dependency. It's a
> workaround, yes, but until there's a significant refactor around
> plugins to properly support in-place ones, I don't think we can do
> much more. I guess we may be able to recursively call the
> compileInplacePlugin on in-plac

My bad.

I thought I had them in the right order but was mistaken (new to this codebase). I reordered them and everything worked fine.

What did you want to do with the ticket? Do you want me to downgrade it or close it? It's probably something that needs to be addressed in some sense (which may not lead to a resolution) so I am in favour of downgrading.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-5400 - Potential blocker for 1.2

Jeff Scott Brown
On Thu, Nov 19, 2009 at 5:48 PM, Luke Daley <[hidden email]> wrote:

>
> On 19/11/2009, at 10:49 PM, Peter Ledbrook wrote:
>
>>> http://jira.codehaus.org/browse/GRAILS-5400 - In place plugins cannot depend on other in place plugins.
>>
>> I don't think Grails recognises such dependencies either. If your app
>> depends on in-place plugin A , which depends on in-place plugin B,
>> then Grails will complain if your app doesn't explicitly depend on B.
>> As far as I can tell anyway.
>>
>> The compilation issue is very tricky. Grails depends heavily on
>> plugin.xml, but you cannot accurately generate it without compiling
>> the plugin first. Unfortunately, there is no easy way to say "please
>> run compile in this project first", so we have a hack.
>
> Why do you need to compile the project to generate the plugin.xml?
>
>> I'm not sure this is a blocker because you should be able to add
>> plugin B as a dependency before the plugin A dependency. It's a
>> workaround, yes, but until there's a significant refactor around
>> plugins to properly support in-place ones, I don't think we can do
>> much more. I guess we may be able to recursively call the
>> compileInplacePlugin on in-plac
>
> My bad.
>
> I thought I had them in the right order but was mistaken (new to this codebase). I reordered them and everything worked fine.
>
> What did you want to do with the ticket? Do you want me to downgrade it or close it? It's probably something that needs to be addressed in some sense (which may not lead to a resolution) so I am in favour of downgrading.

I have downgraded the ticket.  It would be helpful if you could add a
comment there with your latest info.

Thanks for the help.



jb

--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GRAILS-5400 - Potential blocker for 1.2

pledbrook
In reply to this post by ld@ldaley.com
> Why do you need to compile the project to generate the plugin.xml?

Because the plugin.xml is generated from the *GrailsPlugin.groovy
descriptor. That has to be compiled first with the whole plugin
project and and all its dependencies on the classpath.

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

plugins with similar names

Scott Burch
In reply to this post by ld@ldaley.com
I'm having trouble with two plugins that I have written.
HibernateFilter and WeceemAcegi.  Seems that people have trouble loading
them and other issues.

The thing these two plugins have in common is the first part of their
hyphenated names are the same as other plugins that I have installed.  

Has anyone else had these problems?  I am currently seeing this with
1.2-M4.  But, people have reported this with 1.1.1 as well.

Scott



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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: plugins with similar names

netwiser
It is not only plugin with similiar name have this problem, but also  
the taglib has this problem as well, I believe this caused by the  
naming convention bug

For instance, I have a tag lib call categoryTreeOptions, and after it  
I have another tag calls categoryTree, when I call categoryTree in  
gap, the tag categoryTreeOptions is always being called.

Regards

James
Sent from my iPhone

On 2009-11-21, at 15:35, Scott Burch <[hidden email]> wrote:

> I'm having trouble with two plugins that I have written.
> HibernateFilter and WeceemAcegi.  Seems that people have trouble  
> loading
> them and other issues.
>
> The thing these two plugins have in common is the first part of their
> hyphenated names are the same as other plugins that I have installed.
>
> Has anyone else had these problems?  I am currently seeing this with
> 1.2-M4.  But, people have reported this with 1.1.1 as well.
>
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: plugins with similar names

pledbrook
In reply to this post by Scott Burch
> I'm having trouble with two plugins that I have written.
> HibernateFilter and WeceemAcegi.  Seems that people have trouble loading
> them and other issues.

Do you have a reproducible example? If so, please attach it to a new JIRA.

Thanks,

Peter

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

    http://xircles.codehaus.org/manage_email