On 6/6/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
Wendell Beckwith wrote on 06/06/2006 07:41:39 PM:
> This came up previously in this thread, http://dev.eclipse.
> org/mhonarc/lists/pde-build-dev/msg00076.html, but it seems to have
> fallen on the floor and rolled under the couch. Nonetheless,
my
Every once in a while we get a stick and poke around
in the dark recesses under the couch but mostly this topic seems to just
roll further away... :-)
Seriously, it is quite interesting. There is
no desire to lock people into PDE or have PDE rule the world. The
main barrier has been the work required for us to get to know Maven and
others getting to know PDE Build... While the approach you outline
feels plausible, there are some fundamental technology issues that need
to be understood and addressed.
- Dependency management : Maven has a reasonable mechanism
for finding and resolving dependencies. Unfortunately, the OSGi dependency
model is considerably richer. As a result, maven will not know, for
example, how to deal with Import-Package statements that spec arbitrary
dependencies and use the "uses" directive.
I don't consider myself to be a maven 2 guru, however I have implemented a working maven environment and written several plugins for the new m2 architecture. The way I see it, we would need 1 or more maven plugins to perform dependency management and the compiler options below. Currently the code is written and working in eclipse. I imagine that that code would be refactored into a separate jar similar to how the eclipse compiler is now package separately for use by others. The plugin(s) would then have a dependency on this eclipse pde build jar and would invoke its code to do the compile.
- Compiler options : A friend of dependency management
is compiler options. In particular, access rules. PDE, based
on the resolved dependency model, specifies various access rules or filters
on JARs that are added to the classpath. These limit what a particular
project being compiled can see from a particular JAR. It also facilitates
various Eclipse extensions like x-internal and x-friends which are used
extensively to ensure that teams are not overstepping API boundaries.
This again is what leads me to think that there will be a need for a custom maven plugin for building eclipse features/plugins. I also think that there will likely need to be changes pushed into maven to make available the right hooks to acquire and/or provide data.
- Manifest management : There is an ongoing
debate about who owns the manifest. PDE assumes that the bundle developer
crafts the manifest while Mavenites craft POMs and then the manifest is
generated. The current maven-osgi plugin seems to do some merging
on output but I think you still have to have dependencies spec'd in the
POM (so duplicated if you are looking to use the PDE workflows, classpath
containers, quick fixes, dynamic launch capabilities, ...
This is an example of where I believe we would need to potentially push changes to maven. Besides this isn't a bug it's a feature. :) Currently build information is spread across several files, map files,
build.properties, manifest.mf, build.xml, customTargets.xml, etc. Us mavenites keep most info in the pom, but there are cases where we need to refer to external resources to perform a certain action. Currently (and this is where a maven guru/dev can correct me) m2 uses the info in the pom to build the classpath. However, if m2 doesn't have it then I can see an enhancement to maven to provide classpath resolvers. The default classpath resolver would continue to use the pom, while an osgi classpath resolver could use info from the pom (this can tell it where other bundles are in the repo) and the
manifest.mf to determine the right imports, etc.
These are all elements that would need to be considered
even in a scenario where you are using Maven to build just and individual
project and using PDE build to orchestrate.
> From a high level eclipse wants to do pre and
post actions for build
> setup, retrieving the source, building the feature/plugin, testing
> the plugin, assembling the feature/plugin, packaging and publishing
> the feature/plugin. These actions map extremely well to maven
2's
> notion of a lifecycle. Either the current default maven 2 lifecycle
> could be used or a custom plugin can be defined that uses an eclipse
> specific lifecycle similar to how the clover plugin has its own
> lifecycle. To make this happen I think that there should be
a org.
> eclipse.pde.build.IBuildScript interface that is used. The current
> IAntScript interface could extend the IBuildScript interface to
> maintain backwards compatibility. Nonetheless, if the lifecycle
> phase methods were placed in the IBuildScript interface then other
> methods builds systems (IMavenScript, IIvyScript, IJamScript, etc)
> could be plugged in at ease without being tied to a specific one.
>
> There may be glaring holes and over simplifications I have made but
> getting our builds working again in a smooth fashion is a priority
> goal I have and currently I have 1.5 engineers I can throw at the
> problem. Thoughts??
It would be extremely interesting to see how one could
use Maven to build, for example, the RCP feature for several platforms
(say Win32 and Linux GTK x86) and produce the corresponding zips. By
this I mean, ignore PDE Build and imagine that we all went native Maven,
fell in love with POMs and all started hand crafting them every chance
we had. What would the POMs look like? How would it work? Would
it work? How are the points above addressed? Having understood
this we can then look at how to automate parts of that process.
Does that make sense?
Yes, it makes sense, but if you all went native and became card carrying mavenites then I would likely have my problems solved but others would still be in the same boat. After I sent my original email I started thinking that what was needed was not a simple build script, but instead a build model. If we can describe and declare how a feature/plugin build model should work then we can then explore how to map that model to ant, and maven. With ant and maven providing concrete implementations of the build model, other parties could plugin in their own models. In my mind the build model should support using all of say maven for the entire build as well as using an IAntScript to fetch the source, eclipse to compile and test it and finally maven to assembly, package and deploy it.
Now does what I said make sense to you?
Jeff
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev