On 6/7/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
To me the best place is to write an
example following ideal Maven setup (given what we have to start with in
Eclipse in terms of source layout etc) and see what that is. For
us we understand the words but not the real meaning. I suspect also
that this will uncover some issues. Essentially this would have
examples at both ends of the spectrum.
This sounds fine to me. I will start with a hello world plugin project using the PDE template and rework the project layout for maven projects. Before we went the RCP route for some of our work the default eclipse project layout was mostly maven compatible. Actually I probably could have made it work with out changing the eclipse layout, but if you go the maven route and use their layout then a lot of plugin configuration is completely wiped out since they will assume the default layout and everything just works.
On a different frontthe dependency resolution
issue seems central in as much as that, for both Maven and PDE, it drives
the show. As was mentioned before, we have (or can quickly make)
a standalone OSGi resolver JAR that should be good for this usecase. Integrating
that and prototyping a mechanism for driving Maven via manifests seems
like a good place to start.
This is the one that is going to generate the most sleepless nights for me as this is where maven itself will have to be enhanced and "use the source Luke" is still the appropriate SOP (standard operating procedure), even though I will freely admit their documentation improved a whole lot after
2.0 was released. Yet and still there are holes that can only be grokked by reading the code.
As for what is on the table, we clearly
cannot destablize the build system. It does seem unlikely that we
would pitch PDE build and use Maven in the 3.3 timeframe. Seems like
alot of risk. However, one has to have goals and then make baby steps
towards them. Understanding what it would mean to jump all the way
to the other end of the spectrum is one of those baby steps.
Jeff
ps., I hear the kool-aid is Grape. Is
that right?
I share your concerns because in general I'm a pessimist but I'm optimistic that if the dependency resolution issue is handled to every one's satisfaction then the rest will come quickly.
FYI, It took a while but I got my company to join the Eclipse Foundation effective 05/30/06 and as part of the welcome kit I got the bill for it all today. :)
|
|
To
| |
|
cc
|
|
|
| Re: [pde-build-dev] Eclipse Builds and
Maven 2.x |
|
Currently the whole dependency resolution thing is not
pluggable IIRC. However, Brett previously stated that it could be
made pluggable. If that is done then the default implementation of
this IMavenDependencyResolver would work for maven backwards compatibility
and an alternate could be selected via properties and/or command line for
eclipse/osgi builds.
Now that we seem to have a meeting of the minds where is the best place
to start? I have started reading the build automation article, but
I'm not done yet. Also I have seen comments of multiple platforms/operating
systems, but are there other variables we need to be concerned with such
as defect tracking systems, cm systems, build servers like anthill pro,
continuum, ...?
Wb
P.S.
Are you all aware that you can take an ant script and expose it as a maven
plugin? Maven will then invoke the appropriate ant targets under
the covers. Maven users are exposed to this and really should care
whether the maven plugin they're using is ant-based or java-based unless
performance or memory becomes an issue.
On 6/7/06, Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx
>
wrote:
I think I start to see your points about integration but I'm a bit surprised
as I thought that the whole dependency resolution was not pluggable.
>Does PDE care that the source was fetched with
ant and place at /x/y/z or does it merely want the action performed?
PDE does not care how the source is
obtained, in the end it just needs to know where on the local filesystem
it is located and what to do with it (this is why we have the build.properties).
PaScaL, curious to taste the maven kool-aid.
_______________________________________________
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
