Hi Paul, Take over, does that mean you're completely taking over the development of the library, or you're just going to use it? If you're really taking over, then the current owner can "transfer ownership" of the repo to you, which means that you don't have to fork.
>From my experience, git submodules are still a pain to use. You have to manually commit updates to the main repository whenever you push changes to the submodule, and you have to explicitly update the submodules, they're not updated with a simple "git pull". So I'd say that the pain it adds (especially for git newbies) doesn't make up for the benefit of having just one repository to checkout. Three alternatives: - Just keep them separate, like the xwiki-* repositories, and tell users that they have to build them in order. If users aren't working on the JS library, they can just get the latest snapshot from a remote Maven repository, that's a lot simpler than working with submodules. - You can improve the previous idea with a path convention and Maven submodules: if the JS library is present in a certain subdirectory of the main repository, then let Maven build it as a submodule. In your main pom, define a <profile>, activated only if the <file>myjslib/pom.xml</file> exists, and which will add myjslib as a <module>. Then all one has to do to include the JS library in the main build is to clone the repository in the right location. This still means that both repositories will have to be pushed and pulled individually, but it's less than half the work for maintaining a submodule. - You can permanently merge the two repositories into one, which means that you'll have only one repository to maintain, but existing users and contributors of the JS library will lose the ability to checkout just the library, without the Curriki code. Depending on the size of the userbase, it might not be a nice thing to do. Now, for the build part, when you say you want to build a partial web application, do you mean you'll have it packaged as a war? I don't think that's necessary or semantically correct, since just a JS library doesn't make a web application. And it isn't needed, you can just package it as a jar (the default project packaging, just put all the files in src/main/resources), or as a zip (using the maven-assembly-plugin), or there's even a dedicated plugin for JS development at Codehaus: http://mojo.codehaus.org/javascript-maven-tools/ Here's how you would unpack a .jar dependency as an overlay of your war module: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <configuration> <overlays> <overlay> <groupId>some.js.library</groupId> <artifactId>js-library</artifactId> <!-- The version is taken from the <dependency> declaration, which is still required --> <type>jar</type> <targetPath>resources/uicomponents/</targetPath> <!-- This is the path in the final webapp --> </overlay> On Sat, Aug 24, 2013 at 4:41 PM, Paul Libbrecht <[email protected]> wrote: > > Hello fellow developers, > > At Curriki we are about to take over a new JS library for some assessment > specific pages. > The library is a GitHub repository which we would like to fork and include > in Curriki's webapp. > > Our intent is to do the following but I would like to know if there is a > danger of doing so or if it is indeed best practice. > > - we fork the GitHub repository > - part of the adaptation includes creating a maven project; it would build > a (partial) web-application > - Curriki's web project depends on that webapp(-part) and thus includes > the resources > - so as to ensure that recipients of Curriki can also build with it, we > make the repository a sub-module (somewhat equivalent to an svn:external) > in Git and in maven > > Thanks in advance for your comments, hints as to possible advantages or > dangers. > > Paul > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
