MavenIn67

Technical Council Review Specification - NetBeans 6.7.

Maven Support in NetBeans 6.7

Milos Kleint (MK)
Tonda Nebuzelsky (AN)
David Simonek (DS)
Tor Norbye (TN)
Jesse Glick JG)
Jano Rojcek (JR)
Tomas Zezula (TZ)
Marian Mirilovic (MM)
Petr Pisl (PP)
Petr Jiricka (PJ)
Hrebejk (PH)

AN: Moving Maven from autoupdate to distribution. Already done: legal review, relicensing, CA from Contributors, 
    build infrastructure change. Bugs in the process of migration. DevRev done.
    UI review pending, will be done.
    Besides moving to standard build, make it a 1st class citizen: UI changes, support all the features: debugging, 
    profiling, ... (see the spec).
    Maven-specific features: pom.xml editing.
    P0: Redistribute to clusters
JG: In theory could preserve the Maven cluster, but would be messy. Redistribution is better.
MK: maven.gsf is controversial - used for Groovy and Scala integration
TZ: maven.gsf will probably go away with Parsing API
MK: Connected Developer - pom.xml elements map well to Kenai concepts (mailing lists). Not sure about Kenai support 
    for Maven (repositories etc.). java.net allows direct publishing Maven projects.
PH: Not sure about the current Kenai plans for Maven (probably none), but sounds easy to do.
MK: Binary artifacts deployment through Maven should be doable. 
PH: Downloads on Kenai are currently manual. 
???
MK: P1 means - highly desirable to have this
PJ: Can we do continuous builds for Maven projects in Kenai?
MK: Hudson supports Maven.
JG: Hudson has a pretty good support for Maven - embedded (in-process) Maven.
MK: This has some compatibility problems. Would prefer external Maven.
JG: Embedded Maven has some positive aspects.
PJ: Any other stoppers for inclusion in the main distro.
MM: Only the redistribution to clusters is required for putting into standard distro.
JR: Should do UI review before integration before NB 7 builds. Does not expect any major issues.
PJ: Jarda brought up the requirement of not slowing down the IDE when . 
MK: Indexes downloaded from repositories, downloaded on startup. Up to 20MB. Can it be postponed to when it is 
    needed?
JG: Could it be delayed to when you open a project?
MK: Also used when creating a project.
AN: Can it be bundled?
MK: Incremental updates would help, not sure if Maven will do them in time for 6.7.
MK: Project creation is waiting for the download - slow initial creation.
JG: Can just show basic archetypes? The advanced ones would be shown after download it completed.
AN: Let's discuss features with external dependencies.
MK: Web services was requested often, staffed.
MK: Libraries with Maven pom volume. Needed for e.g. Woodstock. Assumption: New Servlet assumes that servlet.jar is 
    on classpath. 
JG: If we have servlet as a standard library, we are fine.
MK: Either need to include a servlet library, or have another way.
JG: javaee.jar can be legally shipped without 
PJ: We don't want to ship libraries if possible
JG: ClassPath modifier solution?
TZ: Maybe an API between Maven and JavaEE?
JG: Probably belongs to classpath modifier.
TZ: What will it do for JavaSE project?
MK: Can not have servlet in JavaSE project, non-issue. 
JG: Can think of a solution using CP modifier.
MK: Test single, profiling, swing app framework: lots of user input, highly desirable
MM: Buy in from the other teams?
AN: No.
AN: Test single and profiling are more important, swing app framework may not be that important, and probably 
    not staffed
MK: There is still user input on Swing app framework
MK: JPA sort of supported, maybe not completely.
MK: EJB+EAR - not reviewed, works a bit
AN: Review of the current state is needed, P1, others are not critical
MK: J2EE 1.3 is the default currently
PJ: Yes, bad indeed.
MK: JavaScript libraries do not work well
MK: JavaScript editing works well (with a hack)
MK: Never tried JavaScript debugging
PJ: Priorities in JavaScript: editing, then debugging, then libraries
AN: Can some things that do not work be disabled?
MK: Probably not from the Maven side
PJ: Preferable to disable from the JS-libraries side.
MM: QE coverage - 2 people full time, will need participation from other teams. The status of 1st class citizen 
    will require changes in the test specs and more coverage going forward.
PP: Do features e.g. web services have to be implemented differently than in Ant?
MK: Yes
MK: APIsupport - works quite well, some user input on this. 
MK: For developing NB platform apps with Maven, need a Maven repository. Maven goals for this already exist.
PJ: Do we want to do for 6.7?
MK: Already have a repository, though this is not 24/7
MK: More maven specific features. Very demoable.
MM: Planned trunk integration date? Pre-integration testing needed, hudson build exists.

Followup steps for integration to standard distro:
- moving into individual clusters
- UI review
- investigate delaying download of index to project creation/opening
- pre-integration testing, of course

After:
- support from JavaEE, Profiler and JUnit teams needed

JG: JavaEE is critical
MK: expect the JavaEE team will take over Maven integration
JB: Conversion of Ant to Maven is not planned?
MK: Not really.
MM: Maven will be bundled, right? Which version?
MK: Will be snapshot of 3.0 (formerly 2.1). 3.0 schedule unclear - will probably be incompatible.
PJ: External Maven still required?
MK: Pretty much yes. About 3MB.

Motivation

Maven Support has been available for several previous NetBeans releases on Update Center. According to download statistics Maven Support has been the most downloaded plugin ever and usage statistics of NetBeans 6.5 Beta shows 19% users have been using the IDE with Maven projects.

Making the Maven Support integral part of the IDE's standard distribution and putting it on par with Ant project support is a logical next step in attracting more Maven users into NetBeans. Improving Maven Support integration with the rest of the IDE is also the only way of keeping our position of the IDE with the best Maven support. Competitors are quickly improving their Maven supports and we could easily lose all our Maven oriented users if we don't invest enough effort into doing this final step of tight Maven support integration.

Features and tasks planned for NetBeans 6.7

Work on Maven Support in NetBeans 6.7 will be focusing on two goals - making the Maven support an integral part of the standard build and making it first-class citizen next to Ant projects with regard to UI, feature set and quality.

See the list of features and tasks in MavenSupport67.

There is a space for improvements and new features in all types of projects - J2SE, J2EE, also NetBeans modules. Some functionality requires revising in all projects, for example profiling and testing support. Special attention must be payed to Maven specific UI features, like comfortable modification of project configuration, both via UI customizers and via enhanced pom.xml editing support.

Significant features and tasks not planned for NetBeans 6.7

Precise scoping for 6.7 is still TBD.

For sure certain areas will not be covered due to time constraints of the release. Candidates for postponing to later releases could be webstart support, groovy support, javascript support and Maven configuration refactoring features.

Interactions with other features and teams

See more detailed list in MavenSupport67. Specific dependencies on other teams include the following work:

  • improving test support
  • improving profiling support
  • improving user experience with Swing App Framework projects
  • improving JPA support
  • writing groovy integration
  • implementing webservices support
  • improving EJB/EAR support

High level design

The most up-to-date UI overview can be found in MavenBestPractices wiki page. This document describes the current state of Maven Support as of version 6.5.

Links

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo