Hi. On Friday 22 January 2010 13:01:05 Paul Gier wrote: > There was some discussion about naming conventions and svn structure for > the javaee api spec projects this morning. There is also more info in > jira [1]. Here is the plan at this point. > > GroupId: org.jboss.spec.<sun groupId> > ArtifactId:<spec name>_<spec version>_spec > Version: Standard OSGI versions starting with 1.0.0 > > For example: > <dependency> > <groupId>org.jboss.spec.javax.servlet</groupId> > <artifactId>servlet-api_2.5_spec</artifactId> > <version>1.0-SNAPSHOT</version> > </dependency> > > The structure in svn will look similar to the structure that the geronimo > project uses for their spec jars [2]. Meaning that each spec version will > have a separate trunk and a separate release cycle. > -1 The API should be maintained by their implementing projects. It is up to the project where the code is maintained. I want full control over the JCA API, hence moved the development of the JCA 1.6 API to my project. The reasons for this were that is a real PITA to do 600 small releases of the API project while the specification was being developed.

"But after the spec have been released..." you may say - but no. I still want full control over the release cycle, revisions update and so on. In my case I'll enhance the API document once we hit the Beta and CR stage in project - so there will continue to be a lot of updates. And doing a possible once a month release of the API project will be an unnecessary step in the release process.

Just to be clear the "-1" is only referring to moving spec sources to a single place in svn right? And the rest you are ok with?

I was imagining keeping the sources in one place because it seems like better organization to group them together. You could still have full control of the release lifecycle no matter where it is in svn.

I don't understand why you would have to do "600 small releases", why can't you use a snapshot while you are developing it?

> The project will release the API under its own Maven artifact using the > project group id - as the JCA container has a life besides AS. What is the rationale for this? The naming convention Paul outlined is in no way JBoss AS specific. The whole point of this exercise is to reduce confusion around what the correct spec impl is for use in jboss.org projects. Having two releases of the same thing under the org.jboss namespace is totally confusing.

If that point's accepted, I don't see the significance of where in the svn repo the source lives. The only thing I could see is if you don't want to have the rest of the JCA project depend on an external spec jar, but instead manage it as a single project with multiple modules, the way the AS was before it was mavenized. But then you're releasing a new version of the spec every time the rest of the project needs a release.

I don't see how this discussion is any different from a generic dependency issue. We have some API which may be consumed by N projects. The namespace must be "javax.something". Would you look in some project implementation for this, or somewhere externally shared? "Multimodule builds are to be used to group modules together in a single build."[1] From this I infer that modules are intended to share release cycles. Now, I don't consider the EJB Specification APIs to be a part of the JBoss EJB implementation. We want to continually publish updates, bug fixes, and enhancements without re-releasing the Spec APIs. From this setup I'd conclude that the JBoss EJB Impl should depend upon the EJB Spec APIs, exporting the dependency to consumers. If we want to change the Spec APIs to adjust source or JavaDoc or whatever, we can update the module shared by all, cut a new release, and update our dependency. Contrast that with the ShrinkWrap API; here we actually re-release the API as a module as part of the main release cycle, but only because: 1) It's just plain easier to manage given the tools available. 2) We may want to update user-visible implementation classes (in a way that doesn't break binary compatibility) 3) We may want to update JavaDocs, and have there be a 1:1 relationship between releases and docs. Easier for users. Spec APIs on the other hand are: 1) Shared by N impls 2) Intended to be locked and done after TCK passes S, ALR [1] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sec... On 01/22/2010 02:50 PM, Jesper Pedersen wrote: > On Friday 22 January 2010 13:57:21 Brian Stansberry wrote: > >>> The project will release the API under its own Maven artifact using the >>> project group id - as the JCA container has a life besides AS. >>> >> What is the rationale for this? The naming convention Paul outlined is >> in no way JBoss AS specific. The whole point of this exercise is to >> reduce confusion around what the correct spec impl is for use in >> jboss.org projects. Having two releases of the same thing under the >> org.jboss namespace is totally confusing. >> >> > My point is that AS will have one public API and the standalone JCA project > will have its own public API. > > Each of these should be clear and documented, and will target different groups > of developers. Yes, with some overlap I know. > > >> If that point's accepted, I don't see the significance of where in the >> svn repo the source lives. The only thing I could see is if you don't >> want to have the rest of the JCA project depend on an external spec jar, >> but instead manage it as a single project with multiple modules, the way >> the AS was before it was mavenized. But then you're releasing a new >> version of the spec every time the rest of the project needs a release. >> >> > EJB3 seems to be managing individual version identifiers for their components > just fine. > > Best regards, > Jesper > ____________

I'm not able to run our testsuite. Any idea what might be wrong here? ----------------------------------------------- C:\projects\jboss6\trunk\testsuite>build one-test -Dtest=org.jboss.test.deployers.ear.test.EARAltDDDeploymentUnitTestCase Calling ..\tools\ant\bin\ant.bat one-test -Dtest org.jboss.test.deployers.ear.test.EARAltDDDeploymentUnitTestCase Buildfile: build.xml check-env: init-maven-ant-tasks: init-dependencies: init-dependencies: [echo] Loading dependency paths from file: C:\projects\jboss6\trunk\testsuite\output\build-dependencies.xml init-paths: server-config: init: one-test: [junit] Running org.jboss.test.deployers.ear.test.EARAltDDDeploymentUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec BUILD FAILED C:\projects\jboss6\trunk\testsuite\build.xml:3456: Process fork failed. Total time: 31 seconds C:\projects\jboss6\trunk\testsuite> ---------------------- Testsuite: org.jboss.test.deployers.ear.test.EARAltDDDeploymentUnitTestCase Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec Testcase: null took 0 sec Caused an ERROR Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.

Hi everyone, There was some discussion about naming conventions and svn structure for the javaee api spec projects this morning. There is also more info in jira [1]. Here is the plan at this point. GroupId: org.jboss.spec.<sun groupId> ArtifactId: <spec name>_<spec version>_spec Version: Standard OSGI versions starting with 1.0.0 For example: <dependency> <groupId>org.jboss.spec.javax.servlet</groupId> <artifactId>servlet-api_2.5_spec</artifactId> <version>1.0-SNAPSHOT</version> </dependency> The structure in svn will look similar to the structure that the geronimo project uses for their spec jars [2]. Meaning that each spec version will have a separate trunk and a separate release cycle. In addition to deploying the spec jars (and pom) to the Maven repository, there will also be an aggregate pom, but not an aggregate jar. The aggregate pom will be a project with packaging "pom" and will list each included spec in the dependencyManagement and dependencies sections. This will allow the app server build to declare a single dependency on the combined javaee pom and it will automatically get all the individual spec jars added to the dependency tree. Going forward, we would like to have all spec jars in same area in svn, and each will have it's own release lifecycle and projects that need the spec jars can either depend on the individual jars or on the aggregator pom. [1]https://jira.jboss.org/jira/browse/JBEE-15 [2]http://svn.apache.org/repos/asf/geronimo/specs/trunk/ _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Any reason we shouldn't just make it uniform though? Seems like we'd want to keep them all in the same place, in maven and in svn, just for ease of management. - DML On 01/22/2010 01:18 PM, Emmanuel Bernard wrote: > Note that we own a couple of specs like CDI and Bean Validation. For these we do use javax.blah as the genuine owner and implementor of that namespace. > > On 22 janv. 2010, at 19:01, Paul Gier wrote: > >> Hi everyone, >> >> There was some discussion about naming conventions and svn structure for the >> javaee api spec projects this morning. There is also more info in jira [1]. >> Here is the plan at this point. >> >> GroupId: org.jboss.spec.<sun groupId> >> ArtifactId:<spec name>_<spec version>_spec >> Version: Standard OSGI versions starting with 1.0.0 >> >> For example: >> <dependency> >> <groupId>org.jboss.spec.javax.servlet</groupId> >> <artifactId>servlet-api_2.5_spec</artifactId> >> <version>1.0-SNAPSHOT</version> >> </dependency> >> >> The structure in svn will look similar to the structure that the geronimo >> project uses for their spec jars [2]. Meaning that each spec version will have >> a separate trunk and a separate release cycle. >> >> In addition to deploying the spec jars (and pom) to the Maven repository, there >> will also be an aggregate pom, but not an aggregate jar. The aggregate pom will >> be a project with packaging "pom" and will list each included spec in the >> dependencyManagement and dependencies sections. This will allow the app server >> build to declare a single dependency on the combined javaee pom and it will >> automatically get all the individual spec jars added to the dependency tree. >> >> Going forward, we would like to have all spec jars in same area in svn, and each >> will have it's own release lifecycle and projects that need the spec jars can >> either depend on the individual jars or on the aggregator pom. >> >> [1]https://jira.jboss.org/jira/browse/JBEE-15 >> [2]http://svn.apache.org/repos/asf/geronimo/specs/trunk/ >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development