james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Date Mon, 31 Mar 2008 19:48:28 GMT
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?

>  >>  You may have noticed that we only get 2 +1 ;-)
>  >>  So I'd like to know what exactly we have to do to get the 3rd +1, either
>  >>  by you or by someone of the other PMC members!
>  >
>  > i count +1s from yourself danny and norman: that should be sufficient
>  >
>  > - robert
>
>  I think Danny voted +0, the "thank goodness one +1!" was a reply to my
>  +1 and not a vote, I guess :-(

no, you're right

- robert

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