[m2e-wtp-dev] Issue with zip files from overlays in the Deployment Assembly

[Alexandre Palma]

Hello,
My name is Alexandre Palma. I work in the R&D team of company which
produces web-based solutions for the financial market.
We have recently started to adapt our java project's structures to use
Maven, and we have also adhered to m2e and m2e-wtp, from which we greatly
benefit, and they have become vital tools in our development process.
We have, though, a little problem with the way m2e-wtp handles overlays,
which I've been bypassing by making a little modification to it's source
code and building in-house versions of it to fit our need, which I believe
may be the need of other developers as well.

What happens is that we need our modules to be served without being
published, and the zip files m2e-wtp attaches to the deployment assembly
cannot be deployed in this way. But I noticed that m2e-wtp already extracts
the overlays zip files to the directory "target\m2e-wtp\overlays", and if
those directories be attached to the deployment assembly instead of the zip
files it works both ways, publishing and not publishing modules.

The modification I made is in the org.eclipse.m2e.wtp.OverlayConfigurator
class (which is attached in this message) is to attach those directories to
the deployment assembly. It was certainly not done in the best possible
way, given my little understanding of m2e-wtp's architecture and the
eclipse API itself, but I hope it'll at least help to illustrate what is
being proposed.

It'd be greatly appreciated if a change to attach directories instead of
zip files could be incorporated to m2e-wtp. I believe it would have no
impact the way it works and it would also improve performance, since it
would not have to extract zip files every time the application is published.

I apologize for my poor English and hope that you could understand what I
tried to explain.

Regards and thanks in advance,
Alexandre

[Fred Bricon]

Alexandre,

Thanks for the patch but please open feature requests over at
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2E-WTP and attach
patches using the git format (
http://wiki.eclipse.org/Jetty/Contributor/Contributing_Patches#Git_Format_Patch).
You might also need to signe Eclipse's CLA(
http://wiki.eclipse.org/Development_Resources/Contributing_via_Git) I know
I need to put up some contribution guide somewhere but I'm kinda swamped
right now.

Now the technicalities are out of the way, about the actual solution you
propose :
- first of all, unzip is done only once, unless the source zip changed, in
that case it's unzipped again. so there's no performance overhead here
- performance overhead could occur while scanning the unzipped folder to
determine what's to be published, I grant you that :-)
- now if we serve these unzipped folders directly, we lose
maven-war-plugin's inclusion/exclusion mechanism. It may be a problem for
some.
- I'm aware of some issues with Tomcat's "serve without publishing"
feature, which doesn't support the overlay components for some reason.
- In any case I don't believe naively serving the unzipped folders is the
*proper* solution. I may revisit my opinion but I need to spend more time
investigating the issue (and please attach a proper patch so I can review
the diffs).
The whole overlay support in m2e-wtp is rather experimental. so things
could be handled completely differently in the future. I'm not excluding
anything just yet.

Unfortunately, I don't think I'll be able to spend some quality time with
your problem before at least mid-august.

Regards,

Fred Bricon

Post by Alexandre Palma
Hello,
My name is Alexandre Palma. I work in the R&D team of company which
produces web-based solutions for the financial market.
We have recently started to adapt our java project's structures to use
Maven, and we have also adhered to m2e and m2e-wtp, from which we greatly
benefit, and they have become vital tools in our development process.
We have, though, a little problem with the way m2e-wtp handles overlays,
which I've been bypassing by making a little modification to it's source
code and building in-house versions of it to fit our need, which I believe
may be the need of other developers as well.
What happens is that we need our modules to be served without being
published, and the zip files m2e-wtp attaches to the deployment assembly
cannot be deployed in this way. But I noticed that m2e-wtp already extracts
the overlays zip files to the directory "target\m2e-wtp\overlays", and if
those directories be attached to the deployment assembly instead of the zip
files it works both ways, publishing and not publishing modules.
The modification I made is in the org.eclipse.m2e.wtp.OverlayConfigurator
class (which is attached in this message) is to attach those directories to
the deployment assembly. It was certainly not done in the best possible
way, given my little understanding of m2e-wtp's architecture and the
eclipse API itself, but I hope it'll at least help to illustrate what is
being proposed.
It'd be greatly appreciated if a change to attach directories instead of
zip files could be incorporated to m2e-wtp. I believe it would have no
impact the way it works and it would also improve performance, since it
would not have to extract zip files every time the application is published.
I apologize for my poor English and hope that you could understand what I
tried to explain.
Regards and thanks in advance,
Alexandre
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

[Alexandre Palma]

Hi Fred,
Thanks for answering in such short notice and for the much valuable
explanations! Now I can see it was really naive of me to think that could
have found a simple solution that would work on everyone's favor.
It never occurred that maybe it could be a container specific problem, and
indeed I have only tried to get it to work with Tomcat. If you know of any
other containers that support overlay components properly, could you please
tell me which ones? If that would solve our problem, I believe we could
have Tomcat replaced.

There's yet another thing that could solve our problem: We only need to use
the "serve modules without publishing" feature because we have resources in
multi-module projects which we need to be able to edit without having to
restart the application to have the changes applied. If you know of any way
to achieve this without having to use the "serve modules without
publishing" feature, I would be very grateful if you could tell me.

I'm no longer sure whether attaching the patch to the git repository would
be useful. I'll probably have it figured out after running tests with
different containers.
Again, thank you very much for your answer and please excuse me for making
questions which are not only about m2e-wtp.

Regards,
Alexandre

Post by Fred Bricon
Alexandre,
Thanks for the patch but please open feature requests over at
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2E-WTP and attach
patches using the git format (
http://wiki.eclipse.org/Jetty/Contributor/Contributing_Patches#Git_Format_Patch).
You might also need to signe Eclipse's CLA(
http://wiki.eclipse.org/Development_Resources/Contributing_via_Git) I
know I need to put up some contribution guide somewhere but I'm kinda
swamped right now.
Now the technicalities are out of the way, about the actual solution you
- first of all, unzip is done only once, unless the source zip changed, in
that case it's unzipped again. so there's no performance overhead here
- performance overhead could occur while scanning the unzipped folder to
determine what's to be published, I grant you that :-)
- now if we serve these unzipped folders directly, we lose
maven-war-plugin's inclusion/exclusion mechanism. It may be a problem for
some.
- I'm aware of some issues with Tomcat's "serve without publishing"
feature, which doesn't support the overlay components for some reason.
- In any case I don't believe naively serving the unzipped folders is the
*proper* solution. I may revisit my opinion but I need to spend more time
investigating the issue (and please attach a proper patch so I can review
the diffs).
The whole overlay support in m2e-wtp is rather experimental. so things
could be handled completely differently in the future. I'm not excluding
anything just yet.
Unfortunately, I don't think I'll be able to spend some quality time with
your problem before at least mid-august.
Regards,
Fred Bricon

Post by Alexandre Palma
Hello,
My name is Alexandre Palma. I work in the R&D team of company which
produces web-based solutions for the financial market.
We have recently started to adapt our java project's structures to use
Maven, and we have also adhered to m2e and m2e-wtp, from which we greatly
benefit, and they have become vital tools in our development process.
We have, though, a little problem with the way m2e-wtp handles overlays,
which I've been bypassing by making a little modification to it's source
code and building in-house versions of it to fit our need, which I believe
may be the need of other developers as well.
What happens is that we need our modules to be served without being
published, and the zip files m2e-wtp attaches to the deployment assembly
cannot be deployed in this way. But I noticed that m2e-wtp already extracts
the overlays zip files to the directory "target\m2e-wtp\overlays", and if
those directories be attached to the deployment assembly instead of the zip
files it works both ways, publishing and not publishing modules.
The modification I made is in the org.eclipse.m2e.wtp.OverlayConfigurator
class (which is attached in this message) is to attach those directories to
the deployment assembly. It was certainly not done in the best possible
way, given my little understanding of m2e-wtp's architecture and the
eclipse API itself, but I hope it'll at least help to illustrate what is
being proposed.
It'd be greatly appreciated if a change to attach directories instead of
zip files could be incorporated to m2e-wtp. I believe it would have no
impact the way it works and it would also improve performance, since it
would not have to extract zip files every time the application is published.
I apologize for my poor English and hope that you could understand what I
tried to explain.
Regards and thanks in advance,
Alexandre
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

[Fred Bricon]

I don't know of any other server adapter allowing the equivalent of "serve
modules without" publishing (maybe IBM has some for their websphere liberty
thing)
When not using that feature, changed resources from overlay projects (in
the workspace) are supposed to be published to tomcat automatically, I
demoed that during last EclipseCon Europe. If you can provide a use case /
sample project to bugzilla, I could probably be of more help.

Another alternative is to try sonatype webby[1], which has very good
overlay support, but unfortunately, it can't be used along m2e-wtp, hence
Java EE Kepler. You would have to start from a Java Classic distro and
install WTP over, if you need its tooling.

[1]
https://docs.sonatype.org/display/M2ECLIPSE/Integration+with+Maven+WAR+Plugin

Post by Alexandre Palma
Hi Fred,
Thanks for answering in such short notice and for the much valuable
explanations! Now I can see it was really naive of me to think that could
have found a simple solution that would work on everyone's favor.
It never occurred that maybe it could be a container specific problem, and
indeed I have only tried to get it to work with Tomcat. If you know of any
other containers that support overlay components properly, could you please
tell me which ones? If that would solve our problem, I believe we could
have Tomcat replaced.
There's yet another thing that could solve our problem: We only need to
use the "serve modules without publishing" feature because we have
resources in multi-module projects which we need to be able to edit without
having to restart the application to have the changes applied. If you know
of any way to achieve this without having to use the "serve modules without
publishing" feature, I would be very grateful if you could tell me.
I'm no longer sure whether attaching the patch to the git repository would
be useful. I'll probably have it figured out after running tests with
different containers.
Again, thank you very much for your answer and please excuse me for making
questions which are not only about m2e-wtp.
Regards,
Alexandre

Post by Fred Bricon
Alexandre,
Thanks for the patch but please open feature requests over at
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2E-WTP and attach
patches using the git format (
http://wiki.eclipse.org/Jetty/Contributor/Contributing_Patches#Git_Format_Patch).
You might also need to signe Eclipse's CLA(
http://wiki.eclipse.org/Development_Resources/Contributing_via_Git) I
know I need to put up some contribution guide somewhere but I'm kinda
swamped right now.
Now the technicalities are out of the way, about the actual solution you
- first of all, unzip is done only once, unless the source zip changed,
in that case it's unzipped again. so there's no performance overhead here
- performance overhead could occur while scanning the unzipped folder to
determine what's to be published, I grant you that :-)
- now if we serve these unzipped folders directly, we lose
maven-war-plugin's inclusion/exclusion mechanism. It may be a problem for
some.
- I'm aware of some issues with Tomcat's "serve without publishing"
feature, which doesn't support the overlay components for some reason.
- In any case I don't believe naively serving the unzipped folders is the
*proper* solution. I may revisit my opinion but I need to spend more time
investigating the issue (and please attach a proper patch so I can review
the diffs).
The whole overlay support in m2e-wtp is rather experimental. so things
could be handled completely differently in the future. I'm not excluding
anything just yet.
Unfortunately, I don't think I'll be able to spend some quality time with
your problem before at least mid-august.
Regards,
Fred Bricon

Post by Alexandre Palma
Hello,
My name is Alexandre Palma. I work in the R&D team of company which
produces web-based solutions for the financial market.
We have recently started to adapt our java project's structures to use
Maven, and we have also adhered to m2e and m2e-wtp, from which we greatly
benefit, and they have become vital tools in our development process.
We have, though, a little problem with the way m2e-wtp handles overlays,
which I've been bypassing by making a little modification to it's source
code and building in-house versions of it to fit our need, which I believe
may be the need of other developers as well.
What happens is that we need our modules to be served without being
published, and the zip files m2e-wtp attaches to the deployment assembly
cannot be deployed in this way. But I noticed that m2e-wtp already extracts
the overlays zip files to the directory "target\m2e-wtp\overlays", and if
those directories be attached to the deployment assembly instead of the zip
files it works both ways, publishing and not publishing modules.
The modification I made is in the
org.eclipse.m2e.wtp.OverlayConfigurator class (which is attached in this
message) is to attach those directories to the deployment assembly. It was
certainly not done in the best possible way, given my little understanding
of m2e-wtp's architecture and the eclipse API itself, but I hope it'll at
least help to illustrate what is being proposed.
It'd be greatly appreciated if a change to attach directories instead of
zip files could be incorporated to m2e-wtp. I believe it would have no
impact the way it works and it would also improve performance, since it
would not have to extract zip files every time the application is published.
I apologize for my poor English and hope that you could understand what
I tried to explain.
Regards and thanks in advance,
Alexandre
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

[Max Andersen]

FYI If you just want to have updatable Content using jboss with jboss tools server adapter allows updates without a restart since we deploy exploded by default.

Not sure it fits your needs but from your description it sounds like it.

/max (sent from my phone)

I don't know of any other server adapter allowing the equivalent of "serve modules without" publishing (maybe IBM has some for their websphere liberty thing)
When not using that feature, changed resources from overlay projects (in the workspace) are supposed to be published to tomcat automatically, I demoed that during last EclipseCon Europe. If you can provide a use case / sample project to bugzilla, I could probably be of more help.
Another alternative is to try sonatype webby[1], which has very good overlay support, but unfortunately, it can't be used along m2e-wtp, hence Java EE Kepler. You would have to start from a Java Classic distro and install WTP over, if you need its tooling.
[1] https://docs.sonatype.org/display/M2ECLIPSE/Integration+with+Maven+WAR+Plugin

Post by Alexandre Palma
Hi Fred,
Thanks for answering in such short notice and for the much valuable explanations! Now I can see it was really naive of me to think that could have found a simple solution that would work on everyone's favor.
It never occurred that maybe it could be a container specific problem, and indeed I have only tried to get it to work with Tomcat. If you know of any other containers that support overlay components properly, could you please tell me which ones? If that would solve our problem, I believe we could have Tomcat replaced.
There's yet another thing that could solve our problem: We only need to use the "serve modules without publishing" feature because we have resources in multi-module projects which we need to be able to edit without having to restart the application to have the changes applied. If you know of any way to achieve this without having to use the "serve modules without publishing" feature, I would be very grateful if you could tell me.
I'm no longer sure whether attaching the patch to the git repository would be useful. I'll probably have it figured out after running tests with different containers.
Again, thank you very much for your answer and please excuse me for making questions which are not only about m2e-wtp.
Regards,
Alexandre

Post by Fred Bricon
Alexandre,
Thanks for the patch but please open feature requests over at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2E-WTP and attach patches using the git format (http://wiki.eclipse.org/Jetty/Contributor/Contributing_Patches#Git_Format_Patch). You might also need to signe Eclipse's CLA(http://wiki.eclipse.org/Development_Resources/Contributing_via_Git) I know I need to put up some contribution guide somewhere but I'm kinda swamped right now.
- first of all, unzip is done only once, unless the source zip changed, in that case it's unzipped again. so there's no performance overhead here
- performance overhead could occur while scanning the unzipped folder to determine what's to be published, I grant you that :-)
- now if we serve these unzipped folders directly, we lose maven-war-plugin's inclusion/exclusion mechanism. It may be a problem for some.
- I'm aware of some issues with Tomcat's "serve without publishing" feature, which doesn't support the overlay components for some reason.
- In any case I don't believe naively serving the unzipped folders is the *proper* solution. I may revisit my opinion but I need to spend more time investigating the issue (and please attach a proper patch so I can review the diffs).
The whole overlay support in m2e-wtp is rather experimental. so things could be handled completely differently in the future. I'm not excluding anything just yet.
Unfortunately, I don't think I'll be able to spend some quality time with your problem before at least mid-august.
Regards,
Fred Bricon

Post by Alexandre Palma
Hello,
My name is Alexandre Palma. I work in the R&D team of company which produces web-based solutions for the financial market.
We have recently started to adapt our java project's structures to use Maven, and we have also adhered to m2e and m2e-wtp, from which we greatly benefit, and they have become vital tools in our development process.
We have, though, a little problem with the way m2e-wtp handles overlays, which I've been bypassing by making a little modification to it's source code and building in-house versions of it to fit our need, which I believe may be the need of other developers as well.
What happens is that we need our modules to be served without being published, and the zip files m2e-wtp attaches to the deployment assembly cannot be deployed in this way. But I noticed that m2e-wtp already extracts the overlays zip files to the directory "target\m2e-wtp\overlays", and if those directories be attached to the deployment assembly instead of the zip files it works both ways, publishing and not publishing modules.
The modification I made is in the org.eclipse.m2e.wtp.OverlayConfigurator class (which is attached in this message) is to attach those directories to the deployment assembly. It was certainly not done in the best possible way, given my little understanding of m2e-wtp's architecture and the eclipse API itself, but I hope it'll at least help to illustrate what is being proposed.
It'd be greatly appreciated if a change to attach directories instead of zip files could be incorporated to m2e-wtp. I believe it would have no impact the way it works and it would also improve performance, since it would not have to extract zip files every time the application is published.
I apologize for my poor English and hope that you could understand what I tried to explain.
Regards and thanks in advance,
Alexandre
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-wtp-dev mailing list
http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev