Mailing List Archive

On Fri, 2002-01-25 at 06:53, Erik Hatcher wrote:
> Lucene-dev,
>
> I have a suggestion/request for future distributions of Lucene - could the
> JAR filename be made simply lucene.jar rather than including the full
> version number? The distribution (.zip/.tar, and the embedded root
> directory name) contain the version number already.
>
> Most Jakarta projects currently do it differently that Lucene's current
> procedure, so I'm not proposing anything unusual.
>

IMHO They are wrong.

> By naming the JAR with the version, it makes it more difficult to switch to
> using a new version of Lucene because the build procedure has to be updated
> in some way to switch to the new file name.
>
> Are there strong opinions/reasons to not make this adjustment?
>
> Erik
>
>

-1.. Yes.. Think of the situation where you have two unknown versions
of the jar... It is very easy to cause the java version of DLL hell.
Yet by simply looking at the jar in your classpath or web container you
can see which one to zap or rename to mud.

This doesn't solve the problem but it sure as heck makes it obvious.

-Andy

>
> --
> To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

From: "Andrew C. Oliver" <acoliver@apache.org>
> > Most Jakarta projects currently do it differently that Lucene's current
> > procedure, so I'm not proposing anything unusual.
> >
>
> IMHO They are wrong.

:) At least we all have our own strong opinions on this issue.

> -1.. Yes.. Think of the situation where you have two unknown versions
> of the jar... It is very easy to cause the java version of DLL hell.
> Yet by simply looking at the jar in your classpath or web container you
> can see which one to zap or rename to mud.
>
> This doesn't solve the problem but it sure as heck makes it obvious.

Version information can be embedded inside the JAR as a properties file or
in the manifest, so its would be easily identifiable.

I certainly can see both sides of this issue, but my overriding thoughts are
that upgrading to a new version of Lucene should be as easy as pointing a
build to a new directory and not dealing with JAR file name changes too. I
believe classpaths should be tightly controlled and using Ant this means
that a <path> is constructed pointing to exact JAR files (and not to include
"*.jar").

Suppose I have a project that is using Lucene and, of course, is using an
Ant build. How should my build be flexible enough to handle the upgrade of
a new version of Lucene without the build file itself having to be modified?
I'm curious how you handle this situation. I have a technique that I've
developed that works nicely, even with Lucene's scheme (because at least its
JAR file name is the same as distribution directory name) but it works even
nicer with JAR's named the same.

Erik



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

On Fri, 2002-01-25 at 08:15, Erik Hatcher wrote:
> From: "Andrew C. Oliver" <acoliver@apache.org>
> > > Most Jakarta projects currently do it differently that Lucene's current
> > > procedure, so I'm not proposing anything unusual.
> > >
> >
> > IMHO They are wrong.
>
> :) At least we all have our own strong opinions on this issue.
>
> > -1.. Yes.. Think of the situation where you have two unknown versions
> > of the jar... It is very easy to cause the java version of DLL hell.
> > Yet by simply looking at the jar in your classpath or web container you
> > can see which one to zap or rename to mud.
> >
> > This doesn't solve the problem but it sure as heck makes it obvious.
>
> Version information can be embedded inside the JAR as a properties file or
> in the manifest, so its would be easily identifiable.
>
> I certainly can see both sides of this issue, but my overriding thoughts are
> that upgrading to a new version of Lucene should be as easy as pointing a
> build to a new directory and not dealing with JAR file name changes too. I
> believe classpaths should be tightly controlled and using Ant this means
> that a <path> is constructed pointing to exact JAR files (and not to include
> "*.jar").
>
> Suppose I have a project that is using Lucene and, of course, is using an
> Ant build. How should my build be flexible enough to handle the upgrade of
> a new version of Lucene without the build file itself having to be modified?
> I'm curious how you handle this situation. I have a technique that I've
> developed that works nicely, even with Lucene's scheme (because at least its
> JAR file name is the same as distribution directory name) but it works even
> nicer with JAR's named the same.
>

I'm not quite as familiar with POI's new Apacheized (we've adapted the
same standard build as Avalon, Cocoon and other projects with minor
improvements), but until recently at least we've used a command line
parameter.

I'll have a different opinion on this once there is *real* versioning
introduced into the jar/jdk. (I could have sworn I saw a JSR on this),
until then... I like knowing what I have just by looking at it.

-ACO

> Erik
>
>
>
> --
> To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

----- Original Message -----
From: "Andrew C. Oliver" <acoliver@apache.org>

> I'm not quite as familiar with POI's new Apacheized (we've adapted the
> same standard build as Avalon, Cocoon and other projects with minor
> improvements), but until recently at least we've used a command line
> parameter.
>
> I'll have a different opinion on this once there is *real* versioning
> introduced into the jar/jdk. (I could have sworn I saw a JSR on this),
> until then... I like knowing what I have just by looking at it.

Here's a more concete example. How would you go about upgrading to JUnit
3.7 for Lucene builds? (I see that version 3.5 is whats there now by the
filename, which must have been renamed from the JUnit distribution)

The only way possible now (without risking class clashes) is to put the
version 3.7 JAR into the lib directory and remove the 3.5 version JAR.
Correct?

This is whats in Lucene's build.xml:

<path id="junit.classpath">
<pathelement location="${junit.classes}" />
<pathelement location="${build.classes}"/>
<fileset dir="lib">
<include name="*.jar" />
</fileset>
<pathelement path="${java.class.path}" />
</path>

What I do is have properties pointing to each individual JAR file -
${junit.jar} for example, and construct <path>'s from those rather than
"*.jar" inclusion.

I am able to simply flip a switch for my builds to get to a new version of
Lucene:

ant -Dlucene.version=1.2-rc3-dev

and then everything else would adjust from there. Again, my scheme works
"ok" with Lucene since the directory and JAR have the same name. I was
merely making a suggestion based on my experience on how pulling in new
versions of Lucene could be a bit easier - but no big deal that its not
acceptable to lucene-dev.

But think about this issue in terms of Lucene's own build, and the JUnit JAR
situation above. Lucene's own build is not flexible enough to handle a new
version easily.

Erik



--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

On Fri, 2002-01-25 at 15:00, Paulo Gaspar wrote:
> Eric,
>
> I do not see why having the version in the name makes upgrading harder.
>

+1

> A developer can always decide to rename the luceneXXXX.jar to lucene.jar
> all the time he upgrades and there is no trouble with configuration
> anymore. The effort to do this is minimal.
>

+1

> OTOH, having the version showing makes checking what version I am using
> much faster if I am using something like Tomcat - where any jar placed
> in WEB-INF/lib is added to the servlet's "classpath". And renaming is
> in this case harder and error prone.
>

+1

> Have fun,

+1

> Paulo Gaspar
>
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
> > Sent: Friday, January 25, 2002 7:59 PM
> > To: Lucene Developers List
> > Subject: Re: Distributable JAR filename
> >
> >
> > ----- Original Message -----
> > From: "Andrew C. Oliver" <acoliver@apache.org>
> >
> > > I'm not quite as familiar with POI's new Apacheized (we've adapted the
> > > same standard build as Avalon, Cocoon and other projects with minor
> > > improvements), but until recently at least we've used a command line
> > > parameter.
> > >
> > > I'll have a different opinion on this once there is *real* versioning
> > > introduced into the jar/jdk. (I could have sworn I saw a JSR on this),
> > > until then... I like knowing what I have just by looking at it.
> >
> > Here's a more concete example. How would you go about upgrading to JUnit
> > 3.7 for Lucene builds? (I see that version 3.5 is whats there now by the
> > filename, which must have been renamed from the JUnit distribution)
> >
> > The only way possible now (without risking class clashes) is to put the
> > version 3.7 JAR into the lib directory and remove the 3.5 version JAR.
> > Correct?
> >
> > This is whats in Lucene's build.xml:
> >
> > <path id="junit.classpath">
> > <pathelement location="${junit.classes}" />
> > <pathelement location="${build.classes}"/>
> > <fileset dir="lib">
> > <include name="*.jar" />
> > </fileset>
> > <pathelement path="${java.class.path}" />
> > </path>
> >
> > What I do is have properties pointing to each individual JAR file -
> > ${junit.jar} for example, and construct <path>'s from those rather than
> > "*.jar" inclusion.
> >
> > I am able to simply flip a switch for my builds to get to a new version of
> > Lucene:
> >
> > ant -Dlucene.version=1.2-rc3-dev
> >
> > and then everything else would adjust from there. Again, my scheme works
> > "ok" with Lucene since the directory and JAR have the same name. I was
> > merely making a suggestion based on my experience on how pulling in new
> > versions of Lucene could be a bit easier - but no big deal that its not
> > acceptable to lucene-dev.
> >
> > But think about this issue in terms of Lucene's own build, and
> > the JUnit JAR
> > situation above. Lucene's own build is not flexible enough to
> > handle a new
> > version easily.
> >
> > Erik
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:lucene-dev-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

Eric,

I do not see why having the version in the name makes upgrading harder.

A developer can always decide to rename the luceneXXXX.jar to lucene.jar
all the time he upgrades and there is no trouble with configuration
anymore. The effort to do this is minimal.

OTOH, having the version showing makes checking what version I am using
much faster if I am using something like Tomcat - where any jar placed
in WEB-INF/lib is added to the servlet's "classpath". And renaming is
in this case harder and error prone.

Have fun,
Paulo Gaspar


> -----Original Message-----
> From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
> Sent: Friday, January 25, 2002 7:59 PM
> To: Lucene Developers List
> Subject: Re: Distributable JAR filename
>
>
> ----- Original Message -----
> From: "Andrew C. Oliver" <acoliver@apache.org>
>
> > I'm not quite as familiar with POI's new Apacheized (we've adapted the
> > same standard build as Avalon, Cocoon and other projects with minor
> > improvements), but until recently at least we've used a command line
> > parameter.
> >
> > I'll have a different opinion on this once there is *real* versioning
> > introduced into the jar/jdk. (I could have sworn I saw a JSR on this),
> > until then... I like knowing what I have just by looking at it.
>
> Here's a more concete example. How would you go about upgrading to JUnit
> 3.7 for Lucene builds? (I see that version 3.5 is whats there now by the
> filename, which must have been renamed from the JUnit distribution)
>
> The only way possible now (without risking class clashes) is to put the
> version 3.7 JAR into the lib directory and remove the 3.5 version JAR.
> Correct?
>
> This is whats in Lucene's build.xml:
>
> <path id="junit.classpath">
> <pathelement location="${junit.classes}" />
> <pathelement location="${build.classes}"/>
> <fileset dir="lib">
> <include name="*.jar" />
> </fileset>
> <pathelement path="${java.class.path}" />
> </path>
>
> What I do is have properties pointing to each individual JAR file -
> ${junit.jar} for example, and construct <path>'s from those rather than
> "*.jar" inclusion.
>
> I am able to simply flip a switch for my builds to get to a new version of
> Lucene:
>
> ant -Dlucene.version=1.2-rc3-dev
>
> and then everything else would adjust from there. Again, my scheme works
> "ok" with Lucene since the directory and JAR have the same name. I was
> merely making a suggestion based on my experience on how pulling in new
> versions of Lucene could be a bit easier - but no big deal that its not
> acceptable to lucene-dev.
>
> But think about this issue in terms of Lucene's own build, and
> the JUnit JAR
> situation above. Lucene's own build is not flexible enough to
> handle a new
> version easily.
>
> Erik
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>

> Eric,

Erik - with a "k".

> I do not see why having the version in the name makes upgrading harder.

It doesn't necessarily make it harder - but it seemed out of sync with other
Jakarta projects I'm familiar with although there is a discrepancy among
projects in how they deal with this issue.

No point in belaboring this issue since its been rejected by lucene-dev.

But if anyone cares to address the scenario I posed about Lucene's own build
upgrading to JUnit 3.7 I'd love to hear how you'd do it.

> A developer can always decide to rename the luceneXXXX.jar to lucene.jar
> all the time he upgrades and there is no trouble with configuration
> anymore. The effort to do this is minimal.

What I'm after is a way to pull in a dependency with no manual intervention
such as renaming files, but this is an issue bigger than lucene-dev, and I
apologize for opening this can of worms here. CJAN and JJAR are efforts to
accomplish this kind of thing and I've seen lots of talk about them on the
general/commons lists.

Erik


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

> Erik - with a "k".

Sorry Erik!

And I thought I was careful with name spelling, after having so many
people calling me Paolo instead of PaUlo.
=;o)


> What I'm after is a way to pull in a dependency with no manual
> intervention
> such as renaming files, but this is an issue bigger than lucene-dev, and I
> apologize for opening this can of worms here. CJAN and JJAR are
> efforts to
> accomplish this kind of thing and I've seen lots of talk about them on the
> general/commons lists.

Yes, I would say that the can of worms should be open at "general".

I have no great magic bullet idea that solves this issue but I agree that
we should find one.

Please "open the can" at general and lets get everybody thinking about
this. It is possible that guys like Sam Ruby (because of Gump), Geir
(because of CJan/JJar) or some of other veterans have a clearer idea
on how to solve this one.


Have fun,
Paulo


> -----Original Message-----
> From: Erik Hatcher [mailto:lists@ehatchersolutions.com]
> Sent: Friday, January 25, 2002 9:18 PM
> To: Lucene Developers List; paulo.gaspar@krankikom.de
> Subject: Re: Distributable JAR filename
>
>
> From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
>
> > Eric,
>
> Erik - with a "k".
>
> > I do not see why having the version in the name makes upgrading harder.
>
> It doesn't necessarily make it harder - but it seemed out of sync
> with other
> Jakarta projects I'm familiar with although there is a discrepancy among
> projects in how they deal with this issue.
>
> No point in belaboring this issue since its been rejected by lucene-dev.
>
> But if anyone cares to address the scenario I posed about
> Lucene's own build
> upgrading to JUnit 3.7 I'd love to hear how you'd do it.
>
> > A developer can always decide to rename the luceneXXXX.jar to lucene.jar
> > all the time he upgrades and there is no trouble with configuration
> > anymore. The effort to do this is minimal.
>
> What I'm after is a way to pull in a dependency with no manual
> intervention
> such as renaming files, but this is an issue bigger than lucene-dev, and I
> apologize for opening this can of worms here. CJAN and JJAR are
> efforts to
> accomplish this kind of thing and I've seen lots of talk about them on the
> general/commons lists.
>
> Erik
>
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>