The map file has been updated for the following Bug changes:
+ Bug 204209. [prov] Generated repo directory names don't match what
colocated repo UI assumes (FIXED)
+ Bug 216911. [prov] Should IU's have multiple licenses (NEW)
+ Bug 217001. [prov] [ui] [metadata] can IU license and copyright
prope
I also agree with option #1, but would like to make sure that plugins
have extension points to specifically be able to hook into an existing
login process (e.g. add principals/credentials to a Subject before the
relevant collections are made read-only...i.e. prior to
loginmodule.commit()) as pe
I've committed fixes to HEAD for these bugs:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=224180
https://bugs.eclipse.org/bugs/show_bug.cgi?id=224107
I did not tag/release, as John said he or Pascal will be doing it closer to
build time.
As of this moment, I believe I'm done with UI changes fo
I just updated to the latest stable Orbit build and I moved the sat4j
bundles to the orbit.map from the p2.map. I just makes things easier
since I have script to update to the latest S-build from Orbit.
Kim___
equinox-dev mailing list
equinox-dev@ecli
The map file has been updated for the following Bug changes:
+ Bug 223380. [sec] Login event API needs change (ASSIGNED)
+ Bug 223945. [sec] Should AuthorizationEngine/AuthorizationManager be
internal.provisional ? (FIXED)
The following projects have changed:
org.eclipse.equinox.security.ui
org.e
The public APIs for login in the org.eclipse.equinox.security bundle are
going through one final change for 3.4 in tonight's build. Specifically,
we are condensing the login event mechanism into the parent package, and
renaming the login related objects to be more consistent with JAAS.
Specific
If I have to choose then I prefer option #1
- This seems to give us the most flexibility for evolving our APIs.
- This is the current way it is implemented. Changing this now will put
M6 at risk and would result in us pulling the API and making it
internal.provisional.
- Worse case scenario i
We've decided to make a couple of our APIs for working with signed content
internal.provisional. Specifically, AuthorizationEngine and related classes
in org.eclipse.osgi as well as AuthorizationManager in
org.eclipse.equinox.security.ui. The APIs for examining signed content will
continue to b
+1
+1
Voting summary: http://portal.eclipse.org/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
