Continuing the train of thought I started laying out last night, I have some more details about the MavenLoader client module.
The Maven JS Plugin could generate a Javascript file or replace a token in HTML files in war projects that sets up the MavenLoader in the way talked about yesterday automatically based on the war project's POM dependencies upon Javascript artifacts. I suppose this could also be a stand-alone plugin that operates on wars.
There could also be a POM configuration option whether to prefer local copies of dependencies or ones from a specified repository (repopath). The code that expands the artifacts and rolls them up into YUI Loader format could be shared between the daemon and the Maven plugin.
This would close the circle a little more for Maven developers but still not require Maven in order to take advantage of the system. It would also be a step toward building the YUI Test integration with the JS plugin that I want :)
Tuesday, July 01, 2008
More Thoughts on Maven Loader
Monday, June 30, 2008
Javascript Dependency System using Maven + YUI Loader
I started thinking a while back about how to create a repository of Javascript libraries / applications using Maven for decentralized transitive dependency management. The progression of things that has led to these thoughts are Maven, Maven JS Tools (feature request), Google AJAX Libraries API, and YUI Loader.
My initial thoughts include using the Maven JS Tools plugin to build Javascript libraries in the same fashion as library jars for Java. These can be pushed to an external Maven repository and synced with the central repository.
A daemon could then pull Javascript artifacts from the central repository and process them. This would include extraction, building dependency meta-data for YUI Loader so that it could discover dependencies and download them as needed, and making both items available on a public HTTP server using YUI Loader's layout conventions.
On the client side, there would exist a MavenLoader model as a module loaded YUI Loader as normal. It would use addModule() like:
loader.addModule({
name: "mavenloader",
type: "js",
fullpath: "http://jsrepo.maven.apache.org/mavenloader/mavenloader.js"
});
// pull in the mavenLoader module now
loader.insert();
From this point, you could create a new MavenLoader as a decorator for YUILoader:
//Add the module to YUILoaderThe meta-data that the repo adds to the Javascript artifacts would call register() and addModule() just like regular yui modules work, except it would be on MavenLoader and actually wrap the YUI Loader functionality under the hood:
var mavenLoader = new MavenLoader({
loader: loader,
// maybe this can be inferred based on the loaded mavenloader?
repopath: "http://jsrepo.maven.apache.org/"
});
mavenLoader.require( "com.soashable:xmpp4js:1.0-SNAPSHOT" );
// or
mavenLoader.require({
groupId: "com.soashable",
artifactId: "xmpp4js",
version: "1.0-SNAPSHOT"
});
mavenLoader.addModule({
groupId: "com.soashable",
artifactId: "xmpp4js",
version: "1.0-SNAPSHOT",
requires: [{groupId: "com.prototype", artifactId: "prototype", version: "1.5.1"}]
});
// ...
MavenLoader.register({
groupId: "com.soashable",
artifactId: "xmpp4js",
version: "1.0-SNAPSHOT"
}, YAHOO.xmpp4js.Module);At this point, a call to the normal YUI Loader's insert() method should pull in all Maven dependencies transitively, with tranitive modules being added, registered and included recursively.
This is of course rough speculation, but my initial experimentation leads me to belieive that this system should be possible.
Sunday, May 18, 2008
Observations of Doxia Menu Inheritance
I couldn't find much/any documentation on inheriting menus from a Super POM using Doxia + Maven 2. Here is a quick overview of what I think I have learned using a small reference example to illustrate.
Project Layout
superproject
|
+- src/site/site.xml
|
\- module1
|
\- src/site/site.xml
Super Module site.xml Content
<?xml version="1.0" encoding="UTF-8"?>
<project name="${project.name}">
<body>
1 <menu ref="parent" inherit="top"/>
<menu name="Super Menu">
<item name="Parent A" href="parenta.html"/>
<item name="Parent B" href="parentb.html"/>
</menu>
2 <menu ref="modules" inherit="bottom"/>
3 <menu ref="reports" inherit="bottom"/>
</body>
</project>
Sub Module site.xml Content
<?xml version="1.0" encoding="UTF-8"?>
<project name="${project.name}">
<body>
4 <menu name="Menu A" inherit="bottom">
<item name="Link 1" href="link1.html"/>
<item name="Link 2" href="link2.html"/>
</menu>
5 <menu ref="reports" inherit="bottom"/>
</body>
</project>
So what does all this mean?
- interitance="top|bottom" - put a menu node before or after sub module's menu items
- 1 - will only be visible and have content in sub modules
- 2 - will only be visible and have content in super modules
- 3 - put reports at the bottom of all modules
- 4 - inherit="bottom" is not completely clear to me, but either top or bottom is required for the menu to show up
- 5 - I wanted project reports to always be at the bottom of the menu and could not figure it out without explicitly putting it there; this seems to override the report menu specified in the super site.xml.
Please correct me if I'm wrong about any of these observations/assumptions, and point me to documentation if you know of any. Otherwise, I hope this helps somebody.
Friday, May 16, 2008
Internet Identity Workshop (IIW) - Thoughts
I had the privilege of attending the Internet Identity Workshop (IIW) in Mountain View this week. It was a very cool experience, and my first time out to the valley. On a whole people are pretty sharp, but I think what differentiates them from the local talent in the Twin Cities is their connections. The majority of people there weren't much beyond my punching weight, but a key difference is that a good number were. I want to be the least talented person in a given setting; not by striving to be the worst, but simply by being surrounded by people who are great.
My favorite session was of course my own, "Identity Beyond The Web"; it would have been nothing though, without Jeff Hodges there. We went over the basics of SASL and SAML, talked about various SAML profiles and how they would plug into the design pattern of SASL. We also talked about n-tier authN/authZ and bashed OpenID a bit. Not that OpenID sucks, it just doesn't solve any non-web related identity problems.
Another interesting talk that indirectly tied in to SAML was given by Bryant Cutler and Devlin Daley; I don't have the session title, but the part I caught related to patterns of assertions about n-tiers of parties. I'm looking forward to reading their work.
My biggest hope for future IIW is more discussion of identity beyond the web and OpenID. I think it's a reasonable solution for a very limited space (probably its intended purpose), but it does not solve the more fundamental problem of ubiquitous identity.
I have gained a reasonable understanding of the identity space, but it is much, much deeper than the lay person can possibly imagine. I still have a long, long way to go. Otherwise this blog post would be much more insightful :)
There is no sense reiterating a review of the entire event, as there are plenty out there; just search for IIW2008a or IIW6.
Friday, April 25, 2008
XMPP on the Web: Soashable (upcoming MinneBar Session)
I'll be hosting a session at MinneBar this year: "XMPP on the Web: Soashable" on Saturday May 10th, at Coffman Union; it's FREE. I've never done anything like this, so hopefully they get out the free beer early ;).
XMPP on the Web: Soashable
Soashable is a web based, Open Source, multi-protocol instant messenger based on XMPP(Jabber) using BOSH (XEP-0124 and 0206); it is similar to Meebo. XMPP is anything from an IM protocol to a poor-man's middleware solution. Subject matter will range from technical details of XMPP and Soashable, to high level discussion of Jabber and standardization, to direction of the Soashable project.
Even if you don't come to my session, be sure to check out MinneBar if you're in the area. Last year it had an awesome turn out (I think I heard it was the biggest BarCamp ever), and the MinneDemos throughout the year have become more and more popular (though sometimes the presentations have reflected that... people market/seek VC rather than sharing interesting ideas). The unconference style gets some great conversation outside of the sessions going; I've never had a problem joining any conversation that's sounded interesting.
Along with Clayton, I hesitantly signed up for Twitter. Social broadcasting is something that I don't yet understand; well, I should say I don't see as useful; but I'll give it an honest try.
I remember the days when people made fun of LiveJournal because people posted about mundane things like eating a delicious peanut butter and jelly sandwich. I think I'm stuck at web 1.5.
Hit me up: http://twitter.com/harlanji.
