Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

Darryl Miles

The current version 3.0.0-rc3-SNAPSHOT appears to be at:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting

It appears to be getting auto-built.


However the install/deployment step to publish the Maven artifacts is
doing so incorrectly.

It is installing _ALL_ modules into the same articleId of "dwr"


This can be observed at:
https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/

Where you will see a bunch of various attachment types "-sources"
"-javadoc" "-jdk14" are all overwriting themselves.


For example the version number "20120325.171435-50" is currently the
latest version.  Which is a pom project and a "-sources" attachment
relating to it.

Non of the other files listed in the directly are visible to the Maven
resolution process and therefore do not work via Maven.



What should be happening is each module is publish into its own
artifactId folder.  For example:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/dwr-3.0.0-rc3-20120325.171420-48-noncla.jar

This file should be published at:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/3.0.0-rc3-SNAPSHOT/dwr-noncla-3.0.0-rc3-20120325.171420-48.jar

Note the use of <project><type>jar</type>...  so the "-noncla" is
removed from the end of the filename.

Note the filename stem becoming "dwr-noncla" which makes the filename
unique enough.  But personally I prefer to use fully qualified files
names this would be setup on the POM as
<project><build><finalName>${project.groupId}.${project.artifactId}-${project.version}</finalName>...

If you look at just the folder:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/

it is empty where stuff should be.


The release 2.0.10 at
https://oss.sonatype.org/content/repositories/releases/org/directwebremoting/dwr/2.0.10/ 
uses a single JAR for everything.  Maybe the problem is that the project
wasn't updated when various module JAR were split up and created ?



Maybe someone can point me to the script used to perform the publishing
of the -SNAPSHOT by the auto-builder system so I could suggest a patch
so it.



Thanks,

Darryl

Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

david@butterdev.com
Darryl,

"https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/ 


it is empty where stuff should be. "

We abandoned our efforts to build/publish with Maven quite awhile ago.  
If you will notice all of the dates on the directories (dwr-noncla,
dwr-core, etc.) are from January 28th.  So this directory should be
empty and we should be publishing artifacts like we do with 2.x.  We
currently use Ant to publish the artifacts.

"https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/3.0.0-rc3-SNAPSHOT/dwr-noncla-3.0.0-rc3-20120325.171420-48.jar 


Note the use of <project><type>jar</type>...  so the "-noncla" is
removed from the end of the filename. "

I followed the directions on Maven's OSS's repository usage guide (made
a few typos which I just fixed):
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Section - 7C Deploy Snapshots and Stage Releases with Ant

They recommend using the same format that we are using (maybe they have
an error in their documentation)?


         <!-- define artifacts' name, which follows the convention of Maven -->
        <property name="maven-jar"  value="${dist}/lib/${artifactId}-${version}.jar"  />
        <property name="maven-javadoc-jar"  value="${dist}/lib/${artifactId}-${version}-javadoc.jar"  />
        <property name="maven-sources-jar"  value="${dist}/lib/${artifactId}-${version}-sources.jar"  />


If you still see a problem here and want to take a look the work is done
in our build.xml.

Thanks
David

On 03/31/2012 07:44 AM, Darryl Miles wrote:

>
> The current version 3.0.0-rc3-SNAPSHOT appears to be at:
>
> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting 
>
>
> It appears to be getting auto-built.
>
>
> However the install/deployment step to publish the Maven artifacts is
> doing so incorrectly.
>
> It is installing _ALL_ modules into the same articleId of "dwr"
>
>
> This can be observed at:
> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/
>
> Where you will see a bunch of various attachment types "-sources"
> "-javadoc" "-jdk14" are all overwriting themselves.
>
>
> For example the version number "20120325.171435-50" is currently the
> latest version.  Which is a pom project and a "-sources" attachment
> relating to it.
>
> Non of the other files listed in the directly are visible to the Maven
> resolution process and therefore do not work via Maven.
>
>
>
> What should be happening is each module is publish into its own
> artifactId folder.  For example:
>
> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/dwr-3.0.0-rc3-20120325.171420-48-noncla.jar 
>
>
> This file should be published at:
>
> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/3.0.0-rc3-SNAPSHOT/dwr-noncla-3.0.0-rc3-20120325.171420-48.jar 
>
>
> Note the use of <project><type>jar</type>...  so the "-noncla" is
> removed from the end of the filename.
>
> Note the filename stem becoming "dwr-noncla" which makes the filename
> unique enough.  But personally I prefer to use fully qualified files
> names this would be setup on the POM as
> <project><build><finalName>${project.groupId}.${project.artifactId}-${project.version}</finalName>...
>
> If you look at just the folder:
>
> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/ 
>
>
> it is empty where stuff should be.
>
>
> The release 2.0.10 at
> https://oss.sonatype.org/content/repositories/releases/org/directwebremoting/dwr/2.0.10/ 
> uses a single JAR for everything.  Maybe the problem is that the
> project wasn't updated when various module JAR were split up and
> created ?
>
>
>
> Maybe someone can point me to the script used to perform the
> publishing of the -SNAPSHOT by the auto-builder system so I could
> suggest a patch so it.
>
>
>
> Thanks,
>
> Darryl
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

Darryl Miles
David Marginian wrote:

> Darryl,
>
> "https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/
>
>
> it is empty where stuff should be. "
>
> We abandoned our efforts to build/publish with Maven quite awhile ago.
> If you will notice all of the dates on the directories (dwr-noncla,
> dwr-core, etc.) are from January 28th. So this directory should be empty
> and we should be publishing artifacts like we do with 2.x. We currently
> use Ant to publish the artifacts.
Ok I understand this now.  Maybe ask if sonatype.org admin can delete
the empty directories for obsolete artifactId's.  People won't question
or become confused at what they can not see.



 > If you still see a problem here and want to take a look the work is done
 > in our build.xml.


I have just pulled the SVN tree and can see why SNAPSHOTs are getting
different versions because the same artifactId is having deploy-file run
more than once (due to multiple XML elements in use).  Each operation
with a SNAPSHOT version creates a new auto-incrementing version number
at the repository.

I also notice JavaDoc was missing from the SNAPSHOTs deployment process
but is present in the releases.  JavaDoc is useful for IDE assistance
and locating that data via Maven is really helpful to users.


Please find attached an _untested_ patch based on the instructions for
the maven-deploy-module at
https://maven.apache.org/plugins/maven-deploy-plugin/  on how to publish
  multiple classifiers at once to the same artifactId.   The method you
were using before would be valid for deploying to multiple (and
different) artifactId's (such as into each of the directories listed at
https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/ 
but you've explained this is not the intention of how 3.x
releases/snapshots should be and was an old experiment).

If this works correctly you should find there is 1 POM and 5 JARs
published into the SNAPSHOTs folder _ALL_ with the same numeric version
number.  This forms a complete set at that version that the Maven system
can find and resolve.


It would also be useful on the website to add an example of the Maven
configuration snippet.  So it is clear that everything is being
published under the same artifactId.  Also that to get access to noncla
and jdk14 the user would need an explicit entry in their configuration
to obtain it.  Maybe I can provide that back to this list once a set of
artifactId show up in the repository that I can test against.



Darryl

build.xml.v3828.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

david@butterdev.com
Darryl,
     Thanks, but unfortunately this does not work:

[artifact:mvn] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file
(default-cli) on project dwr: The parameters 'file' for goal
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file are missing
or invalid -> [Help 1]



On 04/01/2012 05:09 AM, Darryl Miles wrote:

> David Marginian wrote:
>> Darryl,
>>
>> "https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/ 
>>
>>
>>
>> it is empty where stuff should be. "
>>
>> We abandoned our efforts to build/publish with Maven quite awhile ago.
>> If you will notice all of the dates on the directories (dwr-noncla,
>> dwr-core, etc.) are from January 28th. So this directory should be empty
>> and we should be publishing artifacts like we do with 2.x. We currently
>> use Ant to publish the artifacts.
>
> Ok I understand this now.  Maybe ask if sonatype.org admin can delete
> the empty directories for obsolete artifactId's.  People won't
> question or become confused at what they can not see.
>
>
>
> > If you still see a problem here and want to take a look the work is
> done
> > in our build.xml.
>
>
> I have just pulled the SVN tree and can see why SNAPSHOTs are getting
> different versions because the same artifactId is having deploy-file
> run more than once (due to multiple XML elements in use).  Each
> operation with a SNAPSHOT version creates a new auto-incrementing
> version number at the repository.
>
> I also notice JavaDoc was missing from the SNAPSHOTs deployment
> process but is present in the releases.  JavaDoc is useful for IDE
> assistance and locating that data via Maven is really helpful to users.
>
>
> Please find attached an _untested_ patch based on the instructions for
> the maven-deploy-module at
> https://maven.apache.org/plugins/maven-deploy-plugin/  on how to
> publish  multiple classifiers at once to the same artifactId.   The
> method you were using before would be valid for deploying to multiple
> (and different) artifactId's (such as into each of the directories
> listed at
> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/ 
> but you've explained this is not the intention of how 3.x
> releases/snapshots should be and was an old experiment).
>
> If this works correctly you should find there is 1 POM and 5 JARs
> published into the SNAPSHOTs folder _ALL_ with the same numeric
> version number.  This forms a complete set at that version that the
> Maven system can find and resolve.
>
>
> It would also be useful on the website to add an example of the Maven
> configuration snippet.  So it is clear that everything is being
> published under the same artifactId.  Also that to get access to
> noncla and jdk14 the user would need an explicit entry in their
> configuration to obtain it.  Maybe I can provide that back to this
> list once a set of artifactId show up in the repository that I can
> test against.
>
>
>
> Darryl

Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

david@butterdev.com
Just an FYI, I had to add back the -Dfile for the main artifact, files
is for additional artifacts only:

<arg value="-Dfile=${dwr-maven-jar}" />
<arg value="-Dpackaging=jar" />

On 04/01/2012 07:43 AM, David Marginian wrote:

> Darryl,
>     Thanks, but unfortunately this does not work:
>
> [artifact:mvn] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file
> (default-cli) on project dwr: The parameters 'file' for goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file are
> missing or invalid -> [Help 1]
>
>
>
> On 04/01/2012 05:09 AM, Darryl Miles wrote:
>> David Marginian wrote:
>>> Darryl,
>>>
>>> "https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/ 
>>>
>>>
>>>
>>> it is empty where stuff should be. "
>>>
>>> We abandoned our efforts to build/publish with Maven quite awhile ago.
>>> If you will notice all of the dates on the directories (dwr-noncla,
>>> dwr-core, etc.) are from January 28th. So this directory should be
>>> empty
>>> and we should be publishing artifacts like we do with 2.x. We currently
>>> use Ant to publish the artifacts.
>>
>> Ok I understand this now.  Maybe ask if sonatype.org admin can delete
>> the empty directories for obsolete artifactId's.  People won't
>> question or become confused at what they can not see.
>>
>>
>>
>> > If you still see a problem here and want to take a look the work is
>> done
>> > in our build.xml.
>>
>>
>> I have just pulled the SVN tree and can see why SNAPSHOTs are getting
>> different versions because the same artifactId is having deploy-file
>> run more than once (due to multiple XML elements in use).  Each
>> operation with a SNAPSHOT version creates a new auto-incrementing
>> version number at the repository.
>>
>> I also notice JavaDoc was missing from the SNAPSHOTs deployment
>> process but is present in the releases.  JavaDoc is useful for IDE
>> assistance and locating that data via Maven is really helpful to users.
>>
>>
>> Please find attached an _untested_ patch based on the instructions
>> for the maven-deploy-module at
>> https://maven.apache.org/plugins/maven-deploy-plugin/  on how to
>> publish  multiple classifiers at once to the same artifactId.   The
>> method you were using before would be valid for deploying to multiple
>> (and different) artifactId's (such as into each of the directories
>> listed at
>> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/ 
>> but you've explained this is not the intention of how 3.x
>> releases/snapshots should be and was an old experiment).
>>
>> If this works correctly you should find there is 1 POM and 5 JARs
>> published into the SNAPSHOTs folder _ALL_ with the same numeric
>> version number.  This forms a complete set at that version that the
>> Maven system can find and resolve.
>>
>>
>> It would also be useful on the website to add an example of the Maven
>> configuration snippet.  So it is clear that everything is being
>> published under the same artifactId.  Also that to get access to
>> noncla and jdk14 the user would need an explicit entry in their
>> configuration to obtain it.  Maybe I can provide that back to this
>> list once a set of artifactId show up in the repository that I can
>> test against.
>>
>>
>>
>> Darryl
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

david@butterdev.com
In reply to this post by david@butterdev.com
"I have just pulled the SVN tree and can see why SNAPSHOTs are getting
different versions because the same artifactId is having deploy-file run
more than once (due to multiple XML elements in use).  Each operation
with a SNAPSHOT version creates a new auto-incrementing version number
at the repository. "

Also, this has made our build.xml more concise, but I don't see that it
has resolved what you mention above.  I also don't understand why this
is a problem (the dependencies pull in fine).

On 04/01/2012 07:43 AM, David Marginian wrote:

> Darryl,
>     Thanks, but unfortunately this does not work:
>
> [artifact:mvn] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file
> (default-cli) on project dwr: The parameters 'file' for goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file are
> missing or invalid -> [Help 1]
>
>
>
> On 04/01/2012 05:09 AM, Darryl Miles wrote:
>> David Marginian wrote:
>>> Darryl,
>>>
>>> "https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/ 
>>>
>>>
>>>
>>> it is empty where stuff should be. "
>>>
>>> We abandoned our efforts to build/publish with Maven quite awhile ago.
>>> If you will notice all of the dates on the directories (dwr-noncla,
>>> dwr-core, etc.) are from January 28th. So this directory should be
>>> empty
>>> and we should be publishing artifacts like we do with 2.x. We currently
>>> use Ant to publish the artifacts.
>>
>> Ok I understand this now.  Maybe ask if sonatype.org admin can delete
>> the empty directories for obsolete artifactId's.  People won't
>> question or become confused at what they can not see.
>>
>>
>>
>> > If you still see a problem here and want to take a look the work is
>> done
>> > in our build.xml.
>>
>>
>> I have just pulled the SVN tree and can see why SNAPSHOTs are getting
>> different versions because the same artifactId is having deploy-file
>> run more than once (due to multiple XML elements in use).  Each
>> operation with a SNAPSHOT version creates a new auto-incrementing
>> version number at the repository.
>>
>> I also notice JavaDoc was missing from the SNAPSHOTs deployment
>> process but is present in the releases.  JavaDoc is useful for IDE
>> assistance and locating that data via Maven is really helpful to users.
>>
>>
>> Please find attached an _untested_ patch based on the instructions
>> for the maven-deploy-module at
>> https://maven.apache.org/plugins/maven-deploy-plugin/  on how to
>> publish  multiple classifiers at once to the same artifactId.   The
>> method you were using before would be valid for deploying to multiple
>> (and different) artifactId's (such as into each of the directories
>> listed at
>> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/ 
>> but you've explained this is not the intention of how 3.x
>> releases/snapshots should be and was an old experiment).
>>
>> If this works correctly you should find there is 1 POM and 5 JARs
>> published into the SNAPSHOTs folder _ALL_ with the same numeric
>> version number.  This forms a complete set at that version that the
>> Maven system can find and resolve.
>>
>>
>> It would also be useful on the website to add an example of the Maven
>> configuration snippet.  So it is clear that everything is being
>> published under the same artifactId.  Also that to get access to
>> noncla and jdk14 the user would need an explicit entry in their
>> configuration to obtain it.  Maybe I can provide that back to this
>> list once a set of artifactId show up in the repository that I can
>> test against.
>>
>>
>>
>> Darryl
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

david@butterdev.com
https://issues.sonatype.org/browse/OSSRH-3252

On 04/01/2012 08:14 AM, David Marginian wrote:

> "I have just pulled the SVN tree and can see why SNAPSHOTs are getting
> different versions because the same artifactId is having deploy-file
> run more than once (due to multiple XML elements in use).  Each
> operation with a SNAPSHOT version creates a new auto-incrementing
> version number at the repository. "
>
> Also, this has made our build.xml more concise, but I don't see that
> it has resolved what you mention above.  I also don't understand why
> this is a problem (the dependencies pull in fine).
>
> On 04/01/2012 07:43 AM, David Marginian wrote:
>> Darryl,
>>     Thanks, but unfortunately this does not work:
>>
>> [artifact:mvn] [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file
>> (default-cli) on project dwr: The parameters 'file' for goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy-file are
>> missing or invalid -> [Help 1]
>>
>>
>>
>> On 04/01/2012 05:09 AM, Darryl Miles wrote:
>>> David Marginian wrote:
>>>> Darryl,
>>>>
>>>> "https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/ 
>>>>
>>>>
>>>>
>>>> it is empty where stuff should be. "
>>>>
>>>> We abandoned our efforts to build/publish with Maven quite awhile ago.
>>>> If you will notice all of the dates on the directories (dwr-noncla,
>>>> dwr-core, etc.) are from January 28th. So this directory should be
>>>> empty
>>>> and we should be publishing artifacts like we do with 2.x. We
>>>> currently
>>>> use Ant to publish the artifacts.
>>>
>>> Ok I understand this now.  Maybe ask if sonatype.org admin can
>>> delete the empty directories for obsolete artifactId's.  People
>>> won't question or become confused at what they can not see.
>>>
>>>
>>>
>>> > If you still see a problem here and want to take a look the work
>>> is done
>>> > in our build.xml.
>>>
>>>
>>> I have just pulled the SVN tree and can see why SNAPSHOTs are
>>> getting different versions because the same artifactId is having
>>> deploy-file run more than once (due to multiple XML elements in
>>> use).  Each operation with a SNAPSHOT version creates a new
>>> auto-incrementing version number at the repository.
>>>
>>> I also notice JavaDoc was missing from the SNAPSHOTs deployment
>>> process but is present in the releases.  JavaDoc is useful for IDE
>>> assistance and locating that data via Maven is really helpful to users.
>>>
>>>
>>> Please find attached an _untested_ patch based on the instructions
>>> for the maven-deploy-module at
>>> https://maven.apache.org/plugins/maven-deploy-plugin/  on how to
>>> publish  multiple classifiers at once to the same artifactId.   The
>>> method you were using before would be valid for deploying to
>>> multiple (and different) artifactId's (such as into each of the
>>> directories listed at
>>> https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/ 
>>> but you've explained this is not the intention of how 3.x
>>> releases/snapshots should be and was an old experiment).
>>>
>>> If this works correctly you should find there is 1 POM and 5 JARs
>>> published into the SNAPSHOTs folder _ALL_ with the same numeric
>>> version number.  This forms a complete set at that version that the
>>> Maven system can find and resolve.
>>>
>>>
>>> It would also be useful on the website to add an example of the
>>> Maven configuration snippet.  So it is clear that everything is
>>> being published under the same artifactId.  Also that to get access
>>> to noncla and jdk14 the user would need an explicit entry in their
>>> configuration to obtain it.  Maybe I can provide that back to this
>>> list once a set of artifactId show up in the repository that I can
>>> test against.
>>>
>>>
>>>
>>> Darryl
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

Darryl Miles
In reply to this post by david@butterdev.com
David Marginian wrote:
> "I have just pulled the SVN tree and can see why SNAPSHOTs are getting
> different versions because the same artifactId is having deploy-file run
> more than once (due to multiple XML elements in use). Each operation
> with a SNAPSHOT version creates a new auto-incrementing version number
> at the repository. "
>
> Also, this has made our build.xml more concise, but I don't see that it
> has resolved what you mention above. I also don't understand why this is
> a problem (the dependencies pull in fine).

Thanks for the prompt reply.


You are correct if you already know how to configure your maven pom.xml
with DWR to pull in the necessary artifacts the existing ones are
available at the repository.


Tsskk! to my untested diff.  Here is one I have tested against my local
nexus repo that works as expected.

I think there was a bug in maven-deploy-plugin:2.6:deploy-file and so
have bumped it to 2.7 to get it to work.  I also bumped
maven-gpg-plugin:1.3:sign-and-deploy-file (to 1.4) just in case that too
had such a problem.

Yes the -Dfile=<path> is a required field and looking at the
implementation of the Mojo at
https://svn.apache.org/viewvc/maven/plugins/tags/maven-deploy-plugin-2.7/src/main/java/org/apache/maven/plugin/deploy/ 
it is easier to understand how it intended to work.



Re my original concerns I think they stem from group is circumstances.

1) The website's Maven instructions pointing a user at the raw
repository.  This wouldn't be such a problem if the data there was in
pristine condition.

I have provided some text at the bottom of this email that you might
like to put into the Maven section of the website.


2) The empty directories with some Internet searchs returning other
peoples pom.xml being configured against those directories when using
3.x of DWR.


3) The need to reverse engineer the layout of the Maven repo to think up
a working configuration to use the project.


4) When the JAR is pulled in the source attachments appear to be for a
different version (than the JAR that got pulled in).  This is due to
unwanted version number bumping when deploy:deploy-file is used multiple
times against SNAPSHOTs (this is less of a problem for releases since
the version is fixed, the only observable different might be in
timestamp information).





Some new queries I have.

New Query 1)

It appears the "jdk14" attachment is not really an attachment but a
replacement and it should not be used with the main artifact JAR (due to
overlapping packages in use).  I do not know if the source code is
identical of simply if was just a compiler output class format change.

But due to this it would make sense for it to be artifactId=dwr-jdk14 IMHO.


New Query 2)

The "noncla" does not have its source in the main -sources artifact and
I'm sure there are sources possibly with Copyright headers in place.
Again due to the nature of what "noncla" is; it would make sense for it
to use artifactId=dwr-noncla and then have its own -sources artifact
that relates to it.  Just keeping the separation clean.  Again IMFO.




Some suggested text to provide a sample configuration for the DWR
website Maven instructions section:

    <dependency>
         <!-- Do not use this entry with classifier=jdk14 pick one, this
is the JRE 5+ version -->
         <groupId>org.directwebremoting</groupId>
         <artifactId>dwr</artifactId>
         <version>3.0.0-rc3-SNAPSHOT</version>
     </dependency>
     <dependency>
         <!-- Do not use this entry with the default classifier pick
one, this is the JRE 1.4 version -->
         <groupId>org.directwebremoting</groupId>
         <artifactId>dwr</artifactId>
         <classifier>jdk14</classifier>
         <version>3.0.0-rc3-SNAPSHOT</version>
     </dependency>
     <dependency>
         <!-- Optional non-CLA components see DWR documentation for
details -->
         <groupId>org.directwebremoting</groupId>
         <artifactId>dwr</artifactId>
         <classifier>noncla</classifier>
         <version>3.0.0-rc3-SNAPSHOT</version>
     </dependency>

    <repositories>
         <repository>
             <!-- Please consider setting up your own on-site repository
proxy such as with Nexus and pointing the url element below at that
instead --->
             <id>oss-sonatype-snapshots</id>
             <name>OSS Sonatype Snapshots Repository</name>
 
<url>http://oss.sonatype.org/content/repositories/snapshots</url>
             <releases>false</releases>
             <snapshots>true</snapshots>
         </repository>
     </repositories>




Thanks,

Darryl

build.xml.v3828.v2.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

david@butterdev.com
In reply to this post by Darryl Miles
Darryl, the Sonatype guys have removed the empty directories for us. 

On Sat, Mar 31, 2012 at 7:44 AM, Darryl Miles <[hidden email]> wrote:

The current version 3.0.0-rc3-SNAPSHOT appears to be at:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting

It appears to be getting auto-built.


However the install/deployment step to publish the Maven artifacts is doing so incorrectly.

It is installing _ALL_ modules into the same articleId of "dwr"


This can be observed at: https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/

Where you will see a bunch of various attachment types "-sources" "-javadoc" "-jdk14" are all overwriting themselves.


For example the version number "20120325.171435-50" is currently the latest version.  Which is a pom project and a "-sources" attachment relating to it.

Non of the other files listed in the directly are visible to the Maven resolution process and therefore do not work via Maven.



What should be happening is each module is publish into its own artifactId folder.  For example:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/dwr-3.0.0-rc3-20120325.171420-48-noncla.jar

This file should be published at:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/3.0.0-rc3-SNAPSHOT/dwr-noncla-3.0.0-rc3-20120325.171420-48.jar

Note the use of <project><type>jar</type>...  so the "-noncla" is removed from the end of the filename.

Note the filename stem becoming "dwr-noncla" which makes the filename unique enough.  But personally I prefer to use fully qualified files names this would be setup on the POM as <project><build><finalName>${project.groupId}.${project.artifactId}-${project.version}</finalName>...

If you look at just the folder:

https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-noncla/

it is empty where stuff should be.


The release 2.0.10 at https://oss.sonatype.org/content/repositories/releases/org/directwebremoting/dwr/2.0.10/ uses a single JAR for everything.  Maybe the problem is that the project wasn't updated when various module JAR were split up and created ?



Maybe someone can point me to the script used to perform the publishing of the -SNAPSHOT by the auto-builder system so I could suggest a patch so it.



Thanks,

Darryl


Reply | Threaded
Open this post in threaded view
|

Re: Published maven builds for 3.0.0-rc3-SNAPSHOT invalid

Mike Wilson
Administrator
In reply to this post by Darryl Miles
Darryl Miles wrote:

> <snip>
> New Query 1)
>
> It appears the "jdk14" attachment is not really an attachment but a
> replacement and it should not be used with the main artifact
> JAR (due to
> overlapping packages in use).  I do not know if the source code is
> identical of simply if was just a compiler output class format change.
>
> But due to this it would make sense for it to be
> artifactId=dwr-jdk14 IMHO.
>
> New Query 2)
>
> The "noncla" does not have its source in the main -sources
> artifact and
> I'm sure there are sources possibly with Copyright headers in place.
> Again due to the nature of what "noncla" is; it would make
> sense for it
> to use artifactId=dwr-noncla and then have its own -sources artifact
> that relates to it.  Just keeping the separation clean.  Again IMFO.
> <snip>

These changes seem to make sense. What do you think David?

"IMFO" - are you angry? ;-)
http://www.urbandictionary.com/define.php?term=imfo

Best regards
Mike Wilson