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 Sun, 10 Aug 2008 17:19:58 GMT
I committed my change to postage. Now hudson pass both ant and maven builds.

I also update NOTICE and other docs according to tree content.

Please review and feel free to propose improvement.

Now Postage requires java 5 and its acceptor smtpserver is based on 
server trunk snapshots (from a week ago).

I tested it against james 2.3.1 and it works like expected.

Bernd, if you still think (after my explanation) that basing postage 
smtpserver on server-trunk is bad I will see what I can do to downgrade 
it to james 2.3.1.


Stefano Bagnara ha scritto:
> 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

View raw message