Thank your replies, Stefano and Eric. See inline.
Best, gazda On Tue, Feb 21, 2012 at 3:31 PM, Stefano Bagnara <apa...@bago.org> wrote: > 2012/2/21 Jochen Gazda <gazdahims...@gmail.com>: >> (1) [....] >> But as for parent references I am asking myself what can be the reason >> for distinct versions in the parent's project.version and its child's >> project.parent.version? Here is an example from the current trunk: >> apache-jsieve has version 0.6-SNAPSHOT in its pom, but 0.5-SNAPSHOT is >> referenced in apache-jsieve-assemble's pom as its parent. Both m2e and >> mvn install complain about that. When I replace 0.5-SNAPSHOT in >> apache-jsieve-assemble's pom with 0.6-SNAPSHOT it works. Is it a bug? > > IMO ti does not make sense and it is a bug. I guess the issue is > related to the use of "parent module in a subfolder" pattern, that is > much more difficult to deal with. Eric seems to work on jsieve at the moment. apache-jsieve-assemble module was commented out from its parent and it does not harm my builds now. >> apache-james-mailbox referencing james-project 1.8.1-SNAPSHOT as its >> parent is another example. Why does it not reference james-project >> 1.8.2-SNAPSHOT? > > Maybe simply because the last time we worked on mailbox we only had > 1.8.1-SNAPSHOT and the parent moved forward in the mean time. > This is not a big issue, but you can move mailvox to 1.8.1 final or to > 1.8.2-SNAPSHOT if it helps. I think we can forget about this one too. There is 1.8.1 at present in the trunk which works for me. And yesterday, when I tried to compile it was 1.9-SNAPSHOT and not 1.8.1-SNAPSHOT as I told you. Sorry. >> Generally, which are there situations in which parent reference >> version lower than parent trunk version make sense? > > It simply happens because we don't start upgrading every project pom > when we move the parent forward but we only upgrade them when we need > a release. > Otherwise we should always try to build with the latest available > released parent (not even a snapshot). Why should we always try to build with the latest available released parent? And who is "we" here? Did you mean (a) "we" = developers building James to test our own changes or is it (b) "we" = developers building a release for the public? At the moment I can identify myself with (a): I am trying to find a way how to effectively test my own changes in a freshly built James instance. I will consider what you recommend at the bottom: > mvn clean package && mvn install for each project (in the > right order, so to not depend on only snapshot repositories) >> (2) In (1) I spoke about the case when referenced version is lover >> than the trunk version. Here I am asking about the opposite: >> hupa-parent references james-project 1.9-SNAPSHOT as its parent but >> the version of james-project in the trunk is 1.8.2-SNAPSHOT. This >> cannot be OK, can it? > > Well, when you work with snapshot everything can be right or wrong. > If you release 1.8 then you automatically create 1.9-SNAPSHOT.. after > a while you decide to release 1.9-SNAPSHOT as 1.8.1 and this will move > you to 1.8.2-SNAPSHOT. > As they are snapshots it is not so bad. > >> hupa-parent should be fixed to reference james-project 1.8.2-SNAPSHOT >> as its parent, should it not? > > BTW, it would be better to point to 1.8.1 because it probably doesn't > need anymore to point to a snapshot for the parent. > >> (3) Generally, is the following sequence always expected to work and >> if it does not, is it a reason to file a bug in Jira? >> >> rm -Rf $HOME/.m2/repository >> cd james/current >> svn update >> mvn clean install -DskipTests > > I often found problematic to run a single pass "mvn clean install" but > runinng the mvn clean package && mvn install for each project (in the > right order, so to not depend on only snapshot repositories) is > expected to work and if it doesn't work we should probably fix > something. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
