25 Aug
2013
25 Aug
'13
2:03 a.m.
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 <paul(a)hoplahup.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs