james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [postage] refresh
Date Wed, 06 Aug 2008 07:36:14 GMT
Bernd Fondermann ha scritto:
> On Mon, Aug 4, 2008 at 13:34, Stefano Bagnara <apache@bago.org> wrote:
>> Hi all,
>>
>> I checked out postage to revamp the build and make sure it is self contained
>> and build like every other product we have in the repository.
> 
> :-) Great, thanks.
> 
>> I locally updated both the ant and the m2 descriptors and updated the code
>> to build against server trunk (of course this only changes how postage
>> receive mails and not what server it can test).
> 
> I'm not sure I like that. My initial goal was to make Postage work
> against the latest released (i.e. reasonably stable) server codebase.
> This means it cannot break if something changes in TRUNK. I would
> still opt for this goal unless there are good reasons not to.

The technical issue is that we already have good jars/poms for 
dependencies in james-server-trunk while this is not the same in james 
2.3.1 so it would take much more time for me to make a "stage" for the 
v2.3 dependencies (because we don't have one, while we have one for trunk).

If you plan to make a release then it worth building against something 
stable, otherwise IMHO it is good to build our products against some dev 
version, so we better understand the relationships and how to improve 
binding between projects.

So, if you can leave with this being against trunk I will take care of 
downgrading it in case of a release attempt, otherwise I'll see how much 
it takes to do it and I'll decide if it works for me.

>> I'd like to remove java 1.4 support because it is a bit of a PITA to support
>> conditional build because of missing JMX support.
> 
> :-)
> 
>> We are in 2008 and this is not a library but a tester tool, so I think
>> requiring java 5 is really ok in this case.
> 
> +1
> 
> ... which means Postage is again in the technological front-row of all
> our products. ;-)
> 
>> Summary of changes:
>> 1) add a stage folder with every jar needed to build/run the project (so to
>> not have a JAMES_HOME folder to setup)
> 
> I would like to know what that would mean, also in the light of my
> comments some paragraphs upwards.
> (Short explanations are welcome ;-) )

Sorry I given the "stage" folder process we use in every other product 
as "known", my bad.

For ant the stage folder is nothing more than a structured lib folder.
It contains any depednency jar for compiling and for running the project.

In this specific case we had a lib folder having "some" dependencies: 
junit and jars from server was excluded, so I simply added each 
dependencies until I was able to run "ant compile" successfully and then 
I added more dependencies until I was able to run "ant run".

After that I refactored the lib folder to a stage folder where every 
artifact are in the following format:
stage/<groupId>/jars/<artifactId>-<artifactVersion>.jar
groupId and artifactId are the names used by our m2 descriptors (in case 
of JAMES dependencies) or names used to deploy the jars to maven central 
repository in the case of other dependencies.

Then I also added poms (ASF ones in case of ASF dependencies, written by 
myself in case of junit) because this make this "stage" folder usable 
from the maven descriptor in order to build the project and create the 
website.

Hope I answered your question, please feel free to make more questions 
or to reiterate them if my english was meaningless ;-)
I'm happy to explain why I do/did things and why I don't/didn't do other 
things.

Stefano

---------------------------------------------------------------------
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