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

[Chris Burrell]

Thanks for all your input today. I think we'll be in a very good position
after some of the refactoring and moving things around. Let me know
when/when/how I can help to set up the repository.

Chris


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

>
> On Dec 11, 2010, at 4:00 PM, Chris Burrell wrote:
>
> 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
>
>
> Those will be moving.
>
>
> 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...
>
>
> Yes to those locations. The files will have dotted names rather than
> pathed. so org/crosswire/jsword/book/xxx.properties will be named
> org.crosswire.jsword.book.xxx.properties.
>
> I could move them now, but I'm in the process of doing merges into a
> smaller number of resources.
>
> The pot and po files will be at src/main/i18n. They will build from there
> into src/main/resources.
>
> DM
>
>
>
> 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/9e5e03b6/attachment.html>