9:36 a.m.
Max Rydahl Andersen created JBIDE-11166:
-------------------------------------------
Summary: Supporting multi-module projects in OpenShift Deployment
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift, JBossAS/Servers
Reporter: Max Rydahl Andersen
Assignee: Andre Dietisheim
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things we
need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:44 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen updated JBIDE-11166:
----------------------------------------
Assignee: Rob Stryker (was: Andre Dietisheim)
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:44 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-11166:
---------------------------------------------
Assigning to Rob since he is taking the first "shift"
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:02 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Rob Stryker updated JBIDE-11166:
--------------------------------
Attachment: JBIDE-11166.patch
patch to trunk
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
Attachments: JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:12 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Rob Stryker updated JBIDE-11166:
--------------------------------
Attachment: JBIDE-11166.b1.patch
patch for b1
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:41 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Rob Stryker updated JBIDE-11166:
--------------------------------
Attachment: JBIDE-11166.b1.slim.patch
Slimmed down patch for b1 and trunk. Approval?
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:24 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-11166:
---------------------------------------------
simplest patch ever +1 for beta1
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta1, 3.3.0.Beta2
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:01 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen updated JBIDE-11166:
----------------------------------------
Fix Version/s: (was: 3.3.0.Beta1)
basics done in Beta1 - but this issue needs more for beta2.
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta2
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:50 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Andre Dietisheim updated JBIDE-11166:
-------------------------------------
Labels: new_and_noteworthy (was: )
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Max Rydahl Andersen
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:46 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen updated JBIDE-11166:
----------------------------------------
Assignee: Andre Dietisheim (was: Max Rydahl Andersen)
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Andre Dietisheim
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:04 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-11166:
---------------------------------------------
Assigned to Max to find out how to import recursively.
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Andre Dietisheim
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:32 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-11166:
---------------------------------------------
from fbricon: use a scanner.
https://github.com/jbosstools/jbosstools-svn-mirror/blob/trunk/maven/plug...
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Andre Dietisheim
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:42 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Fred Bricon commented on JBIDE-11166:
-------------------------------------
C) is fixed in trunk : import project also import submodules
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Andre Dietisheim
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:30 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen commented on JBIDE-11166:
---------------------------------------------
Only missing part (it seems) is when you do *not* use "Create new project" in
OpenShift wizard but use an existing one the .settings/*openshift* preferences does not
get created.
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:42 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Max Rydahl Andersen resolved JBIDE-11166.
-----------------------------------------
Release Notes Text: OpenShift tooling now works with multi-module maven projects. One
caveat is that if your root project is just a "pom" project it will not show up
as an independent deployed module under the server but doing Publish will perform the
right git commit/push as needed.
Resolution: Done
Since JBIDE-11722 "only" relates to when using "Existing project"
resolving this issue
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:22 a.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Stefan Bunciak closed JBIDE-11166.
----------------------------------
Tested with Java EE app from JBoss central:
{code}
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] multi application ................................. SUCCESS [2.196s]
[INFO] multi EJB module .................................. SUCCESS [26.699s]
[INFO] multi Web module .................................. SUCCESS [11.798s]
[INFO] multi EAR module .................................. SUCCESS [4.623s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.299s
[INFO] Finished at: Fri May 11 06:17:07 EDT 2012
[INFO] Final Memory: 16M/165M
[INFO] ------------------------------------------------------------------------
{code}
Verified in JBoss Developer Studio
Version: 5.0.0.Beta3
Build id: v20120510-2156-H157-Beta3
Build date: 20120510-2156
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:17 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Isaac Rooskov updated JBIDE-11166:
----------------------------------
Release Notes Docs Status: Not Required
Writer: irooskov
This bug fix is not required as it has not been seen by JBDS 5 users. If this is
incorrect, please let me know.
Thanks,
Isaac
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:19 p.m.
[
https://issues.jboss.org/browse/JBIDE-11166?page=com.atlassian.jira.plugi...
]
Isaac Rooskov closed JBIDE-11166.
---------------------------------
Resolution: Done
Reclosing issue now release note status has been set. Thanks for writing up release note
text though, this will be very useful when writing the component overview.
Supporting multi-module projects in OpenShift Deployment
--------------------------------------------------------
Key: JBIDE-11166
URL: https://issues.jboss.org/browse/JBIDE-11166
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers, openshift
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Labels: new_and_noteworthy
Fix For: 3.3.0.Beta3
Attachments: JBIDE-11166.b1.patch, JBIDE-11166.b1.slim.patch, JBIDE-11166.patch
POH5 archetype recently got updated and became the first project layout that requires
support for multimodule project layouts.
What they have is the following:
Aggregator Project "AP" includes two child projects "A" and
"B".
This is the simplest case - but you could also easily have more complex layouts,
i.e. AP includes another aggregatorproject QAP which nest other child projects.
But the key point is that the "root" in OpenShift is considered the Aggegator
project.
And this is the kind of layout we would need to support, and I see the following things
we need to check/implement to make it happen:
A) The "magic" project on our OpenShift server adapter should be allowed to be
any kind of project as long as it has git enabled on it.
B) OpenShift Server Adapter should *not* deploy any child of Aggregator as binary by
default
C) Import of OpenShift Application should be sure it will actually import a multimodule
project.
D) Import of OpenShift App when using existing App would need to do some validity checks
*and* somehow ensure the child projects gets available if they aren't imported (maybe
a warning is enough?)
I belive A and C should be trivially implemented if not already.
B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP
then dont deploy. i.e. /Users/max/ap is parent for project A stored in
/Users/max/ap/x/y/z/a
D is the hard part.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5071
days inactive
5144
days old
jbosstools-issues@lists.jboss.org
17 comments
6 participants
participants (6)
-
Andre Dietisheim (JIRA) -
Fred Bricon (JIRA)
-
Isaac Rooskov (JIRA)
-
Max Rydahl Andersen (JIRA)
-
Rob Stryker (JIRA)
-
Stefan Bunciak (JIRA)