Bug 1182346

(In reply to Alon Bar-Lev from comment #0)
> Hi,
> 
> Without versionless symlink there cannot be usage of:
> 
> $ build-classpath log4j12.jar
> 

JAR and POM files in compatibility packages, like log4j12, MUST be versioned.
See: http://fedoraproject.org/wiki/Packaging:Java#Compatibility_packages

build-classpath works when full version is given:

$ build-classpath log4j-1.2.17
/usr/share/java/log4j-1.2.17.jar

$ build-classpath log4j12-1.2.17
/usr/share/java/log4j12-1.2.17.jar

how is it related to pom?

so basically what you claiming that for the reason of maven introduction the BuildRequires must be a specific version?

this is a change in behavior.

as you can see there are many packages who kept the behavior in /usr/share/java and still enables build dependency on package without specific version and usage of build-classpath.

A /usr/share/java/log4j12.jar symlink to /usr/share/java/log4j12-1.2.17.jar is really needed. I think this is required by fedora packaging guidelines.

Could this issue be solved within the upcoming days?
This issues blocks providing of Spacewalk on Fedora21.

(In reply to Tomas Lestach from comment #3)
> A /usr/share/java/log4j12.jar symlink to /usr/share/java/log4j12-1.2.17.jar
> is really needed. I think this is required by fedora packaging guidelines.
> 
> Could this issue be solved within the upcoming days?
> This issues blocks providing of Spacewalk on Fedora21.

see 1182346#c1

please see c#0, c#2, c#3, or at least explain why we build-classpath should use explicit z-stream.

Sorry, but this for me is not an issue, as explained by Mikolaj.
You can use log4j 2.x, provides log4j-1.2-api.jar, log4j.jar.
There are very few packages which have compatibility problem with this latest release of the apache logging library. In the near future we remove log4j12 from the distribution. We encourage to port your project to the newer log4j library.

(In reply to Alon Bar-Lev from comment #5)
> please see c#0, c#2, c#3, or at least explain why we build-classpath should
> use explicit z-stream.

We (package maintainers of log4j12) have triaged this ticket and we decided that it's not a defect in log4j12. If don't agree then you can escalate to FESCo. Otherwise please don't reopen this ticket.

Red Hat Bugzilla is not an avenue for technical assistance or support, but simply a bug tracking system. If you want to discuss or ask questions about implementation of "compat packages" in Fedora you can write to java-devel mailing list or ask on IRC.

Nobody asked for support. This is a pure bug. You can ignore it, but please do not state that anyone asking you support questions nor asking for technical assistance.

Closing this per maven behavior to effect non maven based packages is simply incorrect, as it has nothing to do with maven.

Arguing that you do not want to support log4j12 makes somewhat more sense, but as long as the package is there, no reason why not to enable to actually use it.

(In reply to Alon Bar-Lev from comment #8)
> Nobody asked for support. This is a pure bug. You can ignore it, but please
> do not state that anyone asking you support questions nor asking for
> technical assistance.

Yes, you have, in comment #7 ("explain why we build-classpath should
use explicit z-stream")

> Closing this per maven behavior to effect non maven based packages is simply
> incorrect, as it has nothing to do with maven.

Nobody besides you have mentioned Maven in this ticket.

> Arguing that you do not want to support log4j12 makes somewhat more sense,
> but as long as the package is there, no reason why not to enable to actually
> use it.

build-classpath works with log4j12 as expected - I tested it before closing the ticket. Explaining why it is expected to work like that is out of scope for Bugzilla.

(In reply to Mikolaj Izdebski from comment #1)
> JAR and POM files in compatibility packages, like log4j12, MUST be versioned.
> See: http://fedoraproject.org/wiki/Packaging:Java#Compatibility_packages

^^^^^^^^^^^^^^^^^ POM == maven.

> build-classpath works with log4j12 as expected

build-classpath DOES NOT works with log4j12 as expected as it should work without explicit version just like any other jar, using (per comment#0):

$ build-classpath log4j12.jar

Hence bug still valid.

(In reply to Alon Bar-Lev from comment #10)
> (In reply to Mikolaj Izdebski from comment #1)
> > build-classpath works with log4j12 as expected
> 
> build-classpath DOES NOT works with log4j12 as expected as it should work
> without explicit version just like any other jar, using (per comment#0):
> 
> $ build-classpath log4j12.jar
> 

I think what Mikolaj meant was that build-classpath works for log4j12 *package* as expected. And I agree with him.
However, I think it's a bit unfortunate that log4j12 package only provides symlink for very specific version of log4j 1.x.

I think it would be good to create more generic symlinks for whatever 1.x version of log4j we have in Fedora.

Something like:
log4j-1.2.jar
or even:
log4j-1.jar

Then you could modify your spec file to use:
build-classpath log4j-1
and you would always get some log4j 1.x, regardless of specific minor version (1.2.17, 1.2.18,...)

What do you guys think?

> $ build-classpath log4j-1.2.17
> /usr/share/java/log4j-1.2.17.jar
> 
> $ build-classpath log4j12-1.2.17
> /usr/share/java/log4j12-1.2.17.jar

This is nice, but I really cannot hardcode the version for all my dependencies, especially if I have over 40 of them. I'd need to update the configuration with every new package release/version as the previous one gets removed from the Fedora21 repo.
We maintain our project on RHEL5, RHEL6, RHEL7 and two latest Fedora versions and I really cannot hardcode any package/jar versions there.

What is the problem with adding an extra symlink?
/usr/share/java/log4j12.jar -> /usr/share/java/log4j12-1.2.17.jar

(In reply to Tomas Lestach from comment #12)
> > $ build-classpath log4j-1.2.17
> > /usr/share/java/log4j-1.2.17.jar
> > 
> > $ build-classpath log4j12-1.2.17
> > /usr/share/java/log4j12-1.2.17.jar
> 
> This is nice, but I really cannot hardcode the version for all my
> dependencies, especially if I have over 40 of them. I'd need to update the
> configuration with every new package release/version as the previous one
> gets removed from the Fedora21 repo.
> We maintain our project on RHEL5, RHEL6, RHEL7 and two latest Fedora
> versions and I really cannot hardcode any package/jar versions there.

"log4j" is latest version in Fedora (currently 2.x).  We can add a symlink "log4j-1" which would point to latest log4j from 1.x line.

> What is the problem with adding an extra symlink?
> /usr/share/java/log4j12.jar -> /usr/share/java/log4j12-1.2.17.jar

It would violate packaging guidelines and break different tools (javapackages-tools, xmvn) that are built on assumption that compatibility JARs are always versioned.

All right.

> We can add a symlink
> "log4j-1" which would point to latest log4j from 1.x line.

This would help me. Shall I create a separate BZ or can we handle it within this one?
Thank you.

(In reply to Tomas Lestach from comment #14)
> All right.
> 
> > We can add a symlink
> > "log4j-1" which would point to latest log4j from 1.x line.
> 
> This would help me. Shall I create a separate BZ or can we handle it within
> this one?

I've just implemented this in rawhide (F-22) in log4j12-1.2.17-8. If you need this in older Fedora too then please open a new feature request.

(In reply to Mikolaj Izdebski from comment #15)
> I've just implemented this in rawhide (F-22) in log4j12-1.2.17-8. If you
> need this in older Fedora too then please open a new feature request.

Thank you.
I opened Bug 1185297.

I ask you again not to change status of this bug.

(In reply to Mikolaj Izdebski from comment #17)
> I ask you again not to change status of this bug.

why not a bug if was fixed as requested - no full version? not important if you set it to log4j12 log4j-1 or any without explicit z-stream version.

do you want me to open yet another bug so bugzilla actually reflect the reality?

anyway, it is not important as long as you fix this issue.

it could have been nicer process.

(In reply to Alon Bar-Lev from comment #18)
> (In reply to Mikolaj Izdebski from comment #17)
> > I ask you again not to change status of this bug.
> 
> why not a bug if was fixed as requested - no full version? not important if
> you set it to log4j12 log4j-1 or any without explicit z-stream version.

This bug was about adding *versionless* symlink, which is not going to happen. CLOSED/NOTABUG is the right status for this bug.

> do you want me to open yet another bug so bugzilla actually reflect the
> reality?

Different bugs or requests should have separate bugs open. There is already an open RFE to add log4j-1.jar symlink (bug #1185297) so you can use reference this one if that's what you wand. Otherwise you can open a new bug.

(In reply to Mikolaj Izdebski from comment #19)
> (In reply to Alon Bar-Lev from comment #18)
> > (In reply to Mikolaj Izdebski from comment #17)
> > > I ask you again not to change status of this bug.
> > 
> > why not a bug if was fixed as requested - no full version? not important if
> > you set it to log4j12 log4j-1 or any without explicit z-stream version.
> 
> This bug was about adding *versionless* symlink, which is not going to
> happen. CLOSED/NOTABUG is the right status for this bug.
> 
> > do you want me to open yet another bug so bugzilla actually reflect the
> > reality?
> 
> Different bugs or requests should have separate bugs open. There is already
> an open RFE to add log4j-1.jar symlink (bug #1185297) so you can use
> reference this one if that's what you wand. Otherwise you can open a new bug.

these are all the same issue, you just made it very difficult. a build-classpath without explicit version was requested it was the reason this bug was opened, you could have suggested any other versionless, fix it without require any other bug.

just like a bug was opened and problem determination suggested technical description is somewhat different than reported, you do not make customer file yet another bug.

but as I wrote previously, it is not important whatever works for you... as long as we can port packages into fc21.

thank you for your cooperation.