<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Chris,<div>I think that it is important that "build" not get in the way of participation. 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.</div><div><br></div><div>There are a couple of problems to solve with an implementation:</div><div>A) Familiar build/deploy environment</div><div>**Eclipse folk (and maybe other IDE folk) are used to the code not being broken from the outset.</div><div>**Ant folk expect to "ant all" as a first step and then use a text editor to edit the files.</div><div>**Maven folk are used to code being broken until maven is run and dependencies are brought in.</div><div><br></div><div>B) dependency on 3-rd party jars</div><div>**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.</div><div>** 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.</div><div>** Having the jars immediately available on checkout provides an immediate oob build experience.</div><div><br></div><div>C) low cost of checkout for translators</div><div>Currently a translator needs to download all the included jars to do a translation. This is a high bar</div><div><br></div><div>There is a mechanism in SVN called svn:externals that I think we might be able to take advantage of and make everyone happy.</div><div>I don't know svn:externals well enough, but my understanding is that it is a way to say that a imports b.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Let's keep this going until we have a working implementation.</div><div><br></div><div>In Him,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>DM</div><div><br></div><div><div><div>On Dec 11, 2010, at 6:29 AM, Chris Burrell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi All<br><div><br></div><div>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!</div><div><br></div><div>
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:</div>
<div><br></div><div><a href="http://maven.apache.org/ant-tasks/examples/write-pom.html">http://maven.apache.org/ant-tasks/examples/write-pom.html</a></div><div><a href="http://www.jonnyreeves.co.uk/2010/01/automatically-generating-a-maven-pom-file-with-ant/">http://www.jonnyreeves.co.uk/2010/01/automatically-generating-a-maven-pom-file-with-ant/</a></div>
<div><br></div><div>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.</div>
<div><br></div><div>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...</div>
<div><br></div><div>In summary, </div><div><ul><li>let's continue using Ant to build JSword. </li><li>For those people who prefer using Maven (me), let's ensure they can build the maven POMs and JSword library easily locally, </li>
<li>and better let's try and have the JSword libraries deployed widely on the common Maven repositories.</li></ul></div><div><br></div><div><br></div><div>Chris</div>
_______________________________________________<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>http://www.crosswire.org/mailman/listinfo/jsword-devel<br></blockquote></div><br></div></body></html>