james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jsieve] Any more TODO before 0.2 release?
Date Fri, 20 Jun 2008 11:54:02 GMT
David Jencks ha scritto:
> <total snip>
> So I seem to have provoked much more discussion than I intended here.

David, don't take my words as too harsh: this is my way to understand 
things and communicate ;-)

I really appreciate your help and I will try to summarize what we 
discussed and to push "Legal Affairs" so that they confirm this summary 
and put something in the website, so in future a similar thread will 
stop with "the policy is writte at this url, if you don't agree at this 
url you find an explanation of who and how the policy is defined".

Similar threads keeps repeating, if we end up with this stuff published 
then this thread has not been a waste of time. It is an issue that the 
whole thread from january didn't generate a clear result (at least to my 

 > I
> don't know if its best practice, policy, or my misunderstanding but I 
> think the following are supposed to happen:


> 1. expected svn checkout points are supposed to include LICENSE and 
> NOTICE files at their root covering everything in the checkout, and 
> nothing else.  These should be kept up to date via "best-effort" by the 
> pmc and committers, and should definitely be accurate for svn tags.

I personally don't like to have to do that and I don't share the legal 
references made to justify the existence of this policy, but I agree 
that most people in the legal-discuss thread we referred previously 
agreed on this.
I opened this issue: https://issues.apache.org/jira/browse/LEGAL-26

> 2. released artifacts should include LICENSE and NOTICE files applying 
> exactly to their content.   If this goal is not achieved, its better to 
> have unnecessary stuff in the LICENSE/NOTICE files than missing stuff.


> For jsieve, I think these can be achieved simply by using the m-r-r-p 
> with no appended stuff for LICENSE and NOTICE for the java, source, and 
> javadoc jars, and using the svn LICENSE and NOTICE files for (1) in the 
> distro bundles.
> To me, this seems easy, as simple as possible, and correct.

To not have the NOTICE/LICENSE in svn and have it automatically created 
by maven would be simpler, but if legal affair will agree on the policy 
above I'll agree that this is the best option now.

> I've lost track of the ensuing discussion.  Points (1) and (2) are my 
> interpretation of what I thought was consensus reached on the 
> legal-discuss list around dec-2007-jan-2008 leading up to release of the 
> latest maven remote resource bundle for apache.  Getting it documented 
> clearly would have been a good idea at the time but I was tired.
> Discussions about whether (1) and (2) are accurate would probably be 
> best on legal-discuss.  I think Stefano wasn't sure if my proposed 
> strategy would work but I didn't understand why not.

I submitted the 2 JIRAs above :-)
Let's give a good ending to flames :-)

My issue was not your strategy but the need to have LICENSE/NOTICE in 
svn and the need to manually mantain a different LICENSE/NOTICE file for 
each package released (expecially a different LICENSE/NOTICE file for 
src zip and bin zip because they ship different contents).
Furthermore the strategy is not generally applicable because most m2 
projects do not have dependencies in svn so the LICENSE/NOTICE for the 
binary with runtime dependencies package will have to be created 
somewhere else or managed via a second m-r-r-p plugin in the build.

*IF* the above JIRA will be approved and added to the policy it would be 
probably good if maven (or some of our maven guides for ASF, like the 
activemq, geronimo, openjpa guides I found really useful in past) 
document a good way to achieve the result (2 m-r-r-p seems the only 
alternative to manually create multiple copies, but maybe smarter people 
have smarter solutions)

> I guess there might be some question about whether the java, source, and 
> javadoc jars are released independently, such as by deploying to the 
> maven central repo.  I hope you do release them in this way since not 
> doing so makes it really hard for other projects that use maven to use 
> interoperate with james.
> thanks
> david jencks

Yes, for our m2 based projects we use maven release plugin and we use 
the stage/deploy process described in the guides previously quoted. jars 
are automatically published to ASF m2 repository.

To make sure we don't leave anything back I also opened this:

Thank you,
hope you understand that beside my methods I was propositive :-)

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message