Projects tagged for 20080902 integration build

Re: .qualifier for export package?

Re: .qualifier for export package?

GWT+Equinox

Re: .qualifier for export package?

> API Tooling also has
> items in plan that deal with package versioning, but that will be post 
M2

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 there is a compelling story to have SDK bundles change to using 
package imports. Of course, if someone else has the resources to do the 
work and sees this as a priority, please step up.

        http://www.eclipse.org/pde/pde-api-tools/dev_plans/r3_5/plan.php

> Thoughts for how/if this should be introduced?

To start, I would like to see a better specification developed/agreed upon 
before tooling is introduced. Currently, the description of package 
versioning is minimal - leaving questions to the developers and tool 
implementors:

        http://wiki.eclipse.org/Version_Numbering#How_to_version_packages

Here are some obvious questions:

* How are @since tags formatted to indicate that the version number 
corresponds to packages vs. bundles?
* How are initial package versions derived for existing bundles?

Darin

Re: .qualifier for export package?

Re: GWT+Equinox

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 to the required plug-ins for GWT? I 
have a GWT bundle, and I noticed that it depends on javax.servlet. If I 
remove this dependency I get the class cast exception.

I also removed all the servlet stuff from Exported Packages list. (See 
the Runtime tab in the Manifest editor).

Cheers,
Ian

Ricardo Giacomin wrote:
>
> Hi there,
>
> I tried to follow the directions from wiki page 
> http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with 
> no success. The problem is that no matter what I do I still get the 
> ClassCastException when the ServletManager tries to instantiate the 
> servlet. It is probably a problem of different servlet API version 
> (2.4 in equinox http and 2.3 in gwt).
>
> I’m using:
>
> GWT 1.5.2
>
> Eclipse 3.4
>
> Jetty Http from 
> http://www.eclipse.org/equinox/server/downloads/jettyhttp-anon.psf
>
> Any hints?
>
> Thank you in advance.
>
> Regards,
>
> Ricardo Giacomin
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>   

-- 
R. Ian Bull
PhD Candidate, University of Victoria
http://www.ianbull.com
http://irbull.blogspot.com/

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: .qualifier for export package?

Darin Wright
Eclipse Debug Lead,
Rational Team,
IBM Canada
(204)938-8051

equinox-dev-bounces@... wrote on 09/02/2008 01:59:00 PM:

> 
> > Here are some obvious questions:
> > 
> > * How are @since tags formatted to indicate that the version number 
> > corresponds to packages vs. bundles?
> 
> If there is a package version then the @since should always reference
> the package version exported in my opinion.

Right, but since package versions will now evolve independently of bundle 
versions, should the package name also appear in the @since tag - like 
"@since org.eclipse.jdt.debug.model 3.4". Else, when just looking at the 
Javadoc, consumers of an API will not know if they need a required bundle 
or a package import.

> 
> > * How are initial package versions derived for existing bundles?
> 
> The simple answer here is to seed the package versions with the 
> bundle's version.  This makes some sense because using the Eclipse 
> versioning rules today the API packages from a single bundle are 
> versioned together as one unit using the Bundle-Version.

Another option is to use the highest @since tag in the package. If a most 
recent since tag in a package is 3.1, it could start at 3.1 instead of 
3.5.

Darin

Re: .qualifier for export package?

Re: .qualifier for export package?

> > Right, but since package versions will now evolve independently of 
bundle 
> > versions, should the package name also appear in the @since tag - like 

> > "@since org.eclipse.jdt.debug.model 3.4". Else, when just looking at 
the 
> > Javadoc, consumers of an API will not know if they need a required 
bundle 
> > or a package import.
> 
> Wouldn't the package name already be stated by the package statement
> at the head of the source code? It seem redundant and repetitive to 
> put it in the @since tag. 
> 
> I think @since obviously applies to the package. When you javadoc 
> the code, bundle membership is absent. Only the package organization 
remains.

OK, this would be a good argument to have initial package versions reflect 
the highest @since tag in the package, rather than the current bundle 
version. Else we'd have a mix of @since tags in existing bundles - where 
some referenced the bundle version, and some referenced the package 
version.

Darin