7 Mar
2013
7 Mar
'13
12:11 p.m.
2013/3/7 Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
2013/3/7 Eduard Moraru <enygma2002(a)gmail.com>
Worse, is that I would have to do something like
java.util.regex.Pattern.quote("${file.separator}") to put in in the
<regex>
...
Hi,
On Thu, Mar 7, 2013 at 9:22 AM, Vincent Massol <vincent(a)massol.net>
wrote:
(enforce-javadoc-exists)
java.io.File("C:\PRIVATE\tabs-macro\target\checkout\target/xwiki-macro-tabs-1.0.1-SNAPSHOT-javadoc.jar")
java.io.File("${project.build.directory}/${project.build.finalName}-javadoc.jar").exists())</condition>
Main problem is that maven exposes system paths inside properties without
caring about them being later used from java or other language, which is
understandable though pretty annoying sometimes.
On Mar 6, 2013, at 6:16 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com>
wrote:
from
Hi,
@Vincent : I agree with all your points, my feedback was more on that
these
points may not be clear for contributors at first
(at least, it wasn't
for
me).
We need to put all information on contrib.xwiki.org so if you think
something is missing there, maybe you could add it?
My only little worry is that maybe it does not
require the same level
of knowledge to merely create and publish a simple extension on
xwiki.org,
> and to develop a maven module for it and release it to Nexus staging github,
though it'd be better to have all extensions in a maven
repository
(for flavors/bundles for example).
Sure it doesn't! This is why contrib.xwiki.org provides explanations.
> Additionnally, it seems that with the sample pom provided (for xar), I
> always get the following error when trying to release:
>
> [INFO] --- maven-enforcer-plugin:1.1:enforce @
> xwiki-macro-tabs ---
> [WARNING] Rule 0:
org.apache.maven.plugins.enforcer.EvaluateBeanshell
failed
with message:
Couldn't evaluate condition: ("xar" != "jar") ||
("xar" == "jar" &&
new
.exists())
The rule we have in the commons pom is:
<condition>("${project.packaging}" !=
"jar") ||
("${project.packaging}" == "jar" && new
so I guess replacing all "\" with "/" in ${project.build.directory}
should
work.
I don`t know all the details, but that looks like java (or groovy), so I
guess that, for windows, instead of "\", you should use "\\" or else
it
will try to escape stuff.
Also, why not use java.io.File.separator instead of the manual "/" or
"\\"?
For sure, I should replace "${file.separator}" by '/' to be sure. But
as
separator that causes problems in java is 100% of time single backslash
'\', I'm not sure it would bring anything better.
What is wrong in my configurations above, is that I
replace all '\' by
'/', though I should take care to only replace single '\' by '/'
(in regex
above, "\\" would be replaced by "//"). This is likely to never cause
any
problem though, as I don't think "\\" is a path separator on any system.
Hope this helps,
Eduard
is
on
http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HPublishingonextension…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
It's strange that it fails since the first
condition is true so it
shouldn't even evaluate the second one…
Maybe you could try to duplicate this rule in your pom to verify if it
works:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-javadoc-exists</id>
<phase>verify</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<evaluateBeanshell>
<condition>("${project.packaging}" !=
"jar") ||
("${project.packaging}" == "jar" && new
java.io.File("${project.build.directory}\${project.build.finalName}-javadoc.jar").exists())</condition>
<message>Missing
Javadoc JAR</message>
</evaluateBeanshell>
</rules>
<fail>true</fail>
</configuration>
</execution>
<executions>
</plugin>
</plugins>
</build>
Thanks
-Vincent
of a
I think maybe it's because of being on Windows (as show by the paths),
that
> would explain why you seem not to have this problem ;-)
>
> It's easily workaround by skiping that enforcer rule, but it's kind dirty
workaround.
BR,
Jeremie
2013/3/3 Vincent Massol <vincent(a)massol.net>
> Hi Jeremie,
>
> On Feb 22, 2013, at 12:01 PM, Jeremie BOUSQUET <
jeremie.bousquet(a)gmail.com>
>> wrote:
>>
>>> Hi Vincent,
>>>
>>> Very nice and welcome add :)
>>>
>>> Just a small remark, maybe it's written somewhere else (or obvious
>> enough),
>>> but if you have an extension that depends on another extension that >> not
>>> in a maven, but only in an xwiki repository, then of course you
can't
>>> define this dependency in your
pom.xml, and there is an additional
step
>>> after "import" from
repository application, it is to manually add
those
>>
kind of dependencies.
>
> Indeed.
>
> Actually the only good solution for this is to never depend on an
> extension that is not published in a maven repository.
>
> If you do then you don't have a proper working build. I don't see how
> you're able to write automated functional tests for your extension
either
> this way. So it means you have an incomplete
build.
>
> Thus the solution is to first publish the extension in a maven
repository,
>> by creating a repo for it in xwiki-contrib and releasing it.
>>
>> Thanks
>> -Vincent
>>
>>>
>>> BR,
>>> Jeremie
>>>
>>>
>>> 2013/2/22 Vincent Massol <vincent(a)massol.net>
>>>
>>>> Hi guys,
>>>>
>>>> I've just added explanations on how to publish a contrib extension
>>> extensions.xwiki.org here:
>>>
>>>
>
>>>
>>> Hope it helps,
>>> -Vincent
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs