Community
Participate
Working Groups
Rather than reopen bug 241042. Log4j has had new releases. Surely new releases should at least have sources? It is really inconvenient, not having a) a source attachment b) sources in CVS c) a link from readme to the Apache source CM
Notes to save anyone else wasting as much time as me. a) checkout org.apache.log4j from tools/org.eclipse.orbit b) switch to 1.2.15 branch c) download http://archive.apache.org/dist/logging/log4j/1.2.15/apache-log4j-1.2.15.zip d) switch off build automatically e) extract the src/main/java tree to the project root (class and java in same folder) f) change .classpath second line from <classpathentry exported="true" kind="lib" path=""/> to <classpathentry kind="src" path=""/> g) switch on build automatically again h) fix errors quick fixes do most things ending up with addition to manifest of Import-Package: javax.jms, javax.mail, javax.mail.internet, javax.management An awkward sun import does not want to quick fix so just delete org.apache.log4j.jmx from source and manifest
It might make sense to check whether the new Eclipse-SourceReferences Header can be used in the MANIFEST.MF for Orbit projects, such that projects consuming just the binaries can make it easy for end users to get to the source when needed. See http://download.eclipse.org/eclipse/downloads/drops/R-3.6-201006080911/eclipse-news-part4.html#importcvs For more information, please refer to the following: * http://wiki.eclipse.org/PDE/UI/SourceReferences * https://bugs.eclipse.org/bugs/show_bug.cgi?id=195729 * https://bugs.eclipse.org/bugs/show_bug.cgi?id=243582 While PDE Build can auto-generate the "Eclipse-SourceReferences" header, it looks like for Orbit projects, this would rather be specified manually, referring to the CVS branch in which the respective Orbit project resides.
Moving bugs out of the Inbox to bundle owners.
As with bug 241042, there's no plans to add source for log4j, for same reasons as mentioned in bug 241042. But, thanks for the "how to" info, Edward. I'm sure others will find it and find it helpful. Note, also, that source can be "attached" to a binary jar, which is good for viewing the source, java doc, or stepping through with a debugger ... at least when you do not have a need to re-compile or actually modify the source, in which case you'd need Edwards steps. To learn more about "attaching source", see http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/ref-properties-source-attachment.htm. (I haven't tried for this particular jar, but have for others and works pretty well). Martin, The use of Eclipse-SourceReferences would be a separate topic and would be a separate feature request. IMHO, though, I don't think it'd be that useful for Orbit bundles. I'm sure it would be in some cases, but in terms of need or magnitude, I think that's most useful when someone wants to "work with" the source such as to provide a patch. [Note: for this log4j case, and others, there's no source in cvs, so would not help any of the "missing sources" cases to have an Eclipse-SourceReference.] I think I recall seeing some p2 bugs/features about improving "also install source", which is what would be good for Orbit bundles, since we don't actually do the development. (sorry, don't have the numbers handy, but I'd search for things along that angle, if the need is just to make it easier to get source along with binaries). To be clear, I'm just marking as 'wontfix' simply to be open, honest, and explicit about what the plans are ... as I mentioned before, I'm sympathetic, but when it comes to doing "new" work ... there are so many other higher higher priorities.
Bug 241042 had been about adding source in order to aid debugging. According to bug 241042 comment 5, there can't be an "en block" effort to add sources, but these must be dealt with case-by-case. This is such a specific request. We agreed that having source in general is a good thing, but it must be specified in the CQ for IP reasons. In the log4j case, CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2555 requested "binary only". This brings up following questions: 1. Can we encourage people who bring in new 3rd party libs to bring those in with source from the start? If the CQ specifies "sourceandbinary" from the start, it's only minimal additional effort. I think that this should be the default, since it provides tangible value at very little extra effort. 2. For bundles that don't have source yet, how can interested, engaged Community Contributors help bringing in source? Process could be that (1) Contributor brings source into Orbit format as per instructions http://wiki.eclipse.org/Source_Bundles (2) Contributor attaches the source in Orbit-format, either as a patch or as a pre-built source bundle (I did this in bug 330848 for instance) (3) Committer opens CQ to add source (4) When approved, source gets added to Orbit. With step (2), Community can already leverage the work from Bugzilla attachment. The work for committers should be small enough with these preparations since the bundling, filtering is all done. I think we should open the door for contributors to help adding source. 3. For bundles where we cannot provide source (eg for legal reasons), how can we enhance the metadata such that source can be obtained automatically from 3rd party repositories. This directly relates to part (c) of the original comment #0. The SCM-SourceReferences: header is one option for doing so, although I agree it's problematic in the Orbit case where the original project is not in Eclipse format. Bug 326926 improves the situation for Eclipse; but It would require some testing to see whether it makes sense for Orbit. After all, we typically want sources just for debugging and not as a full-blown buildable project. Another option is in the recent Maven discussion, bug 283745 comment 165. If Orbit Manifest Markup can reference a Maven POM, that POM will have everything needed to obtain source, mailinglist, bugtracker etc info in a fashion that's much more organized than our current about.html. For log4j, http://repo1.maven.org/maven2/log4j/log4j/1.2.15/log4j-1.2.15.pom I'm not going to reopen this bug since I'm not the submitter. But Ed, I'd like to hear your thoughts and whether you'd be interested in contributing the source? Seems like we're missing a bugzilla state for "committers won't invest time into this, but contributions are still welcome". To me, the WONTFIX resolution gives the improession of "it's against our project goals and architecture, so we won't do this even if you contribute a fix". IMO that's the wrong message.
Once upon a time I recall a LATER or was it DEFER state, which seems to fit the case, although perhaps HELPWANTED might avoid a infinite loop. The lack of log4j sources was a major pain while I was in a novice state trying to figure out why my log4j configuration refused to do what I wanted. I've got past/side-stepped that state so today this is very low down my priorities. When I come back to sorting out logging, I may well follow your steps. Since, at least for a significant number of modeling projects, log4j is used as part of the platform, I think sources are 'required'. Reopening as an enhancement.
Instructions for Orbit Source Bundles are actually here: http://wiki.eclipse.org/Orbit_Bundle_Checklist#Create_a_Source_Bundle And, on 2nd thought, I do think that an SCM-SourceReferences: header should be helpful for Orbit bundles when a source bundle exists. Consumers which only have the binary from Orbit can use this to get the original Orbit branch from CVS into their workspace, and with it the source bundle.
Created attachment 184528 [details] Source bundle Attached source bundle should be usable with Eclipse as-is (untested). Please test and provide feedback. The jar was generated from http://repo2.maven.org/maven2/log4j/log4j/1.2.15/log4j-1.2.15-sources.jar by - adding about.html - Moving META-INF/NOTICE and META-INF/LICENSE into about_files/ - adding plugin.properties - adding build.properties - Replacing META-INF/MANIFEST.MF with Orbit variant This Jar can be unzipped for IP Review of sources. When committing into Orbit, the JAR only needs to be extracted into a folder named "source-bundle" in the log4j project. Then, the .classpath file must be modified to register the source bundle and the Orbit Feature needs to register the source-bundle.
To install the JAR for testing, just copy into dropins/ of your Eclipse. From that point on, debugging into log4j binaries should bring up source.
PS: the JAR contains a couple images which could be removed to save space.
I have filed bug 331827 requesting to generate the "Eclipse-SourceReferences" header in Orbit. Note that this will only help the concrete situation if the respective source code has been checked in for Orbit. It won't help retrieving source code from repositories outside Eclipse - that's a completely different and much more complex story, where (again) I find the Maven approach most promising.
I never meant to say contributions weren't welcome ... just since it was assigned to me, and I wasn't going to do it ... but I'll assign to Martin. Thank you both.
The attachment seems good when just dropped in to 3.6.1 Windows Vista as org.apache.log4j.source_1.2.15.v201005080500.jar (rather than attachment.cgi - thank you Firefox). I can navigate, browse, set breakpoints etc. (I thought dropins were deprecated these days, but it works.) Thanks.
Released the Fix >= I20101207 (Indigo M5).
(In reply to comment #14) > Released the Fix >= I20101207 (Indigo M5). Where is the fix? I'm using M5 but am again source-less and the earlier attachment is now old P2-wise.
Hi Ed, Looking at Orbit http://download.eclipse.org/tools/orbit/downloads/drops/S20110304120314/ I see that source is being provided for log4j v1.2.15 (the latest) but not 1.2.13 nor 1.2.8 (the older versions). It will be up to the project using or bundling log4j (not sure where you get it from) to include the source bundle as well as the binary bundle from Orbit when they do their builds.
