[jsword-devel] Maven, ant, ivy, etc.

[Chris Burrell]

A) Familiar build/deploy environment
>> I can't agree here: Maven folk expect either to
a- be able to simply import it into eclipse (whether that be before or after
sync from subversion, and before or after any build commands)
or b- if they prefer, then to use the command line with the simple command
line "mvn install" (similar to ant all).

B) dependency on 3-rd party jars
>> Maven's core aim is to be the Out Of the Box build experience. That's why
it was designed in the first place. It's aim is to be as portable as
possible. Dependencies are stored outside, and custom repositories can be
defined as part of the poms if they are not on Maven's Central repository.
Nexus is a free repository for that kind of thing so we can easily set one
up on the crosswire server. The instructions for building STEP come in 2
steps (spot the play on words!):
- step 1: sync from subversion
- step 2- mvn install

C) low cost of checkout for translators
I'm not very familiar with which bits translators actually require and which
bits they don't? We could set up a maven assembly goal, that builds a zip
file containing everything they need, in one download and store that in a
maven nexus repository. That should be do-able.

D) Setting up a repository
Yes that is easy to do. And the best way to do it really, would be to have a
crosswire repository on crosswire.org where releases and snaphots (nightly
builds) are stored. Then mirror the releases to Central (or some other
popular repository). Nexus comes as an HTTP server as well. So maybe that
would help the translators in your question above? At the moment, I'd like
to build STEP against JSword snapshots ideally, because I'd like to know
that if I submit a patch to JSword, I can confidently rely on the next
snapshot to have my fix in. When I release however, I will release against
the released versions. Perhaps when I'm ready to release I could ask for a
minor point JSword release?

E) Maintaining a maven build
I'd be happy to do this, as long as 1- we set up some continuous integration
at least for JSword, so that I/the developer who commits is notified when
the build is broken, 2- the committer is responsible for talking with me if
I have issues with their commit!
Also, we could set up the builds to automatically release into a Nexus
(maven) repository nightly, or on any change (preferred). I can
support/install Hudson (my preferred continuous integration tool), Nexus
(maven repository) and if possible Sonar (static code analysis and
reporting).




On 11 December 2010 14:14, DM Smith <dmsmith at crosswire.org> wrote:

> Chris,
> I think that it is important that "build" not get in the way of
> participation.
>
>> I agree wholeheartedly but the other main component is that it should be
very easy to reuse as part of other applications especially since JSword is
a library.



> So I think that we need to go ahead with maven support as another way. As
> long as you (or someone else) are willing to step up to on-going maintenance
> of the additional build mechanism and document it well enough for simple
> changes, go for it.
>
> There are a couple of problems to solve with an implementation:
> A) Familiar build/deploy environment
> **Eclipse folk (and maybe other IDE folk) are used to the code not being
> broken from the outset.
> **Ant folk expect to "ant all" as a first step and then use a text editor
> to edit the files.
> **Maven folk are used to code being broken until maven is run and
> dependencies are brought in.
>


>
> B) dependency on 3-rd party jars
> **We need a mechanism to include jars that are not available in maven (or
> other aggregating) repositories, but are available directly from the source
> project. Examples for us: JDOM 1.1.1 has a method that give us a huge
> performance increase. ICU 4.6 just came out.
> ** Maintaining the jars in SVN is helpful, but it bloats the server as no
> copy is ever actually deleted. And it serves no useful purpose.
> ** Having the jars immediately available on checkout provides an immediate
> oob build experience.
>

> C) low cost of checkout for translators
> Currently a translator needs to download all the included jars to do a
> translation. This is a high bar
>
> There is a mechanism in SVN called svn:externals that I think we might be
> able to take advantage of and make everyone happy.
> I don't know svn:externals well enough, but my understanding is that it is
> a way to say that a imports b.
>
> My thought is that we have a jsword-dependency that houses the 3-rd party
> jars and their source. This would make it easy for a translator as they
> don't have to have a long download. As it is an svn move, it does not cause
> bloat, and pushes the bloat problem to the future.
>
> Then jsword-mvn that uses svn:externals to bring in the few jars that are
> not externally available. This would use maven to do build and deploy and
> would be a central location for all things maven.
>
> A note on ivy. It is not a build mechanism, it leaves that to ant. It
> extends ant so that it does dependency management and iirc, deployment
> management. It also can generate maven POM files.
>
> Another thought: Can we set up a maven repository of the JSword jars and
> its dependencies on the CrossWire server? Would this be a good idea? I don't
> mind if they are mirrored elsewhere.
>
> Let's keep this going until we have a working implementation.
>
> In Him,
> DM
>
> On Dec 11, 2010, at 6:29 AM, Chris Burrell wrote:
>
> Hi All
>
> There are Ant fans, Maven fans. People who want to use Ant with Ivy. I'm a
> Maven fan. And think everyone should go the Maven way for all the benefits
> it provides!
>
> However, it's quite a big decision to move from one to the other and I
> don't think both work together very well, as one has to maintain 2 builds
> (which as we've seen can be difficult - the maven currently being broken).
> Clearly lots of people use Ant and aren't familiar with Maven (I was like
> that). Can I suggest a compromise:
>
> http://maven.apache.org/ant-tasks/examples/write-pom.html
>
> http://www.jonnyreeves.co.uk/2010/01/automatically-generating-a-maven-pom-file-with-ant/
>
> The main idea behind maven is that like Ivy is can do your dependency
> management. The POM file describes the project, the type of file associated
> with it (jar, war, sources, etc.) and all its dependencies. I think the
> above link would be a good compromise.
>
> It tries to generate the POM from what it knows of the Ant build, and then
> deploy to a repository. Would someone be willing to see if they can get that
> working in the ant build (i'm not very familiar with that). And I'll see if
> we can a maven repository set up somewhere external so that projects
> currently using Maven and JSword can download releases straight from
> there...
>
> In summary,
>
>    - let's continue using Ant to build JSword.
>    - For those people who prefer using Maven (me), let's ensure they can
>    build the maven POMs and JSword library easily locally,
>    - and better let's try and have the JSword libraries deployed widely on
>    the common Maven repositories.
>
>
>
> Chris
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20101211/2a191f2b/attachment.html>