[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dali-dev] Storing connection information
|
Shaun,
In both cases there'd be a problem. In case #1, the problem would be
something like "No connection defined for "TestPetStoreDataSource"". In
case #2, the problem would be more like "No connection defined." The
first would simply be a bit more descriptive or leading than the second.
In Dali 1.0, both scenarios would be configured in the same way.
There'd be an option on the install wizard page to set the connection,
and there'd be a project properties page as well. For the user, aside
from the "team" ramifications, the solutions would be identical.
- Paul
Shaun Smith wrote:
Hi Paul,
Can you clarify #2? What do you mean by "They would still get a
problem prompting them to set up a connection for a JPA project, but
wouldn't get a naming clue about what the connection should be"? In
Dali 1.0, how would this connection be visible to a developer when
creating a project/adding the JPA facet or when checking source out of
source control?
Shaun
Paul Fullbright wrote:
Hello all,
We had some discussions in our daily dev meeting about where to store
various project settings. Currently we have two such settings: JPA
platform and DTP connection. Since the JPA platform is such an
important part of the definition of a project, similar to a facet, we
decided that it should be stored as part of the project's resources
in the .settings folder, similar to how facets are stored. But the
DTP connection is a bit different. There are three standard places
that information can be stored in eclipse: as a workspace-wide
preference, as a project-specific workspace preference, or as a
project-specific setting (as we decided to store the JPA platform).
We'll be storing a reference (a String) to a DTP connection, which is
defined and stored by DTP plugins in the workspace-wide preferences.
It makes sense to store DTP connections that way, since they're not
really associated with any project in particular, but since our
reference is most definitely project-specific, we ruled out the
workspace-wide preference route. We are still somewhat in doubt
about whether to store this information as a project-specific setting
or a project-specific workspace preference. The two methods are
outlined below.
1) Project-specific setting: Information stored in this method are
shared among team members (that is, they are part of the project's
resources). WTP facets and JDT-specific settings are commonly stored
here. Storing our reference string here would signal to users that
they should set up a DTP connection by a certain name. (for example,
"TestPetStoreDataSource") It would also mean that in order to change
the connection (such as for test-validating against a deployment data
source) a user would have to edit the actual DTP connection instead
of switching to a different DTP connection (that is, if they didn't
want to be out of synch with the shared project.)
2) Project-specific workspace preference: Information stored in this
method is not shared among team members. It exists for one project
in one workspace. This mechanism is most commonly used for storing
overridden workspace preferences, such as those for java coding style
or WTP validators, but it is also the primary mechanism for storing
such things as the cvs repository for a project. If we stored our
connection reference string here, it would allow users to specify
their own DTP connection names. They would still get a problem
prompting them to set up a connection for a JPA project, but wouldn't
get a naming clue about what the connection should be. However,
they'd be able to switch between DTP connections (or use existing
ones) without having to edit the information within the DTP
connections themselves.
I think we're generally leaning in the direction of #2, but we wanted
to get some community feedback on this.
--
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
