Home » Eclipse Projects » Technology Project and PMC » Eclipse Branding - feature.xml Version Numbers
| Eclipse Branding - feature.xml Version Numbers [message #49661] |
Thu, 20 March 2003 18:09  |
Eclipse User |
|
|
|
Originally posted by: Kevin.clark.accessbc.com.nospam
I'm going to try and explain my problem as best I can.
The short-winded version:
I've got a branded primary feature and plug-in that I've created for
version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
as I try to move to 2.1 (or any other version) my feature.xml file no
longer points to the right versions of all the plug-ins. Therefore,
creating errors in my primary feature.
I want to keep the same feature.xml everytime my office upgrades to a new
version of Eclipse. I don't want to have to go back and touch my branded
files unless something fundamental changes in the eclipse structure. Is
there any way I can do this?
I've tried deleting the version numbers from my feature.xml file and just
leaving the id's. This should work because there will -never- be more than
one version of a plugin or feature installed on a computer. Except,
Eclipse doesn't like not having version numbers and ignores my primary
feature. It's somewhat strange behaviour really... The icons, about screen
and welcome screen all appear correctly. But things like the splash screen
doesn't. The primary feature that I've created doesn't even appear in the
install/update perspective.
The long-winded version... Skip this if you think you understand the
question!
I've automated the branding process for Eclipse by creating a program that
goes through and customizes everything. It's actually quite a simple
program. It is a wizard that accepts:
- An eclipse version .zip file
- All 3rd Party plug-ins in .zip files
- And my branded feature and plug-in in .zip file
The "customizer" goes and unzips all these files into a standard Eclipse
directory structure; all the files are tied together, creating a branded
version of Eclipse. Then this directory structure gets distributed to the
workstations in the office. The program also goes through the entire
Eclipse directory structure, and REMOVES the version numbers from the
folder names. I realize this doesn't change or determine the version
number of the plug-in or feature. However, it does enforce the one plug-in
version at a time rule. For example: If you install a newer version of the
plugin overtop of the old one, it will be overwritten, not create a
separate directory for itself.
Basically, everytime I go to a new version of eclipse, all I should have
to do is run the customizer on it. Get my brand new product, and
distribute it. I don't want to have to "re-brand" anything by hand. I
don't want to have to edit the .zip file with the branding in it.
Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
could do this programmatically. I could create a new feature.xml file
everytime I ran the customizer, but it will get complicated. I just want
to know if there is a simpler way of creating the feature.xml so that it
will be compatible with all forseeable future upgrades.
End long-winded version....
Feel free to ask me any further questions!
Kevin
|
|
|
| Re: Eclipse Branding - feature.xml Version Numbers [message #49753 is a reply to message #49661] |
Fri, 21 March 2003 11:53  |
 Peter Manahan
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Should be asked in the eclipse.tools newsgroup.
Have a question though. Why are you including the eclipse features in
your branding? Normally the only reason for doing that is to restrict
access to where it can be updated from. Which would mean you would WANT
to increment the branding feature version. Since you don't want to do
that just remove the includes for eclipse's features. Does that work?
Peter
Kevbo wrote:
> I'm going to try and explain my problem as best I can.
>
> The short-winded version:
> I've got a branded primary feature and plug-in that I've created for
> version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
> as I try to move to 2.1 (or any other version) my feature.xml file no
> longer points to the right versions of all the plug-ins. Therefore,
> creating errors in my primary feature.
>
> I want to keep the same feature.xml everytime my office upgrades to a new
> version of Eclipse. I don't want to have to go back and touch my branded
> files unless something fundamental changes in the eclipse structure. Is
> there any way I can do this?
>
> I've tried deleting the version numbers from my feature.xml file and just
> leaving the id's. This should work because there will -never- be more than
> one version of a plugin or feature installed on a computer. Except,
> Eclipse doesn't like not having version numbers and ignores my primary
> feature. It's somewhat strange behaviour really... The icons, about screen
> and welcome screen all appear correctly. But things like the splash screen
> doesn't. The primary feature that I've created doesn't even appear in the
> install/update perspective.
>
> The long-winded version... Skip this if you think you understand the
> question!
>
> I've automated the branding process for Eclipse by creating a program that
> goes through and customizes everything. It's actually quite a simple
> program. It is a wizard that accepts:
> - An eclipse version .zip file
> - All 3rd Party plug-ins in .zip files
> - And my branded feature and plug-in in .zip file
>
> The "customizer" goes and unzips all these files into a standard Eclipse
> directory structure; all the files are tied together, creating a branded
> version of Eclipse. Then this directory structure gets distributed to the
> workstations in the office. The program also goes through the entire
> Eclipse directory structure, and REMOVES the version numbers from the
> folder names. I realize this doesn't change or determine the version
> number of the plug-in or feature. However, it does enforce the one plug-in
> version at a time rule. For example: If you install a newer version of the
> plugin overtop of the old one, it will be overwritten, not create a
> separate directory for itself.
>
> Basically, everytime I go to a new version of eclipse, all I should have
> to do is run the customizer on it. Get my brand new product, and
> distribute it. I don't want to have to "re-brand" anything by hand. I
> don't want to have to edit the .zip file with the branding in it.
>
> Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
> could do this programmatically. I could create a new feature.xml file
> everytime I ran the customizer, but it will get complicated. I just want
> to know if there is a simpler way of creating the feature.xml so that it
> will be compatible with all forseeable future upgrades.
>
> End long-winded version....
>
>
> Feel free to ask me any further questions!
> Kevin
>
|
|
|
| Re: Eclipse Branding - feature.xml Version Numbers [message #49783 is a reply to message #49753] |
Fri, 21 March 2003 16:57 |
| Eclipse User |
|
|
|
Originally posted by: Kevin.clark.accessbc.com.nospam
Ah, sorry about the wrong newsgroup. I've responded to you in
eclipse.tools.
What exactly is this newsgroup used for then? From what I can gather, the
eclipse.tools group is mainly based on programming Eclipse and using the
tools it has. While this group is more based on the framework of eclipse
and how to use it. That's why I chose this group to post my question,
cause it's more of a framework question than a programming question. Sorry
for the misunderstanding!
Peter Manahan wrote:
> Should be asked in the eclipse.tools newsgroup.
> Have a question though. Why are you including the eclipse features in
> your branding? Normally the only reason for doing that is to restrict
> access to where it can be updated from. Which would mean you would WANT
> to increment the branding feature version. Since you don't want to do
> that just remove the includes for eclipse's features. Does that work?
> Peter
> Kevbo wrote:
> > I'm going to try and explain my problem as best I can.
> >
> > The short-winded version:
> > I've got a branded primary feature and plug-in that I've created for
> > version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
> > as I try to move to 2.1 (or any other version) my feature.xml file no
> > longer points to the right versions of all the plug-ins. Therefore,
> > creating errors in my primary feature.
> >
> > I want to keep the same feature.xml everytime my office upgrades to a new
> > version of Eclipse. I don't want to have to go back and touch my branded
> > files unless something fundamental changes in the eclipse structure. Is
> > there any way I can do this?
> >
> > I've tried deleting the version numbers from my feature.xml file and just
> > leaving the id's. This should work because there will -never- be more than
> > one version of a plugin or feature installed on a computer. Except,
> > Eclipse doesn't like not having version numbers and ignores my primary
> > feature. It's somewhat strange behaviour really... The icons, about screen
> > and welcome screen all appear correctly. But things like the splash screen
> > doesn't. The primary feature that I've created doesn't even appear in the
> > install/update perspective.
> >
> > The long-winded version... Skip this if you think you understand the
> > question!
> >
> > I've automated the branding process for Eclipse by creating a program that
> > goes through and customizes everything. It's actually quite a simple
> > program. It is a wizard that accepts:
> > - An eclipse version .zip file
> > - All 3rd Party plug-ins in .zip files
> > - And my branded feature and plug-in in .zip file
> >
> > The "customizer" goes and unzips all these files into a standard Eclipse
> > directory structure; all the files are tied together, creating a branded
> > version of Eclipse. Then this directory structure gets distributed to the
> > workstations in the office. The program also goes through the entire
> > Eclipse directory structure, and REMOVES the version numbers from the
> > folder names. I realize this doesn't change or determine the version
> > number of the plug-in or feature. However, it does enforce the one plug-in
> > version at a time rule. For example: If you install a newer version of the
> > plugin overtop of the old one, it will be overwritten, not create a
> > separate directory for itself.
> >
> > Basically, everytime I go to a new version of eclipse, all I should have
> > to do is run the customizer on it. Get my brand new product, and
> > distribute it. I don't want to have to "re-brand" anything by hand. I
> > don't want to have to edit the .zip file with the branding in it.
> >
> > Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
> > could do this programmatically. I could create a new feature.xml file
> > everytime I ran the customizer, but it will get complicated. I just want
> > to know if there is a simpler way of creating the feature.xml so that it
> > will be compatible with all forseeable future upgrades.
> >
> > End long-winded version....
> >
> >
> > Feel free to ask me any further questions!
> > Kevin
> >
|
|
|
| Re: Eclipse Branding - feature.xml Version Numbers [message #49813 is a reply to message #49753] |
Fri, 21 March 2003 17:11 |
| Eclipse User |
|
|
|
Originally posted by: Kevin.clark.accessbc.com.nospam
Yes, that worked. I had a big misunderstanding of the role of features,
but I think I understand them now. They are more for updating than
anything else.
Thanks for the help!
Kevin
Peter Manahan wrote:
> Should be asked in the eclipse.tools newsgroup.
> Have a question though. Why are you including the eclipse features in
> your branding? Normally the only reason for doing that is to restrict
> access to where it can be updated from. Which would mean you would WANT
> to increment the branding feature version. Since you don't want to do
> that just remove the includes for eclipse's features. Does that work?
> Peter
> Kevbo wrote:
> > I'm going to try and explain my problem as best I can.
> >
> > The short-winded version:
> > I've got a branded primary feature and plug-in that I've created for
> > version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
> > as I try to move to 2.1 (or any other version) my feature.xml file no
> > longer points to the right versions of all the plug-ins. Therefore,
> > creating errors in my primary feature.
> >
> > I want to keep the same feature.xml everytime my office upgrades to a new
> > version of Eclipse. I don't want to have to go back and touch my branded
> > files unless something fundamental changes in the eclipse structure. Is
> > there any way I can do this?
> >
> > I've tried deleting the version numbers from my feature.xml file and just
> > leaving the id's. This should work because there will -never- be more than
> > one version of a plugin or feature installed on a computer. Except,
> > Eclipse doesn't like not having version numbers and ignores my primary
> > feature. It's somewhat strange behaviour really... The icons, about screen
> > and welcome screen all appear correctly. But things like the splash screen
> > doesn't. The primary feature that I've created doesn't even appear in the
> > install/update perspective.
> >
> > The long-winded version... Skip this if you think you understand the
> > question!
> >
> > I've automated the branding process for Eclipse by creating a program that
> > goes through and customizes everything. It's actually quite a simple
> > program. It is a wizard that accepts:
> > - An eclipse version .zip file
> > - All 3rd Party plug-ins in .zip files
> > - And my branded feature and plug-in in .zip file
> >
> > The "customizer" goes and unzips all these files into a standard Eclipse
> > directory structure; all the files are tied together, creating a branded
> > version of Eclipse. Then this directory structure gets distributed to the
> > workstations in the office. The program also goes through the entire
> > Eclipse directory structure, and REMOVES the version numbers from the
> > folder names. I realize this doesn't change or determine the version
> > number of the plug-in or feature. However, it does enforce the one plug-in
> > version at a time rule. For example: If you install a newer version of the
> > plugin overtop of the old one, it will be overwritten, not create a
> > separate directory for itself.
> >
> > Basically, everytime I go to a new version of eclipse, all I should have
> > to do is run the customizer on it. Get my brand new product, and
> > distribute it. I don't want to have to "re-brand" anything by hand. I
> > don't want to have to edit the .zip file with the branding in it.
> >
> > Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
> > could do this programmatically. I could create a new feature.xml file
> > everytime I ran the customizer, but it will get complicated. I just want
> > to know if there is a simpler way of creating the feature.xml so that it
> > will be compatible with all forseeable future upgrades.
> >
> > End long-winded version....
> >
> >
> > Feel free to ask me any further questions!
> > Kevin
> >
|
|
|
| Re: Eclipse Branding - feature.xml Version Numbers [message #591822 is a reply to message #49661] |
Fri, 21 March 2003 11:53 |
Peter Manahan
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Should be asked in the eclipse.tools newsgroup.
Have a question though. Why are you including the eclipse features in
your branding? Normally the only reason for doing that is to restrict
access to where it can be updated from. Which would mean you would WANT
to increment the branding feature version. Since you don't want to do
that just remove the includes for eclipse's features. Does that work?
Peter
Kevbo wrote:
> I'm going to try and explain my problem as best I can.
>
> The short-winded version:
> I've got a branded primary feature and plug-in that I've created for
> version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
> as I try to move to 2.1 (or any other version) my feature.xml file no
> longer points to the right versions of all the plug-ins. Therefore,
> creating errors in my primary feature.
>
> I want to keep the same feature.xml everytime my office upgrades to a new
> version of Eclipse. I don't want to have to go back and touch my branded
> files unless something fundamental changes in the eclipse structure. Is
> there any way I can do this?
>
> I've tried deleting the version numbers from my feature.xml file and just
> leaving the id's. This should work because there will -never- be more than
> one version of a plugin or feature installed on a computer. Except,
> Eclipse doesn't like not having version numbers and ignores my primary
> feature. It's somewhat strange behaviour really... The icons, about screen
> and welcome screen all appear correctly. But things like the splash screen
> doesn't. The primary feature that I've created doesn't even appear in the
> install/update perspective.
>
> The long-winded version... Skip this if you think you understand the
> question!
>
> I've automated the branding process for Eclipse by creating a program that
> goes through and customizes everything. It's actually quite a simple
> program. It is a wizard that accepts:
> - An eclipse version .zip file
> - All 3rd Party plug-ins in .zip files
> - And my branded feature and plug-in in .zip file
>
> The "customizer" goes and unzips all these files into a standard Eclipse
> directory structure; all the files are tied together, creating a branded
> version of Eclipse. Then this directory structure gets distributed to the
> workstations in the office. The program also goes through the entire
> Eclipse directory structure, and REMOVES the version numbers from the
> folder names. I realize this doesn't change or determine the version
> number of the plug-in or feature. However, it does enforce the one plug-in
> version at a time rule. For example: If you install a newer version of the
> plugin overtop of the old one, it will be overwritten, not create a
> separate directory for itself.
>
> Basically, everytime I go to a new version of eclipse, all I should have
> to do is run the customizer on it. Get my brand new product, and
> distribute it. I don't want to have to "re-brand" anything by hand. I
> don't want to have to edit the .zip file with the branding in it.
>
> Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
> could do this programmatically. I could create a new feature.xml file
> everytime I ran the customizer, but it will get complicated. I just want
> to know if there is a simpler way of creating the feature.xml so that it
> will be compatible with all forseeable future upgrades.
>
> End long-winded version....
>
>
> Feel free to ask me any further questions!
> Kevin
>
|
|
|
| Re: Eclipse Branding - feature.xml Version Numbers [message #591835 is a reply to message #49753] |
Fri, 21 March 2003 16:57 |
| Eclipse User |
|
|
|
Originally posted by: Kevin.clark.accessbc.com.nospam
Ah, sorry about the wrong newsgroup. I've responded to you in
eclipse.tools.
What exactly is this newsgroup used for then? From what I can gather, the
eclipse.tools group is mainly based on programming Eclipse and using the
tools it has. While this group is more based on the framework of eclipse
and how to use it. That's why I chose this group to post my question,
cause it's more of a framework question than a programming question. Sorry
for the misunderstanding!
Peter Manahan wrote:
> Should be asked in the eclipse.tools newsgroup.
> Have a question though. Why are you including the eclipse features in
> your branding? Normally the only reason for doing that is to restrict
> access to where it can be updated from. Which would mean you would WANT
> to increment the branding feature version. Since you don't want to do
> that just remove the includes for eclipse's features. Does that work?
> Peter
> Kevbo wrote:
> > I'm going to try and explain my problem as best I can.
> >
> > The short-winded version:
> > I've got a branded primary feature and plug-in that I've created for
> > version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
> > as I try to move to 2.1 (or any other version) my feature.xml file no
> > longer points to the right versions of all the plug-ins. Therefore,
> > creating errors in my primary feature.
> >
> > I want to keep the same feature.xml everytime my office upgrades to a new
> > version of Eclipse. I don't want to have to go back and touch my branded
> > files unless something fundamental changes in the eclipse structure. Is
> > there any way I can do this?
> >
> > I've tried deleting the version numbers from my feature.xml file and just
> > leaving the id's. This should work because there will -never- be more than
> > one version of a plugin or feature installed on a computer. Except,
> > Eclipse doesn't like not having version numbers and ignores my primary
> > feature. It's somewhat strange behaviour really... The icons, about screen
> > and welcome screen all appear correctly. But things like the splash screen
> > doesn't. The primary feature that I've created doesn't even appear in the
> > install/update perspective.
> >
> > The long-winded version... Skip this if you think you understand the
> > question!
> >
> > I've automated the branding process for Eclipse by creating a program that
> > goes through and customizes everything. It's actually quite a simple
> > program. It is a wizard that accepts:
> > - An eclipse version .zip file
> > - All 3rd Party plug-ins in .zip files
> > - And my branded feature and plug-in in .zip file
> >
> > The "customizer" goes and unzips all these files into a standard Eclipse
> > directory structure; all the files are tied together, creating a branded
> > version of Eclipse. Then this directory structure gets distributed to the
> > workstations in the office. The program also goes through the entire
> > Eclipse directory structure, and REMOVES the version numbers from the
> > folder names. I realize this doesn't change or determine the version
> > number of the plug-in or feature. However, it does enforce the one plug-in
> > version at a time rule. For example: If you install a newer version of the
> > plugin overtop of the old one, it will be overwritten, not create a
> > separate directory for itself.
> >
> > Basically, everytime I go to a new version of eclipse, all I should have
> > to do is run the customizer on it. Get my brand new product, and
> > distribute it. I don't want to have to "re-brand" anything by hand. I
> > don't want to have to edit the .zip file with the branding in it.
> >
> > Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
> > could do this programmatically. I could create a new feature.xml file
> > everytime I ran the customizer, but it will get complicated. I just want
> > to know if there is a simpler way of creating the feature.xml so that it
> > will be compatible with all forseeable future upgrades.
> >
> > End long-winded version....
> >
> >
> > Feel free to ask me any further questions!
> > Kevin
> >
|
|
|
| Re: Eclipse Branding - feature.xml Version Numbers [message #591844 is a reply to message #49753] |
Fri, 21 March 2003 17:11 |
| Eclipse User |
|
|
|
Originally posted by: Kevin.clark.accessbc.com.nospam
Yes, that worked. I had a big misunderstanding of the role of features,
but I think I understand them now. They are more for updating than
anything else.
Thanks for the help!
Kevin
Peter Manahan wrote:
> Should be asked in the eclipse.tools newsgroup.
> Have a question though. Why are you including the eclipse features in
> your branding? Normally the only reason for doing that is to restrict
> access to where it can be updated from. Which would mean you would WANT
> to increment the branding feature version. Since you don't want to do
> that just remove the includes for eclipse's features. Does that work?
> Peter
> Kevbo wrote:
> > I'm going to try and explain my problem as best I can.
> >
> > The short-winded version:
> > I've got a branded primary feature and plug-in that I've created for
> > version 2.0.2 of Eclipse. It works perfectly for that version, but as soon
> > as I try to move to 2.1 (or any other version) my feature.xml file no
> > longer points to the right versions of all the plug-ins. Therefore,
> > creating errors in my primary feature.
> >
> > I want to keep the same feature.xml everytime my office upgrades to a new
> > version of Eclipse. I don't want to have to go back and touch my branded
> > files unless something fundamental changes in the eclipse structure. Is
> > there any way I can do this?
> >
> > I've tried deleting the version numbers from my feature.xml file and just
> > leaving the id's. This should work because there will -never- be more than
> > one version of a plugin or feature installed on a computer. Except,
> > Eclipse doesn't like not having version numbers and ignores my primary
> > feature. It's somewhat strange behaviour really... The icons, about screen
> > and welcome screen all appear correctly. But things like the splash screen
> > doesn't. The primary feature that I've created doesn't even appear in the
> > install/update perspective.
> >
> > The long-winded version... Skip this if you think you understand the
> > question!
> >
> > I've automated the branding process for Eclipse by creating a program that
> > goes through and customizes everything. It's actually quite a simple
> > program. It is a wizard that accepts:
> > - An eclipse version .zip file
> > - All 3rd Party plug-ins in .zip files
> > - And my branded feature and plug-in in .zip file
> >
> > The "customizer" goes and unzips all these files into a standard Eclipse
> > directory structure; all the files are tied together, creating a branded
> > version of Eclipse. Then this directory structure gets distributed to the
> > workstations in the office. The program also goes through the entire
> > Eclipse directory structure, and REMOVES the version numbers from the
> > folder names. I realize this doesn't change or determine the version
> > number of the plug-in or feature. However, it does enforce the one plug-in
> > version at a time rule. For example: If you install a newer version of the
> > plugin overtop of the old one, it will be overwritten, not create a
> > separate directory for itself.
> >
> > Basically, everytime I go to a new version of eclipse, all I should have
> > to do is run the customizer on it. Get my brand new product, and
> > distribute it. I don't want to have to "re-brand" anything by hand. I
> > don't want to have to edit the .zip file with the branding in it.
> >
> > Somehow, the feature.xml file has to be updated along with Eclipse. Now, I
> > could do this programmatically. I could create a new feature.xml file
> > everytime I ran the customizer, but it will get complicated. I just want
> > to know if there is a simpler way of creating the feature.xml so that it
> > will be compatible with all forseeable future upgrades.
> >
> > End long-winded version....
> >
> >
> > Feel free to ask me any further questions!
> > Kevin
> >
|
|
|
Goto Forum:
Current Time: Wed Apr 24 13:53:06 GMT 2024
Powered by FUDForum. Page generated in 0.03223 seconds |
] 
Search
Help
Register
Login
Home
