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