Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b60
    • Fix Version/s: 4.0_b76_EE7MS5
    • Component/s: sample_apps
    • Labels:
      None

      Description

      We need to implement samples for Java EE 7. Some things to consider:

      • Component teams should be responsible for writing samples.
      • Component teams contribute the samples to the java.net javaee samples project.
      • The Java EE 7 samples should be buildable using Maven
        • There should be a parent Pom that builds all Java EE 7 samples
        • Each sample should have its own POM for building the sample individually
      • The samples need to run in NetBeans and Eclipse (both support maven projects, so that's good)

      Some issues to clarify:

      • Do we ship the old (Java EE 6) samples? In Java EE 6 we did not ship Java EE 5. We may have shipped Java EE 4 samples in Java EE 5.
      • Do we re-work the old samples to build with Maven? We may not have the bandwidth to do that. We may need to cherry pick high value Java EE 6 samples and "port" them to Java EE 7 and the new sample framework.

      Also, the tutorial team is migrating their examples to maven. They are currently using the Maven GlassFish Plugin as a replacement for the capabilities that the old ant based BP framework provided, but it needs enhancements.

        Issue Links

          Activity

          Hide
          Romain Grécourt added a comment -

          Here are some additional thougths:

          1)

          • the parent pom should be only an aggregator pom
          • if there is a need for a parent pom, it should be released separately and available in maven central, or be the only building pre-requisite.
          • each sample should be runnable separately without requiring build the samples project first, if there is a need for a parent pom it should NOT be the aggregator pom

          2)

          • the sample sources should be located under src/main, as usual
          • the logic related to running the sample should be done during testing.
          • I believe we should not require a GlassFish installation up and running for the tests but instead leverage glassfish embeeded.
          • We can certainly provide a way of running the tests on an exisiting GlassFish installation by using profiles
          • We might need to write a maven plugin to wrap asadmin commands in order to interact with a glassfish intallation from maven in an elegant way!

          3)

          • the documentation of each tests should be located inside each test project. However we don't want to require a separate building step that would build the documentation, a unique aggregrated documentation should exist in the top level directory.
          • This aggreagated documentation should be generated by aggreagating the generated documentation of each sample projects, with a goal that is not part of the default lifecycle that is used when using the samples. i.e We should be able to build the documentation during the build of the samples-bundle.
          Show
          Romain Grécourt added a comment - Here are some additional thougths: 1) the parent pom should be only an aggregator pom if there is a need for a parent pom, it should be released separately and available in maven central, or be the only building pre-requisite. each sample should be runnable separately without requiring build the samples project first, if there is a need for a parent pom it should NOT be the aggregator pom 2) the sample sources should be located under src/main, as usual the logic related to running the sample should be done during testing. I believe we should not require a GlassFish installation up and running for the tests but instead leverage glassfish embeeded. We can certainly provide a way of running the tests on an exisiting GlassFish installation by using profiles We might need to write a maven plugin to wrap asadmin commands in order to interact with a glassfish intallation from maven in an elegant way! 3) the documentation of each tests should be located inside each test project. However we don't want to require a separate building step that would build the documentation, a unique aggregrated documentation should exist in the top level directory. This aggreagated documentation should be generated by aggreagating the generated documentation of each sample projects, with a goal that is not part of the default lifecycle that is used when using the samples. i.e We should be able to build the documentation during the build of the samples-bundle.
          Hide
          Tom Mueller added a comment -

          Here is some information from Ian Evans that might be relative to the Java EE samples:

          First, some background. Our example source was previously based on the Blue Prints Ant build files, customized for our purposes. This allowed us to use a single build.xml file that would work on the command-line with Ant, or within NetBeans (in which case the application would use the NetBeans-generated build files). Maintaining the Blue Prints build files was a hassle, though, and having two parallel build systems made testing more difficult.

          We're now in the middle of migrating to Maven for our examples. I've documented some of the process in the following wiki pages on our java.net site:
          http://java.net/projects/javaeetutorial/pages/ConvertingAntToMaven
          http://java.net/projects/javaeetutorial/pages/MavenArtifacts

          Currently we have not tried using the maven-glassfish-plugin to deploy the applications or configure resource, though we intend to. We can, however, deploy and run the applications from within NetBeans, with the exception of Application Clients. The NetBeans team, for whatever reason, doesn't support running Application Clients, either standalone or as EAR modules, within the IDE if they are Maven projects. This worked for Ant-based projects.

          Our example code can be checked out using svn from the following URL:
          https://svn.java.net/svn/javaeetutorial~svn/trunk

          Show
          Tom Mueller added a comment - Here is some information from Ian Evans that might be relative to the Java EE samples: First, some background. Our example source was previously based on the Blue Prints Ant build files, customized for our purposes. This allowed us to use a single build.xml file that would work on the command-line with Ant, or within NetBeans (in which case the application would use the NetBeans-generated build files). Maintaining the Blue Prints build files was a hassle, though, and having two parallel build systems made testing more difficult. We're now in the middle of migrating to Maven for our examples. I've documented some of the process in the following wiki pages on our java.net site: http://java.net/projects/javaeetutorial/pages/ConvertingAntToMaven http://java.net/projects/javaeetutorial/pages/MavenArtifacts Currently we have not tried using the maven-glassfish-plugin to deploy the applications or configure resource, though we intend to. We can, however, deploy and run the applications from within NetBeans, with the exception of Application Clients. The NetBeans team, for whatever reason, doesn't support running Application Clients, either standalone or as EAR modules, within the IDE if they are Maven projects. This worked for Ant-based projects. Our example code can be checked out using svn from the following URL: https://svn.java.net/svn/javaeetutorial~svn/trunk
          Hide
          Joe Di Pol added a comment - - edited

          Feedback from Arun concerning Java EE 6 samples to carry forward:

          Based upon the Java EE 6 SDK Samples at:

          http://java.net/downloads/glassfish-samples/promoted/javaee6-samples-1.0-b03-installer.jar

          Here are the samples that should be carried forward:

          ejb/*
          jpa/*
          rest/message-board-war
          rest/managed-beans-war need to be cleaned up and remove classes with @ManagedBeans
          security/*
          web/jsf/* should be moved to one higher level directory
          web/servlet/* should be moved to one higher level directory
          webservices/* should be renamed to jaxws/* (no need for "hello" in all directory names)
          weld/* should be renamed to cdi/*

          And from John Clingan:

          Regarding engineering priority, here's my take:
          First:
          REST samples (taking into account Arun's managed beans comment)
          weld (simply because many developers are still new to it)
          ejb war app, servlet 3.0 annotations sample (would be nice to keep pushing this message)
          ejb embeddable api (popular for testing)

          Next:
          JSF 2 (AJAX) samples
          security - servlet programmatic login sample
          Servlet 3.0 Web Fragments sample

          Next:
          remainder of samples

          Show
          Joe Di Pol added a comment - - edited Feedback from Arun concerning Java EE 6 samples to carry forward: Based upon the Java EE 6 SDK Samples at: http://java.net/downloads/glassfish-samples/promoted/javaee6-samples-1.0-b03-installer.jar Here are the samples that should be carried forward: ejb/* jpa/* rest/message-board-war rest/managed-beans-war need to be cleaned up and remove classes with @ManagedBeans security/* web/jsf/* should be moved to one higher level directory web/servlet/* should be moved to one higher level directory webservices/* should be renamed to jaxws/* (no need for "hello" in all directory names) weld/* should be renamed to cdi/* And from John Clingan: Regarding engineering priority, here's my take: First: REST samples (taking into account Arun's managed beans comment) weld (simply because many developers are still new to it) ejb war app, servlet 3.0 annotations sample (would be nice to keep pushing this message) ejb embeddable api (popular for testing) Next: JSF 2 (AJAX) samples security - servlet programmatic login sample Servlet 3.0 Web Fragments sample Next: remainder of samples
          Hide
          Snjezana Sevo-Zenzerovic added a comment -

          Initial Java EE 7 sample workspace is in place, migration instructions for Java EE 6 samples have been provided.

          Show
          Snjezana Sevo-Zenzerovic added a comment - Initial Java EE 7 sample workspace is in place, migration instructions for Java EE 6 samples have been provided.
          Hide
          Joe Di Pol added a comment -

          Samples workspace:
          https://svn.java.net/svn/glassfish-samples~svn/trunk/ws/javaee7

          See README.html in that directory for details.

          Show
          Joe Di Pol added a comment - Samples workspace: https://svn.java.net/svn/glassfish-samples~svn/trunk/ws/javaee7 See README.html in that directory for details.
          Hide
          Snjezana Sevo-Zenzerovic added a comment -

          Closing since basic Java EE 7 samples build and deployment framework has been provided although there will be ongoing improvements.

          Show
          Snjezana Sevo-Zenzerovic added a comment - Closing since basic Java EE 7 samples build and deployment framework has been provided although there will be ongoing improvements.

            People

            • Assignee:
              Snjezana Sevo-Zenzerovic
              Reporter:
              Joe Di Pol
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: