Let me elaborate on the question...
I have a custom CMS (built on codeigniter FTW) that includes many different types of modules.
Every time we have a new project come through the door, it is a variation and amalgamation of a few of the existing modules.
Sometimes a project comes through with requirements that are not satisfied by the existing modules, in that case I will write a new module...
All the modules are separated out in folders and the code is VC-ed using GIT. Every module has it's own Model, View, Controller, SQL and Javascript files. All the dependencies are also separated and folder-ed nicely...
The next step for me is to create some sort of installer script that will take me through the "scaffolding" process step by step, allowing me to choose from the existing modules. A glorified "makefile" if you may...
Rather than rolling my own, does anyone know of any such thing out in the wild.
I know of Apache ANT (java), what I need is something in pure PHP with very low or no dependencies...
I would like something as simple as running a git pull and then php make.php
Thanks.
The "Ant-like" alternative I am aware of in PHP land is phing it is written in PHP and it will allow you to perform several tasks for packaging, deploying and testing your web applications. The documentation is a great starting point if you want to hit the ground running.
It is can also be extended to define new tasks if needed (examples and explanations are provided in the documentation)
Reading through the doco it appears to be possible to install Phing without PEAR as documented here you would have to correctly setup the environment on each machine you wish to use Phing on. I can not confirm this method though as I use PEAR for all my installs.
Related
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
I am trying to install LXR tp parse my working folder of linux. In some of the tutorials on the web to set it up, they are trying to use the initdb-mysql script to initialize LXR's database in mysql. Well, I can not find this script in v2.0.0 but I can see it in older versions. Is that one still valid for use with v2.0.0? If not, what script I can use to setup the db for LXR v2.0.0? or if this whole DB thing was dropped how can I proceed?
on a side note: why linux projects always lack the proper documentation?!!!! I can see they have procedure for installing LXR on their own webiste and I believe it is outdated...why not update it?
Thank you!
Don't know if you're still looking for an answer, but here is one for the record.
Creating the DB is part of LXR initialization and is considered an internal step (i.e. not end-user visible). As such, it is allowed to change along the configuration process. This is why it is crucial to follow the procedure adapted to the LXR version.
LXR 2.x is configured with a configuration wizard (scripts/configure-lxr.pl) which takes care of generating the DB structure based on a template (templates/initdb/initdb-*-template.sql). These templates are not directly usable; they must be customized by the wizard to produce an initialization script custom.d/initdb.sh which you must manually launch after the wizard has finished its job.
The whole procedure for a simple case is shown on the LXR site. From the home page, select the installation link for the version you use (note that the procedure for 1.x also applies to 2.x).
For complex cases, download and read the comprehensive user's manual from SourceForge. Once again, select the manual adapted to the LXR version.
These manuals are not outdated since the LXR project has a rule to withhold release until documentation is ready.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.
I'm in a team that is converting a suite of Java applications to use OSGi. Previously, we used our own home-brew class loader system that has some similarities to OSGi, but it was nothing but trouble; we expect that by moving to using a system like Apache Felix we can have a system that works better while requiring less overall effort on our part to support.
We have been converting the modules that make up the applications into OSGi bundles, a largely painless affair with the use of Spring DM.
However, we — well, I as it's my responsibility in the team — need some way to reliably produce applications from this via a tool like Maven (or Jenkins); having a redistributable application installer that will install everything for the user is an absolute requirement. (We know our userbase fairly well; they want a simple install that won't download extra things after installation, well, not unless they decide to install extra plugins, but that's another story.) We do not wish to have to build the application manually at a console, or by using a GUI, as manual processes are too likely to run into silly human errors; we want to get it right and debugged once.
Moreover, some of the applications in our suite have to take command line arguments “like a conventional application”. (The application in question does significant processing internally, and sometimes needs to be invoked from other processes, such as web portals.) I know this causes some issues with the default Felix main, which only allows command line arguments for its own purposes instead of providing a way by default to export those to the bundles. (I know we could wrap things with a shell script so as to pass them in as properties, but… ewwww… there's got to be a better way. I suspect that making a custom main that exports a service providing access to the command line arguments is the best method.)
So, my question is what is a recommended way of building whole OSGi applications automatically, and am I using a reasonable approach to provide the command line arguments?
I'm guessing your best option is to write your own main that does specifically what you want. Since OSGi R4.2 the launching API is standard and pretty straightforward. You can just start from Felix' Main since it is already generic (i.e., it can launch any R4.2 framework, such as Felix or Equinox) and change it how you wish.
If the command line args represent configuration properties, you could just push them into Config Admin. Otherwise, just expose them how you see fit.
The Apache Sling Maven Launchpad Plugin generates a finished OSGi app from a list of bundles to include, and the Sling installer can be used to include initial configurations as well.
Even though they come from the Sling project, those module do not require your app to use the Sling app model, they are just used to build, launch and configure it.
For your arguments, use metatype. It will allow your bundles to load with default values and when the user configures the bundle via the web console or config files, metatype will inject the values into your variables. An installer would also be able to set these values at install time via the config files.
Me and my team are starting to build up a few re-usable scripts. They're re-usable within our org only as they work with proprietry apps and our particular server environment. So not really suitable for rubyforge or github, etc.
My question is, what is the best practice for ensuring we're all using the latest and greatest scripts across all users? We pretty much run these scripts on one server, but may need to expand to others.
Should we bundle them into gem(s) and start a private gem server?
Or something simpler like a common, shareable lib directory. Perhaps with a script to download/update from our SCM?
Other ideas?
Thanks....
This depends on some factors, like how many people want to change the code (only your team, or someone else too), or how much money you have for this?
Personally I'd create a build+gem server, where you can upload the scripts using some versioning system (like git or svn, depends on how many people are working on the project), and then create a cron job, that would automatically genereate the gems from the sources at generic intervals and store them as different versions. This way you can be sure that you always have an authorative server that stores your applications gems, and you can always get an earlier version if something breaks. Your script might create separate gem version names, like "appserv-edge" or "appserv-stable"
You might also want to check out github's closed source options too, if you have the money to afford that. I don't know however whether they have gem building and hosting facilities for non open-source programs.
I've created a private gemserver and it's dead easy. The only tricky bit is deciding how you want your users to upload gems. Personally, I just use a PHP upload form, and have it check to make sure that it's not masking any existing gems.
At my office we're using a bit of a hybrid approach for some of our shared scripts and libs. We do bundle them all in to a gem, but rather than using a gem server we keep them in source control, and then build the gem (using newgem) and install it locally as necessary.
The downside of this approach is that it takes two commands instead of one to install the gem, but this is largely mitigated in qa and production environments, since we use Capistrano for deployment.
The upsides are that it's dead simple, and in development there is a very short edit/build/deploy cycle if you're working with something that requires changes to the gem. I'm currently pulling a lot of common functionality in to the shared gem, so I'm really appreciating that aspect.