You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Christine <ch...@christine.nl> on 2009/09/14 14:04:20 UTC
deploy tools
The mvn script for building my project was complaining about deploy-tools:
>[INFO] Trace
>org.apache.maven.BuildFailureException: Compilation failure
>error: error reading
/home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
error >in opening zip file
>
> at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
The pom.xml says "version 2.2.0" but the file that's downloaded says
"jetspeed-deploy-tools-2.2". In the repository, there's a
jetspeed-deploy-tools-2.2.0-SNAPSHOT.
I have manually downloaded the 2.2.0 file and put it in my maven
repository, now the project builds. I take it that some place in a pom
file, someone forgot a ".0"?
dagdag
Christine
--
dagdag is just a two-character rotation of byebye.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
> Christine wrote:
>> Ate Douma wrote:
[...]
>> If a bad internet connection can result in downloading the wrong file,
>> that may be what happened.
>> As I said, I'm ok now, I was just wondering why it is that the only
>> way I can get it to work by manually installing the file.
> I'm not sure yet how to reproduce here.
> I will try to remove my own local version of the file and try to build
> myself.
I tried this myself now, first deleting my ~/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0 folder.
When doing a full (mvn jetspeed:mvn -Dtarget=all) build of my custom project, the jetspeed-deploy-tools-2.2.0.jar was correctly downloaded
from http://repo1.maven.org/maven2/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar and all went
fine...
If you're will to try once more and post your console output during the build where it searches for and downloads this jar, maybe that'll
help a bit to find out what goes wrong in your case.
Regards,
Ate
>
> Ate
>
>>
>> dagdag
>> Christine
>>>
>>> Groet,
>>>
>>> Ate
>>>
>>>
>>>>
>>>> dagdag
>>>> Christine
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by "blog s2o.bcn" <bl...@sacristan.com.es>.
Thanks for the comments!.
Yes, in fact, I have a pendent post to explain how to migrate the portlet to
websphere :)
and that really taking all the references to taglib of portlets from the
web.xml all continue working right (at least in my portlets). As the tld are
taken from the portlet.jar by tomcat.
Regards
Sergi
2009/9/15 Ate Douma <at...@douma.nu>
> blog s2o.bcn wrote:
>
>> I'm developing/deploying portlets in jetspeed with the wtp eclipse plugin,
>> with an easy solution that I didn't see before, and that can integrate
>> closely eclipse wtp with jetspeed.
>>
>> You can see here:
>>
>> http://s2o-bcn.blogspot.com/2009/08/developing-portlets-using-eclipse-part.html
>>
>> a detailed explanation.
>>
>> May this could be helpful for someone...
>>
>
> Nice blog.
>
> One thing I noticed is that you only reference the portlet 1.0 tld in your
> web.xml.
> As long as you only develop JSR-168 portlets that fine, but as Jetspeed 2.2
> also supports JSR-286/Portlet 2.0, you might want to include the following
> just to be sure:
>
> <taglib>
> <taglib-uri>http://java.sun.com/portlet_2_0</taglib-uri>
> <taglib-location>/WEB-INF/tld/portlet_2_0.tld</taglib-location>
> </taglib>
>
> Note: if you do the above, you should also add the portlet_2.0.tld file to
> your WTP project (just like the JSR-186 portlet.tld).
>
> And related to that, you might want to mention in you blog that these
> portlet tld(s) are portal/portlet-container specific.
> If you migrate your build to another portal/portlet-container these portlet
> tld(s) will have to be migrated as well.
> Jetspeed 2.2 uses the Pluto portlet tld(s), which won't work if you move to
> say WebSphere Portal (if you Jetspeed on plain WAS however it would be fine
> though).
> The Jetspeed runtime deployment (or alternatively buildtime/command-line
> pre-processing) of standard portlet applications will take care of these
> specifics, including injecting the JetspeedContainerServlet and portlet
> tld(s) in your web.xml.
> Doing that hard coded in your project is fine for sure as long as you are
> aware of the above :)
>
> Regards,
>
> Ate
>
>
>
>
>> a10
>> Sergi
>>
>>
>> 2009/9/14 Christine <ch...@christine.nl>
>>
>> Ate Douma wrote:
>>>
>>> Christine wrote:
>>>>
>>>> Ate Douma wrote:
>>>>>
>>>>> Christine wrote:
>>>>>>
>>>>>> The mvn script for building my project was complaining about
>>>>>>> deploy-tools:
>>>>>>> >[INFO] Trace
>>>>>>> >org.apache.maven.BuildFailureException: Compilation failure
>>>>>>> >error: error reading
>>>>>>>
>>>>>>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>>>>>>> error >in opening zip file
>>>>>>> >
>>>>>>> > at
>>>>>>>
>>>>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>>>>>>
>>>>>>>
>>>>>>> The pom.xml says "version 2.2.0" but the file that's downloaded says
>>>>>>> "jetspeed-deploy-tools-2.2".
>>>>>>>
>>>>>>> Hi Christine,
>>>>>>
>>>>>> What do you mean by "says"?
>>>>>>
>>>>>> The pom file in the same directory as the jar file contains
>>>>> <version>2.2.0</version>.
>>>>>
>>>>> Right.
>>>> But where is the "2.2" without the ".0" mentioned, or are you saying
>>>> that
>>>> the the file in your local repository itself is named
>>>> jetspeed-deploy-tools-2.2.jar?
>>>>
>>>> yes. I manually replaced the 2.2 file with a 2.2.0 file.
>>>
>>>
>>> --
>>> dagdag is just a two-character rotation of byebye.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: deploy tools
Posted by Ron McNulty <rm...@xtra.co.nz>.
Hi Ate
Deploying to Websphere Portal Server is actually not a problem. We develop
on Jetspeed (2.1.3 currently), and deploy the unmodified WAR file to WPS.
I've done some testing on Jetspeed 2.2 and no real problems have been found.
It's a while since I looked at the code, but I think the jetspeed deployment
code rips out whatever portlet.tlds are in the WAR, and repackages it with
the pluto TLDs (both _1.0 and _2.0 in the case of Jetspeed 2.2). The
modified WAR then gets deployed into the standard Tomcat deploy directory.
The only fishooks we have found are:
- IBM specific code needs to be stubbed out on Jetspeed. Some of our
production code uses the proprietary IBM clustered cache to provide JMS
message caching across servers in a cluster. But this is loaded as a JNDI
resource, and so can be cleanly replaced with a simple Hashmap for
development on Jetspeed.
- IBM implement non-standard JNDI branches (e.g. /cells/persistent.. and
/services/.... - no java:comp prefix). We fixed this by having all JNDI
access funnelled through a class that knows what the platform is, and adds
the prefix when running on Jetspeed. A better solution would be to make
Tomcat implement these branches, but that is a fairly complex job. (This is
a Tomcat problem, not a Jetspeed issue)
- On Jetspeed 2.2 the <c:url> tag behaves differently to WPS and Jetspeed
2.1.3. It requires the context="myapp" parameter set, else it defaults to
the /jetspeed context. Possibly this is a JSR168/286 change?
- Our WPS version only supports Java 1.4. Our workaround is to write 1.5
(or 1.6) code, and use JBoss weaver to produce 1.4 class files. It works
remarkably well. We run the weaved classes on both environments, but the
unweaved run fine on Jetspeed.
- Using two different containers means two sets of skins and themes -
Hacked JSPs for IBM and Velocity macros for Jetspeed. But this is a one-off
hit, as a single skin or theme is typically used across a number of
portlets.
I'm glad to help out anyone who is going down this path. Developing on
Jetspeed is far more productive than fighting with WPS.
Regards
Ron
----- Original Message -----
From: "Ate Douma" <at...@douma.nu>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Tuesday, September 15, 2009 7:34 PM
Subject: Re: deploy tools
> blog s2o.bcn wrote:
>> I'm developing/deploying portlets in jetspeed with the wtp eclipse
>> plugin,
>> with an easy solution that I didn't see before, and that can integrate
>> closely eclipse wtp with jetspeed.
>>
>> You can see here:
>> http://s2o-bcn.blogspot.com/2009/08/developing-portlets-using-eclipse-part.html
>>
>> a detailed explanation.
>>
>> May this could be helpful for someone...
>
> Nice blog.
>
> One thing I noticed is that you only reference the portlet 1.0 tld in your
> web.xml.
> As long as you only develop JSR-168 portlets that fine, but as Jetspeed
> 2.2 also supports JSR-286/Portlet 2.0, you might want to include the
> following just to be sure:
>
> <taglib>
> <taglib-uri>http://java.sun.com/portlet_2_0</taglib-uri>
> <taglib-location>/WEB-INF/tld/portlet_2_0.tld</taglib-location>
> </taglib>
>
> Note: if you do the above, you should also add the portlet_2.0.tld file to
> your WTP project (just like the JSR-186 portlet.tld).
>
> And related to that, you might want to mention in you blog that these
> portlet tld(s) are portal/portlet-container specific.
> If you migrate your build to another portal/portlet-container these
> portlet tld(s) will have to be migrated as well.
> Jetspeed 2.2 uses the Pluto portlet tld(s), which won't work if you move
> to say WebSphere Portal (if you Jetspeed on plain WAS however it would be
> fine though).
> The Jetspeed runtime deployment (or alternatively buildtime/command-line
> pre-processing) of standard portlet applications will take care of these
> specifics, including injecting the JetspeedContainerServlet and portlet
> tld(s) in your web.xml.
> Doing that hard coded in your project is fine for sure as long as you are
> aware of the above :)
>
> Regards,
>
> Ate
>
>
>>
>> a10
>> Sergi
>>
>>
>> 2009/9/14 Christine <ch...@christine.nl>
>>
>>> Ate Douma wrote:
>>>
>>>> Christine wrote:
>>>>
>>>>> Ate Douma wrote:
>>>>>
>>>>>> Christine wrote:
>>>>>>
>>>>>>> The mvn script for building my project was complaining about
>>>>>>> deploy-tools:
>>>>>>> >[INFO] Trace
>>>>>>> >org.apache.maven.BuildFailureException: Compilation failure
>>>>>>> >error: error reading
>>>>>>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>>>>>>> error >in opening zip file
>>>>>>> >
>>>>>>> > at
>>>>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>>>>>>
>>>>>>>
>>>>>>> The pom.xml says "version 2.2.0" but the file that's downloaded says
>>>>>>> "jetspeed-deploy-tools-2.2".
>>>>>>>
>>>>>> Hi Christine,
>>>>>>
>>>>>> What do you mean by "says"?
>>>>>>
>>>>> The pom file in the same directory as the jar file contains
>>>>> <version>2.2.0</version>.
>>>>>
>>>> Right.
>>>> But where is the "2.2" without the ".0" mentioned, or are you saying
>>>> that
>>>> the the file in your local repository itself is named
>>>> jetspeed-deploy-tools-2.2.jar?
>>>>
>>> yes. I manually replaced the 2.2 file with a 2.2.0 file.
>>>
>>>
>>> --
>>> dagdag is just a two-character rotation of byebye.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by Ate Douma <at...@douma.nu>.
blog s2o.bcn wrote:
> I'm developing/deploying portlets in jetspeed with the wtp eclipse plugin,
> with an easy solution that I didn't see before, and that can integrate
> closely eclipse wtp with jetspeed.
>
> You can see here:
> http://s2o-bcn.blogspot.com/2009/08/developing-portlets-using-eclipse-part.html
>
> a detailed explanation.
>
> May this could be helpful for someone...
Nice blog.
One thing I noticed is that you only reference the portlet 1.0 tld in your web.xml.
As long as you only develop JSR-168 portlets that fine, but as Jetspeed 2.2 also supports JSR-286/Portlet 2.0, you might want to include the
following just to be sure:
<taglib>
<taglib-uri>http://java.sun.com/portlet_2_0</taglib-uri>
<taglib-location>/WEB-INF/tld/portlet_2_0.tld</taglib-location>
</taglib>
Note: if you do the above, you should also add the portlet_2.0.tld file to your WTP project (just like the JSR-186 portlet.tld).
And related to that, you might want to mention in you blog that these portlet tld(s) are portal/portlet-container specific.
If you migrate your build to another portal/portlet-container these portlet tld(s) will have to be migrated as well.
Jetspeed 2.2 uses the Pluto portlet tld(s), which won't work if you move to say WebSphere Portal (if you Jetspeed on plain WAS however it
would be fine though).
The Jetspeed runtime deployment (or alternatively buildtime/command-line pre-processing) of standard portlet applications will take care of
these specifics, including injecting the JetspeedContainerServlet and portlet tld(s) in your web.xml.
Doing that hard coded in your project is fine for sure as long as you are aware of the above :)
Regards,
Ate
>
> a10
> Sergi
>
>
> 2009/9/14 Christine <ch...@christine.nl>
>
>> Ate Douma wrote:
>>
>>> Christine wrote:
>>>
>>>> Ate Douma wrote:
>>>>
>>>>> Christine wrote:
>>>>>
>>>>>> The mvn script for building my project was complaining about
>>>>>> deploy-tools:
>>>>>> >[INFO] Trace
>>>>>> >org.apache.maven.BuildFailureException: Compilation failure
>>>>>> >error: error reading
>>>>>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>>>>>> error >in opening zip file
>>>>>> >
>>>>>> > at
>>>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>>>>>
>>>>>>
>>>>>> The pom.xml says "version 2.2.0" but the file that's downloaded says
>>>>>> "jetspeed-deploy-tools-2.2".
>>>>>>
>>>>> Hi Christine,
>>>>>
>>>>> What do you mean by "says"?
>>>>>
>>>> The pom file in the same directory as the jar file contains
>>>> <version>2.2.0</version>.
>>>>
>>> Right.
>>> But where is the "2.2" without the ".0" mentioned, or are you saying that
>>> the the file in your local repository itself is named
>>> jetspeed-deploy-tools-2.2.jar?
>>>
>> yes. I manually replaced the 2.2 file with a 2.2.0 file.
>>
>>
>> --
>> dagdag is just a two-character rotation of byebye.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by "blog s2o.bcn" <bl...@sacristan.com.es>.
I'm developing/deploying portlets in jetspeed with the wtp eclipse plugin,
with an easy solution that I didn't see before, and that can integrate
closely eclipse wtp with jetspeed.
You can see here:
http://s2o-bcn.blogspot.com/2009/08/developing-portlets-using-eclipse-part.html
a detailed explanation.
May this could be helpful for someone...
a10
Sergi
2009/9/14 Christine <ch...@christine.nl>
> Ate Douma wrote:
>
>> Christine wrote:
>>
>>> Ate Douma wrote:
>>>
>>>> Christine wrote:
>>>>
>>>>> The mvn script for building my project was complaining about
>>>>> deploy-tools:
>>>>> >[INFO] Trace
>>>>> >org.apache.maven.BuildFailureException: Compilation failure
>>>>> >error: error reading
>>>>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>>>>> error >in opening zip file
>>>>> >
>>>>> > at
>>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>>>>
>>>>>
>>>>> The pom.xml says "version 2.2.0" but the file that's downloaded says
>>>>> "jetspeed-deploy-tools-2.2".
>>>>>
>>>> Hi Christine,
>>>>
>>>> What do you mean by "says"?
>>>>
>>> The pom file in the same directory as the jar file contains
>>> <version>2.2.0</version>.
>>>
>> Right.
>> But where is the "2.2" without the ".0" mentioned, or are you saying that
>> the the file in your local repository itself is named
>> jetspeed-deploy-tools-2.2.jar?
>>
> yes. I manually replaced the 2.2 file with a 2.2.0 file.
>
>
> --
> dagdag is just a two-character rotation of byebye.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: deploy tools
Posted by Christine <ch...@christine.nl>.
Ate Douma wrote:
> Christine wrote:
>> Ate Douma wrote:
>>> Christine wrote:
>>>> The mvn script for building my project was complaining about
>>>> deploy-tools:
>>>> >[INFO] Trace
>>>> >org.apache.maven.BuildFailureException: Compilation failure
>>>> >error: error reading
>>>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>>>> error >in opening zip file
>>>> >
>>>> > at
>>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>>>
>>>>
>>>> The pom.xml says "version 2.2.0" but the file that's downloaded
>>>> says "jetspeed-deploy-tools-2.2".
>>> Hi Christine,
>>>
>>> What do you mean by "says"?
>> The pom file in the same directory as the jar file contains
>> <version>2.2.0</version>.
> Right.
> But where is the "2.2" without the ".0" mentioned, or are you saying
> that the the file in your local repository itself is named
> jetspeed-deploy-tools-2.2.jar?
yes. I manually replaced the 2.2 file with a 2.2.0 file.
--
dagdag is just a two-character rotation of byebye.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by Ate Douma <at...@douma.nu>.
Christine wrote:
> Ate Douma wrote:
>> Christine wrote:
>>> The mvn script for building my project was complaining about
>>> deploy-tools:
>>> >[INFO] Trace
>>> >org.apache.maven.BuildFailureException: Compilation failure
>>> >error: error reading
>>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>>> error >in opening zip file
>>> >
>>> > at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>>
>>>
>>> The pom.xml says "version 2.2.0" but the file that's downloaded says
>>> "jetspeed-deploy-tools-2.2".
>> Hi Christine,
>>
>> What do you mean by "says"?
> The pom file in the same directory as the jar file contains
> <version>2.2.0</version>.
Right.
But where is the "2.2" without the ".0" mentioned, or are you saying that the the file in your local repository itself is named
jetspeed-deploy-tools-2.2.jar?
>
> I have removed the file and tried again, removed the dir and tried
> again, emptied the repository and tried, all with the same error. I'm ok
> now, I was just wondering.
Well, I'm wondering too. This clearly should not happen so I'd like to find out why.
>>
>>> In the repository, there's a jetspeed-deploy-tools-2.2.0-SNAPSHOT.
>>> I have manually downloaded the 2.2.0 file and put it in my maven
>>> repository, now the project builds. I take it that some place in a
>>> pom file, someone forgot a ".0"?
>> I don't think so.
>> If a specific dependency reference is specified as "2.2", Maven will
>> only look for a 2.2 version, never "magically" append a ".0" to it if
>> it can't find a "2.2" version.
>> There is also a feature in Maven for version ranges but to enable and
>> use that requires an explicit configuration, e.g. "[2.2,)" but we
>> don't use that with Jetspeed.
>>
>> My guess is the 2.2.0 jar download was botched before, maybe because
>> of a bad network connection at the time. Often Maven detects this
>> itself and can recover from it, but seemingly not always...
> A bad internet connection probably doesn't result in a 2.2.0.jar file
> losing the 0. in the middle.
No, surely not.
> If a bad internet connection can result in
> downloading the wrong file, that may be what happened.
> As I said, I'm ok now, I was just wondering why it is that the only way
> I can get it to work by manually installing the file.
I'm not sure yet how to reproduce here.
I will try to remove my own local version of the file and try to build myself.
Ate
>
> dagdag
> Christine
>>
>> Groet,
>>
>> Ate
>>
>>
>>>
>>> dagdag
>>> Christine
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by Christine <ch...@christine.nl>.
Ate Douma wrote:
> Christine wrote:
>> The mvn script for building my project was complaining about
>> deploy-tools:
>> >[INFO] Trace
>> >org.apache.maven.BuildFailureException: Compilation failure
>> >error: error reading
>> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
>> error >in opening zip file
>> >
>> > at
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>>
>>
>> The pom.xml says "version 2.2.0" but the file that's downloaded says
>> "jetspeed-deploy-tools-2.2".
> Hi Christine,
>
> What do you mean by "says"?
The pom file in the same directory as the jar file contains
<version>2.2.0</version>.
I have removed the file and tried again, removed the dir and tried
again, emptied the repository and tried, all with the same error. I'm ok
now, I was just wondering.
>
>> In the repository, there's a jetspeed-deploy-tools-2.2.0-SNAPSHOT.
>> I have manually downloaded the 2.2.0 file and put it in my maven
>> repository, now the project builds. I take it that some place in a
>> pom file, someone forgot a ".0"?
> I don't think so.
> If a specific dependency reference is specified as "2.2", Maven will
> only look for a 2.2 version, never "magically" append a ".0" to it if
> it can't find a "2.2" version.
> There is also a feature in Maven for version ranges but to enable and
> use that requires an explicit configuration, e.g. "[2.2,)" but we
> don't use that with Jetspeed.
>
> My guess is the 2.2.0 jar download was botched before, maybe because
> of a bad network connection at the time. Often Maven detects this
> itself and can recover from it, but seemingly not always...
A bad internet connection probably doesn't result in a 2.2.0.jar file
losing the 0. in the middle. If a bad internet connection can result in
downloading the wrong file, that may be what happened.
As I said, I'm ok now, I was just wondering why it is that the only way
I can get it to work by manually installing the file.
dagdag
Christine
>
> Groet,
>
> Ate
>
>
>>
>> dagdag
>> Christine
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
--
dagdag is just a two-character rotation of byebye.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: deploy tools
Posted by Ate Douma <at...@douma.nu>.
Christine wrote:
> The mvn script for building my project was complaining about deploy-tools:
> >[INFO] Trace
> >org.apache.maven.BuildFailureException: Compilation failure
> >error: error reading
> /home/christine/.m2/repository/org/apache/portals/jetspeed-2/jetspeed-deploy-tools/2.2.0/jetspeed-deploy-tools-2.2.0.jar;
> error >in opening zip file
> >
> > at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
>
>
> The pom.xml says "version 2.2.0" but the file that's downloaded says
> "jetspeed-deploy-tools-2.2".
Hi Christine,
What do you mean by "says"?
> In the repository, there's a
> jetspeed-deploy-tools-2.2.0-SNAPSHOT.
> I have manually downloaded the 2.2.0 file and put it in my maven
> repository, now the project builds. I take it that some place in a pom
> file, someone forgot a ".0"?
I don't think so.
If a specific dependency reference is specified as "2.2", Maven will only look for a 2.2 version, never "magically" append a ".0" to it if
it can't find a "2.2" version.
There is also a feature in Maven for version ranges but to enable and use that requires an explicit configuration, e.g. "[2.2,)" but we
don't use that with Jetspeed.
My guess is the 2.2.0 jar download was botched before, maybe because of a bad network connection at the time. Often Maven detects this
itself and can recover from it, but seemingly not always...
Groet,
Ate
>
> dagdag
> Christine
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org