| Project export/import and the "derived" flag [message #326952] |
Thu, 03 April 2008 15:53  |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
I've just realized that files marked as "Derived" lose that setting when
their project is exported and then imported. The explanation is fairly
obvious (I think): the derived attribute is not stored in the physical
file (probably in the workspace/.metadata somewhere) so it can't travel
with the file into the exported ZIP/JAR.
The problem is that this causes problems with the product I'm working on
because its custom code generation builder (based on JET) uses the
derived flag to know what files it can safely blow away during a clean
build and which ones to leave alone. If a file is marked derived, our
policy is that the builder is free to delete it and re-generate; but
files without the derived flag are not touched. So when importing one of
our projects from an exported ZIP, all the generated files get marked as
not derived and thus clean builds don't work correctly.
I imagine EMF faces the same dilemma and must have solved it somehow, right?
Any EMF-specific or platform-general ideas for avoiding or working
around this issue (without requiring user interaction)?
Eric
|
|
|
| Re: Project export/import and the "derived" flag [message #326963 is a reply to message #326952] |
Thu, 03 April 2008 17:38  |
| Eclipse User |
|
|
|
Originally posted by: eclipseng.arthorne.com
There is some discussion of this here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=150578
Do you control the export process? I.e., is it your own export wizard?
If so, perhaps you could strip out derived files during export, so they
never appear at import time. Come to think of it, this would make sense
as a general option in the platform export wizards.
--
Eric Rizzo wrote:
> I've just realized that files marked as "Derived" lose that setting when
> their project is exported and then imported. The explanation is fairly
> obvious (I think): the derived attribute is not stored in the physical
> file (probably in the workspace/.metadata somewhere) so it can't travel
> with the file into the exported ZIP/JAR.
> The problem is that this causes problems with the product I'm working on
> because its custom code generation builder (based on JET) uses the
> derived flag to know what files it can safely blow away during a clean
> build and which ones to leave alone. If a file is marked derived, our
> policy is that the builder is free to delete it and re-generate; but
> files without the derived flag are not touched. So when importing one of
> our projects from an exported ZIP, all the generated files get marked as
> not derived and thus clean builds don't work correctly.
> I imagine EMF faces the same dilemma and must have solved it somehow,
> right?
>
> Any EMF-specific or platform-general ideas for avoiding or working
> around this issue (without requiring user interaction)?
>
> Eric
|
|
|
| Re: Project export/import and the "derived" flag [message #326968 is a reply to message #326963] |
Thu, 03 April 2008 18:25 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
John,
It would indeed make really good sense to not export derived files, or
at the very least an option on the wizard for that. I often export
projects and find it a bit annoying that the bin folder ends up with all
kinds of .class files that I really don't need to be sent to the
recipient because of course the project will be rebuilt and hence those
files are just taking up unneeded space. I think the bin folder itself
is marked derived and when I delete it, it comes back, so I think this
would work well; though the project doesn't rebuild, which seems a
little odd...
John Arthorne wrote:
> There is some discussion of this here:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=150578
>
> Do you control the export process? I.e., is it your own export wizard?
> If so, perhaps you could strip out derived files during export, so
> they never appear at import time. Come to think of it, this would make
> sense as a general option in the platform export wizards.
> --
>
>
> Eric Rizzo wrote:
>> I've just realized that files marked as "Derived" lose that setting
>> when their project is exported and then imported. The explanation is
>> fairly obvious (I think): the derived attribute is not stored in the
>> physical file (probably in the workspace/.metadata somewhere) so it
>> can't travel with the file into the exported ZIP/JAR.
>> The problem is that this causes problems with the product I'm working
>> on because its custom code generation builder (based on JET) uses the
>> derived flag to know what files it can safely blow away during a
>> clean build and which ones to leave alone. If a file is marked
>> derived, our policy is that the builder is free to delete it and
>> re-generate; but files without the derived flag are not touched. So
>> when importing one of our projects from an exported ZIP, all the
>> generated files get marked as not derived and thus clean builds don't
>> work correctly.
>> I imagine EMF faces the same dilemma and must have solved it somehow,
>> right?
>>
>> Any EMF-specific or platform-general ideas for avoiding or working
>> around this issue (without requiring user interaction)?
>>
>> Eric
|
|
|
| Re: Project export/import and the "derived" flag [message #326981 is a reply to message #326963] |
Thu, 03 April 2008 20:35 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
John Arthorne wrote:
> There is some discussion of this here:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=150578
>
> Do you control the export process? I.e., is it your own export wizard?
> If so, perhaps you could strip out derived files during export, so they
> never appear at import time. Come to think of it, this would make sense
> as a general option in the platform export wizards.
We plan to build custom export/import wizards; I've recommended to my
client that we bump up the priority of that task given this issue, but
there are a lot of tasks they consider higher priority.
So do you want a bugzilla to add an "Exclude derived resources" option
on the platform export wizards? I'm surprised there isn't one already...
Eric
>
> Eric Rizzo wrote:
>> I've just realized that files marked as "Derived" lose that setting
>> when their project is exported and then imported. The explanation is
>> fairly obvious (I think): the derived attribute is not stored in the
>> physical file (probably in the workspace/.metadata somewhere) so it
>> can't travel with the file into the exported ZIP/JAR.
>> The problem is that this causes problems with the product I'm working
>> on because its custom code generation builder (based on JET) uses the
>> derived flag to know what files it can safely blow away during a clean
>> build and which ones to leave alone. If a file is marked derived, our
>> policy is that the builder is free to delete it and re-generate; but
>> files without the derived flag are not touched. So when importing one
>> of our projects from an exported ZIP, all the generated files get
>> marked as not derived and thus clean builds don't work correctly.
>> I imagine EMF faces the same dilemma and must have solved it somehow,
>> right?
>>
>> Any EMF-specific or platform-general ideas for avoiding or working
>> around this issue (without requiring user interaction)?
>>
>> Eric
|
|
|
| Re: Project export/import and the "derived" flag [message #326987 is a reply to message #326981] |
Thu, 03 April 2008 22:20 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:ft3f2f$g9c$1@build.eclipse.org...
> So do you want a bugzilla to add an "Exclude derived resources" option on
> the platform export wizards? I'm surprised there isn't one already...
+1. This hits us in APT, too; APT-generated files are marked as derived,
and blown away on a clean. But there's a lot of code in serving the
function of being paranoid about what happens when a project is exported and
then re-imported; we can no longer tell if something is "ours".
|
|
|
Powered by
FUDForum. Page generated in 0.04366 seconds
] 
Search
Help
Register
Login
Home
