[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[pde-build-dev] Mails that didn't seem to go through (
|
I have recently had
some emails to the list that didn't go throught because of apparently spamcop
(stupid product name IYAM) blocking them. This may be affecting
other
June
14:
On 6/14/06, Andrew Niefer <aniefer@xxxxxxxxxx>
wrote:
> Are
you saying that we would just need to add a <bootclasspath/> element or
do you see something more involved required?
Fundamentally, yes it is setting the
bootclasspath. However, it would be nice to abstract it one layer so the
bundle did not need to specify paths to jars. I don't know how maven
normally handles this, do you put the jars in your local repo and just express
a dependency on them? It would be nice to just say "I need J2SE-1.3"
have maven know where to find it.
I would not put the rt.jar and its siblings in the repo and it is not
necessary to specify full paths. Normally it will use what is on your
path, but the eclipse-compiler plugin would have special needs. There are
several ways that this can be done and mostly you would want to use properties
for this. You can have something like <bootclassapath>${
eclipse.compiler.bootclassapth}</bootclasspath> and have the property
resolved within the plugin (bad idea IMHO), within the pom, within a profile or
IIRC there is a way to specify this as a default for the whole maven
installation. As a last resort the property can be specified on the
command line. I would favor the use of profiles as they work pretty
similar to how eclipse now has Execution Environments. The difference
being you can stack up and activate multiple profiles while you can only have 1
Execution Environment.
> Is this the
type of meta data you meant would be needed? Now that I think about it,
nothing prevents us from adding the Manifest.mf itself as an attachment to the
jar artifact being installed/deployed to a maven repo. Thus the compiler
wouldn't even have to open the jars to get at the manifest data.
Yes. Because we can't list the
contents of a repository, we need a way to answer the question "Does the repo
contain some bundle that exports package foo?". Once we know that a
bundle exists, then we can find it in the repo and download the manifest.
Having the manifest available separate from the jar would be good since
it allows us to reason about dependency resolution without having to download
the jars right away.
Adding the manifest as an attachment requires very little work to
achieve. I'll look into working this out today/tomorrow. However,
there isn't currently an index of everything in a repo. This is why I was
thinking we would need the dependency-pom mechanism I was previously talking
about as this would map to the current use of an eclipse target to compile
against. The maven-eclipsecompiler-plugin would be configured with 0 or
more dependency poms. The code in the plugin (or if we can push it back,
maven itself) would load and resolve a dependency pom down to its component
dependencies. From each dependency it will load the manifest.mf containing
imports/exports. Paths to the actual jars files are retrieved from the
Repository instance. At this point, I'm hoping eclipse would have the same
information from the repo that it would have if it used a target folder.
Use of the repo is the end game, but I'm hoping we can move forward with
using a target folder to work out other kinks, seen and unseen, while the end
game is worked on.
-Andrew
This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments.