ah ok 🙂

You depend on JCommander, declare it explicitly. Don't rely on another dependency to pull it for you.

That's the general idea.

right.. but if A depends on B and B depends on B_internal and B_internal2, i'll go ahead and let B figure that out

and rely on the build system to bring it all in

Which is correct since A doesn't depend on B_Internal

Let's replace "depend" with "need" to be clearer

right

so yeah, in my case xchart is an internal dep of golem-core... core has a

plot

function that it internally uses xchart to implement, so i'd prefer not to have to have users also need to dep on xchart explicitly. i may have some time in the near future to dig into kobalt a bit and see if i can get familiar enough with it to contribute

It should work (barring Kobalt's bug getting fixed).

Like I said, it's a bit dangerous but I understand that the value added to your users (less configuration) is worth it in this case, especially since they're unlikely to be bitten by the downsides of this approach.

You and I as library authors need to be more strict with what we release, it's a higher standard in the lib world.

Maybe one day I'll get to use IDEA to create a plugin, not today apparently.

You already have

Never had one project that worked.

Not even

kobalt-exec

?

Oh did you mean an IDEA plug-in?

I think on and off, most of the time the kobalt IDEA plugin sees nothing.

The IDEA plugin is using it's own version of kobalt, right?

@cedric: You didn't push a new API for

fileFor

, did you?

@ethauvin: No the current

fileFor()

is the last one

@cedric: Does the

maven

tasks calls on the

generatePom

tasks?

@cedric: Nevermind, it won't matter if I have a way to get to the pom.

@cedric: you around?

yup

TaskContributor.addVariantTasks

, what is the

group

used for?

I put

publish

in there, but it still shows as a separate task.

It’s for the IDE, so it knows where in the task tree this task should be shown

Ah!

It’s optional, you’ll go in a default group if you don’t specify it