[Jakarta-commons Wiki] Update of "ReleaseShoppingList" by BrettPorter

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by BrettPorter:
http://wiki.apache.org/jakarta-commons/ReleaseShoppingList

------------------------------------------------------------------------------
  
  Both LICENSE and NOTICE files need to be included: by default maven only includes the LICENSE
  
+ '''Status:''' Easy with the assembly plugin, may need to be configured for the JARs.
+ 
+ A: (Maven2: http://maven.apache.org/plugins/maven-assembly-plugin/descriptor.html - a description of what the maven2 standard distributions look like)
+ 
  == Consistent Line Endings ==
  
  Having windoz line endings in the zip and *nix in the tar.gz would make many windoz users happy. 
+ 
+ '''Status:''' Maven 2's assembly plugin lets you group filesets with a particular line ending and file mode, but these are not treated differently between zip and tar.gz without recreating the descriptor. I prefer this operation - making the main text files and batch files CRLF, shell scripts LF, and everything else untouched. Modern editors on both systems work with either, so all we need is for notepad to be able to read the .txt files, really.
  
  == Accurate Building Against 1.3 ==
  
  It's very important commons to be able to build against Java 1.3 even now maven requires 1.4. Good 1.3 builds using 1.4 is tricky. Difficult to solve this one.
  
- A: (BrettPorter looking into this)
+ '''Status:''' Maven 2 can currently allow forking of the compiler, tests, etc under installed JDKs in the same way as m1. Maven 2.1 intends to allow the application of a toolchain consistently by specifying a JDK installation location. We should look at having build servers with the necessary software rather than the user having to worry about it.
  
  (More Info) 
  It feels like the 'maven way' would be to specify the target JVM in the POM. Of course, it's not that easy. One of the wrinkles is that it may be that the way I've always done targetted releases (using a JVM of the current vintage) is not actually the right way. The problem is that older compilers may have bugs which have been addressed in later releases. So, AFAIK the best advice is to use -bootclasspath set and then use a modern JVM with the correct flags set.  
@@ -27, +33 @@

  
  Modern IDEs can associate javadoc and source jars with the binaries. We haven't distributed these in the past but doing so would make many folks very happy.
  
+ '''Status:''' Maven 2 has this capability by default when using the release plugin.
- A: (Maven2: http://maven.apache.org/plugins/maven-assembly-plugin/descriptor.html - a description of what the maven2 standard distributions look like)
- 
  
  == Expanding Source And Binary Distributions ==
  
  Source and binary distributions should expand to different directories.
  
+ == Signing Artifacts ==
+ 
+ ASCII armored detached signatures are required for all Apache distributed artifacts.
+ 
+ == Release Candidates ==
+ 
+ Need a way to produce the final release and test it before deploying it. Commons has a particular problem with doing numerous release candidates.
+ 
+ '''Status:''' I think it might be better to prepare untagged snapshots until folks are mostly happy, then produce an official RC for further testing that is finally just renamed to the final release.
+ 
+ == Easy Deployment of final Release to /dist/ as well as artifacts to the maven-repository ==
+ 
+ Deployment should be a one step process to release both.
+ 
+ '''Status:''' releases can be put in the repository, possibly an apache plugin should symlink these together.
+ 

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