You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2008/07/29 16:31:55 UTC
Re: svn commit: r680694 - in /commons/proper/cli/branches/cli-1.x: NOTICE.txt build.properties build.xml maven.xml pom.xml project.properties project.xml src/assembly/src.xml src/conf/MANIFEST.MF
Personally I think its a bad idea having all this MANIFEST stuff
hardcoded - since it just makes errors during release more likely. A
good example was BeanUtils 1.7.0 where the manifest version number
wasn't updated and has caused alot of confusion and quite a few bug
tickets.
Niall
On Tue, Jul 29, 2008 at 2:44 PM, <eb...@apache.org> wrote:
> Author: ebourg
> Date: Tue Jul 29 06:44:08 2008
> New Revision: 680694
>
> URL: http://svn.apache.org/viewvc?rev=680694&view=rev
> Log:
> Generated a new Ant build with Maven 2 + minor tweaks
> Removed the Maven 1 build
> Updated the manifest used by Ant to include the OSGI stuff
>
<snip>
> Modified: commons/proper/cli/branches/cli-1.x/src/conf/MANIFEST.MF
> URL: http://svn.apache.org/viewvc/commons/proper/cli/branches/cli-1.x/src/conf/MANIFEST.MF?rev=680694&r1=680693&r2=680694&view=diff
> ==============================================================================
> --- commons/proper/cli/branches/cli-1.x/src/conf/MANIFEST.MF (original)
> +++ commons/proper/cli/branches/cli-1.x/src/conf/MANIFEST.MF Tue Jul 29 06:44:08 2008
> @@ -1,4 +1,23 @@
> -Implementation-Title: Apache Commons CLI
> -Specification-Title: Apache Commons CLI
> -Specification-Vendor: Apache Software Foundation
> -Specification-Version: 1.1
> +Manifest-Version: 1.0
> +Implementation-Title: Commons CLI
> +Implementation-Vendor: The Apache Software Foundation
> +Implementation-Vendor-Id: org.apache
> +Implementation-Version: 1.2-SNAPSHOT
> +Specification-Title: Commons CLI
> +Specification-Vendor: The Apache Software Foundation
> +Specification-Version: 1.2-SNAPSHOT
> +X-Compile-Source-JDK: 1.3
> +X-Compile-Target-JDK: 1.3
> +Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
> +Import-Package: org.apache.commons.cli;version="1.2.0.SNAPSHOT"
> +Bnd-LastModified: 1217335218750
> +Export-Package: org.apache.commons.cli;version="1.2.0.SNAPSHOT"
> +Bundle-Version: 1.2.0.SNAPSHOT
> +Bundle-Name: Commons CLI
> +Bundle-Description: Commons CLI provides a simple API for presenting,
> + processing and validating a command line interface.
> +Bundle-DocURL: http://commons.apache.org/cli/
> +Bundle-ManifestVersion: 2
> +Bundle-Vendor: The Apache Software Foundation
> +Bundle-SymbolicName: org.apache.commons.cli
> +Tool: Bnd-0.0.238
</snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r680694 - in /commons/proper/cli/branches/cli-1.x:
NOTICE.txt build.properties build.xml maven.xml pom.xml project.properties
project.xml src/assembly/src.xml src/conf/MANIFEST.MF
Posted by Emmanuel Bourg <eb...@apache.org>.
Niall Pemberton a écrit :
> Better IMO to produce the release using
> JDK1.5 and Maven2 and just provide an ant build to be able to test the
> RC using JDK 1.3. As long as m2 has JDK 1.3 source/target options set,
> then it will be JDK 1.3 compatible and as long as we test the RC using
> Ant JDK1.3 then it ensures no JDK 1.4+ APIs have crept into the code
> base.
I guess someone will object that it doesn't ensure that the jar
generated by Maven actually works with a Java 1.3 environment. However I
don't think this is really a concern for CLI, because it's used mainly
for command line applications and not web applications, and these
applications are less likely to require an older JRE.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r680694 - in /commons/proper/cli/branches/cli-1.x: NOTICE.txt build.properties build.xml maven.xml pom.xml project.properties project.xml src/assembly/src.xml src/conf/MANIFEST.MF
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Jul 29, 2008 at 3:38 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Niall Pemberton a écrit :
>>
>> Personally I think its a bad idea having all this MANIFEST stuff
>> hardcoded - since it just makes errors during release more likely. A
>> good example was BeanUtils 1.7.0 where the manifest version number
>> wasn't updated and has caused alot of confusion and quite a few bug
>> tickets.
>
> I would prefer to remove the Ant build and use exclusively Maven 2 but
> that's the same old issue with Java 1.3. My idea was to build the jar with
> Ant+Java 1.3 and replace it in the binary distribution generated by Maven.
> That's why I updated the manifest to match the details of the one generated
> by Maven.
This seems too painful then IMO, because you have to manually hack too
many things to create the release - updating the version number in at
least six places, replacing the jar in the binary distro, redoing the
sigs/checksums. Building the RC should be as staright forward (and
reproducable) as possible. Better IMO to produce the release using
JDK1.5 and Maven2 and just provide an ant build to be able to test the
RC using JDK 1.3. As long as m2 has JDK 1.3 source/target options set,
then it will be JDK 1.3 compatible and as long as we test the RC using
Ant JDK1.3 then it ensures no JDK 1.4+ APIs have crept into the code
base.
Niall
> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r680694 - in /commons/proper/cli/branches/cli-1.x:
NOTICE.txt build.properties build.xml maven.xml pom.xml project.properties
project.xml src/assembly/src.xml src/conf/MANIFEST.MF
Posted by Emmanuel Bourg <eb...@apache.org>.
Niall Pemberton a écrit :
> Personally I think its a bad idea having all this MANIFEST stuff
> hardcoded - since it just makes errors during release more likely. A
> good example was BeanUtils 1.7.0 where the manifest version number
> wasn't updated and has caused alot of confusion and quite a few bug
> tickets.
I would prefer to remove the Ant build and use exclusively Maven 2 but
that's the same old issue with Java 1.3. My idea was to build the jar
with Ant+Java 1.3 and replace it in the binary distribution generated by
Maven. That's why I updated the manifest to match the details of the one
generated by Maven.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org