Closed GoogleCodeExporter closed 9 years ago
Just out of curiosity: What is the advantage of the new scheme? :)
Original comment by torsten....@gmail.com
on 18 Jun 2014 at 8:26
It's the standard scheme for Maven and it is shorter ( e.g. when writing Groovy
scripts ;) ).
The reasons would be, we did we not always use that scheme. The reason is that
OSGi has a different scheme (the one we use). Back in the day I know less about
Maven and was expecting OSGi to be something important to us in the mid term.
However, time has proven this expectation not to be correct.
Original comment by richard.eckart
on 18 Jun 2014 at 9:00
If we decide to change the artifact ids, we should do it before the release, so
that they stay stable from then on. What's the general opinion? Should I make
these changes now?
Original comment by oliver.ferschke
on 18 Jun 2014 at 10:02
DKPro Core will transition to the new scheme too
https://code.google.com/p/dkpro-core-asl/issues/detail?id=186
So it makes sense to do that now. Any objections?
Original comment by oliver.ferschke
on 18 Jun 2014 at 10:06
REC also brought up the issue whether to get rid of the -ASL and -GPL suffixes
to get more readable IDs.
It's a tradeoff - people have to look into a module (or some overview on the
project page) to see what license a module has, but the shorter ids are much
nicer if the end with the actual module name,
e.g.
dkpro-tc-features-ngram
instead of
dkpro-tc-features-ngram-asl
instead of
de.tudarmstadt.ukp.dkpro.tc.features.ngram-asl
Original comment by oliver.ferschke
on 18 Jun 2014 at 10:23
I guess people who really care about licenses will do the extra step :)
Original comment by torsten....@gmail.com
on 18 Jun 2014 at 11:53
Good. I am currently making the changes locally on my machine. I'll report
again when I'm done before doing any commits.
Original comment by oliver.ferschke
on 18 Jun 2014 at 11:57
Well, we should care. Before doing a release, it would be good to check if
somebody accidentally introduced a GPL dependency to an ASL module. But whether
we check the POM or the dependency report is probably wurscht. In fact, the
dependency report is probably more detailed and may also catch third-party
dependencies accidentally introduced.
Original comment by richard.eckart
on 18 Jun 2014 at 11:57
This issue was closed by revision r901.
Original comment by oliver.ferschke
on 18 Jun 2014 at 1:02
Original issue reported on code.google.com by
richard.eckart
on 18 Jun 2014 at 12:06