I wasn't aware of this. I already have implemented a short term solution, but this certainly could prove useful in the long term when I move from Maven 1 to Maven 2. Thanks!
Do the platform and the other prereqs publish these map files as well? On Feb 3, 2006, at 2:25 PM, Arthur Ryman wrote: Sachin, Perhaps you could drive your Maven builds off the map files?(e.g. [1]) They contain all the gory detail about plug-in versions. [1] http://download.eclipse.org/webtools/downloads/drops/I-I200602022035-200602022035/directory.txt
Arthur Ryman, IBM Software Group, Rational Division blog: http://ryman.eclipsedevelopersjournal.com/ phone: +1-905-413-3077, TL 969-3077 assistant: +1-905-413-2411, TL 969-2411 fax: +1-905-413-4920, TL 969-4920 mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
Thanks Sachin, yes it does make sense (though I do not know enough about maven to give much advise .... but I bet there's other readers of this mailing list that do), Too bad there is not the concept, as there is in ant, of specifying the classpath (or, part of the classpath) for compiling against simply like something similar to the following bootclasspath=${eclipse.home.plugins}/*.jar If, what you are trying to accomplish is to only "update" the jars that have changed since the last time, you might read about using the Eclipse update manager from the command line, and see if that would satisfy this need. See http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/update_standalone.html I *think* using update manager is the long term solution to handling dependancies like this and to minimize downloads, but we won't be ready to support that in time to solve your immediate problem. (but if you have comments on long term appropriateness, or comparisons with maven style, I'd love to hear them). And, yes, the Eclpse base has already moved to this type of build in their 3.2 stream (but they do not plan to for their 3.1.x stream). David
So basically, when each plugin I have is defined as a "maven" project. So maven goals are invoked to compile the source, rather then the PDE builder. Defining a maven project requires defining a project.xml which declares the dependencies to compile. So PDE to locate dependencies to compile looks at the plugin.xml or manifest for the "required plugins", where as I have to redefine those plugins as dependencies in a maven specific project.xml. Now since Eclipse/WTP doesn't upload each of the plugins is a remote maven repository where maven can pull down only the jars it needs for compilation, I download the entire wtp image and extract it. I then use a maven concept of a jar override for each plugin dependency to point to the absolute path to that plugin... maven.jar.org.eclipse.jst.j2ee.web = ${eclipse.home.plugins}/org.eclipse.jst.j2ee.web_${wtp.version}.jar maven.jar.org.eclipse.jst.j2ee.ejb = ${eclipse.home.plugins}/org.eclipse.jst.j2ee.ejb_${wtp.version}.jar maven.jar.org.eclipse.jst.j2ee.jca = ${eclipse.home.plugins}/org.eclipse.jst.j2ee.jca_${wtp.version}.jar This is where the I'm impacted... Before I simply set the wtp.version property, and in some cases, they differ, but before they were either 1.0.0, or 1.0.1. Now for every single wtp dependency each version will be different and different for every build. So each time I pull down a build to compile against I'll have to manually update this hard coded absolute path to the jar. Hope that makes sense. Talking to the maven folks in the past, I know there in discussions with the platform team to have better integration for plugin development. But this introduction of qualifier builds poses another problem that the maven team will need to be informed of. Do you know if and when the Eclipse Platform will be moving their builds to this? - sachin On Feb 1, 2006, at 5:14 PM, David M Williams wrote: Sachin, Those for making us aware of impacts. What dependancies to you mean? I don't now that much about maven, but as for dependancies in Eclipse, you would still list your "requires" as "1.0" (or, "1.0.1") ... normally the 4th field should never be used. Just for my own education, or other mavenized users ... what dependancies are you refering to? David
Um... so I just realized this introduction of "long" version numbers has broken my mavenized build for the geronimo plugin. Each time now I want to build against a new driver, I'll be forced to manually update all the versions of my dependencies or the build will fail. I'm probably going to have to write a script that does a compare of old dependencies and new and updates the qualifier :( - sachin On Feb 1, 2006, at 12:11 PM, David M Williams wrote: This is our weekly build towards our 1.0.1 release. This is an important one, since first with all 3.1.2 level pre-reqs, and first with "long" version numbers. M200602010238Wed, 1 Feb 2006 -- 02:38 (UTC) _______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list
|