Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Long, frequently changing version IDs and maven build styles

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?

- sachin



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



David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

02/01/2006 09:58 PM

Please respond to
"General discussion of project-wide or architectural issues."

To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
[wtp-dev] Long,        frequently changing version IDs and maven build styles






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



Sachin Patel <sppatel2@xxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

02/01/2006 05:31 PM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Weekly M-build declared: M200602010238 Wed,        1 Feb 2006 -- 02:38 (UTC)







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



Sachin Patel <sppatel2@xxxxxxxxx>
Sent by:
wtp-dev-bounces@xxxxxxxxxxx

02/01/2006 04:40 PM

Please respond to
"General discussion of project-wide or architectural issues." <
wtp-dev@xxxxxxxxxxx>


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Weekly M-build declared: M200602010238 Wed,        1 Feb 2006 -- 02:38 (UTC)









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


Back to the top