You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jean-Paul Vallée <je...@gmail.com> on 2008/07/24 22:23:54 UTC
packaging wars
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: packaging wars
Posted by Jeff MAURY <je...@jeffmaury.com>.
Have a look at cargo.codehaus.org.
Jeff MAURY
On Thu, Jul 24, 2008 at 10:23 PM, Jean-Paul Vallée <
jeanpaul.vallee1@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
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
Re: packaging wars
Posted by Jean-Paul Vallée <je...@gmail.com>.
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 <ss...@vub.de>
> 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 <packaging>pom</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>
> <artifactId>common</artifactId>
> <scope>provided</scope>
> </dependency>
> and
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-dependency-plugin</artifactId>
> <version>2.1-SNAPSHOT</version>
> <executions>
> <execution>
> <id>expand common JSP fragments</id>
> <goals>
> <goal>unpack-dependencies</goal>
> </goals>
> <phase>generate-test-resources</phase>
> <configuration>
> <includeGroupIds>group.id</includeGroupIds>
> <includeArtifactIds>common</includeArtifactIds>
> <excludeTransitive>true</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. sseidel@vub.de
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: packaging wars
Posted by Stefan Seidel <ss...@vub.de>.
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 <packaging>pom</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>
<artifactId>common</artifactId>
<scope>provided</scope>
</dependency>
and
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1-SNAPSHOT</version>
<executions>
<execution>
<id>expand common JSP fragments</id>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<phase>generate-test-resources</phase>
<configuration>
<includeGroupIds>group.id</includeGroupIds>
<includeArtifactIds>common</includeArtifactIds>
<excludeTransitive>true</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. sseidel@vub.de
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: packaging wars
Posted by Jean-Paul Vallée <je...@gmail.com>.
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
Posted by Manuel EVENO <ma...@gmail.com>.
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 <
jeanpaul.vallee1@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>