I can look into adding the OSGi jar as a separate artifact.  Hopefully this will provide a temporary "quick fix" for you.

The current "OSGi Runtime Library" is actually a collection of several artifacts, specifically I think it's scala-dbc, scala-swing + scala-library.   If we wanted to cannonize this, I'd recommend making each of these three libraries have appropraite OSGi manifests, and then there's no need to update maven at all (however this would affect the eclipse plugin).

-Josh

On Wed, Jan 7, 2009 at 11:39 AM, Grey <ray.racine@gmail.com> wrote:

I swapped an email this morning with Dave B of scala-tools inquiring whether
scala-tools maven repo could host the Scala OSGi Runtime library jar as well
as the standard Scala jars.

The problem is a naming collision of the library name,
scala.library_2.7.2.final.jar

Would  EFPL  (Josh S.) consider modifying the push script to scala-tools to
push scala.library_osgi_2.7.2.final.jar to scala-tools or some other
uniquely named jar.

Or.

Another option, I think, is to have only one scala.library_x.y.z.final.jar
as part of the standard release with OSGi bundle manifest information as
opposed to the current dual version approach.

Thanks,

Ray



--
View this message in context: http://www.nabble.com/OSGi-Scala-Runtime-In-Scala-Tools-Maven-Repo-tp21335168p21335168.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

Hate to put the stability of the plug-in at risk for just little ol' me. I
didn't know the OSGi jar was a compendium jar of EFPL's Scala body of work.
I really just need the runtime.

I have another route which is actually pretty easy. I have a standard
technique of creating a OSGi bundle from an arbitrary jar via a Maven
module. The module pom grabs the jar and then uses the OSGi bundler Maven
plugin to insert the appropriate exports et al.

The one time cost is just typing the exports which I can steal from the
manifest from the current version you put out.

It will work just fine for me.

Thanks for getting back on the request though, thanks Josh.

Josh Suereth wrote:
>
> I can look into adding the OSGi jar as a separate artifact. Hopefully
> this
> will provide a temporary "quick fix" for you.
>
> The current "OSGi Runtime Library" is actually a collection of several
> artifacts, specifically I think it's scala-dbc, scala-swing +
> scala-library. If we wanted to cannonize this, I'd recommend making each
> of these three libraries have appropraite OSGi manifests, and then there's
> no need to update maven at all (however this would affect the eclipse
> plugin).
>
> -Josh
>
> On Wed, Jan 7, 2009 at 11:39 AM, Grey wrote:
>
>>
>> I swapped an email this morning with Dave B of scala-tools inquiring
>> whether
>> scala-tools maven repo could host the Scala OSGi Runtime library jar as
>> well
>> as the standard Scala jars.
>>
>> The problem is a naming collision of the library name,
>> scala.library_2.7.2.final.jar
>>
>> Would EFPL (Josh S.) consider modifying the push script to scala-tools
>> to
>> push scala.library_osgi_2.7.2.final.jar to scala-tools or some other
>> uniquely named jar.
>>
>> Or.
>>
>> Another option, I think, is to have only one
>> scala.library_x.y.z.final.jar
>> as part of the standard release with OSGi bundle manifest information as
>> opposed to the current dual version approach.
>>
>> Thanks,
>>
>> Ray
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/OSGi-Scala-Runtime-In-Scala-Tools-Maven-Repo-tp213...
>> Sent from the Scala - Tools mailing list archive at Nabble.com.
>>
>>
>
>

Ray,

You aren't the first person to make this request.  I believe I made a similar request a while ago.  For now as long as you have a workaround, it isn't high priority, but I am going to put this on my  back-burner of todos (which seems to only be increasing lately...)

Let me know if you need any other help with the maven+scala.

-Josh

On Wed, Jan 7, 2009 at 7:15 PM, Grey <ray.racine@gmail.com> wrote:

Hate to put the stability of the plug-in at risk for just little ol' me.  I
didn't know the OSGi jar was a compendium jar of EFPL's Scala body of work.
I really just need the runtime.

I have another route which is actually pretty easy.  I have a standard
technique of creating a OSGi bundle from an arbitrary jar via a Maven
module.  The module pom grabs the jar and then uses the OSGi bundler Maven
plugin to insert the appropriate exports et al.

The one time cost is just typing the exports which I can steal from the
manifest from the current version you put out.

It will work just fine for me.

Thanks for getting back on the request though, thanks Josh.


Josh Suereth wrote:
>
> I can look into adding the OSGi jar as a separate artifact.  Hopefully
> this
> will provide a temporary "quick fix" for you.
>
> The current "OSGi Runtime Library" is actually a collection of several
> artifacts, specifically I think it's scala-dbc, scala-swing +
> scala-library.   If we wanted to cannonize this, I'd recommend making each
> of these three libraries have appropraite OSGi manifests, and then there's
> no need to update maven at all (however this would affect the eclipse
> plugin).
>
> -Josh
>
> On Wed, Jan 7, 2009 at 11:39 AM, Grey <ray.racine@gmail.com> wrote:
>
>>
>> I swapped an email this morning with Dave B of scala-tools inquiring
>> whether
>> scala-tools maven repo could host the Scala OSGi Runtime library jar as
>> well
>> as the standard Scala jars.
>>
>> The problem is a naming collision of the library name,
>> scala.library_2.7.2.final.jar
>>
>> Would  EFPL  (Josh S.) consider modifying the push script to scala-tools
>> to
>> push scala.library_osgi_2.7.2.final.jar to scala-tools or some other
>> uniquely named jar.
>>
>> Or.
>>
>> Another option, I think, is to have only one
>> scala.library_x.y.z.final.jar
>> as part of the standard release with OSGi bundle manifest information as
>> opposed to the current dual version approach.
>>
>> Thanks,
>>
>> Ray
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/OSGi-Scala-Runtime-In-Scala-Tools-Maven-Repo-tp21335168p21335168.html
>> Sent from the Scala - Tools mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: http://www.nabble.com/OSGi-Scala-Runtime-In-Scala-Tools-Maven-Repo-tp21335168p21343417.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

Our Maven builds are configured with just two repositories, http://repo1.maven.org/maven2 and http://scala-tools.org/repo-releases (We use Artifactory as a central repo cache) But since Friday, I've noticed builds failing because builds are trying to download jms-1.1.jar from maven-repository.dev.java.net even though that is not in our repo path or configuration. Downloading: https://maven-repository.dev.java.net/nonav/repository/javax.jms/jars/jm... 347b downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'd0b7ce08d257e8fefdc6ad0f0f0368635bbeb3d0'; remote = ' 301 Moved Permanently

Moved Permanently

The document has moved here.

Apache Server at maven-repository.dev.java.net Port 443 I'm baffled. Does anyone know how http://scala-tools.org/repo-releases is configured - could it be forwarding or redirecting requests to java.net? Or does anyone know how/why the maven-repository.dev.java.net repo is being injected into my maven repository path? (I can workaround this by downloading jms-1.1.jar and putting in our artifactory repo, but I think that is simply masking a problem, so this will probably pop back up.) thanks ------- More details, in case this might help: http://repo2.maven.org/maven2/javax/jms/jms/1.1/ contains a pom but no jar , but http://repository.jboss.com/maven2/javax/jms/jms/1.1/ has the jar. my project does not even depend on jms directly; it appears to be one of the internal Maven compile or site targets that cause it to get loaded, but I'm not sure which. In artifactory's config, we specify: repo1 true false org/artifactory/**,org/jfrog/** http://repo1.maven.org/maven2 SASproxy scala-tools.org true false http://scala-tools.org/repo-releases SASproxy My ~/.m2/settings.xml is empty and /usr/local/maven/conf/settings.xml simply points to my Artifactory server, no other repos in the profile: artifactory true central http://aclmvn.unx.sas.com:8192/artifactory/repo false snapshots http://aclmvn.unx.sas.com:8192/artifactory/repo false central http://aclmvn.unx.sas.com:8192/artifactory/repo false snapshots http://aclmvn.unx.sas.com:8192/artifactory/repo false

We have the same issue since we used log4j (1.2.15) (last week).
maven use every reporitory you define in settings + repository define in the pom.xml of the artifact (eg: log4j-1.2.15 define the repository  maven-repository.dev.java.net because it depends of jms-1.1, jmxtools,...).
Use mvn dependency:tree to (or generate the site to know which artifact and from where).
About your html as jar. maven, nexus should do the check/redirect (option for nexus, I don't know about artifactory),
I hope this help you.
On Mon, Dec 7, 2009 at 21:23, David J. Biesack <David.Biesack@sas.com> wrote:

Our Maven builds are configured with just two repositories,
http://repo1.maven.org/maven2 and http://scala-tools.org/repo-releases
(We use Artifactory as a central repo cache)

But since Friday, I've noticed builds failing because builds are trying to download jms-1.1.jar
from maven-repository.dev.java.net even though that is not in our repo path or configuration.

 Downloading: https://maven-repository.dev.java.net/nonav/repository/javax.jms/jars/jms-1.1.jar
 347b downloaded
 [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'd0b7ce08d257e8fefdc6ad0f0f0368635bbeb3d0'; remote = '<!DOCTYPE' - RETRYING

Worse, what gets downloaded is not a jar but some html. Maven seems to ignore the 301 status and thinks this is a jar. The contents are:

   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
   <html><head>
   <title>301 Moved Permanently</title>
   </head><body>
   <h1>Moved Permanently</h1>
   <p>The document has moved <a href="http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar">here</a>.</p>
   <hr>
   <address>Apache Server at maven-repository.dev.java.net Port 443</address>
   </body></html>

I'm baffled.

Does anyone know how http://scala-tools.org/repo-releases is configured - could it be forwarding or redirecting requests to java.net?

Or does anyone know how/why the maven-repository.dev.java.net repo is being injected into my maven repository path?

(I can workaround this by downloading jms-1.1.jar and putting in our artifactory repo, but I think that is simply masking a problem, so this will probably pop back up.)

thanks

-------

More details, in case this might help:

http://repo2.maven.org/maven2/javax/jms/jms/1.1/ contains a pom but no jar , but http://repository.jboss.com/maven2/javax/jms/jms/1.1/ has the jar.

my project does not even depend on jms directly; it appears to be one of the internal Maven compile or site targets
that cause it to get loaded, but I'm not sure which.

In artifactory's config, we specify:

  <remoteRepositories>
       <remoteRepository>
           <key>repo1</key>
           <handleReleases>true</handleReleases>
           <handleSnapshots>false</handleSnapshots>
           <excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>
           <url>http://repo1.maven.org/maven2</url>
           <proxyRef>SASproxy</proxyRef>
       </remoteRepository>

       <remoteRepository>
           <key>scala-tools.org</key>
           <handleReleases>true</handleReleases>
           <handleSnapshots>false</handleSnapshots>
           <url>http://scala-tools.org/repo-releases</url>
           <proxyRef>SASproxy</proxyRef>
       </remoteRepository>
  </remoteRepositories>

My ~/.m2/settings.xml is empty and /usr/local/maven/conf/settings.xml simply points to my Artifactory server, no other repos in the profile:

 <profiles>
   <profile>
     <id>artifactory</id>
     <activation><activeByDefault>true</activeByDefault></activation>

        <repositories>
            <repository>
                <id>central</id>
                <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </repository>
            <repository>
                <id>snapshots</id>
                <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
                <releases>
                    <enabled>false</enabled>
                </releases>
            </repository>
        </repositories>
        <pluginRepositories>
            <pluginRepository>
                <id>central</id>
                <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
                <snapshots>
                    <enabled>false</enabled>
                </snapshots>
            </pluginRepository>
            <pluginRepository>
                <id>snapshots</id>
                <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
                <releases>
                    <enabled>false</enabled>
                </releases>
            </pluginRepository>
        </pluginRepositories>

   </profile>
 </profiles>

--
David J. Biesack, SAS
SAS Campus Dr. Cary, NC 27513
www.sas.com    (919) 531-7771