[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dash-dev] Bug 342046 - Invalid third party dependencies in Mavenized BIRT plugins
|
Hello,
I'm working on this bug. To resolve it, two things need to be done:
1. We need to identify artifacts which are released under the EPL but
which aren't below org.eclipse.*.
Most prominent example: com.ibm.icu.
2. We need a tool to replace dependencies in POMs.
Re #1: Simply ignoring everything besides org.eclipse when copying to
the Nexus folder is not enough. We need more fine grained rules.
Comments?
We also need a mapping between Orbit and Maven Central.
Re #2: I've completed a first version of the tool which can remove
"<optional>false</optional>" from the generated POMs and which can
replace dependencies.
Currently, it has the following limitations:
1. It matches version by equals. More elaborate version matching could
be problematic since there might be cases where I need to know if two
version ranges *overlap*.
My current plan is to modify the tool to match artifacts by group+name
only (ignoring the version) and then check the version. If the version
doesn't match, I'll log a warning so we can accumulate a report what
versions are used.
With that report, we can decide what to do next.
2. Currently, I replace the existing dependency with a new one. I'm
wondering if I should create a profile section instead so users can
select the original dependency or our patch.
The problem with a profile section is that it's hard to make one the
default (as in "unless the user has selected a profile") because there
can be any number of profiles and there is no way to say "enable this
profile if no profile of this set is enabled".
That means users will generic errors if they import our POMs and they
forget to specify a profile :-/
3. There is currently no way to attach a condition to a patch (like
"apply it anywhere but for the POM X:Y:Z"). Not sure if that's
necessary, though.
4. There are generic patches (like the one which removes the
optional=false elements) and special patches (like the one which
replaces one dependency with another).
Special patches are small Python scripts which the patch tool
evaluates. The tool gets a directory and loads all the scripts in
there. I'm uneasy how this will work out when the number of patches
grows. Maybe it would be better to load a single patch which then
includes others with the help of an include command.
5. Python vs. Java. Right now, I'm developing the tools in Python just
because I'm about 10 times more productive with Python for tools like
that. But looking at the big picture, is that the right decision?
Should I stay with Python or convert the code to Java?
PS: The new version sits on my harddisk but I can't push it to github
right now; will do that tomorrow.
Regards,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/ http://blog.pdark.de/
