I am creating a new Moodle plugin, and I have created more than 180 files. I think it would be better to reorder them in a directory structure. Is there any rule or best practice to do this?
It depends on the type of plugin you are building. Moodle only enforces some folder structures for components like strings, db and templates. The documentation is somehow incomplete on the subject : https://docs.moodle.org/dev/Tutorial#Let.27s_make_a_plugin
You should take a look at core plugins that have recently been modernized by the implementation of mustache templates. The mod_forum plugin should be a suitable example of how to structure a large plugin (classes, libs, templates, etc).
Related
Is pod structure recommended over the traditional way of organizing files in ember projects using version 2.x ?
Ember pods are a way of structuring your project by feature, instead of type. Instead of having a directory structure with several types (controllers, models, templates...), everything is grouped around a feature (comments, posts...).
So its your decision to go that way. As you application grows you'll be able to easily find the route, model and template for each feature without having to look in a directory with a long list of files.
this might be a duplicate question (see Xtext Project: Add Jar Libraries with the Project Wizard Manager into the Classpath/Referenced Libaries of the clients Project), but I'm not able to comment on the original one due to low reputation.
Therefore my question regarding a similar topic:
I created a custom DSL which is working nice so far. The next step for us is to support newly created projects in this language with a custom library that will come as a dependency for created projects. This library was also created using our DSL so it's fully compatible with other projects.
This library will contain basic datatypes and other types as well as the generated code that will be used by the generator of the "surrounding" project.
I would need a hint on how to include this jar-file into the process of new-project-instantiation. Adding it manually to the created project works like a charm, but I'd like to have some automatism in this.
I'm on to creating a custom project wizard for the DSL, but I'm kind of stuck there due to the not-so-availability of in-depth documentation on this topic.
Thanks
noff
Situation:
I need several swf/exe output files compiled in FlashDevelop from several projects. More than 60% of ActionScript 3.0 source is common for all project, rest are project-specific. How can I organize that in FlashDevelop? I want to have "one-click-to-build all" setting without duplicating common codebase (so when I need to fix something I do not need to copy-paste solution into several files).
All sources are under develeopment and will change very often.
A straightforward solution is to make an external classpath, for instance:
c:\dev\shared_src\
c:\dev\project1\
c:\dev\project2\
Then configure each project:
Project Properties > Classpath
Add Classpath > select '../shared_src'
PS: of course you should keep everything under source control.
Using svn:externals you could structure your repository in such a way that the commom parts are stored just once in the source control system, so changes made can be synchronised with just a single commit and update cycle.
For example, imagine that you have ^/ProjectA and ^/ProjectB, each of with require ^/Common as a sub directory.
Using svn:externals, pull ^/Common into both projects.
The exact nature of doing this will depend on the version of svn you use, and any client you use (such as TortoiseSvn). Refer to the relevant edition of the svn book for specifics.
The ease of implementing this will depend quite a lot on how separate the common code currently is in your application; and pulling in directories as directories is much more practical than trying to pull them into an existing directory; and unfortunately wildcards for filepaths are not supported.
However, based on your description of your aim; this is the most straight-forward solution I can imagine.
Hope this helps.
I think (see below) that I would like to structure a Clojure project as multiple modules, with ordered dependencies - just like Maven lets me do with multi-modules projects.
But I can't see how to do this with Leiningen - all I can see is the checkouts fix described in the FAQ which doesn't seem to be as powerful.
Will lein do this? Should I be using Gradle instead? Or is this kind of thing not needed?
Some more context: I am wondering how to architect a modular application that supports plugins (which I imagine means jars dumped on the classpath). And am wondering to what extent I can structure that as a core + plugins (I am thinking I should be able to do something with Clojure's dynamic code loading and not have to go with Java/OSGi). So I guess the driving motivation for a single project comes from wanting some way of packaging everything (the core + default plugins) as a single blob that is easy for the end user, but which can also be divided up (and which is built and tested in fragments, testing the logical independence of each module). More general advice about this is welcome
Update
A possible solution that wasn't mentioned below is using a Maven plugin - I assume that supports everything Maven does, but compiles Clojure, so will work with nested modules, etc.
First, it does not seem like Leiningen supports a module hierarchy like Maven does. The checkouts are the next closest thing it has. It should be sufficient though to develop a modular application in Clojure though.
For the project structure, I would have an API project, a "core" project, the plugins themselves, and a separate packaging project. The core and the plugins should only depend on the API. Which build tool you use to create the packaging project is up to you. Gradle would probably be more effective at handling the packaging, however having the "checkout" functionality Leiningen offers could make development of the system as a whole easier.
I would take a look at the code for Leiningen and Noir to figure out how to effectively handle this.
For dynamically loading the plugins, I would start with looking how Noir handles it in two of their files:
server.clj has namespace loading for all files under a particular namespace. Under the hood it uses tools.namespace, but you can easily see how it's used to require every namespace under a particular base. This is how Leiningen handles custom tasks as well - the base definition for the task should be in the leiningen.$task namespace.
core.clj has what I would use for plugin registration. In summary, use a map under an atom and add plugins to that map. I would advice wrapping the registration with a macro to keep your code cleaner.
What I listed above should be sufficient if you don't need to handle adding plugins at run time. If you don't have every plugin on the classpath during start-up, I would recommend utilizing pomegranite to add entries to the classpath. You can see an example in classpath.clj.
We decided to go for an plugin mechanism which brings some services / logic etc., we use XML as a model approach, so the plugin has to bring it's own XSD to be integrated into the XML of the main application. This is done like the Spring approach (e.g. util:, jee: and other namespaces).
We can't upload every plugins XSD to a server. The XSD is located in the JAR of our plugin. Is it possible without adding this JAR to an XML Catalog to directly access this XSD and be able to reference it? So Eclipse can find this XSD and perform the auto-completion, validation, etc.?
Short: We have an XSD in our library and want to make use of it, how can we achieve this?
Look at the org.eclipse.wst.standard.schemas for examples of how to add schemas to the catalog from an Eclipse plug-in.