Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Portability problems #14

Closed
altavir opened this issue Jan 18, 2016 · 17 comments
Closed

Portability problems #14

altavir opened this issue Jan 18, 2016 · 17 comments

Comments

@altavir
Copy link

altavir commented Jan 18, 2016

Grain works fine when one use one of given templates, but there a quite a lot of little annoying problems, when one tries to create his own template or move installation.

  • project group can not be changed from com.sysgears.grain. Main class name is bound to it and it seams that some internal features as well, because project would not compile if group name is changed.
  • groovy source code classes are bound to com\sysgears\theme\ directory. I tried to move them to another directory and change imports in SiteConfig, but got some NPEs. It is not very easy to access these files and I do not see any reason for complicated directory structure since there are no name conflicts. I also do not understand the purpose of Launcher.java class since it just point to some internal launcher.
  • SiteConfig.groovy has direct class imports which is not very good idea if it is intended as a configuration file. If one moves this classes or uses custom ones, he should replace all imports? It is better to use fully qualified class names and reflects to invoke user classes.
  • generally in gradle all temporary files and build results are stored inside build directory. Is there a reason to store target and caches in project root? If they are all in one directory, than it is easier to clean.
  • gradle plugin has some strange behavior. It should seem to replace build.gradle in theme projects and work directly with the source code, but instead it just creates 'project in project' in the source folder with its own build gradle. It is alright if one works with pre-built theme and does not use any external data but when one needs to design his own theme or include some data from the project in the site (for example JavaDoc), it is not convenient at all.

In my opinion, it would be good to add additional flexibility to plugin and completely remove this 'project in project' structure, storing all configuration in gradle file or in separate groovy configuration file.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

project group can not be changed from com.sysgears.grain. Main class name is bound to it and it seams that some internal features as well, because project would not compile if group name is changed.

Nothing is bound to com.sysgears.grain group inside themes. Please clarify. How code compilation can be bound to any specific group? It's not possible at all. It's just plain Groovy code.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

groovy source code classes are bound to com\sysgears\theme\ directory. I tried to move them to another directory and change imports in SiteConfig, but got some NPEs. It is not very easy to access these files and I do not see any reason for complicated directory structure since there are no name conflicts. I also do not understand the purpose of Launcher.java class since it just point to some internal launcher.

The fact that you weren't able to move something to another directory doesn't mean that anything is bound to specific directory layout. Nothing in Grain is bound to specific layout structure. Please read documentation carefully.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

SiteConfig.groovy has direct class imports which is not very good idea if it is intended as a configuration file. If one moves this classes or uses custom ones, he should replace all imports? It is better to use fully qualified class names and reflects to invoke user classes.

SiteConfig.groovy is just a Groovy file. What is inside it is a responsibility of theme author. It can hold direct imports or can use qualified class names. What it has to do with Grain at all?

@larixer
Copy link
Member

larixer commented Jan 18, 2016

generally in gradle all temporary files and build results are stored inside build directory. Is there a reason to store target and caches in project root? If they are all in one directory, than it is easier to clean.

Grain is not a gradle plugin. Grain can work as a gradle plugin, but it can work standalone as well. Grain cache files have nothing to do with the build cycle. They are in the Grain rendering cycle and they are not build files, rather they are cache files.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

For gradle plugin related issues, please open issue at:
https://github.com/sysgears/grain-gradle-plugin

@altavir
Copy link
Author

altavir commented Jan 18, 2016

I mean that if I change the group, it won't compile.
The obvious reason is that string: mainClassName = [project.group, 'Main'].join('.'). It references com.sysgears.grain.Main class which is not exposed to the user. It tried to set main class manually like mainClassName = com.sysgears.grain.Main. But it still won't work causing some NullPointerException.

SiteConfig.groovy is used by internal grain classes and so it is a part of grain framework. Can I create theme without this file? I tried to move classes referenced by SiteConfig to another directory and change imports but it throws

Caused by: java.lang.NullPointerException
        at org.eclipse.jetty.util.resource.ResourceCollection.<init>(ResourceCollection.java:98)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:80)
        at org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke(CachedConstructor.java:74)
        at org.codehaus.groovy.runtime.callsite.ConstructorSite.callConstructor(ConstructorSite.java:45)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:247)
        at com.sysgears.grain.preview.SitePreviewer.start(SitePreviewer.groovy:90)

@larixer
Copy link
Member

larixer commented Jan 18, 2016

I mean that if I change the group, it won't compile.
The obvious reason is that string: mainClassName = [project.group, 'Main'].join('.'). It references com.sysgears.grain.Main class which is not exposed to the user. It tried to set main class manually like mainClassName = com.sysgears.grain.Main

Yes, it's the problem in the logic of the theme. mainClassName shouldn't be computed this way. I'm not sure though, why NPE if you set mainClassName directly. Have you set it as a string? i.e.:

mainClassName = "com.sysgears.grain.Main"

@altavir
Copy link
Author

altavir commented Jan 18, 2016

OK, tried that again, and this time it worked. Probably last time I changed source code directory as well or forgot the quotes.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

SiteConfig.groovy is used by internal grain classes and so it is a part of grain framework. Can I create theme without this file? I tried to move classes referenced by SiteConfig to another directory and change imports but it throws

To what directory did you tried to move which imports? Please be more specific. Please keep in mind, that Grain is not bound to com.sysgears group, but general Groovy class finding rules still apply.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

OK, tried that again, and this time it worked. Probably last time I changed source code directory as well or forgot the quotes.

Yep, I also thought, it's missing quotes...

@altavir
Copy link
Author

altavir commented Jan 18, 2016

I moved files directly to src (without changing source directory location in configuration). So import com.sysgears.theme.ResourceMapper should be transformed to ResourceMapper. Import from the same package is unnecessary, but it still should work.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

You should still have some package name, not default one as your classes will be accessed by Grain, which has named package:
http://stackoverflow.com/questions/283816/how-to-access-java-classes-in-the-default-package

It's a Java-thing, has nothing to do with Grain itself...

@altavir
Copy link
Author

altavir commented Jan 18, 2016

After some experimenting, I forced it to work.

What one need is:

  • non-default package
  • change imports
  • change package names

I still do not understand, what Launcher.java does. Preview obviously works without it.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

Launcher.java is for more convenient IDE integration. It's referenced in the docs. The purpose is to let user just import the gradle project with Grain theme, then right-click on Launcher.java and select Run to run the preview.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

Some IDEs have poor support for Groovy, hence Launcher.java should be supported by most IDEs, even those that don't know about Groovy at all

@altavir
Copy link
Author

altavir commented Jan 18, 2016

OK, it solves most of problems. Still, constructing my own theme is not overwhelmingly convenient, but I suppose this is the opposite side of flexibility.

Currently, I am working on my second project using Grain (first one here), so I wish you luck in future development.

@larixer
Copy link
Member

larixer commented Jan 18, 2016

Yes, we are aware that it's cumbersome at times. But as you mentioned, the flexibility was the first priority. And wrapping flexibility into ease of use will require more effort.

Thanks for sharing info about your projects, feel free to ask questions. Please consider posting into Grain user group as well:
https://groups.google.com/forum/#!forum/grain-user

@larixer larixer closed this as completed Jan 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants