Community
Participate
Working Groups
Wikitext ant tasks should use org.eclipse.ant.core.antTasks and org.eclipse.ant.core.extraClasspathEntries extension points so these tasks can be freely used in Eclipse. Attached patch is doing all the things to make the wikitext tasks available to ant editor completion and ant classpath is set so the tasks work. The patch is doing the following: 1. Extract ant tasks to a separate src_ant source folder. 2. Adds a custom builder to build the ant tasks library. 3. Adds all tasks to the org.eclipse.ant.core.antTasks and the new library to the org.eclipse.ant.core.extraClasspathEntries extension points. 4. Other project settings changes needed. This work is based on the org.eclipse.equinox.p2.publisher way of adding its ant tasks.
Created attachment 132824 [details] The patch
Thanks for the feature request and patch. Is there a way to do this without having a separate jar and source folder for the Ant tasks?
I don't know other way. I've looked at most p2 plugins and all of them are acting in this way. So even if it's not the cleanest way to do it, this should be a recognized pattern :).
I'm not sure that we can use the patch as-is. One of the key requirements of the org.eclipse.mylyn.wikitext.core project is that it can be used as-is without an Eclipse runtime by putting it on a Java classpath. Having jars inside the org.eclipse.mylyn.wikitext.core jar is a problem. The way I see it is we have a couple of ways to move forward: # the approach is modified such that the org.eclipse.mylyn.wikitext.core jar remains in its current form, or # a new plug-in is created What are your thoughts?
Created attachment 133015 [details] Second version
I've attached a new patch that just modifies plugin.xml. It seems to work but looks a little hack-ish because library is mandatory and it is just setting it to the current folder. I'm not sure whether this can cause some problems I haven't found. In case there are any problem I would be in favour of making a new plugin.
(In reply to comment #6) > I've attached a new patch that just modifies plugin.xml. It seems to work but > looks a little hack-ish because library is mandatory and it is just setting it > to the current folder. > I'm not sure whether this can cause some problems I haven't found. Nice, thanks! I've posted the question to the JDT newsgroup.
BTW, for future please create workspace-relative patches. They are much easier to apply.
reassigned to give Alexander credit
patch applied
Created attachment 133038 [details] mylyn/context/zip
apparently the classpath hack only works when self-hosting. See bug 276085
Unless we can workaround this classpath issue then I'm afraid that we'll have to remove this from 3.2. From bug 276085 it appears as if org.eclipse.ant.core.extraClasspathEntries of '.' is not acceptable except in a self-hosted environment.
You should put the ant task code into a separate output folder and built them into a separate jar file that is nested within the bundle jar file. You can find example into the JDT/Core bundle or inside the API tooling bundle. Let me know if you need more details.
(In reply to comment #14) > You should put the ant task code into a separate output folder and built them > into a separate jar file that is nested within the bundle jar file. > You can find example into the JDT/Core bundle or inside the API tooling bundle. > Let me know if you need more details. My first patch is doing exactly this but David said it's unacceptable because it prevents using wikitext outside of OSGi container. I'm really not sure what else can I do.
Didn't PDE build sole ths problem by using nested jars in a *folder* plugin, instead of a *jar* plugin? As an everyday Ant user, I agree that is it is important for the Ant community to be able to run Eclipse ant tasks out of Equinox. I had the same problem with PDE API Tools Ant tasks, where ant tasks are in a nested jar: cannot be used in standalone Ant. Thanks for the great Wiki Text anyway!
Thanks for the feedback. I've been considering creating a WikiText IDE plug-in to address this issue and bug 273013. Unfortunately it's a lot of work and would involve API breakage as per bug 273013 comment 4. Something to consider for after the Mylyn 3.2 release. What I was thinking is that the jars included in the WikiText stand-alone package would be included in the IDE plug-in. Of course an alternative that would resolve this issue but not bug 273013 would be to submit a patch to the Ant plug-in that allows a plug-in jar itself to be the classpath contribution to Ant. Whichever route we go, contributions in this area would be greatly appreciated.
(In reply to comment #14) > You should put the ant task code into a separate output folder and built them > into a separate jar file that is nested within the bundle jar file. > You can find example into the JDT/Core bundle or inside the API tooling bundle. > Let me know if you need more details. > Is there any rational behind this? Why can't Ant tasks come into their own plugin. I guess the Ant tasks are not used by the core plugin, so why is this organization not possible? : - *.core plugin - *.anttasks plugin, that depends on *.core plugin both without any nested jar. The plugin with Ant tasks would be a classic "POJO" jar with Equinox manifest.mf and plugin.xml. But it seems a lot of project are using the nested jar way you describe, so we can hope there were good reasons for this, can't we? ;-)
(In reply to comment #18) > Is there any rational behind this? Why can't Ant tasks come into their own > plugin. I guess the Ant tasks are not used by the core plugin, so why is this > organization not possible? : Considering that the WikiText plug-in jars can be used directly by Ant without modification, there's no reason why this cannot be done. I've created a feature request bug 278246
Created attachment 141439 [details] org.eclipse.mylyn.wikitext.core.patch Here's an updated patch.
Created attachment 141441 [details] org.eclipse.mylyn.wikitext.core.patch Here's an improved patch that adds a builder for the wikitext-ant.jar I think this is good enough now to warrant further testing from the community that it meets their needs.
Chris, thanks for the excellent patch. Unfortunately the patch suffers from the same problem as previous patches: WikiText plug-in jars cannot be put on the Ant classpath because they contain nested jars. In my opinion there's a lot of value in having the WikiText core bundle as a plain-old-jar which can be put on anyone's classpath both for Ant task usage and other stand-alone usage. This is how WikiText has been packaged since day one; changing it not only breaks backward compatibility, it adds unnecessary complexity. Unless there's a compelling reason to do otherwise it should stay that way. As far as I can see the best way to move forward on this issue is either to fix bug 278246, or to provide an _additional_ WikiText bundle (@org.eclipse.mylyn.wikitext.ide.core@?) that provides Ant tasks in a nested jar. That way the @org.eclipse.mylyn.wikitext.core@ bundle can remain in its current state, consumable by stand-alone WikiText users and Eclipse users alike.
(In reply to comment #22) > Chris, thanks for the excellent patch. > > Unfortunately the patch suffers from the same problem as previous patches: > WikiText plug-in jars cannot be put on the Ant classpath because they contain > nested jars. > > In my opinion there's a lot of value in having the WikiText core bundle as a > plain-old-jar which can be put on anyone's classpath both for Ant task usage > and other stand-alone usage. This is how WikiText has been packaged since day > one; changing it not only breaks backward compatibility, it adds unnecessary > complexity. Unless there's a compelling reason to do otherwise it should stay > that way. I understand the needs for backwards compatibility here. One compelling reason is that at its current state, wikitext is painful for people to use within the Eclipse . As a seasoned Eclipse developer, I was having issues in getting access to the ant tasks which I'm going. I'm used to things just being there as most Eclipse projects contribute their ant tasks for the ant.core extension points. > As far as I can see the best way to move forward on this issue is either to fix > bug 278246, or to provide an _additional_ WikiText bundle > (@org.eclipse.mylyn.wikitext.ide.core@?) that provides Ant tasks in a nested > jar. That way the @org.eclipse.mylyn.wikitext.core@ bundle can remain in its > current state, consumable by stand-alone WikiText users and Eclipse users > alike. Let me ponder this a bit.
Off the top of my head, one option could be to have wikitext.core be unpacked and people need to add it to their classpath along with the wikitext-ant.jar to get the ant tasks. That may meet the standalone case... but that's two jars still :/ Another thing I'm looking at is if the ant.core extension points support platform URLs... <extension point="org.eclipse.ant.core.extraClasspathEntries"> <extraClasspathEntry library="platform:/plugin/org.apache.ant/lib/ant.jar"> </extraClasspathEntry> </extension> Something to that effect.
*** Bug 286738 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > Off the top of my head, one option could be to have wikitext.core be unpacked > and people need to add it to their classpath along with the wikitext-ant.jar to > get the ant tasks. That may meet the standalone case... but that's two jars > still :/ > > Another thing I'm looking at is if the ant.core extension points support > platform URLs... > > <extension > point="org.eclipse.ant.core.extraClasspathEntries"> > <extraClasspathEntry > library="platform:/plugin/org.apache.ant/lib/ant.jar"> > </extraClasspathEntry> > </extension> > > Something to that effect. > You might want to take a look at org.eclipse.wst.xsl.core and particularly the xinclude.jar. The xinclude.jar file can be used within Eclipse or it can be used outside. Works quitewell. Chris the problem you have is that Eclipse is taking the wrong approach to it's usage of ant. It's a build anti-pattern to have to depend on the IDE to build. These documentation builds should not have to depend on Eclipse to build the docs. There are many cases where eclipse ant tasks could be useful outside of eclipse-headless as standalone tasks that don't depend on eclipse.
How does xinclude.jar get built? I don't see a builder for it. How does this work in ant standalone without AntRunner? If you provide details, maybe we can come to a good consensus on how to do this.
(In reply to comment #27) > How does xinclude.jar get built? I don't see a builder for it. > > How does this work in ant standalone without AntRunner? > > If you provide details, maybe we can come to a good consensus on how to do > this. > Right now I just export the jar, when I make a change to the Xinclude classes, and then include the jar in the lib. If you configure and tweak your automated builds, you can create the necessary jar during the build process. You then have two jars, one you include for the necessary Eclipse ANT integration in the lib.jar, and the other that is used external. So in the case of wiki text, you have your standalone jars now, and the jars in the lib folder. You may want a separate plugin for this and to keep it unpacked for easier access. In ant standalone you use a TaskDef (TypeDef) to make the task available. http://ant.apache.org/manual/CoreTasks/taskdef.html <taskdef classpathref="wikitext.classpath" resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties" /> The taskdef is a typdef which means it can take a classpath to point where to find the necessary jar. <taskdef classpathref="wikitext.classpath" resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties"> <classpath location="path/to/jar/file"/> <classpath location="more/paths/to/jar/file"/> </taskdef> This way you get the best of both worlds, it running within eclipse, and available as a jar. You could also point the external class to the appropriate plugins bin directory and reference the whole folder without refering to the jar.
If I understand this, the class files that represent the Ant task will be duplicated, one in the standalone ant jar (in the lib directory) and one in the bundle jar itself? If this is the case, I think we may have a winner.
(In reply to comment #29) > If I understand this, the class files that represent the Ant task will be > duplicated, one in the standalone ant jar (in the lib directory) and one in the > bundle jar itself? > > If this is the case, I think we may have a winner. > That is correct, or you could just keep the bundle unjarred, and access the wikitext.jar file in the lib directory of the bundle directly from the standalone ant instance.
Just thought of one more option. You will still need the lib directory and a jar in there, for Eclipse (why it requires this is beyond me), but you could just distribute the bundle jars, and reference those from standalone ant. Just create the taskdef and add the bundles to the classpath. Should work just the same. After all a bundle is just a jar with some manifest info.
(In reply to comment #31) > After all a bundle is just a jar with some manifest info. YES!! WikiText stand-alone simply uses the bundles as jars on the classpath. Simple and easy. > You will still need the lib directory and a jar in there, for Eclipse (why it > requires this is beyond me) Agreed. I've filed bug 278246 against Eclipse. From the bug: bq. several people watching but very little to no enhancement work planned for Platform Ant. Committers seem unwilling to work on it. > Just create the taskdef and add the bundles to the classpath. Should work just > the same. After all a bundle is just a jar with some manifest info. That is how WikiText is intended to be used: stand-alone (without Eclipse) using taskdefs. See http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html
All the eclipse extension point really does is add a taskdef to the lib. The wikitext jars could be added to a customTarget in a pde build, with the necessary task def, and made available with a reference where they can be found. The extension point just provides a convience method to create the necessary taskdef.
Created attachment 145285 [details] org.eclipse.mylyn.wikitext.core.patch An updated patch. The big changes are that the build.properties was updated to include src_ant in both the ant supporter jar and the bundle itself. Furthermore, the Eclipse-BundleShape header was added to the MANIFEST.MF to ensure that the bundle comes out in the directory shape instead of the jar shape. If there is a feature for wikitext.core, the feature should be updated to specify unpack=false Now, you should be able to use both wikitext as standalone and within Eclipse.
Let me know if this works for your David.
Created attachment 145328 [details] a candidate plug-in (sources) If I understand your patch correctly, the o.e.m.wikitect.core bundle jar could no longer be used as-is stand-alone. That's a major issue, since it would affect existing users of Mylyn WikiText (they'd have to reconfigure their classpath). For me that's a show-stopper. I hate to beat this one to death, but how about the attached? It involves creating a new bundle (plug-in) that contains the wikitext-ant.jar (which is why it can't be a patch).
Created attachment 145446 [details] org.eclipse.mylyn.wikitext.core.patch An updated patch that removes the Eclipse-BundleShape header This patch should have the bundle both work in standalone and within Eclipse. The only downside is the duplication of the ant task classes but that's something we live with to make things easier for Eclipse folks.
(In reply to comment #37) > Created an attachment (id=145446) > org.eclipse.mylyn.wikitext.core.patch Thanks for your great work! To be clear, any solution that involves nested jars in the wikitext.core bundle is not acceptable. Nested jars _are_ okay if we're putting them in a new bundle, as suggested in comment #36.
(In reply to comment #38) > (In reply to comment #37) > > Created an attachment (id=145446) [details] > > org.eclipse.mylyn.wikitext.core.patch > > Thanks for your great work! > To be clear, any solution that involves nested jars in the wikitext.core bundle > is not acceptable. Nested jars _are_ okay if we're putting them in a new > bundle, as suggested in comment #36. Why wouldn't nested jars work? It shouldn't break anything existing... we are simply duplicating the ant classes in the new nested JAR. One of the cases that I view nested jars OK is this specific case we're dealing with. For example, look how a p2 bundle deals with ant tasks via a nested jar: org.eclipse.equinox.p2.repository.tools
(In reply to comment #39) > Why wouldn't nested jars work? It shouldn't break anything existing... we are It's not that they won't work, it's that it breaks backward compatibility for users who are using the bundle as a normal jar on their classpath. The nested jar solution looks like the way to go, however I don't want to see nested jars in any of the _existing_ *.wikitext.*core bundles. I'm quite happy with nested jars as long as they are isolated to _new_ bundles.
(In reply to comment #40) > (In reply to comment #39) > > Why wouldn't nested jars work? It shouldn't break anything existing... we are > > It's not that they won't work, it's that it breaks backward compatibility for > users who are using the bundle as a normal jar on their classpath. How does it break backwards compatibility? Can you be specific, may I haven't had coffee this morning.
Actually, I don't see how nested jars are going to break existing implementations. The reason being is that when a standalone ant task is done, you just add the existing bundle jar with the nested jar in the lib folder included. The nested jar isn't even refrenced by the ant task. Existing users can still include the other bundle jars on the taskdef class path as necessary.
(In reply to comment #42) > Actually, I don't see how nested jars are going to break existing > implementations. The reason being is that when a standalone ant task is done, > you just add the existing bundle jar with the nested jar in the lib folder > included. Exactly, that's the point: they'll have to change their classpath. Currently all they need on their classpath is the bundle jars. What you're proposing is that they also have to add the nested jar to their classpath. I want to avoid such a burden unless there's a compelling reason to do otherwise.
(In reply to comment #43) > (In reply to comment #42) > > Actually, I don't see how nested jars are going to break existing > > implementations. The reason being is that when a standalone ant task is done, > > you just add the existing bundle jar with the nested jar in the lib folder > > included. > > Exactly, that's the point: they'll have to change their classpath. Currently > all they need on their classpath is the bundle jars. What you're proposing is > that they also have to add the nested jar to their classpath. I want to avoid > such a burden unless there's a compelling reason to do otherwise. > No, they just keep things as they are. The nested Jar is only for internal eclipse headless mode, and the extension point. Otherwise if it's used external they just use the bundle jars as is, as they are just jars. Try it out, instead of using your standalone jars, replace them with the bundle jars instead. Should still work the same.
I must have missed something. Let me take another look.
Here's what I missed before: even though the classes in src_ant are compiled by the external Ant script and jarred as a nested jar, they are _also_ included in the bundle jar. I've confirmed that this works by using the PDE manifest editor to export the bundle jar... it all seems to just work. I did some testing with a self-hosted Eclipse instance, and the Ant editor picked up the WikiText tasks nicely, however when running the Ant build script I got the following: pre. BUILD FAILED /Users/dgreen/Documents/mine/runtime-mylyn.wikitext/test2/build.xml:4: Problem: failed to create task or type wikitext-to-html Cause: The name is undefined. Action: Check the spelling. Action: Check that any custom tasks/types have been declared. Action: Check that any <presetdef>/<macrodef> declarations have taken place. What am I missing? I looked at the classpath under Preferences->Ant->Runtime and the classpath entry was there -- however looking at the external tool configuration classpath I can't see the contributed jars. And the last remaining question.... (drum roll) does this work with the headless build?
Created attachment 145881 [details] workspace preferences screenshot of my self-hosted Eclipse workspace preferences (Ant runtime)
Created attachment 145882 [details] external tool configuration I don't see the classpath contributions in the external tool configuration
btw, sorry this one has taken so long but it's important to get it right!
Created attachment 145883 [details] wikitext sdk javadoc builder patch
(In reply to comment #46) > pre. > BUILD FAILED > /Users/dgreen/Documents/mine/runtime-mylyn.wikitext/test2/build.xml:4: Problem: > failed to create task or type wikitext-to-html > Cause: The name is undefined. > Action: Check the spelling. > Action: Check that any custom tasks/types have been declared. > Action: Check that any <presetdef>/<macrodef> declarations have taken place. > > What am I missing? I looked at the classpath under Preferences->Ant->Runtime > and the classpath entry was there -- however looking at the external tool > configuration classpath I can't see the contributed jars. Check on the JRE tab, to make sure that you have it checked to: "Use the SAME JRE as Eclipse" so that it picks up the ant tasks. The tasks should show up on in Windows->Prefrences->Ant->Runtime->Tasks if the new plugin is installed with the patch > > And the last remaining question.... (drum roll) does this work with the > headless build? I've tried this with ant standalone (no eclipse) and dropped the bundle jars in place of the existing standalone jars, and had to change one thing in build. Apparently tasks.properties has been renamed wikitext-tasks.properties. Once I changed that on my taskdef, everything ran fine.
Chris I'm ready to commit this patch with the following changes: # change the copyright header of buildWikiTextAntSupportJar.xml to the standard one that mentions the EPL (including your name and EclipseSource is fine of course) # rename wikitext-tasks.properties to tasks.properties and restore its original copyright header Great work!
(In reply to comment #52) > Check on the JRE tab, to make sure that you have it checked to: "Use the SAME > JRE as Eclipse" so that it picks up the ant tasks. The tasks should show up on > in Windows->Prefrences->Ant->Runtime->Tasks if the new plugin is installed with > the patch Great tip! It works!
(In reply to comment #53) > Chris I'm ready to commit this patch with the following changes: > > # change the copyright header of buildWikiTextAntSupportJar.xml to the standard > one that mentions the EPL (including your name and EclipseSource is fine of > course) > # rename wikitext-tasks.properties to tasks.properties and restore its original > copyright header Those changes work for me. Commit away :)
Created attachment 146509 [details] org.eclipse.mylyn.wikitext.core.patch Here's an updated patch c/o David's comments.
Just made the commit. Thanks very much Chris and others for your contribution. Assigning to Chris for credit.
This change has introduced an issue running wikitext Ant tasks from within Eclipse in the same VM as the workbench.
I believe the solution is to unpack the jars as part of the build and we should all be good.
I've tackled this one elsewhere and what I discovered is that the plug-in containing the ant tasks jar must not have any references to ant classes in the bundle classpath.
What I mean by bundle classpath, is the classes that make up the bundle, not including the ant contrib jar.
Closing per project guidelines to maintain history of contributions to 3.3 release. Bug 302616 opened to continue this discussion
