james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Gazda <gazdahims...@gmail.com>
Subject Re: How to build James from trunk
Date Tue, 21 Feb 2012 20:36:39 GMT
Thank your replies, Stefano and Eric.

See inline.

Best,

gazda

On Tue, Feb 21, 2012 at 3:31 PM, Stefano Bagnara <apache@bago.org> wrote:
> 2012/2/21 Jochen Gazda <gazdahimself@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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message