>> 3) work on the API as much as possible to gain confidence that it is API we
>> can live with and support in future releases.
>>
>> 3) seems rather risky at this point in time. Is 2) an acceptable approach?
>>
>> Tom
>>
>>
>>
>>
On 2011-04-20, at 11:32 AM, Pascal Rapicault wrote:
> There is only one discussion point. Do we want a new class versus a setter?
> Rather than focusing on the process, please review the API.
>
> On 2011-04-20, at 11:30 AM, Jeff McAffer wrote:
>
>> We seem to still be discussi
s been ready since before eclipsecon. Dave and others reviewed it
> and it is good.
> What do you propose instead? We wait 3.7.1?
>
> On 2011-04-20, at 10:29 AM, Jeff McAffer wrote:
>
>>
>>> If there is no objection I will release that during the week so we can
&g
there is no objection I will release that during the week so we can
> actually work on the code together.
>
>
> On 2011-04-19, at 9:27 AM, Jeff McAffer wrote:
>
>> Darn. you are talking about
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=337016?
>>
>&g
Darn. you are talking about
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337016?
That's new API right? I took a look but am not sure what the final form is
that you are thinking of. Susan had some comments and David as well. The
original patch from you had a method getAgent() which see
Can the relevant people update the incubator pages to reflect reality? See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340648
Jeff
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Jeff McAffer voted:
+1
+1
Voting summary: http://portal.eclipse.org/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Jeff McAffer voted:
+1
+1
Voting summary: http://portal.eclipse.org/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Jeff McAffer voted:
+1
+1
Voting summary: http://portal.eclipse.org/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
rt.equinox.incubator Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Brian de Alwis. Brian de Alwis is
a new full Committer on the rt.equinox.incubator project.
Welcome!
___
Fogell
? Ted Habeck
? Thomas Hallgren
? BJ Hargrave
+1 DJ Houghton
? Simon Kaegi
+1 Lazar Kirchev
? Peter Kriens
? David Lavin
+1 Daniel Le Berre
? Scott Lewis
? Eric Li
? Stefan Liebig
+1 Martin Lippert
+1 Jeff McAffer
? Susan McCourt
rt.equinox.incubator Committers,
This automatically generated message signals that Jeff McAffer has
nominated Brian de Alwis as a Committer on the rt.equinox.incubator
project. The reason given is as follows:
I am pleased to nominate Brian de Alwis to work in the Equinox incubator.
Specifically
After some discussion, we have decided to create a work area in the equinox
incubator to work on improving the p2 support for publishing features and
products. We are doing this work in the incubator to better facilitate others
participating.
The goal here is to unify the p2 and PDE (and other
hould be done in order to include them in orbit? File another CQ to request
> this?
>
> Lazar
>
> From: equinox-dev-boun...@eclipse.org
> [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Jeff McAffer
> Sent: Thursday, December 02, 2010 4:11 PM
> To: Equinox developm
> 1,2: I do not think that users will prefer the built-in console if Gogo is
> available, as long as the Equinox commands are available through Gogo.
I tend to agree especially because Gogo is likely better from a user
perspective.
> 5: in the implementation in the patch proposed in
> https://
use the -console option. When they
> eventually start Equinox, configured with Gogo, with the –console option,
> they will have a framework with two shells, fighting with each other for
> resources. This may be a problem.
>
> Lazar
>
> From: equinox-dev-boun...@eclipse.org
> [ma
t the console
> out and test it properly. I am reluctant to do any of that work when we want
> to eventually replace the console implementation with the gogo shell and a
> bundle that bridges the old equinox command implementations to the new shell.
>
> Tom
>
>
>
> Jeff McA
The disadvantage is usability. Right now you get equinox and run with -console
and its all good. If we break it out you'll have to get two bundles and make
sure that the console bundle is started...
We have thought about shipping two setups, one with the console and one
without. That might w
> I'm not sure how to deal with the gogo jars in orbit. The jars are real
> bundles and we will not have to repackage them or anything like that. Jeff
> what do you recommend?
>
Orbit is about maintaining bundles for third party code that eclipse projects
use. We already have cases where the co
Hey Robert,
I think we need some more information here. You should not have to mess with
the system packages settings etc. I've been using javax and org.xml etc for
years and have never had to do this. What Alex says may be required in cases
where you are going for internal/private JRE clas
In an effort to create some starter kits for Equinox and p2 I created some
"core" features to capture the essential elements of equinox and p2 in various
headless scenarios. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=314486
Of course no feature will cover all use cases but these s
Last night I converted over a mess of the Equinox website to the new format. I
tried to get all the "popular" pages. Please do the following:
- Look at the site and see if there are any things missing or messed up.
- Check that the pages of interest to your work have been converted. If they
In response to the discussion in today's call, and with the help of DJ, I
updated the prototype website and download samples as follows
- The website now has a RSS feed view in the right column showing the 5 most
recent posts found on Planet Eclipse that have the word "equinox" in them
somewher
I've been playing a little in my "spare" time with the Equinox and RT web
sites. The prototype web pages are here
http://eclipse.org/equinox/testweb/
http://eclipse.org/equinox/testweb/resources.php
http://eclipse.org/equinox/testweb/download.php
http://eclipse.org
it out, and I
> suspect the same with Susan.
>
>
>
> Jeff McAffer
> Sent by: equinox-dev-boun...@eclipse.org
> 09/20/2010 10:48 AM
> Please respond to
> Equinox development mailing list
>
> To
> Equinox development mailing list
> cc
> P2 deve
Thanks for setting up the poll Pascal. A few things to note
- The poll closes tomorrow so vote now
- Please be careful about the timezones. I'm not really sure how this works
but it seems like Susan is ok with 0600PT calls. Perhaps she is but it would
be worth confirming your votes and the ti
Jeff McAffer voted:
+1
Great
Voting summary: http://portal.eclipse.org/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
-04-11, at 2:51 PM, Jeff McAffer wrote:
I don't recall a API change proposal or approval for this. The bug
cited does have the API keyword but no approvals AFAICT. Was that
done somewhere else?
Jeff
On 2010-04-09, at 8:52 PM, Pascal Rapicault wrote:
In order to address bug 3
I don't recall a API change proposal or approval for this. The bug cited does
have the API keyword but no approvals AFAICT. Was that done somewhere else?
Jeff
On 2010-04-09, at 8:52 PM, Pascal Rapicault wrote:
> In order to address bug 303990 - metarequirement seems broken, I have had to
>
res and start levels, I thought this could be accomplished via p2
> with CUs.
>
> (Sent from my Droid)
>
> -Original Message-
> From: Jeff McAffer [j...@eclipsesource.com]
> Received: 4/3/10 3:49 PM
> To: Equinox development mailing list [equinox-...@eclipse.org]
nothing about eggs. We need some kind of knowledge that lives outside of the
> ingredients -- i.e., a recipe -- in order to make pancakes.
>
> Rgds,
> Neil
>
> On Fri, Apr 2, 2010 at 9:57 PM, Jeff McAffer wrote:
> Good point Jason. I would generalize it even more and say th
anifest so even if we specified these today I don't think it would
> really help in ensuring a DS runtime is provisioned by p2. Perhaps we should
> consider adding that to p2?
>
> Also note that the OSGi alliance is currently looking at providing a standard
> way for declaring gen
ng a standard
> way for declaring generic capabilities and requirements for a future core
> specification. We should keep an eye on this space and feed any additional
> requirements we may have to OSGi in this area.
>
> Tom
>
>
>
> Jeff McAffer ---04/01/2010
It should be up to the system integrator. Actually, there should be metadata
(in p2) that expresses the need for various services to be present to make the
integrator's job easier but ultimately inclusion/activation/... are in the eye
of the beholder. So we should not cod classpath (bundle or pa
I also agree that existing impls should be considered. My hope is that
the end result is at least as powerful as the current state of the
art. If using existing stuff or working with those teams is the way to
go then +1. Having said that, if this team is keen on creating and
maintaining a
Krassi,
This is great. I've been wanting the console out of the framework for some
time. See Bug 169603.
Having a better, more functional console that has a better command UI structure
would be a real bonus to many users.
As you observe, maintaining compatibility with the old way is essenti
Great points Tom. We discussed this again in the Equinox team call this
morning.
The need to talk openly about API changes is two-fold:
1) The community needs to be aware of what is coming or proposed. We need
their feedback and input. Perhaps they are depending heavily on something that
is a
Perhaps some information on why you are doing this would help. It
seems that you are infering some semantics from things that just
*happen* to be a certain way. This may change in the future so
understanding what you are actually looking for would help.
Jeff
On 18-Sep-09, at 5:53 AM, Fi
This is required for the compiler. At compile time you need to see
the complete supertype hierarchy of the type being compiled. At
runtime this is not required. Basically this is caused by the JDT
compiler using a flattened classpath rather than a delegating
structure that matches the OS
FYI, there is a security related thread starting on eclipse-pmc
Begin forwarded message:
Eclipse PMC,
My name is Arshan and I'd like Eclipse to enable developers to write
more secure code. I'm working with the OWASP foundation and have
elicited funds to accomplish the introduction of secur
BTW, it turns out that you have to have simple.configurator there AND
marked as started for the configuration you are creating to be
considered "p2 enabled" and the bundles.info file to be written. The
bundles.info file may be written in other cases (I seem to have seen
that).
Jeff
Chris
Not sure if you did already but a bug report here would be useful.
Anything that makes stuff easier to use is a good thing.
Jeff
Alin Dreghiciu wrote:
Thanx Stuart.
That resolved the import problem so now DS is up and running (using
the supplement bundle).
In this case, as debug stuff is
As discussed in the call today, I created features for the various SDK
slicings of the Equinox world. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270694
and comment there.
Jeff
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.
+1
Thomas Watson wrote:
Hello fellow Equinox team. In the past Equinox was under the
Eclipse PMC and we needed to get PMC approval for post M6 API changes.
Now that we are under RT Jeff and I decided that it would be best to
keep the Equinox API change approvals localized to the Equinox dev
note as well that there are some DS console commands like "ls" and
"component" that are quite usefule.
Jeff
Neil Bartlett wrote:
Okay this looks fine, both the equinox.ds and equinox.util bundles are
present and active.
Which bundles contain the two DS components you're expecting to
Thanks for bringing this up. The information should be broadcast quite
widely. I'm sure there are folks consuming Equinox that will be
affected.
Should likely also be in release notes etc.
Jeff
Thomas Watson wrote:
The failure in org.eclipse.core.tests.runtime
(org.eclipse.core.tests.inte
In working through some contributions in the Component area it was noted
that there is no decent home for Components tests. The current
components constituents either have no apparent tests or have them in
the core.runtime test area in the Eclipse project. Given that Equinox is
a full-fledged
I agree that C is the way to go for all th reasons Tom mentioned plus:
The incubator is a distinct "subproject" with distinct commit rights
etc. spreading out the content will be confusing and just asking for
things to "graduate by accident"
The incubator area should be structured according
I belive there is an incubator build. You should be able to define some
features, add them to that build and have the aspects stuff built all
the time and put up on the Equinox build site and repo.
Jeff
Martin Lippert wrote:
Hi Andrew,
we don't have one yet, but I will try to figure out wha
+1
The more John can commit to, the better off we are...
Voting summary: http://portal.eclipse.org/
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
directories for us.
Tom
Jeff McAffer
---10/16/2008 09:28:41 AM---Given that these tests were never included
in the build in their old location, should we just delete the now empty
projects fro
From:
Jeff McAffer <[EMAIL PROTEC
Given that these tests were never included in the build in their old
location, should we just delete the now empty projects from the repo to
eliminate confusion and clutter?
Jeff
DJ Houghton wrote:
They were moved to be included inside the regular p2 test suites a
couple of weeks ago.
Ah, Assuming we are not using any Java5 language features we need to
set the source and target options to Java 1.3 equivalents.
Jeff
Heiko Seeberger wrote:
Tom,
My issues were based on the VM that was defined for the run
configuration for my test cases. This was not a Java 5 VM and
reason
J2SE-1.5 is listed first, so that PDE will use J2SE-1.5.
Tom
Jeff McAffer
---10/10/2008 09:22:21 AM---I believe there is a property we can put in
the build.properties to tell PDE which EE to use for compilation
purposes. This se
From
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
Oleg Besedin wrote:
=> Single context object <=
> I don't like that clients cannot provide more
than just one single
> "context" object.
Good point. I did this for simplicity as having
only
one argument eliminates the need to match constructor arguments. If we
were to suppo
With the recent move and reorg of the Equinox bugzilla buckets, you
might want to check that your bugzilla account is setup to listen to all
the new components. Below is the complete list of inbox users you can
watch using the Bugzilla > Preferences > email settings.
[EMAIL PROTECTED]
[EMAIL
The registry itself is already a service. In the past I have written
an executable extension factory that did service lookup to supply the
desired extension object. so the base pieces should be there but it
would be great to make the integration much smoother.
Jeff
Heiko Seeberger wrote:
The plan is looking pretty good. Below are a few comments. In some
places I did some changes (I marked these in the comments below). These
should have your review. Please add or tweak as needed in the next few
days so we can meet the Tuesday deadline
Jeff
General
- the bugs referred to fr
Great. Thanks Kim.
Are there any issues with the fall maintenance release and update site
URLs? For example, if there is an "old" URL in circulation then do we
need to put the fall release content on the old site?
Jeff
On Sep 11, 2008, at 5:35 PM, Kim Moir <[EMAIL PROTECTED]> wrote:
Eq
In my view these are the
only packages that are worth versioning at the package level. I
certainly
think the *goal* should be moving towards this world of
specification-level
dependencies (and thus use of import-package), but that's not where we
are today.
John
ellow and CTO of the OSGi
Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Jeff McAffer
<[EMAIL PROTECTED]>
To:
this API use case would only be a special
case of a general problem of using "old" implementations.
Perhaps I'm missing the point?
From:
Jeff McAffer
<[EMAIL PROTECTED]>
To:
ransparently. In my view these are the only packages that are worth
versioning at the package level. I certainly think the *goal* should be
moving towards this world of specification-level dependencies (and thus
use of import-package), but that's not where we are today.
John
From:
Jeff McAffer
<[EMAIL PROTECTED]>
To:
Equinox development
mailing list
Date:
2008/09/03 06:16 AM
Subject:
Re: [equinox-dev]
.qu
You might want to get the real Jetty stuff rather than checking it out
using the psf. The psf may be out of date. Try using all released code.
Jeff
Ian Bull wrote:
Ricardo,
I have this working with GWT 1.5 and Eclipse 3.4, so we know it's
possible :-).
Have you tried adding javax.servlet
FYI - plans for package version support in API tooling have been reduced.
Currently, there is nothing on the draft plan due to resources available
to do the work, and the fact that SDK plug-in developers generally use
components at the plug-in granularity vs. package granularity. I'm not
sure
s a developer maintain the version of a split package
across
all the bundles the package is split?
Tom
"Chris
Aniszczyk" ---08/31/2008 02:46:34 PM---On Sun, Aug 31, 2008 at 5:53
AM, Jeff McAffer < [EMAIL PROTECTED]
F
Interesting problem Otto. Normally the response would be "your app
should just observe the services coming and going and react
accordingly". However, in your case the interesting twist is that the
app appears to be short lived. So as you say, while DS is poking
around doing stuff, your app i
Could you summarize the information in the quoted posts and put them on
the wiki? Perhaps the outdated material should also be removed? or
archived?
Oleg Besedin wrote:
Hi Ricardo,
That page is quite outdated and
probably
is not a good starting point. See:
http://dev.eclipse.
As version numbers on packages become more prevalent does it start
making sense to use .qualifier on them in addition to bundle version
numbers? The logic here is the same as for bundles. we rev the version
number of the bundle to match the most extreme change for that release.
in between if
This should be asked on the the newsgroups.
Summary is that you should use the eclipse executable. it is available
for many many platforms. The PDE tooling contains comprehensive
tooling. Even if you are just using Equinox, get the RCP book and
pretend you are making and RCP app without the
As I mentioned earlier, the Equinox move to RT is in progress. Today
the ever helpful webmaster team moved the bug bucket to its new home
under RT . It seems that many of the queries continue to work as they
are based on "product" (in bugzilla terms) so hopefully you will not
experience much
The process of moving Equinox to its new home under RT has begun. Much
of the Eclipse Foundation database information has been moved and over
the course of this week the bugs, CVS repo and downloads sites will move
as well. Tom and I will continue to keep you informed of the progress
and any
Overall looks good. Some questions.
- is this info captured somewhere on the wiki?
- when you say that content will be purged do you mean that the repo
will be deleted of that some off the older ius will be deleted? In the
past we trashed the whole repo and added the next build. This left the
Would be good to summarize the transformation/copy information in a new
list somewhere. We will have to give this to the webmaster to execute
the copy operation anyway and there seem to have been some tweaks since
the original proposal.
Jeff
Thomas Watson wrote:
There will still be a bund
yes, Equinox is moving and all future releases should come from the
"new" repo in RT-land.
Jeff
Thomas Watson wrote:
Yes we will retain history. We do not plan to physically remove
the old tags and branches from the /cvsroot/eclipse repo so the old map
files should continue to be able to
Given the recent difficulty we had with creating meeting invites that
people could use I took Chris' suggestion and created an Equinox Google
calendar. Use the following link and add it to your iCal-enabled
calendaring software.
http://www.google.com/calendar/ical/08i9q5g17o9il95b4pbc5n4f4g
d be interested?
Cheers,
Olaf
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Jeff McAffer
Gesendet: Freitag, 4. Juli 2008 15:09
An: Equinox development mailing list
Betreff: Re: [equinox-dev] Possible to obtain org.eclipse.osgi.jar
withoutOSGi framework classes?
Hey Olaf
Did you try copying out the OSGi types and putting them on the JCA
classloader? If the FirstChild is actually a child of the JCA loader
then it should get the OSGi types from JCA and ignore the ones in the
osgi.jar. Of course, if you are trying to isolate Equinox from the JCA
classe
Hey Olaf,
The short answer is, No, such a distribution is not readily available.
The question in my mind is why do you need this? If you remove the OSGi
classes where will they come from? If you happen to be running on an
OSGi-based JEE app server then you could in theory get the classes fro
:-)
What do you think?
-Martin
Jeff McAffer wrote:
Possible solutions:
- graduate
- lower the version numbers
In either case there will need to be a review if there is going to
be a "release". You could avoid a review if the version number is
lowered AND the event is rephrased
Craig,
Thanks for taking the time to report this. Can I ask you to enter a
bug report at
https://bugs.eclipse.org/bugs/
That helps us track and address these issues.
Jeff
Craig Phillips wrote:
Hi,
If someone wants to take a deeper
look... Stack trace at bottom of this post
builds.
3. start the graduation process for a future first release of equinox
aspects including reviews, a release review and whatever is necessary
to graduate... :-)
What do you think?
-Martin
Jeff McAffer wrote:
Possible solutions:
- graduate
- lower the version numbers
In either case
Just to add a bit to this. The actual structure of the p2 code is far
from optimal. We made a number of trade-offs in the interest of
getting things done rather than proper component programming style.
Expect these to be revisited soon.
Jeff
Pascal Rapicault wrote:
Hi Fredrik
Extensio
forcing is that a project in
incubation must have releases < 1.0 and that projects out of
incubation have releases >= 1.0. I apologize that this is not clearly
written.
Jeff McAffer wrote:
In any event, Bjorn (cc'd) would certainly know i
a hint where I could ask whether 1.* might be an issue in
incubation?
Am 14.06.2008 um 02:58 schrieb Jeff McAffer:
On a side note, I'm not 100% but there may be an issue with calling
the Aspects stuff 1.* when it is incubation.
___
inox Aspects to work with 3.4.
Nevertheless it might be nice for marketing reasons to publish a new
release shortly after 3.4.
What do you think?
Best regards,
-Martin
Do you have a hint where I could ask whether 1.* might be an issue in
incubation?
Heiko
Am 14.06.2008 um 02:58 schri
Heiko,
This is great. Thanks. some suggestions
- It would be great to have the quick start and demo somewhere in a
permanent location on the main page. These items will not be "new"
forever and the what's new section is not where people would look to get
started. Perhaps a whole "Getting S
sistency is of course good and it would make sense to
update them all to be consistent in 3.5 if we don't do it earlier.
"Jeff McAffer" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/11/2008 11:51 AM
Please respond to
Equinox development mailing list
To
&q
As discussed in the planning call this morning our feature names are all
over the map. Here is a sample of some I see in the current testUpdates
repo
Eclipse Project Equinox bundle feature
Eclipse P2 Developer Resources
Equinox bundle source feature
Equinox Provisioning Director Application
I fyou run the installer in shared mode it uses one profile registry and
creates a new profile for every different thing you install.
Jeff
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:equinox-dev-
> [EMAIL PROTECTED] On Behalf Of Thomas Hallgren
> Sent: Friday, May 30, 2008 5:38
ation Jeff. Maybe my solution is to contribute
everything I'm doing to p2 so it can get included in the allowed list :)
Cheers,
Doug
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff McAffer
Sent: Friday, May 30, 2008 3:27 PM
To: 'Equinox developme
It was the joint decision of the team and the PMC that p2 would not have any
API. By definition, anything that is not API is marked as x-internal =
true. As a result, and by design, you get a warning that you are using
something that is not API. I agree that this is annoying however, no one
will
age-
> From: [EMAIL PROTECTED] [mailto:equinox-dev-
> [EMAIL PROTECTED] On Behalf Of Jeff McAffer
> Sent: Wednesday, May 21, 2008 12:18 AM
> To: 'Equinox development mailing list'
> Subject: RE: [equinox-dev] Is the P2 installer supposed to work?
>
> Dunno Alex. Thi
Dunno Alex. This works fine for me on windows but I see your point on the Mac.
> I had a look at the p2installer.ini:
>
> -showsplash
> org.eclipse.platform
> -vmargs
> -Xdock:icon=../Resources/Eclipse.icns
> -XstartOnFirstThread
> -Xms40m
> -Xmx256m
> -XX:MaxPermSize=256m
> -Dorg.eclipse.swt.in
respond to
Equinox development mailing list
To
equinox-dev@eclipse.org
cc
Subject
[equinox-dev] Commit rights for Rafael Chaves have been expired
eclipse.equinox Committers,
Jeff McAffer has expired the commit rights for Rafael Chaves (rchaves).
The reaso
+1 I annotated the bug with more thoughts
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Timothy Webb
Sent: Thursday, May 15, 2008 5:17 PM
To: Equinox development mailing list
Subject: [equinox-dev] [p2] Milestone update site for 3.4
Apologies for the persistence on this is
Ideally people would not have to copy the repos somewhere else just to get
Maven integration. Perhaps someone in the community can provide/point to an
update site/p2 adapter for Maven? That way you would just point Maven at
the main Eclipse repos (or a mirror).
Jeff
> -Original Message-
creating installers
for EPP packages, since this is where bundle pooling across applications
really comes into play.
"Jeff McAffer" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/26/2008 11:38 AM
Please respond to
Equinox development mailing list
To
"'G
1 - 100 of 291 matches
Mail list logo