Re: packaging wars
Ok, so I reply to myself...
My needs were not to duplicate code (JSR168) between a generic version of my
portlets and the specific portlet (needed by one particular portal
solution).
My first idea was this one because of the intrusive needs due to the portal
solution (liferay, pluto...). These portals needed specific files inside.
But i did not want to depend on a specific portal solution. (that's why i
tried to make these hugly separation of the generic part and the specific
part)
(I wonder such intrusive things can happen!?)
Anyway, i missed something: the JSR286 (portlet V2) that should get me rid
of this.
Portlets V2 may be portable from one portal to another
I am currently reading it. So let' see...
If I misunderstood something, let me know :-)
Thanks.
2008/7/25 Stefan Seidel [EMAIL PROTECTED]
Hi,
I think we have two cases that are similar: Firstly, EJBs where only
deployment descriptors are different. For this we use
+ parent
+- generic
+- specific1
+- specific2
All the sources are in generic/src/main/java.
parent has packagingpom/packaging and
sourceDirectory../generic/src/main/java/sourceDirectory
specific1 and 2 have src/main/resources and different artifactIds.
The other one is about sharing JSP fragments between WARs, and we use the
dependency plugin for that:
+ common
+ war-parent
+- war1
+- war2
+- war3
In war-parent we have:
dependency
artifactIdcommon/artifactId
scopeprovided/scope
/dependency
and
build
plugins
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.1-SNAPSHOT/version
executions
execution
idexpand common JSP fragments/id
goals
goalunpack-dependencies/goal
/goals
phasegenerate-test-resources/phase
configuration
includeGroupIdsgroup.id/includeGroupIds
includeArtifactIdscommon/includeArtifactIds
excludeTransitivetrue/excludeTransitive
includes**/*.jsp*/includes
outputDirectory${project.build.directory}/webapp/outputDirectory
/configuration
/execution
/executions
/plugin
Likewise, you could unpack your resources to
${project.build.directory}/generates-resources and
${project.build.directory}/generated-sources.
HTH,
Stefan
Jean-Paul Vallée wrote:
Thanks, Jeff and manuel
I think i will have a look at overlays, your explainations seem to be what
i
want to do.
But, is there a smarter way to do what i want, ie merge generic and
specific
artifact when building the specific artifact.
--
best regards,
Stefan Seidel
software developer
VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail. [EMAIL PROTECTED]
web.www.vub.de
HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: packaging wars
I'm not sure to complete understand your needs but I think using war overlays may fill your needs : http://maven.apache.org/plugins/maven-war-plugin/overlays.html Create one war with the common stuff Create another with the specific stuff war and with a dependency of type war to the common war. It will merge the common-war with the specific war ... Manuel On Thu, Jul 24, 2008 at 10:23 PM, Jean-Paul Vallée [EMAIL PROTECTED] wrote: Hi, I want to use maven for creating portlets. The portlets will be deployed on a liferay portal So the problem i want to solve is: I do not want to make my portlets specific to a portal implementation, so using maven, i want to create 2 artifacts: com.mycompany:portlet-foo and com.mycompany:portlet-liferay-specific-foo com.mycompany:portlet-liferay-specific-foo depending on com.mycompany:portlet-foo i want in the com.mycompany:portlet-liferay-specific-foo project only the delta(i mean the specific files and modification needed by liferay, pluto, jboss...) and when packaging com.mycompany:portlet-liferay-specific-foo i want it integrate also the files and structure from com.mycompany:portlet-foo As this i could have a solution to have my portlets not specific to a portal solution Other question, even it is not specific to maven (sorry), is there a portlet container plugin that could just make me test my 'not specific' portlets. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: packaging wars
Thanks, Jeff and manuel I think i will have a look at overlays, your explainations seem to be what i want to do. But, is there a smarter way to do what i want, ie merge generic and specific artifact when building the specific artifact.
Re: packaging wars
Hi,
I think we have two cases that are similar: Firstly, EJBs where only
deployment descriptors are different. For this we use
+ parent
+- generic
+- specific1
+- specific2
All the sources are in generic/src/main/java.
parent has packagingpom/packaging and
sourceDirectory../generic/src/main/java/sourceDirectory
specific1 and 2 have src/main/resources and different artifactIds.
The other one is about sharing JSP fragments between WARs, and we use
the dependency plugin for that:
+ common
+ war-parent
+- war1
+- war2
+- war3
In war-parent we have:
dependency
artifactIdcommon/artifactId
scopeprovided/scope
/dependency
and
build
plugins
plugin
artifactIdmaven-dependency-plugin/artifactId
version2.1-SNAPSHOT/version
executions
execution
idexpand common JSP fragments/id
goals
goalunpack-dependencies/goal
/goals
phasegenerate-test-resources/phase
configuration
includeGroupIdsgroup.id/includeGroupIds
includeArtifactIdscommon/includeArtifactIds
excludeTransitivetrue/excludeTransitive
includes**/*.jsp*/includes
outputDirectory${project.build.directory}/webapp/outputDirectory
/configuration
/execution
/executions
/plugin
Likewise, you could unpack your resources to
${project.build.directory}/generates-resources and
${project.build.directory}/generated-sources.
HTH,
Stefan
Jean-Paul Vallée wrote:
Thanks, Jeff and manuel
I think i will have a look at overlays, your explainations seem to be what i
want to do.
But, is there a smarter way to do what i want, ie merge generic and specific
artifact when building the specific artifact.
--
best regards,
Stefan Seidel
software developer
VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail. [EMAIL PROTECTED]
web.www.vub.de
HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: packaging wars
Have a look at cargo.codehaus.org. Jeff MAURY On Thu, Jul 24, 2008 at 10:23 PM, Jean-Paul Vallée [EMAIL PROTECTED] wrote: Hi, I want to use maven for creating portlets. The portlets will be deployed on a liferay portal So the problem i want to solve is: I do not want to make my portlets specific to a portal implementation, so using maven, i want to create 2 artifacts: com.mycompany:portlet-foo and com.mycompany:portlet-liferay-specific-foo com.mycompany:portlet-liferay-specific-foo depending on com.mycompany:portlet-foo i want in the com.mycompany:portlet-liferay-specific-foo project only the delta(i mean the specific files and modification needed by liferay, pluto, jboss...) and when packaging com.mycompany:portlet-liferay-specific-foo i want it integrate also the files and structure from com.mycompany:portlet-foo As this i could have a solution to have my portlets not specific to a portal solution Other question, even it is not specific to maven (sorry), is there a portlet container plugin that could just make me test my 'not specific' portlets. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal
