-
Notifications
You must be signed in to change notification settings - Fork 30
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
Comments
Nothing is bound to |
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. |
|
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. |
For gradle plugin related issues, please open issue at: |
I mean that if I change the group, it won't compile.
|
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.:
|
OK, tried that again, and this time it worked. Probably last time I changed source code directory as well or forgot the quotes. |
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. |
Yep, I also thought, it's missing quotes... |
I moved files directly to |
You should still have some package name, not default one as your classes will be accessed by Grain, which has named package: It's a Java-thing, has nothing to do with Grain itself... |
After some experimenting, I forced it to work. What one need is:
I still do not understand, what |
|
Some IDEs have poor support for Groovy, hence |
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. |
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: |
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.
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.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 ofLauncher.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.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.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.
The text was updated successfully, but these errors were encountered: