Re: Eclipse import

You need to import and open the eclipse projects for each unresolved dependency. El jue., 19 de diciembre de 2019 19:28, Elliotte Rusty Harold < elh...@ibiblio.org> escribió: > There seems to be something I'm missing about importing projects into > Eclipse. I can build them at the command line, b

Eclipse import

There seems to be something I'm missing about importing projects into Eclipse. I can build them at the command line, but they're full of errors like BookModel cannot be resolved to a typeBookContext.java /doxia-book-renderer/src/main/java/org/apache/maven/doxia/book/context line 113Java

Re: maven site master branch

Hi Elliotte, On 19.12.19 20:24, Elliotte Rusty Harold wrote: To my surprise I just edited the master branch of maven-site directly without review, when I thought I would be creating a PR. Oops. If really went something wrong ...we have a version control... ... This was a minor change, but w

maven site master branch

To my surprise I just edited the master branch of maven-site directly without review, when I thought I would be creating a PR. Oops. This was a minor change, but whoever has permissions to modify the repo should probably protect the master branch in the Github settings so future accidents don't ha

Re: relativePath for parent poms in our plugins

I agree. RelativePath is only useful within a Maven MultiModule project (in 1 git repo) Using is even a bit better, because it overwrites the default of ../pom.xml and forces to look in the local/remote repo Robert On 19-12-2019 12:14:40, Mark Struberg wrote: Hi folks! Looking at massembler

Re: [massembly] code question

If we can still log included deps are empty (agree it should be real deps and not these ones) elsewhere +1 (think otherwise it looks something went wrong in debug mode, no log does not mean empty if you follow me) Le jeu. 19 déc. 2019 à 16:43, Anders Hammar a écrit : > I agree. It's strange and

Re: [massembly] code question

I agree. It's strange and the debug log output is actually technically wrong. So I'd say remove it. /Anders On Thu, Dec 19, 2019 at 2:39 PM Mark Struberg wrote: > Hi! > > Feeling a bit rusty, so I thought I better ask for a 2nd opinion. > > To me it looks like the following code block is really

Re: [massembly] code question

Well, the project dependencies may or may not be used depending on your assembly setup. The only data which is used in this scenario is List dependencySets; So it might probably be fine to add a logging if the dependencySets is empty. The only part where the project dependencies are really used

Re: [massembly] code question

@Mark: likely studid but do you get the debug insight removing it on a project without dependencies? Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

[massembly] code question

Hi! Feeling a bit rusty, so I thought I better ask for a 2nd opinion. To me it looks like the following code block is really obsolete and did not make anything useful ever since https://github.com/apache/maven-assembly-plugin/blob/master/src/main/java/org/apache/maven/plugins/assembly/archive/t

Re: relativePath for parent poms in our plugins

Agree Le jeu. 19 déc. 2019 à 12:14, Mark Struberg a écrit : > Hi folks! > > Looking at massembler right now I stumbled across a parentPom section > > > maven-plugins > org.apache.maven.plugins > 33 > ../../pom/maven/maven-plugins/pom.xml > > > This was perfectly fine when we had all in

relativePath for parent poms in our plugins

Hi folks! Looking at massembler right now I stumbled across a parentPom section maven-plugins org.apache.maven.plugins 33 ../../pom/maven/maven-plugins/pom.xml This was perfectly fine when we had all in SVN under one big project. But nowadays - having all in GIT - I'd we should remove