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

[Chris Burrell]

So I have some POM files almost working, but without a repository with JDOM
1.1.1 it won't be easy. The other thing that I notice from the POM files is
that there are currently resources under src/main/java... and src/main/test

Would it be possible to move them to src/main/resources and
src/test/resources? This would simplify the maven POMs and make them more
readable to everyone. I'm guessing there would be some ant build script
changes there...

Chris



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

>
> On Dec 11, 2010, at 11:26 AM, Chris Burrell wrote:
>
> 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).
>
>
> Actually, I think we agree but are saying it in a way that is at odds with
> each other.
>
>
>
> 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
>
>
> By oob, I meant a one step process. It is a matter of expectation. Not
> until "mvn install" is done is the development area ready. Today, checking
> out JSword is sufficient to start development because the jars are already
> there.
>

> Really the issue is one of process and expectation. Not sure we can satisfy
> both. But to add maven as a complete solution while not disturbing the ant
> and current eclipse solution (I don't mean w/o change), is a great thing.
>
>
> 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.
>
>
> By moving the jars out of the jsword project, it satisfies the cost
> problem. They don't need a build environment. Just the current files from
> svn to translate. Ultimately we need a way to convert pot and po files held
> in one area to build property files in another. We probably will host the
> pot and po files on launchpad for easy translation.
>
>
> 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?
>
>
> This sounds good.
>
>
> 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!
>
>
> Fine by me. ATM you, Peter and I are the committers. Peter only commits
> changes to translations.
>
> 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).
>
>
> What ever you like. Let's see about you setting this up on the CrossWire
> server with Troy's help.
>
> In Him,
> DM
>
>
>
>
>
>
>
> 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/501e1e82/attachment-0001.html>