[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-dev] Expanding 'standards' for build files.
|
Hi Eric,
Just like you define property pair <name>.lib and <name>.jar for every
single jar file, I define property pair <name>.dir and <name>.lib for
every single jar file. In the case you show here, the property pair
are junit.dir and junit.lib, overwiteing junit.dir won't effect other
dependencies at all.
-Edwin
On 2009-11-27, at 7:35 PM, Eric Gwin <eric.gwin@xxxxxxxxxx> wrote:
Edwin,
That is exactly what I meant by "forces an assumption of the
directory". I'll illustrate what I'm talking about below:
The scenarios below assume the use of ${user.home}/build.properties
and/or ${user.home}/test.properties for variable redefinition (as is
currently the standard).
If I check for say ${external.depend.dir}/${junit.lib} as you
suggest, the junit jar will ONLY be found in ${external.depend.dir},
so if you want to use JUnit in say "C:\__mydeps\junit45" with a
jarname of "junit-4.5.jar" where the default name is "junit.jar",
you'd not only have to redefine ${junit.lib} to be "junit-4.5.jar",
but you'd also have to set ${external.depend.dir} to be "C:\__mydeps
\junit45", which would also force all other dependencies that use
that dir to be searched for in that location as well.
By using the three variable standards I suggested (.jar, .lib,
and .dir) I can do what I want easily and with one line:
junit.lib=C:\__mydeps\junit45\junit-4.5.jar
${external.depend.dir} is unaffected (so the rest of my dependencies
can come from the default location, or I could set it to:
external.depend.dir=C:\__mydeps
and the rest of my dependencies would come from there independent of
the lib definition. It is true, that ${junit.jar} would be set to
the default of "junit.jar" but I don't care because the paths and
the dependency checks will use ${<name>.lib} as will all log and
error messages.
At any rate, I don't want to belabor the point, and you have already
stated you have no real preference. Therefore, for the ease of use
and flexibility described above I continue to put forward my
original proposal.
Are there any other questions, or suggestions from the community?
-Eric
Edwin Tang wrote:
You can check for the existence of <name>.dir/<name.lib>.
<name>.dir can ony specify one location, but <name>.lib in your
proposal can only point to one library too.
-Edwin
-----Original Message-----
From: Eric Gwin Sent: Friday, November 27, 2009 12:39 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Expanding 'standards' for build files.
No it doesn't, because you cannot check for the existence of a
jarname only. It is associated with a path (if nothing else "."),
Therefore the check for the file forces an assumption of the
directory which is inherently limiting. Also your scenario removes
the possibility of storing one dependency in a separate location
(say for one-off testing of a dependency change).
-Eric
Edwin Tang wrote:
The example code using the other option is like:
common.plugin.dir=./plugins
external.depends.dir=../external.lib
junit.lib=junit-4.5.jar
junit.dir=${external.depends.dir}
after testing for existence of junit.lib and others...
<path pathref="external.compile.deps.path">
<pathelement ="${junit.dir}/${junit.lib}/>
<pathelement="${jdbc.dir}/${jdbc.lib}"/>
...
</path>
It looks like there are no differences but personal preferences.
Either option is fine for me.
Thanks,
Edwin
-----Original Message-----
From: Eric Gwin Sent: Friday, November 27, 2009 10:46 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Expanding 'standards' for build
files.
So if you want to say use "junit.jar" as the filename, you only
need to redefine ${junit.jar}, if you want a different directory
to hold all your dependencies you only need to redefine $
{external.depends.dir}, and if you want to do both and use a
custom named xdb-11-rel2.jar, in a completely seperate location
with the previous setup you could simply add a redefinition of $
{xdb.lib}.
-Eric
Eric Gwin wrote:
It doesn't. It's more like: (values are just for example...):
common.plugin.dir=./plugins
external.depends.dir=../external.lib
junit.jar=junit-4.5.jar
junit.lib=${external.depends.dir}/${junit.jar}
after testing for existence of junit.lib and others...
<path pathref="external.compile.deps.path">
<pathelement ="${junit.lib}/>
<pathelement="${jdbc.lib}"/>
...
</path>
That minimal redefinitions need to be made for jar names or dirs
if they are customized, and jars can be grouped together, or in
different dirs, as required by the developer/user. However, the
defined location can still be tested for (verify it is found),
before it is added to a classpath (which in many cases will cause
errors if it doesn't exist).
-Eric
Edwin Tang wrote:
Hi Gordon,
If the proposal includes a plan to introduce <name>.dir for
every single jar file, then there are no substantial differences
between these 2 options.
Thanks,
Edwin
-----Original Message-----
From: Gordon Yorke Sent: Friday, November 27, 2009 9:34 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Expanding 'standards' for build
files.
I prefer Eric's proposal for <name>.jar, <name>.lib and <name>.dir
--Gordon
Edwin Tang wrote:
Hi Eric,
This is great initiative.
Probably, instead of <name>.jar, <name>.lib and <name>.path, it
could better that we have
<name>.dir: the location of a jar file
<name>.lib: a jar file name
<name>.path: a path element defined by <pathelement path="$
{<name>.dir}/${<name>.lib}"/>
The benifits of this option are:
1. Users have full flexibility to able to customize <name>.dir,
<name>.lib, or both for every single jar file
2. Avoid the difficulty to choose a sound property name -
<name>.jar or <name>.jarfile
3. Be consistent with the TopLink test/build naming conventions
Thanks,
Edwin
-----Original Message-----
From: Eric Gwin Sent: Thursday, November 26, 2009 8:06 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Expanding 'standards' for build files.
Hi,
I'm sending this out as a notification/proposal of some
additional standard conventions I plan on adding to our build
files after the branch.
- properties ending in .jar define jarfile names only (no
path)
- properties ending in .lib are fully qualified jars (path
and filename)
- properties ending in .dir are directory paths
- properties ending in .path are path refid names
(classpath fragments)
- targets beginning with test- are reserved for high level
test targets,
and are used in test results parsing
- targets typically use the form <action>-<object>-<type>
(ie. package-bundle-zip)
Some are clarifications of standards already in place, but not
well publicized. However, with regard to .jar/.lib
and .dir/.path there is no current standard, and properties are
named and used in a fairly random mostly interchangeable way.
There are many reasons this is becoming an issue now, but here
are the biggest:
- bugs requesting the use of minimal classpaths necessitate
the need to individually
define libraries. However, the build has multiple entry
points so paths to those
libraries are relative to the entry point. So the need to
separate path from jar name.
- adding individual libraries (rather than
eclipselink.core.depend or eclipslink.oracle.depend
which list them all) also creates a need to separately
define directories and classpath subsets.
For the most part I've tried to keep the usage most prevalent
for each postfix
-.lib was mostly used to define full paths to jars, while .jar
mostly defined jar names. However,
there are also a few non-conformant properties (eclipselink.jar.name
and .jarfile)
-.dir really hasn't changed at all, but there were a few uses
where it was a defining a pathref
-.path is pretty much new old pathrefs were either .dir
or .classpath
While I needed to implement these changes for the oracle
modules for critical fixes in 2.0.0, I plan on implementing
these changes across the board after the branch and discussion
has occurred.
Does anyone object to these standards, or have preferences
other than what I plan to implement? I can see .jarfile being
used as the standard postfix because the property can't easily
be confused with a static usage of a jar, but it wasn't
routinely used.
Comments? (If I hear nothing from you I will assume it is
assent, and continue as outlined after the branch is complete.)
-Eric
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev