[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipselink-dev] Expanding 'standards' for build files.
|
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
