[equinox-dev] [security] Merged org.eclipse.osgi v20070914 tag from HEAD into security incubator

2007-09-14 Thread Thomas Watson


I merged the org.eclipse.osgi v20070914 tag from the Equinox 3.4 (HEAD)
stream into the security incubator.

There were some fixes from the HEAD stream which are important to the
security work.  In particular
https://bugs.eclipse.org/bugs/show_bug.cgi?id=202282 is needed to be able
to provide JCA security provider implementations contributed from bundles.
Matt, Eric and others on the security incubator team, please let me know if
you find any issues with the merge.

I created the following tags and branches in the security incubator

equinox-proper-dev branch - intended to contain the unmodified code from
equinox proper stream (3.4 HEAD)
v20070914 - tag on the equinox-proper-dev branch used after initial check
of the v20070914 code
v20070914-premerge - tag used before merging in the changes from the
equinox-proper-dev branch to the security HEAD stream
v20070914-postmerge - tag used after merging in the changes from the
equinox-proper-dev branch to the security HEAD stream


Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


[equinox-dev] Equinox projects tagged for 3.4 I-build

2007-09-14 Thread Thomas Watson

In preparation for M2 build on Monday I have tagged the equinox projects
early.  If additional fixes are releases please make sure they are tagged
appropriately for the M2 warm-up build.

The map file has been updated for the following Bug changes:
+ Bug 96034. Need an API to determine if another location is locked (FIXED)
+ Bug 188089. [osgi] can't launch an osgi bundle if the path of its plugin
project contains the caracter "@" (FIXED)
+ Bug 201425. [osgi R4.1] Fragments should be able to export duplicate
packages (FIXED)
+ Bug 202282. Support a proposed extension:="ext" (FIXED)
+ Bug 203135. buddy classloading fails if the boot classpath contains the
same class as a buddy (FIXED)

The following projects have changed:
org.eclipse.osgi.tests
org.eclipse.osgi
org.eclipse.equinox.supplement

Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Re: AW: [equinox-dev] Equinox->Bundles component is getting crowded

2007-09-14 Thread Peter Kriens
I agree that tagging is a better solution than (always arbitrary)
hierarchies. Over time, I have learned that any hierarchy is always
wrong for some people. Flickr shows how people can create their own
groups by including a set of tags and I think it is highly successful.
Or look at SQL, invented to solve the problem of hierarchical (or
networked) databases that always turned out to have the wrong
hierarchy for any new application.

You can always create "groups" by searching for tags or create tracks
like they use on EclipseCon to create mini-programs.

In the OSGi, we have the Bundle-Category header that has a set of
defined values. We gladly adjust this list.

http://www2.osgi.org/Specifications/Reference

Kind regards,

 Peter Kriensa


AvD> I was primarily thinking about web pages for downloading and searching
AvD> bundles. A download page which would show all server side bundles would
AvD> have some items that are also on the standard bundles page. It doesn't
AvD> solve the problem of what each downloadable item should comprise and it
AvD> doesn't help with tools like bugzilla or how to address things on the
AvD> mailing lists. Personally I would tend to make the items small when
AvD> tagging is available, e.g. a download per bundle. I'd do the same on the
AvD> bugzilla side with rather fine grained partitioning.

AvD> The download pages could even offer you to choose several
AvD> tags/categories to include in your download and then pack you an
AvD> individual downloadable bundles archive without duplicates and all the
AvD> items you wanted. (Ah, the lovely smell of over-engineering in the early
AvD> morning :) ).

AvD> Arthur

AvD> Jeff McAffer wrote:
>> 
>> can you say more about the mechanism for "tagging"?  The sorts of 
>> media/item in question are downloads, bundles in the repo, wiki/web 
>> information, posts on the mail list or newsgroup, bugs, ...  Not all 
>> need the same level of rigor perhaps.
>> 
>> Jeff
>> 
>> 
>> 
>> *"Arthur van Dorp" <[EMAIL PROTECTED]>*
>> Sent by: [EMAIL PROTECTED]
>> 
>> 09/14/2007 01:20 AM
>> Please respond to
>> Equinox development mailing list 
>> 
>> 
>>   
>> To
>>   "Equinox development mailing list" 
>> cc
>>   
>> Subject
>>   AW: [equinox-dev] Equinox->Bundles component is getting crowded
>> 
>> 
>>   
>> 
>> 
>> 
>> 
>> 
>> 
>>  > The challenge is that all
>>  > partitionings will have problems as different people have different
>>  > views on the world.  would the http service be part of "standard
>>  > services" or "server side"?
>> 
>> As an outsider I'd say use tags. HttpService would be tagged
AvD> "standard"
>> as well as "server side". That would naturally involve some work on
AvD> both
>> front and back end and not in itself guarantee that people would
AvD> easily
>> find what they are looking for.
>> 
>> Arthur
>> 
>> Jeff McAffer wrote:
>>  >
>>  > to me it is neither of these options.  It is about community and
>> clarity
>>  > for our consumers.  Walking up to Equinox you just have a sea of
>>  > bundles.  Add in the p2 and security stuff and the sea turns into
AvD> an
>>  > ocean.  Say you hear that Equinox has implementations of some OSGi
>>  > service specs.  If you go to the download page today you have to
>> grovel
>>  > through spec impls, launchers, random other stuff and cannot tell
AvD> one
>>  > from the other.  Since there is no particular web/wiki page for
AvD> people
>> 
>>  > interested in spec implementations, it is hard to build a community
>>  > around that topic.   People interested in contributing to standard
>> spec
>>  > impls cannot easily find related bugs etc.  There is also no clear
>> lead
>>  > of that community who is plotting the course/planning, coordinating
>>  > execution, building the community, ...  You can replace OSGi
AvD> service
>>  > spec with p2, security, ...  
>>  >
>>  > A number of these issues can be addressed simply by structuring the
>>  > download site or wiki or...  If you address most of them then in
>> effect
>>  > you have just created a component without actually creating a
>> component.
>>  >  So what are we afraid of?  Why not reify the structure we think we
>> have?
>>  >
>>  > That begs the question, what is the structure? The challenge is
AvD> that
>> all
>>  > partitionings will have problems as different people have different
>>  > views on the world.  would the http service be part of "standard
>>  > services" or "server side"?  However the existance of issues need
AvD> not
>>  > stop progress or movement.  So this discussion is really about
>> defining
>>  > that structure.  At least thats my view...
>>  >
>>  > Jeff
>>  >
>>  >
>>  >
>>  > *BJ Hargrave <[EMAIL PROTECTED]>*
>>  > Sent by: [EMAIL PROTECTED]
>>  >
>>  > 09/12/2007 05:13 PM
>>  > Please respond to
>>  > Equinox development mailing list 
>>  >
>>  >
>>  >  
>>  > To
>>  >  Equinox development mailing list 
>> 
>>  > cc
>>  >  
>>  > Subje