headers
Curtis Windatt | 8 Feb 16:09
Picon

Planning Meeting Notes - 8 Feb 2012

Planning Meeting Notes
8 February 2012

JDT UI, JDT Text
- helped other components fixing JRE 7 related test failures
- added support to detect EEs for JRE 8
- reviewed several content assist related patches
- restarted work on improved matching bracket support
- bug fixing
- vacation

JDT/Core
- Fixed long standing search failure with generics.
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=123836.
  Issue had been reported several times and was impacting refactoring also.
- Design discussions on null annotation support for fields.
- Several fixes and improvements to resource leaks analysis.
- Patch review for support for ignoring optional compile problems
  against specific folders: https://bugs.eclipse.org/bugs/show_bug.cgi?id=220928
- bug fixing, inbox tracking, newsgroups.
- vacation

Performance:
- No new regressions

PDE
- Bug fixing
- Platform debug and e4 workbench are looking at using dynamic tracing

Debug
- Bug fixing
- Sick time

Ant
- Considering support for Ant 1.8.3

Releng
-contributed 3.7.2RC3 to Indigo SR2 release
-testing running full 4.2 build via cron on build.eclipse.org
-testing invoking tests via JSON API on build.eclipse.org
-two fixes released for 3.7.2RC4 - updated readme with list of bugs fixed and reenabled pde.api fragments to be included in repo

SWT
- applied some patches working toward GTK 3
- continuing ToolBar work on GTK
- XULRunner 10 released, will target this version as the Browser's new supported Mozilla version
- 3.8/4.2-stream fixes, in particular on Cocoa
Permalink | Reply | 0 comments |
headers
Sławomir | 7 Feb 10:31
Gravatar

org.eclipse.persistence.exceptions.ValidationException - JPA ManyToMany mapping

Hello All,

I am new to Eclipse. I stuck since 3 days on strange problem. What I have done:

1. Downloaded and installed Eclipse (eclipse-jee-indigo-SR1-win32-x86_64.zip)
2. Installed GlassFish (glassfish-3.1.1-windows.exe)
3. Installed plugin for Glassfish (for Eclipse Indigio IDE)
4. Created EJB project with facets: Java,EJB,jpa 2.0
5. GlassFish target platform: "GlassFish Server Open Source(Java EE6)"
6. jpa settings - selected as Platform "EclipseLink 2.3"
7. Generated "jpa Entities form Tables"

When I am trying to deploy this application to server I receive following exception:

Exception Description: Predeployment of PersistenceUnit [MegajanServerApp] failed.
Internal Exception: Exception [EclipseLink-7333] (Eclipse Persistence Services -
2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The reference column name [name] mapped on the element [field products] does not
correspond to a valid field on the mapping reference.. Please see server.log for more details.

Here is the mapping definition generated in one of my classe:

//bi-directional many-to-many association to Product
@ManyToMany
@JoinTable(
name="job_products"
, joinColumns={
@JoinColumn(name="job_id", nullable=false)
}
, inverseJoinColumns={
@JoinColumn(name="product_name", referencedColumnName="name", nullable=false)
}
)
private List<Product> products;

In my opinion there is no problem with mapping definition but there is a bug in EclipseLink in this
validation. I found no solution for this problem on the Web. What I tried:

1. Some people calimed this is case-sensitivity issue in mapping definition but this is not my case.
(included in persistence.xml following line <property
name="eclipselink.jpa.uppercase-column-names" value="false"/> and problem still exists)
2. Updated everything what I supposed to cause this error. Even EclipseLink 2.4.0 night build.
3. Reinstalled many times GlassFish server 3.1, Eclipse Indigio IDE
4. The strangest thing is that about 2 month ago I did the same things but on other PC machine and it worked
fine. ???

I am so disappointed... How can I design reliable, distributed applications with EJB 3.1 if mentioned bugs
occur? Maybe I will try NetBeans IDE.
Please, give me any solution to this problem.

Best regards,
Slawek
Permalink | Reply | 0 comments |
headers
Curtis Windatt | 1 Feb 16:29
Picon

Planning Meeting Notes - 1 Feb 2012

Planning Meeting Notes
1 February 2012

Discussion Topic:
- Is anyone using the dynamic tracing API (org.eclipse.osgi.service.debug.DebugOptionsListener)

JDT UI, JDT Text
- shipped Juno M5 (full-time test day, bug fixing, N&N)
- full-time test day against 3.7.2 RC3 - no issues found
- M6 planning
- first UI review of a patch that allows to ignore problems by source folder
- bug fixing

Ant
- investigating updating to Ant 1.8.3
- shipped M5 (N&N + testing)
- bug fixing

Debug
- investigating launching connectors (continued from M5)
- investigate support for key modifiers when toggling breakpoints in editor (https://bugs.eclipse.org/346615 )
- shipped M5 (N&N + testing)
- bug fixing

SWT
- 4.2M5 test week went well
- fixes released on GTK for controls whose preferred sizes were too large (ToolBar fix released for 4.2M5, others fixed this week)
- now testing Eclipse on GTK with Cairo graphics flag turned on, will soon turn this on by default
- fix released for last week's 3.7.2 build: https://bugs.eclipse.org/bugs/show_bug.cgi?id=369757 (OpenGL on Mac)

JDT Core
- Shipped Juno M5 (Verification, code reviews, bug fixing, N&N)
- Test pass for 3.7.2 RC3 - no issues found
- M6 planning
- bug fixing, newsgroups, inbox tracking...

Performance:
- No new regressions

Platform Workspace:
- inbox tracking
- M6 plan created

PDE:
- Inbox cleanup
- Shipped M5
- Tested 3.7.2 RC3
Permalink | Reply | 0 comments |
headers
Daniel Megert | 31 Jan 09:18
Picon
Favicon

Reminder: TODAY Test Pass Against 3.7.2 RC3

This is a reminder that today is a full-time test pass against 3.7.2 RC3 (M20120127-0800). Please also note that all non-doc fixes going into RC3 and beyond need PMC approval on the bug report. For more details, see http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_7_2.php.

Dani
Permalink | Reply | 0 comments |
headers
Kim Moir | 28 Jan 01:52
Picon

Eclipse 4.2M5 now available

New and Noteworthy
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M5-201201271145/eclipse-news-M5.html

Downloads
4.2M5 http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M5-201201271145/index.php

p2 repo http://download.eclipse.org/eclipse/updates/4.2milestones

Enjoy!

Kim
Permalink | Reply | 2 comments |
headers
John Arthorne | 27 Jan 20:16
Picon

Possible platform build delays

We just had a power failure in the building where many IBM Eclipse platform committers are located. This might impact our ability to promote our Eclipse Project Juno M5 build contribution. The current state is that we have a 4.2 build ready [1]. It just needs some final sign-off and renaming/promoting as M5. We will try to get it promoted this evening, but just sending this note in case of delays. If you want to test your M5 contribution you can use the integration build, which will very likely be identical to our M5 with exception of renaming the zips. The only change from yesterday's build is that we picked up the final EMF M5 contribution.

John

[1] http://download.eclipse.org/eclipse/downloads/drops4/I20120127-1145/index.php
Permalink | Reply | 0 comments |
headers
Mike Wilson | 25 Jan 22:24
Picon

Contributing the Eclipse SDK R4.2 to the Juno simultaneous release

At the last Eclipse Architecture Council meeting, I said that we, the Eclipse Project, thought that our ability to deliver the Eclipse SDK R4.2 as part of Juno was at risk. I am happy to say that we have been able to re-align our development effort, and now expect to deliver Eclipse SDK R4.2 as part of Juno. I wanted to talk briefly about how we ended up in this situation, and then cover the highlights of what we are doing to mitigate the risk.

Almost all of the new work in 4.2 is focused around the Platform UI team. When the planning for Juno started, there were 7+ people working (for me) full time on that team. Since then, a number of individuals have left the team to pursue other opportunities. Each time this happened, we looked at what needed to be done, how many people were left, whether we could pull in someone from somewhere else to help, and in the end managed to convince ourselves that a successful delivery was possible.

Last week, two more people told me that they had decided to leave. This left us with just 3 developers working on Platform UI, and that's when I brought the situation up with the EAC; three people, alone, are not enough to deliver a 4.2 of acceptable quality.

Since then, I have worked with the remaining UI team members and the Eclipse PMC to come up with a plan which we believe will allow us to succeed. The highlights of this plan are:

  1. We looked at the other component teams to see whether there was work that could be delayed to free up resources to join the UI team. Because we believe it is critical that 4.2 be part of Juno (see below), this trade off made sense, even though it left some other teams with effectively no active developers. [Even so, we could only add two new people this way, and they will take time to ramp up.]
  2. We took many of the "peripheral" tasks that people from the UI team were working on (e.g. builds, legal/IP, internal company interactions,...) and moved these to others elsewhere on the team.
  3. We made some hard decisions about where to focus our resources. For example, we decided that providing API for the new capabilities of 4.x would have to happen post-4.2. Working on solid backwards compatibility and performance need to be our first priorities.

Some might argue that it would be better to simply release 3.8 into Juno and move ahead with the 4.x stream in a follow on release. Honestly, I believe this would be catastrophic for our community. The Juno simultaneous release is going to be the basis for both the first Eclipse Long Term Support and first Very Long Term Support offerings. Given that, plus the overall maturity of Eclipse and the requirements of many of the large organizations that are participating, I see the Juno release as being extremely important. If we are unable to deliver 4.2 in Juno it would mean that a huge segment of the community would not be able to take advantage of the new features it provides, but more importantly they would be building on a code base that we know needed to be replaced -- that was, after all, the impetus for the 4.x work in the first place. It would literally mean that it would no longer be possible for the Platform (that we all build on) to adapt to the changing needs of modern, desktop applications. And this, more than anything I can think of, would jeopardize the future of Eclipse on the desktop.

In the end, what's clear to me out of all of this is that the Eclipse Platform UI team, and indeed the Eclipse Project as a whole, *needs* more non-IBM committers now. And by that I mean more, *active*, "working on the SDK for the good of the community in general" people. All those arguments about lack of diversity on the Eclipse Project are coming home to roost: It is clear now, that the remaining IBM Eclipse committers are too few to support the entire SDK. It is a virtual certainty that we will see more situations like we did recently with the Platform User Assistance team; that is, we will get to the point where there are no longer *any* active committers left on some areas of the SDK. I tell you truthfully, I am committing all of the people that I can to working on the SDK, but if we (the Eclipse community) care about Eclipse having a future on the desktop, other resources need to be found. There is still calendar time for you to have a positive impact on the Juno release if you wish to participate.

McQ.

-
Permalink | Reply | 0 comments |
headers
Curtis Windatt | 25 Jan 16:10
Picon

Planning Meeting Notes - 25 Jan 2012

Planning Meeting Notes
25 January 2012

JDT UI, JDT Text
- Released support for null fields analysis (https://bugs.eclipse.org/bugs/show_bug.cgi?id=247564)
  Several new diagnostics:
     Potential null pointer access: The field {0} may be null at this location
      Redundant null check: The field {0} can only be null at this location
      Null comparison always yields false: The field {0} can only be null at this location
      Redundant null check: The field {0} cannot be null at this location
      Null comparison always yields false: The field {0} cannot be null at this location
      Redundant assignment: The field {0} can only be null at this location
      instanceof always yields false: The field {0} can only be null at this location
- added support to set source attachment encoding
- improved preference UI for null annotation setup
- bug fixing
- Ready for 3.7.2 RC3
- M5 testing looks good so far. No serious issues found.

Ant
- In good shape for M5, no more items planned
- testing 3.7.2 / M5
- bug fixing

Debug
- launching connector investigation pushed to M6 (https://bugs.eclipse.org/335896 )
- In good shape for M5
- testing 3.7.2 / M5
- bug fixing

SWT
- GTK Cairo graphics work-to-date released but currently turned off by default
- continuing GTK ToolBar work for overflow menus
- applied several patches to remove support for older unsupported GTK version (prep. for GTK3 work)
- 4.2M5 testing underway with particular attention on GTK graphics
- some bug investigations on Cairo

Performance:
- No new regressions

Releng
-moved to Java 7 for windows tests
-tested new Jacoco libraries to verify that new version fixes issues while running tests on Java 7
-opened CQs for JaCoco 0.5.6 for Juno
-bug fixing

Platform Workspace:
- inbox tracking
- ready for M5
- Bug 369522 - IContentTypeManagerTest#testPreferences fails in the recent IBuilds [fixed]
- Bug 369493 - [backport][linked source] deleting a linked resource from a read-only project leaves project in an undefined state [late backport to 3.7.2]

PDE
- Tested 3.7.2 RC1 and 3.8 M5
- No more fixes planned for 3.7.2 / M5
- Inbox cleanup
Permalink | Reply | 1 comment |
headers
Daniel Megert | 24 Jan 15:47
Picon
Favicon

REMINDER: Open Juno M5 Bugs

Component leads please go over your inbox. There are still more than 60 open bugs targeted for Juno M5.

Thanks,
Dani
Permalink | Reply | 0 comments |
headers
Oberhuber, Martin | 23 Jan 15:23
Favicon

Heads up: Eclipse Platform 3.7.2 is going to ship a newer JSch

Hi all,

 

This is just a quick heads up that Eclipse Platform 3.7.2 (Indigo SR2) is going to ship with the JSch-0.1.44 library for SSH transport, while Indigo and SR1 used JSch-0.1.41.

 

We do not expect any regression or breakage … but I did want to mention the change, since JSch deals with encryption, so some adopters may need to go through specific legal procedures to announce the version update when redistributing it in their products on top of Eclipse.

 

The newer JSch-0.1.44 has been in Orbit for a long time and has been included by egit as well as the Eclipse Juno builds so it has received a good deal of testing.

 

Comments or concerns on the bug, please:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=344469

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

Permalink | Reply | 0 comments |
headers
Thomas Watson | 19 Jan 21:44
Picon
Favicon

Use of jsr14 and Java 7 javac


Our use of jsr14 for some Equinox projects in order to use generics AND
continue support of J2SE 1.4 and J2ME Foundation 1.2 will cause problems
for folks compiling against our jars using the Java 7 javac compiler.  I
have opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=369145 to discuss
not using the jsr14 option anymore.  Please comment in that bug with your
concerns or comments.  The consequence is that the Equinox Framework in
Juno will have a J2SE-1.5 minimum execution environment.

Tom
Permalink | Reply | 0 comments |

Gmane