Deploy.java: arg[3] not used

[Michael Westbay <we...@users.sourceforge.net>]

Endre Stølsvik pointed out in the "Some comments after code-browsing" 
thread that:

> *) Deploy:
>   arg 3 (fourt arg) is never used!

I've got a use for it, but don't like the kludge of a patch I've made.

Essentially, I want to be able to use the following maven.xml from my 
own project directory:

<?xml version="1.0" encoding="UTF-8"?>
<project default="deployHelloWorld">
   <goal name="deployHelloWorld">
     <delete dir="${tomcat.home.pluto}/webapps/helloworld" />
     <attainGoal name="war" />
     <java classname="org.apache.pluto.portalImpl.Deploy" fork="yes">
       <classpath>
         <path refid="maven.dependency.classpath"/>
         <pathelement path="${maven.build.dest}"/>
       </classpath>
       <arg value="${tomcat.home.pluto}/webapps" />
       <arg value="pluto" />
       <arg value="${basedir}/target/${maven.war.final.name}" />
       <arg value="${pluto.home}/container/target" />
<!--
       <arg value="-addToEntityReg" />
       <arg value="hello" />
       <arg value="hello:HelloWorld" />
-->
     </java>
   </goal>
</project>

This will go with the following project.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project>
   <extend>${pluto.home}/testsuite/project.xml</extend>
   <pomVersion>3</pomVersion>
   <name>Hello World</name>
   <id>hello</id>
   <groupId>pluto</groupId>
   <currentVersion>1.0</currentVersion>
</project>

This allows me to reuse the Maven build framework that already exists 
for building and deploying a portlet.  So far, so good.

However, line 433 of Deploy.java states:

             String strFrom = ".." + dirDelim + "portal"+dirDelim+ 
"src"+dirDelim+"webapp"+strTo;

Therefore, unless my project is located under ${pluto.home} (which I 
define in build.properties), the portlet.tld file cannot be found.

To fix this, I replaced line 443 with this:

            String strFrom = buildContainerDirectory+".."+dirDelim+
               ".."+dirDelim+"portal"+dirDelim+"src"+dirDelim+
               "webapp"+strTo;

Re: Deploy.java: arg[3] not used

[Stefan Hepper <st...@hursley.ibm.com>]

Michael Westbay wrote:

> I appear to have clipped off the final couple of paragraphs before
> sending.  The above message should conclude:
> 
> [...]
> 
> Ugly, but it works.
> 
> What I would like to do is replace arg[3] (buildContainerDirectory) with
> a parameter that points to the root of the pluto project (i.e.
> jakarta-pluto directory).  That will eliminate the need to go two
> directories up, then a few down to find portlet.tld.  It will just go
> straight down.
> 
> If there are no objections, and it not viewed as being outside the scope
> of the Pluto project to make such a change, I would be more than happy
> to submit a patch to Deploy.java and testsuite/maven.xml to facilitate
> such a deployment strategy.
> 

+1 for this change.

Stefan

Re: Deploy.java: arg[3] not used

["David H. DeWolf" <da...@vivare.com>]

Michael Westbay wrote:

> David H. DeWolf wrote:
>
>> I think in addition, we should make sure that we publish the
>> portlet.tld dependencies to the maven repository and use them when
>> appropriate. This way, whenever we are using maven, we can pull the
>> tld straight out of the repository and use it.  I don't think that
>> will help you much in your situation (since it's referred to inside a
>> class that we don't want depending on maven), but your comments
>> jogged my memory that we should be publishing all artifacts to the
>> maven repository - not just jars. Struts is a good example of a
>> project that publishes tlds to the repo.
>
>
> Is this kind of like the <war.bundle.jar> tag to include a jar file 
> under WEB-INF/lib?  I'm not familiar enough with Maven to know if 
> there's a <war.bundle.tld> tag to include a tld file under 
> WEB-INF/tld, but that would be a more elegant solution and eliminate 
> the need to do that in the Deploy class.
>
Yes, I think you hit the nail on the head.  Unfortunately I'm not a 
maven expert either - just trying to learn it and any related best 
practices as we go.

> Along the lines of Maven, I was thinking that deploy really should be 
> a [pluto] plug-in goal.  But again, I'm not a Maven expert.  I can 
> tweak something that's there to work the way I want, but that's about 
> it. I'll just leave this one as a suggestion.
>
I agree 100%.  We should make a pluto plugin that allows deployment of 
portlets.  I'm just finishing up packaging our tomcat deployment goals 
into a Maven plugin.  Once I get it finalized and submitted to the maven 
team my plan was to look into the "pluto" plugin. 

> Back to the Deploy.java patch, I've submitted it to Bugzilla:
>
>     http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27001
>
> This patch effects three files:
>
>     portal/src/java/org/apache/pluto/portalImpl/Deploy.java
>     testsuite/maven.xml
>     deploy/maven.xml
>
> I actually made two changes in deploy/maven.xml as the 
> ${tomcat.home.pluto} property is called ${maven.tomcat.home} 
> everywhere else.
>
> Which is the correct place to post a patch, to the list here or to 
> Bugzilla?  I see a number of them posted to the list lately, but most 
> other Apache project mailing lists I subscribe to specifically state 
> that nothing will be done unless it's reported to Bugzilla (for 
> tracking purposes).
>
Thanks for your work.

David

Re: Deploy.java: arg[3] not used

[Michael Westbay <we...@users.sourceforge.net>]

David H. DeWolf wrote:

> I think in addition, we should make sure that we publish the
> portlet.tld dependencies to the maven repository and use them when
> appropriate. This way, whenever we are using maven, we can pull the
> tld straight out of the repository and use it.  I don't think that
> will help you much in your situation (since it's referred to inside a
> class that we don't want depending on maven), but your comments
> jogged my memory that we should be publishing all artifacts to the
> maven repository - not just jars. Struts is a good example of a
> project that publishes tlds to the repo.

Is this kind of like the <war.bundle.jar> tag to include a jar file 
under WEB-INF/lib?  I'm not familiar enough with Maven to know if 
there's a <war.bundle.tld> tag to include a tld file under WEB-INF/tld, 
but that would be a more elegant solution and eliminate the need to do 
that in the Deploy class.

Along the lines of Maven, I was thinking that deploy really should be a 
[pluto] plug-in goal.  But again, I'm not a Maven expert.  I can tweak 
something that's there to work the way I want, but that's about it. 
I'll just leave this one as a suggestion.

Back to the Deploy.java patch, I've submitted it to Bugzilla:

     http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27001

This patch effects three files:

     portal/src/java/org/apache/pluto/portalImpl/Deploy.java
     testsuite/maven.xml
     deploy/maven.xml

I actually made two changes in deploy/maven.xml as the 
${tomcat.home.pluto} property is called ${maven.tomcat.home} everywhere 
else.

Which is the correct place to post a patch, to the list here or to 
Bugzilla?  I see a number of them posted to the list lately, but most 
other Apache project mailing lists I subscribe to specifically state 
that nothing will be done unless it's reported to Bugzilla (for tracking 
purposes).

-- 
Michael Westbay

Re: Deploy.java: arg[3] not used

["David H. DeWolf" <da...@vivare.com>]

Michael Westbay wrote:

> I appear to have clipped off the final couple of paragraphs before
> sending.  The above message should conclude:
>
> [...]
>
> Ugly, but it works.
>
> What I would like to do is replace arg[3] (buildContainerDirectory) with
> a parameter that points to the root of the pluto project (i.e.
> jakarta-pluto directory).  That will eliminate the need to go two
> directories up, then a few down to find portlet.tld.  It will just go
> straight down.
>
> If there are no objections, and it not viewed as being outside the scope
> of the Pluto project to make such a change, I would be more than happy
> to submit a patch to Deploy.java and testsuite/maven.xml to facilitate
> such a deployment strategy.
>
+1

I think in addition, we should make sure that we publish the portlet.tld 
dependencies to the maven repository and use them when appropriate. This 
way, whenever we are using maven, we can pull the tld straight out of 
the repository and use it.  I don't think that will help you much in 
your situation (since it's referred to inside a class that we don't want 
depending on maven), but your comments jogged my memory that we should 
be publishing all artifacts to the maven repository - not just jars.  
Struts is a good example of a project that publishes tlds to the repo.

Re: Deploy.java: arg[3] not used

[Michael Westbay <we...@users.sourceforge.net>]

I appear to have clipped off the final couple of paragraphs before
sending.  The above message should conclude:

[...]

Ugly, but it works.

What I would like to do is replace arg[3] (buildContainerDirectory) with
a parameter that points to the root of the pluto project (i.e.
jakarta-pluto directory).  That will eliminate the need to go two
directories up, then a few down to find portlet.tld.  It will just go
straight down.

If there are no objections, and it not viewed as being outside the scope
of the Pluto project to make such a change, I would be more than happy
to submit a patch to Deploy.java and testsuite/maven.xml to facilitate
such a deployment strategy.

-- 
Michael Westbay