Re: [pde-build-dev] Re: Integrating with an external build system (Ant,

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

"Tom Huybrechts" <tom.huybrechts@xxxxxxxxx>
wrote on 06/15/2006 03:55:30 PM:

> Hi Jeff,
> 
> I've sent a few replies to your mails to the pde-build-dev list 
> today. Did you receive them - they don't appear in the archives and
> they didn't bounce so they seem to have just disappeared...

I did not receive any messages from
you via the list.  Strange.  Lets see if this one gets through.
 Perhaps there is a problem with the mail list server...  

> This is what I said: 
> 
> * Regarding the creation of an index:
> 
> How would you create this index ? 'All the bundles that are 
> available' is quite a lot - if you're talking about all artifacts
> available in public and private repositories. Or would you restrict
> this to plugins you have available locally ? 

I suspect that this may have to be scoped because
of scaling issues.  on the other hand, our resolver scales pretty
well to thousands of bundles.  In essence this phase of the build
is one of "provisining" the local repo.  Once it is provisioned
with all the things you think you need/want, you need only consider what
you have locally.  So it is an interesting question as to the best
way of provisioning the local repo...

> If this index would exist, it would also be easier
to create a 
> manifest-to-pom mapper. Then you could skip writing the custom 
> resolver for now (which looks like the hardest part since it 
> requires modifications to the maven core) and just create some 
> custom compiler and packaging plugin as a proof of concept. 

The resolver information is needed in two points during
the build.  In the first instance it is needed when you are trying
to populate the local repo with the prereqs.  In Maven today this
list is simply given to you in the POM.  This is equivalent to the
OSGi Require-Bundle level of dependencies.  If you skip the package
level dependencies at this level it may work but there are a couple potential
problems:
- it forces developers to know or discover which JARs
contain which versions of packages and then code their POM dependencies
on taht JAR rather than on the package.  Pain in the butt but ok...
- version management becomes hard becuse you have
to worry about versions of JARs as well as versions of packages.  

The second point is in computing the compile time
classpath.  This is where you need to build a flat, correctly ordered
classpath of JARs with access rules to define what packages/classes you
can see from each JAR.  To do this you really need to do the full
package level resolution and discover all the actual wirings and then represent
them in the classpath.  Note that this use is key IMHO to this whole
process.  We have several cases in our very modest use of Import-Package
where there are JARs on the classpath of a bundle that supply some package
"com.foo" but we actually want the "com.foo" that comes
from a JAR further down the classpath.  Without this full resolution
and access rules we would not be able to build.

> One more thing: what would happen when more than one plugin provides
> a required package ? How does the current PDE build handle this situation
?

Right now PDE build, in essences, is building  against
whatever is in the "local repo" and has no facilities to provision
the local repo automatically.  This is one of the reasons that Maven
is kind of interesting in this context.  As described above, PDE build
resolves a state that contains all the bundles it knows about (i.e. all
the ones it has locally) and then walks the wirings.  This, BTW, is
exactly what is happening in PDE UI when you are using Eclipse to develop
bundles in the workspace.

> * About MRM:
> 
> It is a web application that allows you to access and manage a Maven
> repository (hence the name). 
> 
> My guess is that it would:
> - act as a proxy for external maven repositories (like maven-proxy
> or proximity) 
> - allow you to search the contents of the repository (something like
> mvnrepository.com)
> - let you manage the contents of your repository ( e.g. delete old
> snapshot builds)
> 
> The MRM is not released yet, and questions about its status are 
> usually ignored on maven-users. I think (looking at the source) that
> it creates an index using Lucene, which contains some standard 
> metadata information from the poms and class and package names for
> jars. It could probably be extended to also index manifest 
> information (like Bundle-SymbolicName, or Export-Package). 

Ok, this last part is perhaps the most important.
 If the index contains the information needed (e.g., package level
details) and the index can be fetched/accessed in an efficient fashion
then it may be useful.  I suspect the required information could actually
be encoded to be quite small.

Jeff