james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Date Mon, 31 Mar 2008 20:08:53 GMT
On Mon, Mar 31, 2008 at 8:48 PM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
>
> On Mon, Mar 31, 2008 at 7:53 PM, Stefano Bagnara <apache@bago.org> wrote:
>  > Robert Burrell Donkin ha scritto:
>  >  > On Mon, Mar 31, 2008 at 2:05 PM, Stefano Bagnara <apache@bago.org>
wrote:
>  >
>  > >>  >>  The funny thing is that all of this thread is about a "stupid"
pom that
>  >  >>  >>  even my father could write as is if I explain him the pom
>  >  >>  >>  semantic+syntax and I tell him to describe junit-3.8.1.jar.
This is what
>  >  >>  >>  scare me: the fact that we don't have a clear way to rewrite
this
>  >  >>  >>  f***ing xml from scratch and release jSPF-0.9.7.
>  >  >
>  >  > under US copyright law, only the expression and not the facts would
>  >  > have been copyrightable. if it were me, i would have simply created a
>  >  > clean room implementation and been done with it.
>  >  >
>  >  > or just deleted the pom altogether
>  >
>  >  My main concern is being diligent in not creating further problems to
>  >  maven users, so I would like to avoid the creation of metadata different
>  >  from the one published in central.
>  >
>  >  This mean that I would not like to create a new junit.pom with the same
>  >  groupId/artifactId but with different data (in this very specific case
>  >  the pom we can create from scratch is almost identical to the original
>  >  one so we could even take this way).
>  >
>  >  Also, removing the pom means that maven tries to download it but if it
>  >  is disconnected or it is ran in offline mode then it will create an
>  >  "empty" pom including only the artifactId/groupId/version stuff. Again
>  >  this would be different but for this very specific case (junit.pom) it
>  >  would work.
>  >
>  >  In both case the risk is that we place a different junit.pom: if some
>  >  other m2 based project used by our users depends on license data,
>  >  description or other stuff declared in the junit.pom we are likely to
>  >  break their build.
>
>  IMHO this is a maven issue: it should really mark any poms it creates
>  and then download replacements once on line again
>
>
>  >  Another "hack" could be renaming junit-3.8.1.jar to myjunit-3.8.1.jar or
>  >  junit-3.8.1-custom.jar, declare our dependency on that specific jar and
>  >  declare a dependency exclusion for every other depedency depending on
>  >  junit. This would place a custom artifact in the build process/local
>  >  repository but would not break other builds. (something tells me we
>  >  already made this analysis for jsieve, before you found the alternative
>  >  solution).
>  >
>  >  Maybe we should ask to maven lists what is better to do (IIRC I already
>  >  asked this in past, receiving no answers...).
>
>  why not just use an ant script for offline builds?

+1

the website generation aspect excluded, I don't get it why removing
maven is not already discussed as an obvious option here.
if we find that maven causes us non-technical problems - and this
thread is definitively proving this - , we are free to not use it.
I downloaded the 0.9.5er source distribution today and it does not
build with ant, only maven. it downloads a ridiculous large number of
jars for very little effect. I remember that I +1'ed maven usage for
building the site. but (hereby also answering a prev question asked on
this thread) the rest should work with ant and offline, please. :-)

Thanks,

  Bernd

PS: the website links downloadunstable.cgi and points to a beta build.

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