Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dali » Dali 2.2 Planning
Dali 2.2 Planning [message #435120] Wed, 10 December 2008 23:54 Go to next message
Neil Hauge is currently offline Neil HaugeFriend
Messages: 475
Registered: July 2009
Senior Member
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 #435121 is a reply to message #435120] Thu, 18 December 2008 00:42 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
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 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
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 #435123 is a reply to message #435121] Mon, 22 December 2008 21:03 Go to previous messageGo to next message
Neil Hauge is currently offline Neil HaugeFriend
Messages: 475
Registered: July 2009
Senior Member
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 #435125 is a reply to message #435123] Tue, 23 December 2008 00:15 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
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 #435127 is a reply to message #435125] Tue, 23 December 2008 19:16 Go to previous messageGo to next message
Tom Ware is currently offline Tom WareFriend
Messages: 17
Registered: July 2009
Junior Member
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 #435130 is a reply to message #435127] Fri, 26 December 2008 10:26 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
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 #435131 is a reply to message #435130] Mon, 05 January 2009 17:03 Go to previous messageGo to next message
Tom Ware is currently offline Tom WareFriend
Messages: 17
Registered: July 2009
Junior Member
Hi Ari,

I have made some updates to the wiki page. Hopefully they are helpful.
Re: Dali 2.2 Planning [message #435240 is a reply to message #435131] Fri, 16 January 2009 06:44 Go to previous messageGo to next message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Thanks Tom -- looks good! You might also want to add in that Maven
stuff I posted, as it would probably help a lot of Maven users get
EclipseLink static weaving working quickly.

Best regards,
Ari

Tom Ware wrote:
> Hi Ari,
>
> I have made some updates to the wiki page. Hopefully they are helpful.
>
Re: Dali 2.2 Planning [message #435465 is a reply to message #435120] Tue, 24 February 2009 18:55 Go to previous messageGo to next message
Susanta Datta is currently offline Susanta DattaFriend
Messages: 3
Registered: July 2009
Junior Member
We internally call the JPA's Entity generation wizard to generate
Entities from selected tables. Once the command executes we need to find
the java classes those get generated from the selected tables in the
wizard, so that we can generate other artifacts from the java classes. I
think the latest version of the wizard a data model is being used (which
is really good). It would be great if the followings features implemented:
1. Make the Dali Entity Wizard or command external so that other
components can reuse the Wizard or Command. We don't want to extend the
wizard, just reuse.
2. Expose the data model (removing any internal API) for the same reason
as mentioned above.
3. The data model to have a property to get/set the selected table in
wizard.

thanks.

Susanta
Re: Dali 2.2 Planning [message #435466 is a reply to message #435465] Thu, 26 February 2009 21:19 Go to previous message
Neil Hauge is currently offline Neil HaugeFriend
Messages: 475
Registered: July 2009
Senior Member
Susanta,

This request is similar to one logged in Enhancement 260474 -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=260474. It would be helpful
if you could provide this information in that bug so it can be tracked.

We are actually in the process of evaluating a new Entity Generation
contribution in bug 251293. As a result, things might be changing quite a
bit in Dali 2.2 (Galileo).

Neil


Susanta Datta wrote:

> We internally call the JPA's Entity generation wizard to generate
> Entities from selected tables. Once the command executes we need to find
> the java classes those get generated from the selected tables in the
> wizard, so that we can generate other artifacts from the java classes. I
> think the latest version of the wizard a data model is being used (which
> is really good). It would be great if the followings features implemented:
> 1. Make the Dali Entity Wizard or command external so that other
> components can reuse the Wizard or Command. We don't want to extend the
> wizard, just reuse.
> 2. Expose the data model (removing any internal API) for the same reason
> as mentioned above.
> 3. The data model to have a property to get/set the selected table in
> wizard.

> thanks.

> Susanta
Re: Dali 2.2 Planning [message #613699 is a reply to message #435120] Thu, 18 December 2008 00:42 Go to previous message
Ari Meyer is currently offline Ari MeyerFriend
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 Go to previous message
Ari Meyer is currently offline Ari MeyerFriend
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 #613704 is a reply to message #435121] Mon, 22 December 2008 21:03 Go to previous message
Neil Hauge is currently offline Neil HaugeFriend
Messages: 475
Registered: July 2009
Senior Member
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 #613712 is a reply to message #435123] Tue, 23 December 2008 00:15 Go to previous message
Ari Meyer is currently offline Ari MeyerFriend
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 #613714 is a reply to message #435125] Tue, 23 December 2008 19:16 Go to previous message
Tom Ware is currently offline Tom WareFriend
Messages: 17
Registered: July 2009
Junior Member
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 #613717 is a reply to message #435127] Fri, 26 December 2008 10:26 Go to previous message
Ari Meyer is currently offline Ari MeyerFriend
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 #613720 is a reply to message #435130] Mon, 05 January 2009 17:03 Go to previous message
Tom Ware is currently offline Tom WareFriend
Messages: 17
Registered: July 2009
Junior Member
Hi Ari,

I have made some updates to the wiki page. Hopefully they are helpful.
Re: Dali 2.2 Planning [message #613783 is a reply to message #435131] Fri, 16 January 2009 06:44 Go to previous message
Ari Meyer is currently offline Ari MeyerFriend
Messages: 136
Registered: July 2009
Senior Member
Thanks Tom -- looks good! You might also want to add in that Maven
stuff I posted, as it would probably help a lot of Maven users get
EclipseLink static weaving working quickly.

Best regards,
Ari

Tom Ware wrote:
> Hi Ari,
>
> I have made some updates to the wiki page. Hopefully they are helpful.
>
Re: Dali 2.2 Planning [message #614918 is a reply to message #435120] Tue, 24 February 2009 18:55 Go to previous message
Susanta Datta is currently offline Susanta DattaFriend
Messages: 3
Registered: July 2009
Junior Member
We internally call the JPA's Entity generation wizard to generate
Entities from selected tables. Once the command executes we need to find
the java classes those get generated from the selected tables in the
wizard, so that we can generate other artifacts from the java classes. I
think the latest version of the wizard a data model is being used (which
is really good). It would be great if the followings features implemented:
1. Make the Dali Entity Wizard or command external so that other
components can reuse the Wizard or Command. We don't want to extend the
wizard, just reuse.
2. Expose the data model (removing any internal API) for the same reason
as mentioned above.
3. The data model to have a property to get/set the selected table in
wizard.

thanks.

Susanta
Re: Dali 2.2 Planning [message #614920 is a reply to message #435465] Thu, 26 February 2009 21:19 Go to previous message
Neil Hauge is currently offline Neil HaugeFriend
Messages: 475
Registered: July 2009
Senior Member
Susanta,

This request is similar to one logged in Enhancement 260474 -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=260474 It would be helpful
if you could provide this information in that bug so it can be tracked.

We are actually in the process of evaluating a new Entity Generation
contribution in bug 251293. As a result, things might be changing quite a
bit in Dali 2.2 (Galileo).

Neil


Susanta Datta wrote:

> We internally call the JPA's Entity generation wizard to generate
> Entities from selected tables. Once the command executes we need to find
> the java classes those get generated from the selected tables in the
> wizard, so that we can generate other artifacts from the java classes. I
> think the latest version of the wizard a data model is being used (which
> is really good). It would be great if the followings features implemented:
> 1. Make the Dali Entity Wizard or command external so that other
> components can reuse the Wizard or Command. We don't want to extend the
> wizard, just reuse.
> 2. Expose the data model (removing any internal API) for the same reason
> as mentioned above.
> 3. The data model to have a property to get/set the selected table in
> wizard.

> thanks.

> Susanta
Previous Topic:Generating annotations in getters
Next Topic:Dali 2.1 is now available!
Goto Forum:
  


Current Time: Thu Sep 19 15:51:04 GMT 2024

Powered by FUDForum. Page generated in 0.07179 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top