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

[Edwin Tang <edwin.tang@xxxxxxxxxx>]

Hi Eric,

Just like you define property pair <name>.lib and <name>.jar for every  
single jar file, I define property pair <name>.dir and <name>.lib for  
every single jar file. In the case you show here, the property pair  
are junit.dir and junit.lib, overwiteing junit.dir won't effect other  
dependencies at all.

-Edwin




On 2009-11-27, at 7:35 PM, Eric Gwin <eric.gwin@xxxxxxxxxx> wrote:

> Edwin,
>
> That is exactly what I meant by "forces an assumption of the  
> directory". I'll illustrate what I'm talking about below:
>
> The scenarios below assume the use of ${user.home}/build.properties  
> and/or ${user.home}/test.properties for variable redefinition (as is  
> currently the standard).
>
> If I check for say ${external.depend.dir}/${junit.lib} as you  
> suggest, the junit jar will ONLY be found in ${external.depend.dir},  
> so if you want to use JUnit in say "C:\__mydeps\junit45" with a  
> jarname of "junit-4.5.jar" where the default name is "junit.jar",  
> you'd not only have to redefine ${junit.lib} to be "junit-4.5.jar",  
> but you'd also have to set ${external.depend.dir} to be "C:\__mydeps 
> \junit45", which would also force all other dependencies that use  
> that dir to be searched for in that location as well.
>
> By using the three variable standards I suggested (.jar, .lib,  
> and .dir) I can do what I want easily and with one line:
> junit.lib=C:\__mydeps\junit45\junit-4.5.jar
> ${external.depend.dir} is unaffected (so the rest of my dependencies  
> can come from the default location, or I could set it to:
> external.depend.dir=C:\__mydeps
> and the rest of my dependencies would come from there independent of  
> the lib definition. It is true, that ${junit.jar} would be set to  
> the default of "junit.jar" but I don't care because the paths and  
> the dependency checks will use ${<name>.lib} as will all log and  
> error messages.
>
> At any rate, I don't want to belabor the point, and you have already  
> stated you have no real preference. Therefore, for the ease of use  
> and flexibility described above I continue to put forward my  
> original proposal.
>
> Are there any other questions, or suggestions from the community?
>
> -Eric
>
>
> Edwin Tang wrote:
> > 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
> > _______________________________________________
> > 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