Home » Eclipse Projects » Eclipse Platform » Can plugin.xml be relocated to a subdirectory?
| Can plugin.xml be relocated to a subdirectory? [message #326842] |
Tue, 01 April 2008 20:17  |
Eclipse User |
|
|
|
I have merged several plugins that we have developed into an existing
project. I would like to put the plugin.xml, build.properties, etc, in a
separate directory, but to this point have been unsuccessful.
Notionally, I would like a directory structure like this:
Project
src
bar.foo
plugin.xml
build.properties
META-INF
MANIFEST.MF
Activator.java
.....
When I structure it like this, the Required Plug-ins in the Dependencies
tab do not get added to the Library Plug-in Dependencies in the Java Build
Path.
TIA...
|
|
| |
| Re: Can plugin.xml be relocated to a subdirectory? [message #326869 is a reply to message #326866] |
Wed, 02 April 2008 08:45  |
| Eclipse User |
|
|
|
Ed:
Thanks. That's about what I was afraid of.
Specifically, the structure, IMO, is less cluttered (personally, I'd
rather not have too many items at the top level directory).
Having a single plugin.xml also makes [again, IMO] CM more challenging.
In our case, we have a large java project with a very tiny plugin. By
allowing only one plugin.xml, it means that if the large java project
requires another plugin that does something completely different, it will
still need to be bundled with the original plugin. Then there's the
aspect that "plugin.xml" really isn't very meaningful of a name. What's
to say that my project doesn't have a plugin framework, with it's own
"plugin.xml", and "build.properties", or even a "META-INF/MANIFEST.MF".
Of course, we could have a separate CM of the plugin(s). No argument
that this would work. However, in my mind it is better for the PDE plugin
to be flexible (all that we're discussing is pointing the plugin.xml to a
Manifest, build.properties, etc - in short - other "resources" that the
plugin needs to deal with), rather than have to work around it.
If you will, it's the semantic difference between having a top level
"images" directory, and placing images/icons in the package where they are
used. There are pros and cons to both, but the existing frameworks to
load images allow both.
I hope that helps to clarify the intent.
Ed Merks wrote:
> Keven,
> No, I don't think so. Things like the plugin.xml and META-INF need to
> be in the project's root to be recognized as providing a special role
> for the plugin. It's best to go with the grain than across it... I
> wonder what you are hoping to achieve with the structure you've outlined?
> Keven Ring wrote:
>> I have merged several plugins that we have developed into an existing
>> project. I would like to put the plugin.xml, build.properties, etc,
>> in a separate directory, but to this point have been unsuccessful.
>>
>> Notionally, I would like a directory structure like this:
>>
>> Project
>> src
>> bar.foo
>> plugin.xml
>> build.properties
>> META-INF
>> MANIFEST.MF
>> Activator.java
>> .....
>>
>>
>> When I structure it like this, the Required Plug-ins in the
>> Dependencies tab do not get added to the Library Plug-in Dependencies
>> in the Java Build Path.
>>
>> TIA...
>>
|
|
|
| Re: Can plugin.xml be relocated to a subdirectory? [message #326871 is a reply to message #326869] |
Wed, 02 April 2008 09:30 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Keven,
It's best to think of project == plugin. Keep in mind that the various
Eclipse projects manage tens of thousands of plugin just fine as it
works today. I'm not sure why you'd have a plugin framework when one
exists, so that sounds like a manufactured hypothetical issue, not a
real one. Also, your argument to make things flexible, is also an
argument in favor of making things more complex. Consider the amount of
infrastructure that's geared around what exists and how it would be
impacted by changes. How, for example, will one know which plugin.xml
is the real one and which is just an xml resource that happens to be
named plugin? Yet another descriptive file that says where to look?
And then were to put it? Anywhere? That would recursively yield the
same problem...
I know it's human nature to try to cast everything into our own image of
personal perfection, but in the real world we're mostly stuck with
someone else's version of that...
Keven Ring wrote:
> Ed:
>
> Thanks. That's about what I was afraid of.
>
> Specifically, the structure, IMO, is less cluttered (personally, I'd
> rather not have too many items at the top level directory).
>
> Having a single plugin.xml also makes [again, IMO] CM more
> challenging. In our case, we have a large java project with a very
> tiny plugin. By allowing only one plugin.xml, it means that if the
> large java project requires another plugin that does something
> completely different, it will still need to be bundled with the
> original plugin. Then there's the aspect that "plugin.xml" really
> isn't very meaningful of a name. What's to say that my project
> doesn't have a plugin framework, with it's own "plugin.xml", and
> "build.properties", or even a "META-INF/MANIFEST.MF".
>
> Of course, we could have a separate CM of the plugin(s). No argument
> that this would work. However, in my mind it is better for the PDE
> plugin to be flexible (all that we're discussing is pointing the
> plugin.xml to a Manifest, build.properties, etc - in short - other
> "resources" that the plugin needs to deal with), rather than have to
> work around it.
>
> If you will, it's the semantic difference between having a top level
> "images" directory, and placing images/icons in the package where they
> are used. There are pros and cons to both, but the existing
> frameworks to load images allow both.
>
> I hope that helps to clarify the intent.
>
> Ed Merks wrote:
>
>> Keven,
>
>> No, I don't think so. Things like the plugin.xml and META-INF need
>> to be in the project's root to be recognized as providing a special
>> role for the plugin. It's best to go with the grain than across
>> it... I wonder what you are hoping to achieve with the structure
>> you've outlined?
>
>
>> Keven Ring wrote:
>>> I have merged several plugins that we have developed into an
>>> existing project. I would like to put the plugin.xml,
>>> build.properties, etc, in a separate directory, but to this point
>>> have been unsuccessful.
>>>
>>> Notionally, I would like a directory structure like this:
>>>
>>> Project
>>> src
>>> bar.foo
>>> plugin.xml
>>> build.properties
>>> META-INF
>>> MANIFEST.MF
>>> Activator.java
>>> .....
>>>
>>>
>>> When I structure it like this, the Required Plug-ins in the
>>> Dependencies tab do not get added to the Library Plug-in
>>> Dependencies in the Java Build Path.
>>>
>>> TIA...
>>>
>
>
|
|
|
| Re: Can plugin.xml be relocated to a subdirectory? [message #326881 is a reply to message #326871] |
Wed, 02 April 2008 11:14 |
| Eclipse User |
|
|
|
I think the point being missed is that there are dozens, if not hundreds
of plug-in frameworks, and for more languages than just Java.
Why would I have a plugin framework when one already exists? Simple - my
main java project isn't an *eclipse* plug-in, and doesn't use the OSGi
plug-in specification. Does that mean that I can't have a plug-in
framework?
As far as the flexibility vs complexity, that issue is faced every day.
Personally, I don't see a significant amount of complexity being required
[again, we're talking about resources that the plug-in needs to
update/whatever. Hard-coding the resource location versus making it a
"variable" with a sensible default doesn't seem all that complex to me,
but maybe I'm just being naive].
I can live with project == plugin. I was merely hoping for a little more
flexibility.
Thanks again for the insight!
Ed Merks wrote:
> Keven,
> It's best to think of project == plugin. Keep in mind that the various
> Eclipse projects manage tens of thousands of plugin just fine as it
> works today. I'm not sure why you'd have a plugin framework when one
> exists, so that sounds like a manufactured hypothetical issue, not a
> real one. Also, your argument to make things flexible, is also an
> argument in favor of making things more complex. Consider the amount of
> infrastructure that's geared around what exists and how it would be
> impacted by changes. How, for example, will one know which plugin.xml
> is the real one and which is just an xml resource that happens to be
> named plugin? Yet another descriptive file that says where to look?
> And then were to put it? Anywhere? That would recursively yield the
> same problem...
> I know it's human nature to try to cast everything into our own image of
> personal perfection, but in the real world we're mostly stuck with
> someone else's version of that...
> Keven Ring wrote:
>> Ed:
>>
>> Thanks. That's about what I was afraid of.
>>
>> Specifically, the structure, IMO, is less cluttered (personally, I'd
>> rather not have too many items at the top level directory).
>>
>> Having a single plugin.xml also makes [again, IMO] CM more
>> challenging. In our case, we have a large java project with a very
>> tiny plugin. By allowing only one plugin.xml, it means that if the
>> large java project requires another plugin that does something
>> completely different, it will still need to be bundled with the
>> original plugin. Then there's the aspect that "plugin.xml" really
>> isn't very meaningful of a name. What's to say that my project
>> doesn't have a plugin framework, with it's own "plugin.xml", and
>> "build.properties", or even a "META-INF/MANIFEST.MF".
>>
>> Of course, we could have a separate CM of the plugin(s). No argument
>> that this would work. However, in my mind it is better for the PDE
>> plugin to be flexible (all that we're discussing is pointing the
>> plugin.xml to a Manifest, build.properties, etc - in short - other
>> "resources" that the plugin needs to deal with), rather than have to
>> work around it.
>>
>> If you will, it's the semantic difference between having a top level
>> "images" directory, and placing images/icons in the package where they
>> are used. There are pros and cons to both, but the existing
>> frameworks to load images allow both.
>>
>> I hope that helps to clarify the intent.
>>
>> Ed Merks wrote:
>>
>>> Keven,
>>
>>> No, I don't think so. Things like the plugin.xml and META-INF need
>>> to be in the project's root to be recognized as providing a special
>>> role for the plugin. It's best to go with the grain than across
>>> it... I wonder what you are hoping to achieve with the structure
>>> you've outlined?
>>
>>
>>> Keven Ring wrote:
>>>> I have merged several plugins that we have developed into an
>>>> existing project. I would like to put the plugin.xml,
>>>> build.properties, etc, in a separate directory, but to this point
>>>> have been unsuccessful.
>>>>
>>>> Notionally, I would like a directory structure like this:
>>>>
>>>> Project
>>>> src
>>>> bar.foo
>>>> plugin.xml
>>>> build.properties
>>>> META-INF
>>>> MANIFEST.MF
>>>> Activator.java
>>>> .....
>>>>
>>>>
>>>> When I structure it like this, the Required Plug-ins in the
>>>> Dependencies tab do not get added to the Library Plug-in
>>>> Dependencies in the Java Build Path.
>>>>
>>>> TIA...
>>>>
>>
>>
|
|
|
| Re: Can plugin.xml be relocated to a subdirectory? [message #326886 is a reply to message #326881] |
Wed, 02 April 2008 11:29 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Keven,
Comments below.
Keven Ring wrote:
> I think the point being missed is that there are dozens, if not
> hundreds of plug-in frameworks, and for more languages than just Java.
Even if there are thousands, I'm not sure what the point is. It doesn't
strike me that any of those cases require you to overlap with the PDE's
file structure.
>
> Why would I have a plugin framework when one already exists? Simple -
> my main java project isn't an *eclipse* plug-in, and doesn't use the
> OSGi plug-in specification. Does that mean that I can't have a
> plug-in framework?
If it's not a plugin, then you don't need a plugin.xml nor any of the
other PDE stuff...
>
> As far as the flexibility vs complexity, that issue is faced every day.
I've noticed that. :-P
> Personally, I don't see a significant amount of complexity being
> required [again, we're talking about resources that the plug-in needs
> to update/whatever. Hard-coding the resource location versus making
> it a "variable" with a sensible default doesn't seem all that complex
> to me, but maybe I'm just being naive].
Given it's been hard coded for years, making it variable requires all
clients to take that variability into account. And of course, as I
explained, it requires a place to record the variability. None of that
actually makes it simpler for anyone, so the additional flexibility
better buy something significant. That's the part that isn't clear...
> I can live with project == plugin. I was merely hoping for a little
> more flexibility.
What is life without hope?
>
> Thanks again for the insight!
You're welcome. I'm sure once you start using things, it will start to
seem much more natural than it does at first...
>
> Ed Merks wrote:
>
>> Keven,
>
>> It's best to think of project == plugin. Keep in mind that the
>> various Eclipse projects manage tens of thousands of plugin just fine
>> as it works today. I'm not sure why you'd have a plugin framework
>> when one exists, so that sounds like a manufactured hypothetical
>> issue, not a real one. Also, your argument to make things flexible,
>> is also an argument in favor of making things more complex. Consider
>> the amount of infrastructure that's geared around what exists and how
>> it would be impacted by changes. How, for example, will one know
>> which plugin.xml is the real one and which is just an xml resource
>> that happens to be named plugin? Yet another descriptive file that
>> says where to look? And then were to put it? Anywhere? That would
>> recursively yield the same problem...
>
>> I know it's human nature to try to cast everything into our own image
>> of personal perfection, but in the real world we're mostly stuck with
>> someone else's version of that...
>
>
>> Keven Ring wrote:
>>> Ed:
>>>
>>> Thanks. That's about what I was afraid of.
>>>
>>> Specifically, the structure, IMO, is less cluttered (personally,
>>> I'd rather not have too many items at the top level directory).
>>>
>>> Having a single plugin.xml also makes [again, IMO] CM more
>>> challenging. In our case, we have a large java project with a very
>>> tiny plugin. By allowing only one plugin.xml, it means that if the
>>> large java project requires another plugin that does something
>>> completely different, it will still need to be bundled with the
>>> original plugin. Then there's the aspect that "plugin.xml" really
>>> isn't very meaningful of a name. What's to say that my project
>>> doesn't have a plugin framework, with it's own "plugin.xml", and
>>> "build.properties", or even a "META-INF/MANIFEST.MF".
>>>
>>> Of course, we could have a separate CM of the plugin(s). No
>>> argument that this would work. However, in my mind it is better for
>>> the PDE plugin to be flexible (all that we're discussing is pointing
>>> the plugin.xml to a Manifest, build.properties, etc - in short -
>>> other "resources" that the plugin needs to deal with), rather than
>>> have to work around it.
>>>
>>> If you will, it's the semantic difference between having a top
>>> level "images" directory, and placing images/icons in the package
>>> where they are used. There are pros and cons to both, but the
>>> existing frameworks to load images allow both.
>>>
>>> I hope that helps to clarify the intent.
>>>
>>> Ed Merks wrote:
>>>
>>>> Keven,
>>>
>>>> No, I don't think so. Things like the plugin.xml and META-INF need
>>>> to be in the project's root to be recognized as providing a special
>>>> role for the plugin. It's best to go with the grain than across
>>>> it... I wonder what you are hoping to achieve with the structure
>>>> you've outlined?
>>>
>>>
>>>> Keven Ring wrote:
>>>>> I have merged several plugins that we have developed into an
>>>>> existing project. I would like to put the plugin.xml,
>>>>> build.properties, etc, in a separate directory, but to this point
>>>>> have been unsuccessful.
>>>>>
>>>>> Notionally, I would like a directory structure like this:
>>>>>
>>>>> Project
>>>>> src
>>>>> bar.foo
>>>>> plugin.xml
>>>>> build.properties
>>>>> META-INF
>>>>> MANIFEST.MF
>>>>> Activator.java
>>>>> .....
>>>>>
>>>>>
>>>>> When I structure it like this, the Required Plug-ins in the
>>>>> Dependencies tab do not get added to the Library Plug-in
>>>>> Dependencies in the Java Build Path.
>>>>>
>>>>> TIA...
>>>>>
>>>
>>>
>
>
|
|
|
| Re: Can plugin.xml be relocated to a subdirectory? [message #326890 is a reply to message #326881] |
Wed, 02 April 2008 12:37 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Keven Ring" <KEVEN@MITRE.ORG> wrote in message
news:d4c0108adf3e56d79bc16439ca1ad317$1@www.eclipse.org...
>I think the point being missed is that there are dozens, if not hundreds of
>plug-in frameworks, and for more languages than just Java.
If you are looking for ways in which Eclipse or OSGi cannot coexist with
arbitrarily selected other frameworks, this won't be the only one you'll
find.
But that problem is endemic among frameworks. Application frameworks (and
operating systems) do not, in general, get along with each other; you need
to choose one, or face considerable complexity as you try to meta-code for
multiple ones. This is nothing new. Usually it gets solved by someone
writing a new, higher-level, framework to try to paper over the underlying
different platforms or frameworks; this new higher-level framework then does
not get along with the other solutions at its own level. At some point, one
has to choose a specific framework based on the business needs, and get on
with it.
Is there a concrete problem you're running into? Perhaps we can help you
solve it; as Ed mentions, tens of thousands of Eclipse plug-ins across
myriad languages, industries, runtime environments, and applications have
managed to find a way to work.
|
|
|
| Re: Can plugin.xml be relocated to a subdirectory? [message #326914 is a reply to message #326890] |
Wed, 02 April 2008 21:45 |
| Eclipse User |
|
|
|
Walter:
I'm certainly not looking for ways that things can't co-exist - quite
the opposite! Our scenario is this: We have a [mostly java] project that
contains some Ada code that gets cross-compiled for embedded devices.
We developed an Eclipse plug-in that keeps portions of the Java code
synchronized with the Ada code [the Java code is the "gold standard", and
the Ada code needs to reflect this]. We could have done this a thousand
ways, but we figured we could try working *with* our IDE, and
learn/understand the Eclipse/OSGi plug-in architecture at the same time.
Ok, so the problem is that the plug-in is really specific [more or
less!] to this mostly java project. As a result, logically, it should
co-exist with the java-project. As Ed has pointed out, however,
logically, it's better to think of a plug-in as being it's own project,
and not embedded. I can certainly respect that line of thinking - as
stated, there are many plug-ins that use this methodology quite
successfully.
Ideally, though [in my world!], what I'd *like* to be able to do is to
have the plug-in resources [code, images, meta-data, ...] co-exist in
their little portion of the java project. The code can do this easily -
it is, after all, just another java package. The images can as well.
But, the meta-data cannot. For the meta-data to work with the PDE, the
plugin.xml, build.properties, and MANIFEST have to be at the root of the
project.
Is having the plugin.xml in the project root directory the end of the
world? No. In my mind, I was thinking that the project should be a pure
Java project for most people, and a Java + PDE project for the few that
need it. By excluding the appropriate package, they eliminate the need to
see (or modify!) any of the plug-in files - code or meta-data.
What's interesting is that when the plugin.xml, build.properties, and
META-INF are copied into the src/.... tree, PDE still *mostly* works -
updates are reflected in the "proper" MANIFEST.MF, and build.properties.
However, the PDE plug-in doesn't update the Plug-in Dependencies Build
Path. This means that even though it's listed in the MANIFEST.MF, and the
PDE plug-in "Dependencies", it won't build..... Now, I could go in and
manually add all of the Eclipse jar dependencies to the libraries list.
At that point, it would build, and I should be able to export the plug-in
as well. It just seems like re-inventing the wheel a bit....
I hope that helps peel back the onion a little bit more. As I said in
my earlier response, there are several paths that we can choose that will
work. The one that made sense in my mind isn't one of them. That's
unfortunate, but certainly not a deal-breaker or a impassible road-block.
If you can think of an alternate solution, I'd be more than willing to
listen. I'm also fine with the "plug-in == project" answer. I certainly
can't be mad if I ask a question and don't like the answer!
Walter Harley wrote:
> "Keven Ring" <KEVEN@MITRE.ORG> wrote in message
> news:d4c0108adf3e56d79bc16439ca1ad317$1@www.eclipse.org...
>>I think the point being missed is that there are dozens, if not hundreds of
>>plug-in frameworks, and for more languages than just Java.
> If you are looking for ways in which Eclipse or OSGi cannot coexist with
> arbitrarily selected other frameworks, this won't be the only one you'll
> find.
> But that problem is endemic among frameworks. Application frameworks (and
> operating systems) do not, in general, get along with each other; you need
> to choose one, or face considerable complexity as you try to meta-code for
> multiple ones. This is nothing new. Usually it gets solved by someone
> writing a new, higher-level, framework to try to paper over the underlying
> different platforms or frameworks; this new higher-level framework then does
> not get along with the other solutions at its own level. At some point, one
> has to choose a specific framework based on the business needs, and get on
> with it.
> Is there a concrete problem you're running into? Perhaps we can help you
> solve it; as Ed mentions, tens of thousands of Eclipse plug-ins across
> myriad languages, industries, runtime environments, and applications have
> managed to find a way to work.
|
|
|
| Re: Can plugin.xml be relocated to a subdirectory? [message #326969 is a reply to message #326914] |
Thu, 03 April 2008 14:28 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Keven Ring" <KEVEN@MITRE.ORG> wrote in message
news:095c4ecfb5be5da50dafc95db2323ac6$1@www.eclipse.org...
> Walter:
Hi, Keven. Thanks for the response.
> We developed an Eclipse plug-in that keeps portions of the Java code
> synchronized with the Ada code [the Java code is the "gold standard", and
> the Ada code needs to reflect this]. We could have done this a thousand
> ways, but we figured we could try working *with* our IDE, and
> learn/understand the Eclipse/OSGi plug-in architecture at the same time.
>
> Ok, so the problem is that the plug-in is really specific [more or less!]
> to this mostly java project. As a result, logically, it should co-exist
> with the java-project.
Hmm, if I understand you, then I'm not sure I agree with that premise. If I
understand, it seems like you're intermingling your build tools (ie the
plugin) with your deliverable (ie the Java code). It's sort of like saying
"we use a particular compiler to compile our code, so we want to check that
compiler's source code into the same project as our source code." It's
definitely good to keep them linked in some way, but I'm not sure "in the
same project" is the right linkage.
Clearly we agree on the basic idea here, which is that you want to have a
separation between the plugin artifacts and the rest of your java code -
what I'm suggesting is that the separation really should (logically) be more
extreme than just a subdirectory of your project.
Maybe one way of thinking about this is to realize that Eclipse does not
support nested projects. What you're hoping to do is, in a way, have a
nested project: you want to nest your plugin project as a logical
sub-project of your Java project. Eclipse doesn't know how to do that.
Another way of thinking about it is that overall, Eclipse is not very good
at building conceptually separate artifacts out of a single project. It can
be done (e.g., the JDT Core plug-in project not only builds a plug-in, it
also builds a standalone compiler jar out of a subset of the JDT packages),
but it usually requires extra work in the form of custom ant scripts and
some jiggering of classpaths.
So I think I'm with Ed on this; best to keep the plugin code in a separate
project from the deliverable Java code.
I've encountered a very similar issue, in my work on the JDT annotation
processing tooling (APT). Users want to put their annotations, their
annotation processor code, and their annotated code all in the same project.
But by doing that, they're muddying some important distinctions: for
example, at annotation processing time, their annotation processor is on the
execution classpath, but their annotated code should not be, just like you
would not expect the compiler to be executing the same code it's compiling.
Similarly, it seems to me that your Eclipse plug-in should *not* have the
Java code on its classpath, if the Java code is also what it's operating
upon: that would amount to self-modifying code, and that's a conceptually
Bad Thing nowadays.
***
So, maybe the above will help convince you to separate the projects. If
not, though, how might you work around the limitation? I wonder if one
possibility would be to keep everything out of the root of the project, and
treat it as essentially a build output location; and then write a custom
builder, that would go *before* the PDE or Java builders in the build order,
and that would simply copy the plugin artifacts from some nested directory
into the root directory.
Thanks,
-Walter
|
|
|
Goto Forum:
Current Time: Tue Nov 04 01:03:24 EST 2025
Powered by FUDForum. Page generated in 0.04898 seconds |
Home