On the last point, the Maven convention would be for things to build into target/generated-resources. But I guess it depends whether they will be checked in or not. Checked in stuff goes into src/main/resources, but as part of the build any generated source/resource goes to target/generates/(re)sources<div>
<br></div><div>Having said that I'm not sure what po and pot files are so I'm not sure where the most appropriate output should be.<br><div><br></div><div>Chris</div><div><br><br><div class="gmail_quote">On 11 December 2010 21:51, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Dec 11, 2010, at 4:00 PM, Chris Burrell wrote:</div>
<br><blockquote type="cite"><div>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</div>
</blockquote><br></div>Those will be moving.</div><div><div class="im"><br><blockquote type="cite">
<div><br></div><div>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...</div>
</blockquote><br></div>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.</div><div><br></div><div>
I could move them now, but I'm in the process of doing merges into a smaller number of resources.</div><div><br></div><div>The pot and po files will be at src/main/i18n. They will build from there into src/main/resources.</div>
<div><br></div><font color="#888888"><div>DM</div></font><div><div></div><div class="h5"><div><br></div><div><br><blockquote type="cite">
<div><br></div><div>Chris</div><div><br></div><br><br><div class="gmail_quote">On 11 December 2010 19:39, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Dec 11, 2010, at 11:26 AM, Chris Burrell wrote:</div>
<br><blockquote type="cite">A) Familiar build/deploy environment<div><div>>> I can't agree here: Maven folk expect either to </div><div>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)</div>
<div>or b- if they prefer, then to use the command line with the simple command line "mvn install" (similar to ant all).</div></div></blockquote><div><br></div></div>Actually, I think we agree but are saying it in a way that is at odds with each other.</div>
<div><br></div><div><div><br><blockquote type="cite"><div><div><br></div><div>B) dependency on 3-rd party jars</div><div><div>>> 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!): </div>
<div>- step 1: sync from subversion</div><div>- step 2- mvn install</div></div></div></blockquote><div><br></div></div>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.</div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>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.</div>
<div><div><br><blockquote type="cite"><div><div><br></div><div>C) low cost of checkout for translators</div><div>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.</div>
</div></blockquote><div><br></div></div>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.</div>
<div><div><br><blockquote type="cite"><div>
<div><br></div><div>D) Setting up a repository</div><div>Yes that is easy to do. And the best way to do it really, would be to have a crosswire repository on <a href="http://crosswire.org/" target="_blank">crosswire.org</a> 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?</div>
</div></blockquote><div><br></div></div>This sounds good.</div><div><div><br><blockquote type="cite"><div>
<div><br></div><div>E) Maintaining a maven build</div><div>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!</div>
</div></blockquote><br></div>Fine by me. ATM you, Peter and I are the committers. Peter only commits changes to translations.</div><div><div><br><blockquote type="cite"><div>
<div>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).</div>
</div></blockquote><div><br></div></div>What ever you like. Let's see about you setting this up on the CrossWire server with Troy's help.</div><div><br></div><div>In Him,</div><div>DM</div><div><div></div><div>
<div><br></div><div><br></div><div><br><blockquote type="cite"><div>
<div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">On 11 December 2010 14:14, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Chris,<div>I think that it is important that "build" not get in the way of participation. </div></div></blockquote><div>>> 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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><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></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><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 style="white-space:pre-wrap"> </span>DM</div><div><br></div><div><div><div><div></div><div>
<div>On Dec 11, 2010, at 6:29 AM, Chris Burrell wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div>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" target="_blank">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/" target="_blank">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></div></div>
_______________________________________________<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
</blockquote></div><br></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div>