Improving manifest property parsing for eclipse plugins and such, where one malformed value in a list of values of a certain manifest property may lead to ParseException and not capture other correct parts of the specification

I was using apache ivy to parse a bunch of eclipse plugin distributions.
I found that for certain plugins e.g.
org.scala-ide.sdt.debug; version:3.0.0.v-2_10-201303191408-1e64c72,
org.scala-ide.sdt.core; version:3.0.0.v-2_10-201303191408-1e64c72,
org.scala-ide.sdt.core.tests; version:3.0.0.v-2_10-201303191408-1e64c72,
org.scala-ide.sdt.scalatest.source, version:2.9.3.v-3-2_10-201303201029-eab6d84
the meta-inf/manifest.mf files have certain properties specified, certain values of which are leading to ParseException from ivy/src/java/org/apache/ivy/osgi/core/ManifestHeaderValue.java

The problem is that the values being parsed are assumed to be of this format more of less by ivy:
say Bundle-Export: value1;something1=xx;something2=yy,value2;something1=xx;
something2=yy

however if there was a case like this: value1;something1=xx;something2=yy;value2;something1=xx;something2=yy

a ParseException is thrown that pretty much ignores the complete manifest.

taking an example:
The following is a manifest of an eclipse scala plugin:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: cheeseng
Build-Jdk: 1.6.0_27
Export-Package: scala.tools.eclipse.scalatest,scala.tools.eclipse.scal
atest.launching, scala.tools.eclipse.scalatest.ui
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: .,target/lib/scalatest-finders_2.9.0-0.9.4.jar
Bundle-Name: ScalaTest Plugin
Bundle-Localization: plugin
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Require-Bundle: org.eclipse.core.runtime,org.eclipse.debug.ui,org.ecli
pse.help,org.eclipse.jdt.core;bundle-version="[3.6.0,3.8.10)",org.ecl
ipse.jdt.debug.ui,org.eclipse.jdt.junit,org.eclipse.jdt.launching,org
.eclipse.jdt.ui,org.eclipse.jface.text,org.eclipse.ui,org.eclipse.ui.
console,org.eclipse.ui.editors,org.eclipse.ui.forms,org.eclipse.ui.id
e,org.scala-ide.scala.library;bundle-version="[2.10.1.v20130302-09201
8-VFINAL-33e32179fd,2.10.1.v20130302-092018-VFINAL-33e32179fd]",org.s
cala-ide.scala.compiler;bundle-version="[2.10.1.v20130302-092018-VFIN
AL-33e32179fd,2.10.1.v20130302-092018-VFINAL-33e32179fd]",org.scala-i
de.sdt.core;bundle-version="[3.0.0.v-2_10-201303191408-1e64c72,3.0.0.
v-2_10-201303191408-1e64c72]"
Bundle-Vendor: scala-ide.org
Bundle-Version: 2.9.3.v-3-2_10-201303201029-eab6d84
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.scala-ide.sdt.scalatest;singleton:=true
Import-Package: com.ibm.icu.text;apply-aspects:=false;org.eclipse.swt.
graphics;apply-aspects:=false,scala.tools.eclipse;apply-aspects:=fals
e,scala.tools.eclipse.contribution.weaving.jdt.ui.javaeditor.formatte
r;apply-aspects:=false

Notice the last property of Import-Package:

Import-Package: com.ibm.icu.text;apply-aspects:=false;org.eclipse.swt.
graphics;apply-aspects:=false,scala.tools.eclipse;apply-aspects:=fals
e,scala.tools.eclipse.contribution.weaving.jdt.ui.javaeditor.formatte
r;apply-aspects:=false

The problem is this: com.ibm.icu.text;apply-aspects:=false;org.eclipse.swt.
graphics;apply-aspects:=false,

There should have been a comma between instead of a semicolon here:
....apply-aspects:=false;org.eclipse.swt.....

So in this case a ParseException is generated, which is sure alright but then it causes the entire manifest parsing process to come to an end. The Eclipse's internal manifest parser however moves over and tries to recover the valid values, essentially ignoring the problem parts and this the plugin gets 'successfully install' by eclipse. On one hand this is an awesome analysis tool for malformed dependency specifications , on the other hand it is annoying as well in other cases.

It would be nice to have Better exception handling.

Also, the way ivy/src/java/org/apache/ivy/osgi/core/ManifestParser.java has been written, the process essentially breaks if a certain property is not found in the manifest, e.g. Require-Bundle or Export-Package.

I would suggest if these things be handled better, it would be a much more robust and much more useful tool. thanks.

BTW: I am looking at the code on truck on the apache/ivy mirror on github: mirrored from git://git.apache.org/ivy.git