|
[
Permlink
| « Hide
]
Craig McClanahan added a comment - 24/Jul/06 08:40 PM
Initial version of "shale-mailreader-jpa" committed to the repository, to be added to the 20060725 nightly biulds. Will be included in 1.0.3 release.
Why is mailreader-jpa in the sandbox? If we follow the normal rules, sandbox components are not allowed to have releases. That would leave this example app dependent on a snapshot of mailreader-jpa. (Which should be named shale-mailreader-jpa, I think...) I seem to recall you mentioning struts-mailreader-dao being in the Struts sandbox, and that is not the case. It is a module at the same level as struts-core and struts-extras. The location in "sandbox" was a process of elimination choice based on our current options:
* It doesn't belong in the "maven" directory because it isn't part of the Maven infrastructure. * It doesn't really belong in "framework", because it has zero dependencies on Shale. (This is also why the name "mailreader-jpa" was chosen for the entity classes project versus "shale-mailreader-jpa" which I used for the webapp.) * The sandbox was the only other option. I'd be fine with an "extras" directory at the same level as framework and sandbox, and moving the mailreader-jpa project there. Some interesting parts of shale-test have no dependencies on Shale, and they're included under 'framework'. I'm not sure it's worth significantly complicating the release process (it would require a separate release of mailreader-jpa) in order to keep this out of the framework directory. How about putting it in shale-apps/mailreader-jpa, and using groupId org.apache.shale.extras artifactId mailreader-jpa ? |
|||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Example application ilustrating Java Persistence Architecture (JPA) integration
