Re: Using publish-local to publish to local Maven repository

[Jeff Olson]

I agree it would be a nice feature. In fact, it would be awesome if publish-local defaulted to publishing to a local Maven repo (~/.m2) whenever publishMavenStyle := true. I get tired of swapping out 'publishTo' whenever I'm done testing.

-Jeff

On Monday, March 18, 2013 11:26:44 PM UTC-5, Brian Topping wrote:

Sorry to necro this thread, but I'd also like to know if this is possible.  I'm guessing it's not possible because nobody's answered it, but hoping for the best!

On Wednesday, June 13, 2012 7:53:01 AM UTC-4, Vetle Leinonen-Roeim wrote:

Hi,

Using publish-local, it is possible to publish an artifact to a local Ivy repository. To publish to a local Maven repository, you can set publishTo, as shown here: https://github.com/harrah/xsbt/wiki/Publishing

Is there any way to get publish-local to publish to the local Maven repository instead of the Ivy repository?

Regards,

Vetle

[Mark Harrah]

On Mon, 18 Mar 2013 21:26:44 -0700 (PDT)
Brian Topping <brian....@gmail.com> wrote:

> Sorry to necro this thread, but I'd also like to know if this is possible.
> I'm guessing it's not possible because nobody's answered it, but hoping
> for the best!

Define these in a Build.scala file:

lazy val publishM2Configuration =
TaskKey[PublishConfiguration]("publish-m2-configuration",
"Configuration for publishing to the .m2 repository.")

lazy val publishM2 =
TaskKey[Unit]("publish-m2",
"Publishes artifacts to the .m2 repository.")

lazy val m2Repo =
Resolver.file("publish-m2-local",
Path.userHome / ".m2" / "repository")

and add these settings to each project you want to publish to .m2/repository/

publishM2Configuration <<= (packagedArtifacts, checksums in publish, ivyLoggingLevel) map { (arts, cs, level) =>
Classpaths.publishConfig(arts, None, resolverName = m2Repo.name, checksums = cs, logging = level)
},
publishM2 <<= Classpaths.publishTask(publishM2Configuration, deliverLocal),
otherResolvers += m2Repo

Then, run publish-m2.

Please let me know how this works out for you. I've provisionally added this for 0.13 and will keep it if you don't run into any problems. In general, it is hard to interoperate with the .m2/repository/ because it is a local repository mixed with a cache. Publishing should be fine, but resolving from it is problematic.

-Mark

> On Wednesday, June 13, 2012 7:53:01 AM UTC-4, Vetle Leinonen-Roeim wrote:
> >
> > Hi,
> >
> > Using publish-local, it is possible to publish an artifact to a local Ivy
> > repository. To publish to a local Maven repository, you can set publishTo,
> > as shown here: https://github.com/harrah/xsbt/wiki/Publishing
> > Is there any way to get publish-local to publish to the local Maven
> > repository instead of the Ivy repository?
> >
> > Regards,
> > Vetle
> >
> >
>

> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simple-build-t...@googlegroups.com.
> To post to this group, send email to simple-b...@googlegroups.com.
> Visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Mark Harrah]

On Tue, 19 Mar 2013 12:07:15 -0700 (PDT)
Brian Topping <brian....@gmail.com> wrote:

> Hi guys, thanks for your replies.
>
> What I'm optimally looking for is functionality that transcends builds, not
> something I have to cut and paste into every build, even if it's a single
> line.
>
> I feel it's a reasonable request because people that are required to use
> Maven on their Scala builds for non-technical reasons are constantly
> running into good and useful projects that are built with SBT, but the
> artifacts aren't published to a public repo anywhere. When that happens,
> they need to "party like it's 1999", download the sources and build them.
> Having to edit every build to do something that is so common for folks in
> this situation isn't very DRY.
>
> If it's some kind of pact with the devil for some to support Maven, maybe
> it could be handled by a global tasks configuration that was loaded
> from ~/.sbt. That way, individual users that needed the functionality
> could configure it and the SBT team could wash their hands of it.
>
> Just trying to figure this out, hopefully I'm overthinking the problem and
> it can just be added to SBT.

I'm not sure we're on the same page. Did you see this part of my reply?

> > Please let me know how this works out for you. I've provisionally added
> > this for 0.13 and will keep it if you don't run into any problems.

If you did, are you looking for a temporary workaround for now?

-Mark

> best, Brian

[Brian Topping]

Oh jeez, my apologies!! I did miss that. Thank you very much on behalf of myself and all the Maven users who won't know they weren't missing the feature!! :))

No workaround necessary, I will set it up and let you know. Thanks again.

Best, Brian

Sent from my iPad

[Brian Topping]

Maybe I should provide some personal background on this functional issue with SBT as I know it echoes the experience of others that I have seen while searching for a solution to this problem over the last three months.

Me and my company use Maven as our build system and because we're using Scala, we're inevitably exposed to dependency projects that are built with SBT as it is the dominant Scala build system.  So far, so good.

Sometimes we need to build an unreleased version of one of these dependency projects and get the artifacts into Nexus so others using Maven in our company have access to them.  We're in early development stages of our project, and as good community members, we like to use unreleased versions and try to help improve them at the same time we take advantage of advanced features.

The problem is that anytime we need to build one of these dependency projects and get Maven artifacts, we need to go through and modify the dependency build.  In declarative builds, this is easier because it doesn't matter where we put the declaration of a repository or publishing strategy, but it does often matter in procedural builds.  Worse, it happens so often for so many people that this isn't an uncommon task for a lot of people.

What's frustrating is publish-local does exactly what we're all looking for, it just simply needs to be improved to allow publishing to the Maven repository instead of the Ivy one.  Just like the local Ivy repository, it's completely reasonable that it could be located anywhere but is usually in the same place, and we all know that SBT is perfectly capable of publishing to Maven repositories. 

So what we're collectively asking for is a simple means to jump into any SBT project and publish to the local Maven repository with defaults.  It's completely reasonable that publishing to remote or non-default repositories would require build reconfiguration, but why is it so hard to have a means to publish to the standard local Maven repository?

best, Brian

[Paul Phillips]

On Thu, Jun 27, 2013 at 8:02 AM, Brian Topping <top...@codehaus.org> wrote:

So what we're collectively asking for is a simple means to jump into any SBT project and publish to the local Maven repository with defaults.  It's completely reasonable that publishing to remote or non-default repositories would require build reconfiguration, but why is it so hard to have a means to publish to the standard local Maven repository?

Does "publish-m2" not do what you want? It does for me, on the subset of projects where I can use sbt 0.13.0-Beta2 (which means, plus or minus, projects which have no sbt plugins.)

[Brian Topping]

Hi Paul, I'm still unable to see this command anywhere.  I'm sure this is a lack of skill with SBT on my part and I've continued to have to modify builds to get things pushed to the local maven repo.  Someone told me a couple of days ago that maybe this has to do with some automagic SBT versioning going on, I really don't know.  Magic is hard to debug, for sure.

I guess it will just magically start working someday, but what's challenging is I thought this was supposed to be the "simple build tool".  I'm no masochist when it comes to builds and code, but I think I went into SBT with the wrong perspective as the name left me thinking that I was going to trade off the (presumably "hard") aspects of declarative builds with procedural magic that was "simple".  I recognize there's no free lunch, but that can't count as an excuse for all this complexity over existing tools that work.  Maybe changing the meaning of the acronym to "SBT Build Tool" would help others avoid the "simple" trap and not ask stupid questions.  A full PDF of the manual might actually help in this regard so new users can get a bigger picture of what they are dealing with before they start.

It was often said that Apple made a big mistake in the 1990's by creating AppleTalk when they could have just created Bonjour/MDNS on TCP/IP in the first place and the world would have been a much better place.  Because, quite literally, multicast discovery was practically all AppleTalk provided over TCP above the physical layer at the time.  I wish that the existing tools and infrastructure could have been similarly improved, but that presumes that the was alignment on the basic premise of declarative builds in the first place.

This is the wrong forum and thread to rant about what's wrong with the world, but I'd eventually like to see the light as to why SBT is a better solution than systems that are already out there and solve the same problems without resorting to new repository formats and duplicating everything that's already been built for unknown reasons.  It's kind of cool that I can practice my Scala while I work on the build, but it's not just a map of properties once "axes" get involved (for instance) and the fact that every new SBT build is like entering a foreign country with no guide is completely crazy.  It's no secret that I am a fan of declarative builds with procedural aspects (and potentially obfuscated or otherwise "see how awesome my code is" coding styles) encapsulated by plugins.

Sorry for the rant.  I'm really grateful anytime folks sign themselves up to improve the world and it's no exception here with the folks that bring us SBT because I know that we all have different experiences that bring us to different conclusions.  It's not fair to them that I am pointing fingers like this and the religious zealotry behind declarative over procedural builds is precisely the reason that Ivy was invented and continues to muddle the simplicity that the we'd all have from a unified repository format for exactly the same artifacts.  It's a delicate dance to point out issues without causing pain, especially in the face of one's own pain and the natural tendency to react negatively in that situation.

[Paul Phillips]

On Sat, Jul 6, 2013 at 10:54 AM, Brian Topping <top...@codehaus.org> wrote:

I guess it will just magically start working someday, but what's challenging is I thought this was supposed to be the "simple build tool".

I assume this was all directed at the world at large and not at me, because I'm usually on the writing end of that message.

[Brian Topping]

LOL, yes.  I'm sure SBT started out as "simple" and then more features were added.  In the end, it's at least as complex as Maven and every build is different because it's procedural.  

Moving along.  I wasn't looking for a response and few probably care, but it doesn't help if nobody asks "why?".