M2E-WTP DEV MEETINGS
Revision as of 19:17, 6 May 2013 by Fbricon.gmail.com
|Mailing List • Forums • IRC • mattermost|
|Open • Help Wanted • Bug Day|
- 1 M2E-WTP Development Status Meeting
- 2 07/05/2012
- 3 06/12/2012
- 4 24/08/2012
- 5 20/07/2012
- 6 22/06/2012
M2E-WTP Development Status Meeting
- New features :
- Java EE 7 support
- Ability to enable/disable the JAXRS/JSF/JPA Configurators at the pom.xml level
- New API for Facet Detection for JAXRS/JSF/JPA. Gives adopters the possibility to contribute Facet detection strategies
- Validation disabled for build output folder
- Conversion use latest maven plugin versions
- No file copy necessary when using non defaut deploy names in wars
- List of all bug fixed for the current Milestone : changelog
- Bumping version to 1.0
- i18n support
- project plan
- New JavaEE project configurators contributed by the JBoss Tools team, was approved by EMO
- JSF : detects presence of WEB-INF/faces-config.xml or FacesServlet in WEB-INF/web.xml, installs corresponding JSF Facet version if needed
- JAX-RS : detects JAX-RS known classes and methods in classpath, installs corresponding JAX-RS Facet version if needed
- JPA : detects persistence.xml presence. Infers JPA platform from dialect or properties. Falls back on Generic platform
- for all configurators, if the facet is already installed, nothing changes (i.e manual settings take precedence)
- All configurators are available as separate, optional features. The main reason is that will allow users to update the corresponding JBoss Tools features to the new m2e-wtp ones, without difficulties (partially working in Juno SR1, should be fully operational in Juno SR2)
Broken JPA configurator in Kepler
- The JPA configurator is broken in Kepler, due to breaking provisional API changes in Dali
- consensus was achieved on the necessity to have separate codebases for Juno and Kepler, as painful as having to maintain several branches can be. WTP works like that, so it's doable.
- JPA configurator won't make it for the next Kepler M4 milestone though, M5 is more likely.
Catching the Kepler train
- Plan is to declare intent for Kepler M4
- At this point, no new bugs will be fixed. Adopters/Community will need to come up with patches for any bug they want to see fixed.
- Setup build infrastructure at eclipse.org :
- in progress : first jobs created
- now need to move build artifacts to m2e-wtp's download area. Probably need Carl Anderson's help for that
- no tests though (due to legal constraints). Builds at Red Hat will be maintained to run regression tests
- once builds artifacts can be made available, need hudson to send notifications to m2e-wtp dev list automatically. Again, need Carl's help for that.
- IP fully cleared by EMO \o/
- List of bug fixed for the current Milestone changelog
Release Candidates and Final Release
- RC1 was released on 22/08/2012
- RC2 (1 bugfix + signed jars)
- TODOs for the release in september
- Ultimate service release for m2eclipse-wtp (github)
What comes next
- Plans for Juno SR2
- List of bug fixed for the current Milestone changelog
Integration/Milestone builds availability
- Next milestone should be released this monday 23/07/12
- Eclipse's policy says milestone update sites should be hosted at download.eclipse.org
- Are we allowed to release a milestone before passing full IP clearing by EMO? http://wiki.eclipse.org/Development_Resources/HOWTO/Parallel_IP_Process says we are, provided "Incubation" is clearly advertised.
- Do the milestone releases need to be jar signed? No, only the final releases. The signing process is defined at http://wiki.eclipse.org/JAR_Signing
- For historical reasons, many m2e-wtp classes are exposed from public packages. Fred doesn't feel they should be considered public API as they do not always adhere to the principles in http://wiki.eclipse.org/Eclipse_Quality, so he wants to move all of them to internal packages. It was agreed, from Carl and Chuck experience with WTP, to keep them and mark them as @provisional instead, to minimize disruption for 3rd party adopters.
- An Juno SR1 RC1 version will be released for wed. 22/08
- the question was raised about the need to disable the Deployment Assembly page for maven projects, since the deployment assembly is controlled by project configurators. It appears we'd need WTP to expose some locking preferences, that would be triggered by m2e-wtp. m2e-wtp should also let users keep their custom settings and prevent their automatic overriding.
- A number of WTP bugs has been created in the context of m2e-wtp and should be addressed in future WTP releases.
m2e-wtp's incubation is moving forward!
- The web site has been set up at https://www.eclipse.org/m2e-wtp/
- m2e-wtp's initial contribution has been greenlit by the IP Team to be uploaded to Eclipse's Git repository, under the parallel IP process.
- m2e-wtp integration tests code is available at github
- The issue tracker has been set up in Eclipse Bugzilla. There will be no issue migration from Sonatype's JIRA. All previous issues will need to be reopened manually in BZ.
- A #m2e-wtp IRC chat room is opened at freenode
- A mailing list for discussions about m2e-wtp developement has been set up.
- TODO : Add some documentation for setting up the developement environment (i.e. how to build m2e-wtp)
- Due to the m2e-wtp test code not being part of m2e-wtp's initial contribution, m2e-wtp is not built using Eclipse.org's Build infrastructure (similar to m2e).
- Instead, Jenkins jobs have been set up under Red Hat's internal build farm.
- Currently, m2e-wtp compiles correctly against Helios, Indigo and Juno. Integration tests are run against Indigo.
- m2e-wtp is built continuously and CI builds are pushed to a public p2 repository hosted by jboss.org : http://download.jboss.org/jbosstools/updates/requirements/m2eclipse/m2e-wtp-indigo/
- TODO : Some tests fail randomly. We need to stabilize them and start from solid foundations before going forward
- TODO : Evaluate the possibility of advertising new dev build availablity on the m2e-wtp-dev mailing list
- IBM wishes to keep Helios backward compatibility. m2e-wtp currently compiles against Helios, but needs to be tested against it. However, its unlikely the existing tests will pass in Helios due to some slight changes in behaviour.
- IBM is willing to perform these backward compatibility tests on their infrastructure and eventually contribute patches back to m2e-wtp and m2e.
- not discussed : backward compatibility / coexistence with the current m2eclipse-wtp install base
- Our objective is to join the Juno SR1 release train on 28/09/2012.
- According to the Juno SR1 calendar, we should target RC1+3 and prepare readyness for wed. 22/08
- we'll work on a release plan (using m2e's release plan as an example),
- m2e-wtp 0.16.0 will focus on stabilization and its main new features will be around the Eclipse to Maven project conversion area (converts eclipse settings to their maven plugin counterpart)