I ran jarsigner -verify against the jars
first after normalize and sign, all the jars came back "jar verified"
then packed the jars ( pack200 )
Then installed ( and so unpacked )
on a number of these I get the error "jarsigner:
java.lang.SecurityException: SHA1 digest error for ..class"
Doe
Hi,
Well, I'm about to throw in the towel, regarding BSF; I think I'll move to
javax.scripting and see where that leads (which is a bit unwieldy, I know)...
I've tried bsfManager.setClassPath() -- that doesn't work;
I've tried bsfManager.setClassLoader() with just about every class loader out
I would suggest trying 3.4M7 where that bug was first fixed, or just move
up to 3.4.
Or if there are other problems upgrading, try at least taking
org.eclipse.update.core from 3.4
-Andrew
Janet Dmitrovich <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
10/09/2008 05:29 PM
Please respond to
Eq
Good question. I'm not sure we can specify a different build.properties
for our source build vs the real build. I imagine this is not supported.
It would be a pretty small corner case for us to solve IMO :-)
Tom
From:
sigh. is another option to include the build.properties in the source
and get PDE to use it?
I am more curious than expecting a change here. I agree that it is
unusual that the BREE content/ordering is causing an issue...
Jeff
Thomas Watson wrote:
We use those properties in the build.
We use those properties in the build.properties file in CVS to setup our
advanced classpath during the real build. And besides, the
build.properties from the CVS project is not the same as the one used by
PDE when you import as source. In this case PDE generates one for you
based on the contents
I believe there is a property we can put in the build.properties to
tell PDE which EE to use for compilation purposes. This seems like the
safer and more explicit path regardless of any issues Heiko may be
seeing.
Jeff
Thomas Watson wrote:
Hi Heiko,
The reason this was added was to avo
You can disable the autostarting of the deafult instance by setting the
framework property:
org.eclipse.equinox.http.jetty.autostart=false
-Simon
|>
| From: |
|>
>
Hi Heiko,
The reason this was added was to avoid compilation errors when importing
org.eclipse.osgi into your workspace as source from the target SDK. The
org.eclipse.osgi project supports the OSGi minimum 1.1 execution
environment but will make use of additional classes from J2SE 1.4 and 1.5
if
Hi All,
I want to use Jetty servlet container to host my servlets within OSGi,
however, the equinox.http.jetty bundle seems to start jetty by default on port
80, or the port specified by the org.osgi.service.http.port property in
config.ini. However I want to programmatically start the J
Hi,
After updating to 3.4.1 I had some issues with my test cases for
Equinox Aspects. The reason was, that the latest version of the system
bundle now defines Java 5 as the first execution environment:
Bundle-RequiredExecutionEnvironment: J2SE-1.5,OSGi/Minimum-1.1
Is this by intention? If y
11 matches
Mail list logo