You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/05/24 11:58:11 UTC
Maven2 opinions
I was writing this to ask Noel for some more explanations about why he
doesn't like Maven2, but I'd like to know the opinion of all committers
about this.
What is your opinion about switching our build system to maven2 ?
I'm +0.5 for the following reasons:
1. using a "standard" directory layout simplify the use of third party tools
2. At least Eclipse and maybe even IDEA and NetBeans have a maven2
plugin that simplify the import/configuration of a maven2 project.
3. We can try to remove libraries from our repository
4. It will allow us to split James in subprojects: mailet-api,
mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets, spoolmanager
having well-defined dependencies between modules. This will improve the
self-documentation provided by james sourcecode (it makes much more
clear the modules and the dependencies) and maybe a step towards OSGi
bundles.
5. It simplify the integration in continuous integrations environments.
6. It should be easier to create a website integrating James Server and
our subprojects (jSPF, jSieve, Mime4J, Postage).
I know we can achieve some of the tasks even not using Maven2: in this
case I would like to know what you propose as an alternative.
About the "website skin" if anyone does not like the maven2 default skins:
Stylus: http://maven.apache.org/
Default: http://www.mime4j.org/
We can even write our own skin to match as close as possible the current
james style.
I would also like to know what is the opinion about the usage of the
Standard Directory Layout
(http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)
and the splitting of James in modules.
Can we do the latter without switching to Maven2 ?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Having no real project experience with maven2 I'm nevertheless impressed
> how highly modularized projects using maven2 build & test.
>
> The Postage build is tightly dependend on James, since the code is
> dependend on a few parts of James. It includes james-2.3-dev.jar (or
> another version of it) and a few other jars from <JAMES>/lib.
> So this is a situation where one project depends on the artefacts of
> another project which I'd expect to be much easier to handle using maven2.
We should probably split james in many modules, so you can add only
small part of James as dependency for postage.
You could also have postage splitted in 2 modules: the main module not
depending on James and the secondary module that contains the james
integration.
Btw I think that we should proceed by steps.
Also Maven2 has its own problems, mostly related to the shared
repositories and we'll probably hit that problems one day, but I think
the features we get from m2 worth this problems.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Having no real project experience with maven2 I'm nevertheless impressed
how highly modularized projects using maven2 build & test.
The Postage build is tightly dependend on James, since the code is
dependend on a few parts of James. It includes james-2.3-dev.jar (or
another version of it) and a few other jars from <JAMES>/lib.
So this is a situation where one project depends on the artefacts of
another project which I'd expect to be much easier to handle using maven2.
CI would be another important step ahead for the James project
infrastructure.
I am cautiously +1.
Bernd
Stefano Bagnara wrote:
> I was writing this to ask Noel for some more explanations about why he
> doesn't like Maven2, but I'd like to know the opinion of all committers
> about this.
>
> What is your opinion about switching our build system to maven2 ?
>
> I'm +0.5 for the following reasons:
>
> 1. using a "standard" directory layout simplify the use of third party
> tools
>
> 2. At least Eclipse and maybe even IDEA and NetBeans have a maven2
> plugin that simplify the import/configuration of a maven2 project.
>
> 3. We can try to remove libraries from our repository
>
> 4. It will allow us to split James in subprojects: mailet-api,
> mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets, spoolmanager
> having well-defined dependencies between modules. This will improve the
> self-documentation provided by james sourcecode (it makes much more
> clear the modules and the dependencies) and maybe a step towards OSGi
> bundles.
>
> 5. It simplify the integration in continuous integrations environments.
>
> 6. It should be easier to create a website integrating James Server and
> our subprojects (jSPF, jSieve, Mime4J, Postage).
>
> I know we can achieve some of the tasks even not using Maven2: in this
> case I would like to know what you propose as an alternative.
>
> About the "website skin" if anyone does not like the maven2 default skins:
> Stylus: http://maven.apache.org/
> Default: http://www.mime4j.org/
> We can even write our own skin to match as close as possible the current
> james style.
>
> I would also like to know what is the opinion about the usage of the
> Standard Directory Layout
> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)
> and the splitting of James in modules.
>
> Can we do the latter without switching to Maven2 ?
>
> 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
Re: Maven2 opinions
Posted by Stefano Bagnara <ap...@bago.org>.
Søren Hilmer wrote:
> Hi Stefano,
>> Just to be sure I understood your comment when you say "POM" you mean
>> the SDL ?
> Well, now you got me :-) What do you mean by SDL?
>
> By POM I mean "Project Object Model", to me that is more than the pom.xml. But
> the model or layout of the project as such.
SDL is the layout of the project, so I think we agree.
> And Maven have a preferred way to do that, and following that way makes it
> alot easier to use Maven IMO.
I agree.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Søren Hilmer <sh...@widetrail.dk>.
Hi Stefano,
>
> Just to be sure I understood your comment when you say "POM" you mean
> the SDL ?
Well, now you got me :-) What do you mean by SDL?
By POM I mean "Project Object Model", to me that is more than the pom.xml. But
the model or layout of the project as such.
And Maven have a preferred way to do that, and following that way makes it
alot easier to use Maven IMO.
>
> If I understood your message you are +1 to change our current layout to
> match the default maven2 layout and have a simple pom.xml because we
> "refactor" our repository to match the maven2 standard.
Exactly!
> You are instead -1 to introduce maven2 as a complicate pom.xml that
> override every default to match our current build model.
>
Again exactly my view.
I believe that if you go the Maven way, you go it all the way!
--Søren
> Is this correct or is this the opposite of your thought?
>
> Stefano
>
> PS: I think that SDL (Standard Directory Layout) is one of the best
> thing introduced by the maven project. When I look to new projects using
> the SDL I feel home, I understand much more thing at a glance than what
> I understand from non SDL projects.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Stefano Bagnara <ap...@bago.org>.
Søren Hilmer wrote:
> I am a +1 for Maven.
> I believe that Maven greatly simplifies build, test, documentation.
> Of course you have to buy it's POM, but I do not consider that to be a major
> drawback, since it is close to what we got and is well designed.
> It is my opinion that if you try to bend your own POM to Maven instead of
> adopting Maven's POM you are in for a bumpy ride, and in that case I would be
> -1 on the subject.
>
> --Søren
Hi Søren,
Just to be sure I understood your comment when you say "POM" you mean
the SDL ?
If I understood your message you are +1 to change our current layout to
match the default maven2 layout and have a simple pom.xml because we
"refactor" our repository to match the maven2 standard.
You are instead -1 to introduce maven2 as a complicate pom.xml that
override every default to match our current build model.
Is this correct or is this the opposite of your thought?
Stefano
PS: I think that SDL (Standard Directory Layout) is one of the best
thing introduced by the maven project. When I look to new projects using
the SDL I feel home, I understand much more thing at a glance than what
I understand from non SDL projects.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Søren Hilmer <sh...@widetrail.dk>.
I am a +1 for Maven.
I believe that Maven greatly simplifies build, test, documentation.
Of course you have to buy it's POM, but I do not consider that to be a major
drawback, since it is close to what we got and is well designed.
It is my opinion that if you try to bend your own POM to Maven instead of
adopting Maven's POM you are in for a bumpy ride, and in that case I would be
-1 on the subject.
--Søren
On Wednesday 24 May 2006 11:58, Stefano Bagnara wrote:
> I was writing this to ask Noel for some more explanations about why he
> doesn't like Maven2, but I'd like to know the opinion of all committers
> about this.
>
> What is your opinion about switching our build system to maven2 ?
>
> I'm +0.5 for the following reasons:
>
> 1. using a "standard" directory layout simplify the use of third party
> tools
>
> 2. At least Eclipse and maybe even IDEA and NetBeans have a maven2
> plugin that simplify the import/configuration of a maven2 project.
>
> 3. We can try to remove libraries from our repository
>
> 4. It will allow us to split James in subprojects: mailet-api,
> mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets, spoolmanager
> having well-defined dependencies between modules. This will improve the
> self-documentation provided by james sourcecode (it makes much more
> clear the modules and the dependencies) and maybe a step towards OSGi
> bundles.
>
> 5. It simplify the integration in continuous integrations environments.
>
> 6. It should be easier to create a website integrating James Server and
> our subprojects (jSPF, jSieve, Mime4J, Postage).
>
> I know we can achieve some of the tasks even not using Maven2: in this
> case I would like to know what you propose as an alternative.
>
> About the "website skin" if anyone does not like the maven2 default skins:
> Stylus: http://maven.apache.org/
> Default: http://www.mime4j.org/
> We can even write our own skin to match as close as possible the current
> james style.
>
> I would also like to know what is the opinion about the usage of the
> Standard Directory Layout
> (http://maven.apache.org/guides/introduction/introduction-to-the-standard-d
>irectory-layout.html) and the splitting of James in modules.
>
> Can we do the latter without switching to Maven2 ?
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Serge Knystautas <sk...@gmail.com>.
On 5/30/06, Noel J. Bergman <no...@devtech.com> wrote:
> Paranoia is a positive adaptive trait in a security administrator.
> Especially when you run the code as root!
I have no problem understanding the security threat; I just find it
FUD. Widespread usage, no publicized attacks, the paranoid that
verify the checksums of their downloads representing a small
contingent.... and heck, this is only for someone building James from
source, not required for the masses.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Stefano Bagnara <ap...@bago.org>.
Serge Knystautas wrote:
> On 5/29/06, Noel J. Bergman <no...@devtech.com> wrote:
>> team indicates they don't support. Second, and more importantly, they
>> must
>> handle authentication of signed artificts. Without the latter, I would
>> sooner include the necessary jars, or require the user to download them
>> directly from a vendor site. Automatic downloading and installation
>> without
>> verification is wrong, dangerous and irresponsible. I don't mean signed
>> jars in the Java sense of jar signing. I mean signed as in the ASF
>> release
>> methodology.
>
> I think this is just a bunch of FUD. Java has survived for 10+ years
> without such an attack. There are just too many easier ways to hack
> systems.
>
> Obviously when ant and maven and other methods of automatically
> downloading support authentication, then great, but I see this as a
> bogus reason to not use automatic downloads.
+1
Automatic download is an optional feature: if you want to manually
download you can. If you like to automatically download then manually
check signatures you can either.
In fact the download itself has nothing to do with verification. If you
manually download the jars you should check the signature anyway because
vendor sites are not much more difficult to be spoofed than ibiblio.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Alex Karasulu <ao...@bellsouth.net>.
Hi all,
Noel asked me to post my opinions to this thread as a result of my
recent experiences with m2. Brace yourselves because I may jump around
in this email :).
I don't even know how to start off. Perhaps I can say Maven is a double
edged sword for me. It has been a journey developing ApacheDS with M1
then migrating to M2. Directory has been completely developed with
Maven since day one.
It made many things easier at first over ant but soon as the number of
project modules increased and we had to do things out of the ordinary we
found that it was just as verbose and sometimes harder to manage. I
don't have the time to list all the pros and cons but let me generalize
and say this. For the most simple of cases wrt every aspect of a
project from builds to generating a website maven is great: referring to
maven 2 here specifically (would never touch m1 ever again). When
things get complicated or out of the ordinary where they do not fall
into a prescribed Maven pattern that's when Maven starts behaving
oddly. This and how SNAPSHOTs are handled are my greatest peeves.
Also we still have not figured how to get some of the new site doc
generation mechanisms working properly. Thinking we could use this
doxia stuff for generating xdocs we have stuffed our latest doco into
confluence at safehaus and still have to figure out a way to get that
stuff into our repo now. It's a bit of a mess which we must solve
soon. I hope things have come along far enough since my m1-m2
conversion where we can actually use these plugins effectively to
rejuvinate our aging website.
In the end, I feel that maven is a great idea with a poor
implementation. But then again everyone thinks they can do it better
don't they? I've begun to suspect that even m2 has issues like the
latest problems I've had with the failing remote repositories. Maven
just has not been the same since codehaus/maven.org went down.
I've already made the mistake of pushing maven on the pro ant Felix
people and unofficially they're not too happy with that and I feel
responsible. Not saying you guys should not use maven tho. However I
think if you have a pre-existing project built on ant and you're
comfortable I'd stick with that. If you're starting a new project and
need to get things up and running fast maven goes a long way.
Sorry for not giving more concrete examples, also I hope my love hate
afair does not offend any of my good maven friends. I'd probably be
complaining and loving Ant just as much if that's what I was using today.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Maven2 opinions
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge Knystautas wrote:
> Java has survived for 10+ years without such an attack.
And for those 10+ years, Java security has been based upon one of two
things: location and, more recently, signing. Most jars, e.g., Sun's jars,
are not signed. Besides, and not atypically, JAMES does not use Java 2
security. So the security a user has when running code is derived from
trusting its origin. Automatic installation of code from untrusted sources
renders such trust foolish at best.
> There are just too many easier ways to hack systems.
If security naive approaches such as Maven's prevail they will become
vectors for easy attack, which is why they are being pushed to fix the
problem. The folks on the Maven project do recognize the issue. They may
have been naive about security, but they are smart folks.
> when ant and maven and other methods of automatically downloading
> support authentication, then great, but I see this as a bogus
> reason to not use automatic downloads.
Imagine if someone pushed to a repository a hacked version of JAF such that
it recognized a special MIME type, and started executing instructions. Few
would be the wiser. Are we having fun yet?
Paranoia is a positive adaptive trait in a security administrator.
Especially when you run the code as root!
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Serge Knystautas <sk...@gmail.com>.
On 5/29/06, Noel J. Bergman <no...@devtech.com> wrote:
> team indicates they don't support. Second, and more importantly, they must
> handle authentication of signed artificts. Without the latter, I would
> sooner include the necessary jars, or require the user to download them
> directly from a vendor site. Automatic downloading and installation without
> verification is wrong, dangerous and irresponsible. I don't mean signed
> jars in the Java sense of jar signing. I mean signed as in the ASF release
> methodology.
I think this is just a bunch of FUD. Java has survived for 10+ years
without such an attack. There are just too many easier ways to hack
systems.
Obviously when ant and maven and other methods of automatically
downloading support authentication, then great, but I see this as a
bogus reason to not use automatic downloads.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Maven2 opinions
Posted by Norman Maurer <nm...@byteaction.de>.
Am Dienstag, den 30.05.2006, 12:35 -0400 schrieb Serge Knystautas:
> On 5/29/06, Noel J. Bergman <no...@devtech.com> wrote:
> > team indicates they don't support. Second, and more importantly, they must
> > handle authentication of signed artificts. Without the latter, I would
> > sooner include the necessary jars, or require the user to download them
> > directly from a vendor site. Automatic downloading and installation without
> > verification is wrong, dangerous and irresponsible. I don't mean signed
> > jars in the Java sense of jar signing. I mean signed as in the ASF release
> > methodology.
>
> I think this is just a bunch of FUD. Java has survived for 10+ years
> without such an attack. There are just too many easier ways to hack
> systems.
>
> Obviously when ant and maven and other methods of automatically
> downloading support authentication, then great, but I see this as a
> bogus reason to not use automatic downloads.
>
I really agree ..
bye
Norman
Re: Maven2 opinions
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> 4. It will allow us to split James in subprojects: mailet-api,
>> mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets,
>> spoolmanager having well-defined dependencies between modules.
>
> What prevents us from doing that with Ant? What prevents us from doing any
> of this with Ant?
Are you willing to do that? When?
If I have to do that I am much more able and it takes much less doing it
with maven2.
Otherwise I could tell you: why don't we use gnu "make"? I'm sure we can
do everythinh with make too...
>> 5. It simplify the integration in continuous integrations environments.
>
> GUMP works fine, no?
I have to manually configure GUMP to "handle" the ci of a project. Using
Continuum and a maven2 "ready" project I can do CI with no configurations.
Will you do the GUMP work for every of the 1000s developers using James
trunk? :-P
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Maven2 opinions
Posted by "Noel J. Bergman" <no...@devtech.com>.
I don't believe that we need Maven 2. But I am willing to see what effect
it would have on our build systems. Fortunately, Maven and Ant build
structures can exist simultaneously, so we can add Maven and see how we all
like the end result. I am not interested to have a Maven generated web-site
unless it is substantially what we have now, except improved. Maven
generated web-sites have generally and historically been hugely bloated.
Our entire site is 28MB, of which javadocs are 19MB.
> 3. We can try to remove libraries from our repository
The Maven repository is not something that we should use. Two primary
problems that Maven must resolve before I would be willing to use it.
First, they must handle HTTP redirection, which e-mail from our mirroring
team indicates they don't support. Second, and more importantly, they must
handle authentication of signed artificts. Without the latter, I would
sooner include the necessary jars, or require the user to download them
directly from a vendor site. Automatic downloading and installation without
verification is wrong, dangerous and irresponsible. I don't mean signed
jars in the Java sense of jar signing. I mean signed as in the ASF release
methodology.
> 4. It will allow us to split James in subprojects: mailet-api,
> mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets,
> spoolmanager having well-defined dependencies between modules.
What prevents us from doing that with Ant? What prevents us from doing any
of this with Ant?
> 5. It simplify the integration in continuous integrations environments.
GUMP works fine, no?
> I know we can achieve some of the tasks even not using Maven2: in this
> case I would like to know what you propose as an alternative.
> Can we [change the directory structure] without switching to Maven2
Why not? But also, why? What benefit do you see, and from what change? I
am not saying no. Just want more details on your thoughts. Obviously, we
already have some separation, e.g., src/java/.../{component} for major
component areas. We could generate separate jars for each.
Not sure if I see a benefit, although it might help with one of my goals,
which is to allow, but not require, a configuration where the protocol
services and the pipeline can all run as separate processes, allowing
distributions and some other benefits (separate restarting and privilege
separation).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org