Re: packaging wars

[Jean-Paul Vallée]

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

[Jean-Paul Vallée]

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.

packaging wars

[Jean-Paul Vallée]

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]