juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Problem with how uddi-ws build works and maven snapshots
Date Fri, 17 Jun 2011 21:15:56 GMT
My source (kevan miller) thinks you need the "includes" line in the NOTICE file.  So I think
it's time for a new vote...

thanks again!
david jencks

On Jun 17, 2011, at 1:49 PM, David Jencks wrote:

> 
> On Jun 17, 2011, at 1:03 PM, Kurt T Stam wrote:
> 
>> On 6/17/11 9:26 AM, Kurt T Stam wrote:
>>> 
>>> On 6/16/11 8:03 PM, David Jencks wrote:
>>>> 
>>>> 
>>>> On Jun 16, 2011, at 2:42 PM, Kurt Stam wrote:
>>>> 
>>>>> Hi David,
>>>>> 
>>>>> You should be able to specify a jaxws21 classifier to get the jaxws21
version?
>>>> 
>>>> Hi Kurt,
>>>> 
>>>> I might not have explained the problem very well.  However, I compared the
jars I got from (no profile) and -Pjaxws21 and the only difference I can see is in some maven
files, the class files all have the same size so I'd guess they are identical.  Can you explain
what the difference is?  Usually a possibly different dependency is not a good enough reason
to add a classifier.  I'd suggest compiling with the jaxws 2.1 spec and marking it as provided
so the user can supply whatever spec they want.  Also, does this stuff really require jaxb
2.2?  I'd guess that since it works with jaxws 2.1 it doesn't.
>>>> 
>>>> Anyway.... back the the problem I think is happening (but haven't verified).
>>>> 
>>>> When you run mvn deploy it updates the maven-metadata.xml to indicate the
timestamp and build number of the uploaded snapshot artifacts.  When maven tries to download
a "SNAPSHOT" it looks at this metadata to find the most recent upload.  So, after I just pushed
a plain uddi-ws-3.1.0-SNAPSHOT.jar the metadata looks like this:
>>>> 
>>>> <metadata modelVersion="1.1.0">
>>>>   <groupId>org.apache.juddi</groupId>
>>>>   <artifactId>uddi-ws</artifactId>
>>>>   <version>3.1.0-SNAPSHOT</version>
>>>>   <versioning>
>>>>     <snapshot>
>>>>       <timestamp>20110616.210535</timestamp>
>>>>       <buildNumber>16</buildNumber>
>>>>     </snapshot>
>>>>     <lastUpdated>20110616210535</lastUpdated>
>>>>     <snapshotVersions>
>>>>       <snapshotVersion>
>>>>         <extension>jar</extension>
>>>>         <value>3.1.0-20110616.210535-16</value>
>>>>         <updated>20110616210535</updated>
>>>>       </snapshotVersion>
>>>>       <snapshotVersion>
>>>>         <extension>pom</extension>
>>>>         <value>3.1.0-20110616.210535-16</value>
>>>>         <updated>20110616210535</updated>
>>>>       </snapshotVersion>
>>>>     </snapshotVersions>
>>>>   </versioning>
>>>> </metadata>
>>>> The previously existing uddi-ws-3.1.0-SNAPSHOT-jaxws21.jar still there but
not mentioned in the metadata so I think it may be inaccessible.  On the other hand somehow
it got into the repo without a timestamp which I thought was impossible so I could be wrong.
>>>> 
>>>> I'd still like to understand what the 2 ways of building the jar are for.
>>>> 
>>>> thanks!
>>>> david jencks
>>>> 
>>>> 
>>> Hi David,
>>> 
>>> If you deploy the uddi-ws.jar compiled against jaxws-2.2 to an environment where
the jaxws-2.1 interfaces are used, then you will get linkage errors (missing methods). I'm
talking older appservers here. So in short, our code maybe the same in both versions of the
jar but the byte code produced is slightly different. 
>>> 
>>> At release time I ran
>>> 
>>> mvn clean deploy -Papache-release -Pjaxws21
>>> 
>>> to add the jaxws21 version of the jar. But as you found out, this seems to mess
with the meta data.
>>> 
>>> I'm open for suggestions on how to support this properly. Aren't classifiers
used to support different jdk versions?
>>> 
>>> Cheers,
>>> 
>>> --Kurt
>> 
>> David,
>> 
>> OK after re-testing it turns out we don't need the different compile. Your assessment
that the jars end up the same
>> was true. Not entirely sure how we got to our conclusion we needed it before, but
things are working now.
> 
> I suspect that somehow due to maven dependencies both the 2.1 and 2.2 jaxws specs got
in the classpath or classloader graph and somehow both possible orders got used.
> 
>> 
>> Do you see any more issues before I start another vote?
> 
> rat results look good to me.
> 
> I updated the NOTICE file to fix the copyright year and not mention junit.  AFAICT juddi
does not include any junit code and the NOTICE file is only supposed to include info about
stuff that is actually included, not stuff that is used.
> 
> I'm asking someone whether the 
> 
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> 
> line in the NOTICE file is needed..... even if it isn't it's not a major disaster :-).
 I'll let you know if I find out before you start the vote :-)
> 
> thanks for taking the time to straighten out all these little niggly details :-)
> 
> david jencks
> 
>> 
>> Cheers,
>> 
>> --Kurt
>> 
>> 
> 


Mime
View raw message