RE: [eclipselink-dev] Expanding 'standards' for build files.

[Edwin Tang <EDWIN.TANG@xxxxxxxxxx>]

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