Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Expanding 'standards' for build files.

Perhaps Eric can clarify but I did not see that he proposed a <name>.dir for every single jar file.
--Gordon

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
  

Back to the top