commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Commons Wiki] Trivial Update of "ReleaseShoppingList" by EmmanuelBourg
Date Fri, 25 Jul 2008 13:04:34 GMT
Dear Wiki user,

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

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

The comment on the change is:
Fixed some typo

------------------------------------------------------------------------------
  
  == Consistent Line Endings ==
  
- Having windoz line endings in the zip and *nix in the tar.gz would make many windoz users
happy. 
+ Having Windows line endings in the zip and *nix in the tar.gz would make many Windows 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.  
  
@@ -29, +29 @@

  '''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.  
+ 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 targeted
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.  
  
  Alternatively, in m1, maven.compile.executable can be set to force compilation on a specific
jdk. The jar plugin (or comparable m2 thingy) should be able to record the correct jdk version
in the manifest (m1 cannot do this currently).
  
@@ -59, +59 @@

  
  '''Status:''' releases can be put in the repository, possibly an apache plugin should symlink
these together.
  
- '''Response:''' an Apache plugin sounds like a very good idea (if you're suggesting what
I think you are) - would the Apache plugin handle the details of the Apache distibution layout
(all those symlinks and so on down into binary and source directories)? If so, would it be
possible to make this all a single operation?
+ '''Response:''' an Apache plugin sounds like a very good idea (if you're suggesting what
I think you are) - would the Apache plugin handle the details of the Apache distribution layout
(all those symlinks and so on down into binary and source directories)? If so, would it be
possible to make this all a single operation?
  
  '''Comment:''' If deployment is to be automatic, it needs to remove the old deployed version.
  
@@ -90, +90 @@

  
  It looks like implementation-vendor-id and specification-version seem to be the main problems
(http://jira.codehaus.org/browse/MPJAR-51). It's becoming increasingly important that we set
these attributes correctly since users are starting to want to use the extension mechanism.
  
- == Autmatically generated, complete release notes ==
+ == Automatically generated, complete release notes ==
  
  The maven 1 changelog report generates passable release notes, but needs to be customized
to be complete and still lacks svn integration.  We need a way to automatically generate full
release notes from changes.xml or a similar store, together with additional text describing
the release. 
  

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


Mime
View raw message