james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [jsieve] Any more TODO before 0.2 release?
Date Tue, 17 Jun 2008 23:59:53 GMT

On Jun 17, 2008, at 4:18 PM, Stefano Bagnara wrote:

> David Jencks ha scritto:
>> On Jun 17, 2008, at 12:50 AM, Stefano Bagnara wrote:
>>> David Jencks ha scritto:
>>>> <unsolicited build advice>
>>>> I glanced over the pom and have a couple comments:
>>> Thank you David, we need this kind of hints like gold, so next  
>>> time feel free to use the <solicited> tag ;-)
>>>> 1. After a lot of discussion on legal discuss the appropriate  
>>>> contents of LICENSE and NOTICE files is to include only wording  
>>>> that applies to what is actually in the jars.  This is encoded in  
>>>> apache-jar-resource-bundle-1.4.jar (you use 1.2).  In particular  
>>>> unless you are including the junit jar in one of the generated  
>>>> jars the extra comment is unnecessary and wrong.  The 1.4  
>>>> resource bundle also generates a DEPENDENCIES file that lists all  
>>>> the jar's dependencies: this is purely for user's possible  
>>>> convenience.
>>> shame on me: I checked for updates but I only updated the maven- 
>>> remote-resources-plugin and not the resource bundle version!! :-(
>>> I tested it now but it break our assembly because this way the  
>>> "simple NOTICE" without references to junit and commons-logging  
>>> references is included also in the bin with dependencies zip and  
>>> in src with dependenciez zip.
>>> I also don't understand why it is completely ignoring our src\main 
>>> \appended-resources\supplemental-models.xml file, but I'll  
>>> investigate a bit more on this, ASAP.
>> I looked at the build a little bit more and, there may be problems  
>> producing correct LICENSE/NOTICE files for all the artifact being  
>> built.  I think this shows up one of the problems with the current  
>> stage repo location.
> It's not a problem with the stage repo location: how do you make  
> maven to create different LICENSE/NOTICE files depending on the real  
> content? We create jar, source-jar, javadoc-jar, bin(with runtime  
> dependencies), src(with runtime, compile, test dependencies)  
> packages: each one would require a different NOTICE/LICENSE. I  
> thought that using the most complete NOTICE/LICENSE (the one for the  
> src with dependencies) was not the best, but acceptable.
>> The source and binary jars do not include junit so their LICENSE  
>> and NOTICE files must not include them.  The distro assemblies do  
>> include them so require a different LICENSE/NOTICE file.  So do the  
>> required LICENSE/NOTICE files in svn at the checkout root.
> You say "MUST NOT" include them: I thought it was a "SHOULD NOT",  
> but maybe the board had different directives?

I don't think there's total consensus except that what the m-r-r-p  
used to generate was wrong :-) To me it's unacceptable to distribute a  
jar with a NOTICE file that any user has to display somewhere claiming  
that there's say junit included when it is not included, likewise for  
license files.  They are supposed to be the users guidance as to what  
is legally going on with the jar they are working with.

>> For me this would be enough to put the stage repo in a different  
>> module with separate legal goo files, so that the build  
>> requirements don't get mixed up so much with the actual apache code  
>> in the module.  However opinions may differ on this.
>> Anyway I'm not sure what is breaking and what problems you are  
>> seeing.
> I'm not sure I understand how to place it in a different module,  
> still create all of our artifacts and have different license/notice  
> files in each artifact: can you drive me there?

I don't know how to produce these different legal files in one module  
except by hardcoding them in each case, so I'm suggesting separating  
into more than one module: the regular java module can just use the m- 
r-r-p with the latest resource bundle and no (AFAIK) additions, and  
the external jars can go in a stage bundle with a hardcoded LICENSE/ 
NOTICE file suitable to the contents.  Maybe I've drunk too much maven  
kool-aid but I find the mixing of repositories and code rather bizarre.

I may well be pushing in an inappropriate direction for the project  
here, so feel free to ignore me or tell me to shut up :-)

david jencks
>>>> 2.  I recommend listing the plugins in a pluginManagement section  
>>>> and leaving out the versions in the build and report sections.
>>> What is the advantage in a single module product? Most plugins are  
>>> used only once: wouldn't this simply duplicate the size of the pom?
>> I suggested this because I thought I saw several versions are  
>> repeated in the build and reports section.  Speaking for myself I  
>> can't keep 2 copies of a version in sync.
> Ok, if it is about duplication maybe I should do this only for  
> plugins used in build and report (javadoc and rat, IIRC).
>>>> 3. I strongly recommend setting up a release profile and using  
>>>> the release plugin.  I did this in geronimo and a couple other  
>>>> projects.  The latest is the activemq release profile
>>>> https://svn.apache.org/repos/asf/activemq/trunk/pom.xml
>>>> This profile does the build, including source and javadoc jars,  
>>>> signs everything, and uploads to a staging area typically on  
>>>> people.apache.org.  It requires some settings in your  
>>>> settings.xml file, see intstructions at http://cwiki.apache.org/GMOxPMGT/geronimo-release-process.html
>>> I used the resources you link many months ago when we made our  
>>> first maven based release! Without that resourcs I could have  
>>> never been success in accomplish the release process.
>>> All of this stuff should be in our parent pom:
>>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/james/james-parent/1.1/james-parent-1.1.pom
>>> We used automatic sign/deploy/stage process for our mime4j and  
>>> jspf releases and after few initial problems it worked very fine!  
>>> I think I configured jSieve the same way, so it should work.  
>>> Please let me know if I missed something!
>> I missed the contents of the parent pom.  In the next version of  
>> the parent pom you might want to consider using the apache pom as a  
>> parent as it includes a lot of the same info.
> We considered this at the time of our first maven release, but the  
> main apache pom had some bad content for us and introduced issues.
> But maybe newer apache parent poms are much better and we will  
> consider this when releasing the next parent pom :-)
> 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

View raw message