Home » Eclipse Projects » Dali » Dali 2.2 Planning
|
Re: Dali 2.2 Planning [message #435121 is a reply to message #435120] |
Thu, 18 December 2008 00:42 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Hi Neil,
I have multiple persistence units (different databases) specified in my
persistence.xml, so everytime I want to test, I have to comment one of
them out. Is there any way around this?
It would also be nice if there were a data modeling tool (like an
improved ErWin) which would automatically generate the relationship
mappings. I'm working against a client's database now that's not been
completely specified, so the foreign keys have not all be defined while
it's in flux. Would be cool to reverse engineer the basics (similar to
Generate Entities), but then be able to use such a GUI tool to specify
cardinalities, which would write the complex mappings.
The hard work is much appreciated!
Ari
Neil Hauge wrote:
> All,
>
> We are in the process of planning for the next Dali release. Please
> take this opportunity to send us any feedback you may have that could be
> useful in the planning process.
>
> Feedback is of course welcome at any time, but could be more effective
> if done soon.
>
> Thanks,
> Neil
|
|
|
Re: Dali 2.2 Planning [message #435122 is a reply to message #435121] |
Mon, 22 December 2008 02:06 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Sorry, meant to say integrate a *UML modeling tool* rather than data
modeling tool. Been using DM tools much more often, hence the slip. ;-)
I see that there are now Eclipse MDT-based UML plugins that may
support this effort, but I'm not sure how mature they are.
Best regards,
Ari
Ari Meyer wrote:
> Hi Neil,
>
> I have multiple persistence units (different databases) specified in my
> persistence.xml, so everytime I want to test, I have to comment one of
> them out. Is there any way around this?
>
> It would also be nice if there were a data modeling tool (like an
> improved ErWin) which would automatically generate the relationship
> mappings. I'm working against a client's database now that's not been
> completely specified, so the foreign keys have not all be defined while
> it's in flux. Would be cool to reverse engineer the basics (similar to
> Generate Entities), but then be able to use such a GUI tool to specify
> cardinalities, which would write the complex mappings.
>
> The hard work is much appreciated!
> Ari
>
> Neil Hauge wrote:
>> All,
>>
>> We are in the process of planning for the next Dali release. Please
>> take this opportunity to send us any feedback you may have that could
>> be useful in the planning process.
>>
>> Feedback is of course welcome at any time, but could be more effective
>> if done soon.
>>
>> Thanks,
>> Neil
|
|
| |
Re: Dali 2.2 Planning [message #435125 is a reply to message #435123] |
Tue, 23 December 2008 00:15 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Thanks Neil. Another issue I've recently encountered is the complexity
of performing static bytecode enhancement. After much hacking (and
discovery of errors/omissions in the Wiki docs), I've managed to
successfully execute the enhancers for both EclipseLink and OpenJPA, via
Eclipse launcher, Ant, and Maven. It should be trivial to do this, but
it's not -- many points in their docs are unclear (command-line args,
etc.), and EclipseLink even specifies the wrong package name for the
enhancer:
http://www.tzavellas.com/techblog/2008/10/17/statically-weav ing-jpa-entities-for-eclipselink-using-maven/.
The OpenJPA Maven plugin doesn't work (out of date), and EclipseLink
doesn't have one. OpenJPA had an unspecified Maven dependency
(https://issues.apache.org/jira/browse/OPENJPA-822). I know this has
nothing to do with Dali, but it's a point where using JPA becomes a pain.
It would be a big help if this were integrated, and I could just select
my JPA runtime/lib and click, "Run Enhancer", and perhaps add this to
the Eclipse builder as a post-compilation step. Or is this something
already available that I've overlooked? :-)
Enjoy your holidays!
Ari
Neil Hauge wrote:
> Thanks for the feedback Ari,
>
> Commenting out persistence units is still the recommended workaround for
> multiples at the moment. We have been discussing ways that we could
> provide multiple persistence unit support to our UI and model, while
> trying to keep the standard (single persistence unit) use case simple.
> This is a challenging problem, but I think we have some good ideas that
> may be put to use in the future.
>
> To make things more complicated, we are also looking at how we can
> support the definition of persistence units across projects in a given
> workspace. This is related to our binary class/JAR support that is
> planned for our upcoming 2.2 release (June).
>
> UML modeling is a bit out of our project scope at the time, but it may
> be interesting to see what types of integrations are possible in the
> future.
>
> Neil
>
|
|
| |
Re: Dali 2.2 Planning [message #435130 is a reply to message #435127] |
Fri, 26 December 2008 10:26 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Hi Tom,
That blog pointed out one of the problems -- the package name for the
enhancer class is incorrect -- but the proper values for the command
line args are also unclear. For instance, for the "persistenceinfo" arg
(from the wiki: "Specifies the location of the persistence.xml file if
it is not in the same location as the source."), my persistence.xml is
in "src/main/resources/META-INF", but the enhancer doesn't like that
complete path, and it only works with "src/main/resources" (no
"META-INF"), which was unexpected. I think also an example for a
typical exploded development file structure would be nice to see in
addition to the one based on JARs.
Here's a relevant snippet from my Maven POM (hopefully it will come out
somewhat readable online), if anyone is interested. I'm no Ant guru,
but I found that adding ${basedir} to the paths made it work. I
commented out the alternative command-line-based invocation, which also
works fine.
<pre>
> <plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <id>JPA Enhancement</id>
> <phase>process-classes</phase>
> <configuration>
> <tasks>
> <taskdef
> name="weave"
> classname=" org.eclipse.persistence.tools.weaving.jpa.StaticWeaveAntTask "
> classpathref="maven.test.classpath"/>
> <weave
> loglevel="FINEST"
> source="${basedir}/target/classes"
> target="${basedir}/target/classes"
> persistenceinfo="${basedir}/src/main/resources">
> <classpath refid="maven.test.classpath"/>
> </weave>
>
> <!--
> <java classname="org.eclipse.persistence.tools.weaving.jpa.StaticWeave "
> classpathref="maven.test.classpath"
> fork="true">
> <arg
> line="-loglevel FINEST -persistenceinfo src/main/resources target/classes target/classes"/>
> </java>
> -->
> </tasks>
> </configuration>
> <goals>
> <goal>run</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
</pre>
Thanks,
Ari
Tom Ware wrote:
> Hi Ari,
>
> Some integration of EclipseLink's static weaving with Dali would be a
> good idea.
>
> What problems are you having with the docs? Are the problems you are
> seeing in the blog post listed above, or are they with the documents
> that blog post references on the EclipseLink wiki documenation site? If
> the docs on the wiki site have issues, I should be able to help.
> Otherwise, it is probably best to post a comment to the blog - since
> that is written by someone outside the EclipseLink development team.
>
> At the moment, we have not done any development work on specific-maven
> integration. We just provide an Ant task and a Java class you can use.
> If there is a way we can help you integrate what we have, let us know.
>
> -Tom
|
|
| | | | |
Re: Dali 2.2 Planning [message #613699 is a reply to message #435120] |
Thu, 18 December 2008 00:42 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Hi Neil,
I have multiple persistence units (different databases) specified in my
persistence.xml, so everytime I want to test, I have to comment one of
them out. Is there any way around this?
It would also be nice if there were a data modeling tool (like an
improved ErWin) which would automatically generate the relationship
mappings. I'm working against a client's database now that's not been
completely specified, so the foreign keys have not all be defined while
it's in flux. Would be cool to reverse engineer the basics (similar to
Generate Entities), but then be able to use such a GUI tool to specify
cardinalities, which would write the complex mappings.
The hard work is much appreciated!
Ari
Neil Hauge wrote:
> All,
>
> We are in the process of planning for the next Dali release. Please
> take this opportunity to send us any feedback you may have that could be
> useful in the planning process.
>
> Feedback is of course welcome at any time, but could be more effective
> if done soon.
>
> Thanks,
> Neil
|
|
|
Re: Dali 2.2 Planning [message #613703 is a reply to message #435121] |
Mon, 22 December 2008 02:06 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Sorry, meant to say integrate a *UML modeling tool* rather than data
modeling tool. Been using DM tools much more often, hence the slip. ;-)
I see that there are now Eclipse MDT-based UML plugins that may
support this effort, but I'm not sure how mature they are.
Best regards,
Ari
Ari Meyer wrote:
> Hi Neil,
>
> I have multiple persistence units (different databases) specified in my
> persistence.xml, so everytime I want to test, I have to comment one of
> them out. Is there any way around this?
>
> It would also be nice if there were a data modeling tool (like an
> improved ErWin) which would automatically generate the relationship
> mappings. I'm working against a client's database now that's not been
> completely specified, so the foreign keys have not all be defined while
> it's in flux. Would be cool to reverse engineer the basics (similar to
> Generate Entities), but then be able to use such a GUI tool to specify
> cardinalities, which would write the complex mappings.
>
> The hard work is much appreciated!
> Ari
>
> Neil Hauge wrote:
>> All,
>>
>> We are in the process of planning for the next Dali release. Please
>> take this opportunity to send us any feedback you may have that could
>> be useful in the planning process.
>>
>> Feedback is of course welcome at any time, but could be more effective
>> if done soon.
>>
>> Thanks,
>> Neil
|
|
| |
Re: Dali 2.2 Planning [message #613712 is a reply to message #435123] |
Tue, 23 December 2008 00:15 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Thanks Neil. Another issue I've recently encountered is the complexity
of performing static bytecode enhancement. After much hacking (and
discovery of errors/omissions in the Wiki docs), I've managed to
successfully execute the enhancers for both EclipseLink and OpenJPA, via
Eclipse launcher, Ant, and Maven. It should be trivial to do this, but
it's not -- many points in their docs are unclear (command-line args,
etc.), and EclipseLink even specifies the wrong package name for the
enhancer:
http://www.tzavellas.com/techblog/2008/10/17/statically-weav ing-jpa-entities-for-eclipselink-using-maven/
The OpenJPA Maven plugin doesn't work (out of date), and EclipseLink
doesn't have one. OpenJPA had an unspecified Maven dependency
(https://issues.apache.org/jira/browse/OPENJPA-822). I know this has
nothing to do with Dali, but it's a point where using JPA becomes a pain.
It would be a big help if this were integrated, and I could just select
my JPA runtime/lib and click, "Run Enhancer", and perhaps add this to
the Eclipse builder as a post-compilation step. Or is this something
already available that I've overlooked? :-)
Enjoy your holidays!
Ari
Neil Hauge wrote:
> Thanks for the feedback Ari,
>
> Commenting out persistence units is still the recommended workaround for
> multiples at the moment. We have been discussing ways that we could
> provide multiple persistence unit support to our UI and model, while
> trying to keep the standard (single persistence unit) use case simple.
> This is a challenging problem, but I think we have some good ideas that
> may be put to use in the future.
>
> To make things more complicated, we are also looking at how we can
> support the definition of persistence units across projects in a given
> workspace. This is related to our binary class/JAR support that is
> planned for our upcoming 2.2 release (June).
>
> UML modeling is a bit out of our project scope at the time, but it may
> be interesting to see what types of integrations are possible in the
> future.
>
> Neil
>
|
|
| |
Re: Dali 2.2 Planning [message #613717 is a reply to message #435127] |
Fri, 26 December 2008 10:26 |
Ari Meyer Messages: 136 Registered: July 2009 |
Senior Member |
|
|
Hi Tom,
That blog pointed out one of the problems -- the package name for the
enhancer class is incorrect -- but the proper values for the command
line args are also unclear. For instance, for the "persistenceinfo" arg
(from the wiki: "Specifies the location of the persistence.xml file if
it is not in the same location as the source."), my persistence.xml is
in "src/main/resources/META-INF", but the enhancer doesn't like that
complete path, and it only works with "src/main/resources" (no
"META-INF"), which was unexpected. I think also an example for a
typical exploded development file structure would be nice to see in
addition to the one based on JARs.
Here's a relevant snippet from my Maven POM (hopefully it will come out
somewhat readable online), if anyone is interested. I'm no Ant guru,
but I found that adding ${basedir} to the paths made it work. I
commented out the alternative command-line-based invocation, which also
works fine.
<pre>
> <plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <id>JPA Enhancement</id>
> <phase>process-classes</phase>
> <configuration>
> <tasks>
> <taskdef
> name="weave"
> classname=" org.eclipse.persistence.tools.weaving.jpa.StaticWeaveAntTask "
> classpathref="maven.test.classpath"/>
> <weave
> loglevel="FINEST"
> source="${basedir}/target/classes"
> target="${basedir}/target/classes"
> persistenceinfo="${basedir}/src/main/resources">
> <classpath refid="maven.test.classpath"/>
> </weave>
>
> <!--
> <java classname="org.eclipse.persistence.tools.weaving.jpa.StaticWeave "
> classpathref="maven.test.classpath"
> fork="true">
> <arg
> line="-loglevel FINEST -persistenceinfo src/main/resources target/classes target/classes"/>
> </java>
> -->
> </tasks>
> </configuration>
> <goals>
> <goal>run</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
</pre>
Thanks,
Ari
Tom Ware wrote:
> Hi Ari,
>
> Some integration of EclipseLink's static weaving with Dali would be a
> good idea.
>
> What problems are you having with the docs? Are the problems you are
> seeing in the blog post listed above, or are they with the documents
> that blog post references on the EclipseLink wiki documenation site? If
> the docs on the wiki site have issues, I should be able to help.
> Otherwise, it is probably best to post a comment to the blog - since
> that is written by someone outside the EclipseLink development team.
>
> At the moment, we have not done any development work on specific-maven
> integration. We just provide an Ant task and a Java class you can use.
> If there is a way we can help you integrate what we have, let us know.
>
> -Tom
|
|
| | | | |
Goto Forum:
Current Time: Thu Sep 19 15:51:04 GMT 2024
Powered by FUDForum. Page generated in 0.07179 seconds
|