Bernd Fondermann ha scritto:
On Mon, Aug 4, 2008 at 13:34, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
