Maven central

[nikkekin]

Hey,

Would it be possible to have the releases available in maven central?

Best,
Niklas

[carueda]

Thanks for your interest!

tscfg is still mainly offered as an executable tool, which is the only artifact being released so far.

Are you referring to this executable jar? Or perhaps your suggestion is about also releasing tscfg as a library or plugin (#21)?

[nikkekin]

Hey,

Thanks for a nice project.

We intend to use it in a way that allows us to define it as a dependency, so it would just be very convenient to have it available in maven central. This way it is also explicit what version of the jar a project is using.

If it is not too big of a deal it would be appreciated :).

-niklas

[carueda]

Just went ahead with a direct publication of the current version 0.8.0: http://search.maven.org/#search%7Cga%7C1%7Ctscfg

Note that the published artifacts (jar, javadocs, etc.) are the ones packaged by the sbt-sonatype plugin by default. In other words, the actual proper artifact that tscfg currently offers is the fat, executable jar file (which is not in the maven release).

From you comment above is not very clear to me whether by "the jar" you are referring to the regular tscfg_2.11-0.8.0.jar (which you would be using as dependency in your project), or to the fat tscfg-0.8.0.jar.

I decided to close this issue as fixed, but we can either re-open it or create a more specific one depending on any additional details.

Thanks for again for your interest and use of tscfg!

[nikkekin]

Hey,

Thanks for looking into this, it would be the fat tscfg-0.8.0.jar that we would like to get from maven central.

Sorry for not being precise enough on the first go...

-niklas

[carueda]

Well, besides not seeing any obvious mechanism to include the fat jar in the upload to maven central (not to mention that it seems to me this would be a rather atypical use), you may want to just go ahead and use the already published artifacts.

As a quick demonstration, I just wrote a simple project from scratch with this structure:

.
├── build.sbt
├── pom.xml
└── src
    └── main
        └── java
            └── tscfgtest
                └── Main.java

So, including build.sbt and pom.xml (I'm not sure which build tool you are using):

build.sbt:

libraryDependencies += "com.github.carueda" % "tscfg_2.11" % "0.8.0"

pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>foo.test</groupId>
	<artifactId>tscfgtest</artifactId>
	<version>1.0-SNAPSHOT</version>

	<dependencies>
		<dependency>
			<groupId>com.github.carueda</groupId>
			<artifactId>tscfg_2.11</artifactId>
			<version>0.8.0</version>
		</dependency>
	</dependencies>
</project>

and this main program (assuming you are calling tscfg from java):

package tscfgtest;

public class Main {
  public static void main(String[] args) {
    tscfg.Main.main(args);
  }
}

All of this runs fine -- no need for the fat jar.

Make sense?

Now, to reiterate, no time has been spent (yet) on making a proper tscfg library per se, I mean, in terms of providing an API with appropriate javadocs, etc. At the moment, that "API" is the tscfg.Main.main method with documentation being the usage message printed out by that method.

As a client of such more proper library, you will probably prefer to call something like this (assuming Scala):

  tscfg.generate(
    spec           = "src/main/resources/my.spec.conf",
    packageName    = "foo"
    className      = "Cfg"
    destDirectory  = "src/main/scala/foo",
    language       = "scala
  )

instead of calling the main program:

  tscfg.Main(Array[String](
    "--spec", "src/main/resources/my.spec.conf",
    "--pn",   "foo",
    "--cn",   "Cfg",
    "--dd",   "src/main/scala/foo",
    "--scala"
  ))
)

[nikkekin]

Hey,

Thanks for opening it up in a very clear manner.

We really just want to have the fat jar we can add as a dependency, that's all. Then our buildtool (gradle) can use it to output the java-classes on demand without still actually including the fat-jar as a dependency to the deployment-package.

But I think we can work it out from here ourselves just fine.

-niklas

[nikkekin]

Hey,

I think I got earlier wrong what you meant by far-jar, the one you provide right now is very much enough for us :)

-niklas

[carueda]

My pleasure!

Feel free to "star" this project if you are so inclined ; )