Is there a quicker way to generate a site for maven for preview?
Background:
I'm using mvn site to generate a website which includes documentation for our project. I'm using the the apt format, which is simple, and very few mistakes are actually made, but I do want feedback after adding large amount of content so I don't have to spend too much time searching for syntax errors.
The problem is the site takes about 2 minutes to generate each time, and I would like quicker feedback then this for how the site looks and if I made any mistakes while typing up the docs. This isn't a huge issue but, the situation could certainly be improved.
Also, in order to help me out I'm using vim with syntax highlighting and if I need to get a quick preview on something there was a nice plug-in for eclipse that allows me to preview whether or not my apt is working correctly (of course, it's not the same as what is generated by maven, but it's close enough).
I'm open to any other suggestions, but generating a quick preview with maven would be the best option for productivity.
Configure the 'reporting' section to turn off what you don't want. Dependency analysis, for example, takes a long time. Look at the doc for the project-info-reports-plugin.
Related
Problem
I want to be able to save an image of either a div or a page (whichever easiest) without using dependencies.
So I have been browsing around for awhile to find many solutions to this problem, most of them I have found use dependencies such as BrowserShot or something else. I was wondering if there was some way to do this without dependencies other than ImageIntervention to manage the images.
I decided to use google's speed API for taking screenshots. I originally was trying to avoid this due to not being able to use it for development since that would be hosted locally.
The solution is described pretty well here.
I am evaluating Hugo for generating my static site that will potentially generate about 20 posts a day. So in about a year, there will be 7000+ posts written in markdown, that will need to be build and deployed to my production server.
I initially started with Jekyll, but the builds even for small number of pages is terribly slow, and I can't, for the life of me, understand how a seemingly basic requirement like incremental builds - building and generating only content that has changed -- is still not supported in Jekyll... #SMH.
So I would like to know if Hugo has incremental builds?
I didn't see anything in the documentation over at gohugo.io,or in the hugo help commandline help.
But Hugo seems to have everything else I am looking for, and the builds on a small batch of posts is blazing fast, so I would really like to give it a chance.
Plus the language that it's written in, GO, was co-authored by 1 of my all-time favorite hackers -- Ken Thompson.
Hugo currently has no incremental builds. The upcoming Hugo 0.16 will be smarter about building in server watch mode (i.e. it will detect what you change and only read that, testing indicates a ~15% improvement in the common case), but the builds will still be everything.
It will eventually happen, but it is a hard problem to solve in a simple way... But Hugo is very, very fast at what it does.
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.
My team uses the Radiator View plugin for Jenkins for fast feedback on the build status of a few different projects. One thing we discussed that would be helpful is if the SVN revision number were included in this view. After only a quick Google search, I haven't found a clear answer on whether this plugin is configurable or not; does anyone know if there's a straightforward way to add this information?
I dont think there are customizable figures there but what you can do is, pull down the source and get the revsion numbers for all the failing builds, you will have to write the code yourself, but from what I can see there is no way of doing this with the configuration options.
What you might want to try if you just need to get that information is the recent changes on the build page of the recently broken build.
Goodluck.
Can I ask why it would be helpful to have the svn revision number on display? As far as I understand it, a build radiator is supposed to 'radiate' meaningful information into the room. The svn number is fairly meaningless unless you can look up the number in the repository, in which case you could have just looked up the revision number on Jenkins anyway.
I'm just guessing, and do correct me if I'm wrong, but I suspect that your real desire is to have some way of quickly working out who might be responsible for a failing build. If this is the case, then processing check-in comments and displaying pictures of the users involved is a far more effective way of getting developers to react to failing builds. I've experienced this first hand at my company.
With this in mind, I have developed a standalone build radiator webapp that talks to Jenkins over its REST API. CI-Eye is trivial to set up, and will probably give you better results in the workplace than the Radiator View plug-in. Give it a try, and let me know what you think -- I'm quite actively improving it, and welcome any feedback.
CI-Eye is free and open source -- see the CI-Eye wiki for more details.
What do you think about this build tool? I'm thinking of migrating from maven2 to raven (my poms are getting bigger and bigger), but I'd like to hear some opinions first.
Thanks!
#andre:
Thank's for writing but I was actually looking for real experiences using raven. Anyway, the fact that nobody wrote is an indicator by itself (it seems few people are using it)
I haven't used either Raven or Buildr, but I have heard good things about the latter. In this blog article by Assaf Arkin, there is a nice case study: a 5,443 line, 52 file Maven configuration was reduced to 485 lines of Buildr. And, even though everybody says "Ruby is slow", Buildr was 2-6x faster than Maven.
Also, unlike Raven, Buildr seems to still be maintained: it is currently in the incubator stage as an official Apache project.
pom growth is a problem that everybody faces w/ maven I guess, but maven is at least maintained (2.1. just around the corner) and the raven project looks pretty dead to me. No updates this year and the mailinglist archives are also very small. It looks to me as it's too risky to switch your build process to a tool w/o a living community. Not quite the answer you wanted I guess, but my 2 cents.
I don't know anything about raven.
You should check out plain old rake, which lets you create very powerful tasks.
I've also heard about sake, which is just like rake tasks but system-wide, instead of being only available inside one of your projects.
They may not be specialized for Java, but they sure beat the hell out of plain old bash or (heaven forbid) batch scripts.