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