Community
Participate
Working Groups
In subversion the project is currently checked in under utils/o.e.p.utils.jpa.query; th eproject name determines the name of the bundle. The internal package structure does not need to be exactly reflected in the project or bundle name. However, it does reflect functionality. In order to proceed further on 337911, we need to finalize on a bundle name, so I can write the proper includes and excludes into the build process. I have no investment in the name other than I'd like it fairly short, unique, and descriptive. We currently have: org.eclipse.persistence.antlr org.eclipse.persistence.asm org.eclipse.persistence.dbws org.eclipse.persistence.dbws.builder (utility bundle) org.eclipse.persistence.core org.eclipse.persistence.oracle (fragment) org.eclipse.persistence.jpa org.eclipse.persistence.jpa.equinox.weaving (fragment) org.eclipse.persistence.jpa.equinox (fragment) org.eclipse.persistence.moxy org.eclipse.persistence.sdo I have no issue with org.eclipse.persistence.hermes from a build perspective, but thought needs to go into the name with possible future functional expantion, and OSGi dependency management in mind.
I think we came to somewhat of a consensus with: org.eclipse.persistence.jpa.jpql Any objections?
I hadn't suggested it because: - Doug and Peter's concerns that close association with jpa would/could cause assumptions to be made that it is the default jpql parser. - my preference is for a shorter bundle name. o.p.e.<something> org.eclipse.persistence.jpa.equinox.weaving for example is an incredible mouthful
that said, I have no real objections to it.
I think the parsers have to coexist as sub-parts of the same namespace. org.eclipse.persistence.internal.jpa.parsing.antlr org.eclipse.persistence.internal.jpa.parsing.hermes We likely have to do some relocation of the antlr code to accomodate this.
(In reply to comment #4) > I think the parsers have to coexist as sub-parts of the same namespace. > > org.eclipse.persistence.internal.jpa.parsing.antlr > org.eclipse.persistence.internal.jpa.parsing.hermes > > We likely have to do some relocation of the antlr code to accomodate this. That makes sense. Works for me.
(In reply to comment #4) > I think the parsers have to coexist as sub-parts of the same namespace. > org.eclipse.persistence.internal.jpa.parsing.antlr > org.eclipse.persistence.internal.jpa.parsing.hermes > We likely have to do some relocation of the antlr code to accomodate this. Are you talking project name or package names? if package naming see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=338138
I've separated out the discussion of the integration code into Bug 338248. We can focus this bug on the packaging and location of the parser itself. With the integration of the Hermes JPQL parser into o.e.p.core the placement of the parser into util is obviously not going to work. Instead, the Hermes JPQL parser, and not the integration code, would be place into bundle o.e.p.jpa.jpql in the JPA component.
I'm moving this bug to the JPA component.
(In reply to comment #8) > I'm moving this bug to the JPA component.
(In reply to comment #7) > We can focus this bug on the packaging and location of the parser itself. I have a problem with this statement only because of the use of the word "packaging", which I am using to refer to the code organization inside the bundle (338138). where this bug is focused on how we name the parser bundle project itself (which also becomes the name of the bundle).
(In reply to comment #7) > With the integration of the Hermes JPQL parser into o.e.p.core the placement of > the parser into util is obviously not going to work. Instead, the Hermes JPQL > parser, and not the integration code, would be place into bundle > o.e.p.jpa.jpql > in the JPA component. I'm ok with this. +1
Peter agrees as well, he unfortunately cannot update the bug himself at this time. I'm hoping he will later.
This work was completed with the patch from bug 338138. The parser has moved to the jpa component with a name of o.e.p.jpa.jpql.
Closing bug. Issue has been resolved
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
