Henri Yandell wrote:
7/7/06, Dennis Lundberg <dennisl (AT) apache (DOT) orgwrote:
>Tarun Ramakrishna wrote:
>Hi,
>>
>The 1.1 PM for commons-logging-api seems to be missing from the
>central maven repository? Is there another place where this can be
>piced up from?
>>
>Regards,
>Tarun
>>
>Hi,
>>
>The reason for this is that commons-logging-api is not a separate module
>and does not have a pom of its own. You will have to make do with the
>pom for commons-logging, which can be found in this directory:
>>
>

? That seems a bit odd. There are many projects that create multiple
jars and have a pom for each.

Yes, but those projects use a Maven feature for multi-projects.
Commons-logging does not build all its different jars using Maven.
Instead it uses Ant with a number of intricate includes and excludes.

Agreed this is not optimal, but commons-logging is not easy to mavenize
full out. The subject has come up before and discussions have agreed
upon letting this be until after 1.1 was pushed out. Perhaps something
suitable for a 2.0 release where the necessary refactorings can be made.

Tarun Ramakrishna wrote:
Hi,

The 1.1 PM for commons-logging-api seems to be missing from the
central maven repository? Is there another place where this can be
piced up from?

Regards,
Tarun

Hi,

The reason for this is that commons-logging-api is not a separate module
and does not have a pom of its own. You will have to make do with the
pom for commons-logging, which can be found in this directory:

Henri Yandell wrote:
7/7/06, Dennis Lundberg <dennisl (AT) apache (DOT) orgwrote:
>Henri Yandell wrote:
>7/7/06, Dennis Lundberg <dennisl (AT) apache (DOT) orgwrote:
>>Tarun Ramakrishna wrote:
>>Hi,
>>>
>>The 1.1 PM for commons-logging-api seems to be missing from the
>>central maven repository? Is there another place where this can be
>>piced up from?
>>>
>>Regards,
>>Tarun
>>>
>>Hi,
>>>
>>The reason for this is that commons-logging-api is not a separate
>module
>>and does not have a pom of its own. You will have to make do with the
>>pom for commons-logging, which can be found in this directory:
>>>
>>
>>
>? That seems a bit odd. There are many projects that create multiple
>jars and have a pom for each.
>>
>Yes, but those projects use a Maven feature for multi-projects.
>Commons-logging does not build all its different jars using Maven.
>Instead it uses Ant with a number of intricate includes and excludes.
>>
>Agreed this is not optimal, but commons-logging is not easy to mavenize
>full out. The subject has come up before and discussions have agreed
>upon letting this be until after 1.1 was pushed out. Perhaps something
>suitable for a 2.0 release where the necessary refactorings can be made.

Any reason why we can't write a commons-logging-api pom by hand to be
deployed to ibiblio?

Well, if we find a good place for it in svn and keep it minimal I don't
see why we couldn't. It would have to be handled completely manually though.

My guess is that the use case here is that they want to use
commons-logging-api as a dependency in their (Maven 2 built) project, so
they don't get all the transitive dependencies that the pom for
commons-logging currently has in it.

There are a lot of hand made poms in the repo so i don't see that as a problem.

AFAIK the difference between api and implementation is the
dependencies section, so it's just a matter of copying it and strip
all unneded deps (all of them?).

7/8/06, Dennis Lundberg <dennisl (AT) apache (DOT) orgwrote:
Henri Yandell wrote:
7/7/06, Dennis Lundberg <dennisl (AT) apache (DOT) orgwrote:
>Henri Yandell wrote:
>7/7/06, Dennis Lundberg <dennisl (AT) apache (DOT) orgwrote:
>>Tarun Ramakrishna wrote:
>>Hi,
>>>
>>The 1.1 PM for commons-logging-api seems to be missing from the
>>central maven repository? Is there another place where this can be
>>piced up from?
>>>
>>Regards,
>>Tarun
>>>
>>Hi,
>>>
>>The reason for this is that commons-logging-api is not a separate
>module
>>and does not have a pom of its own. You will have to make do with the
>>pom for commons-logging, which can be found in this directory:
>>>
>>
>>
>? That seems a bit odd. There are many projects that create multiple
>jars and have a pom for each.
>>
>Yes, but those projects use a Maven feature for multi-projects.
>Commons-logging does not build all its different jars using Maven.
>Instead it uses Ant with a number of intricate includes and excludes.
>>
>Agreed this is not optimal, but commons-logging is not easy to mavenize
>full out. The subject has come up before and discussions have agreed
>upon letting this be until after 1.1 was pushed out. Perhaps something
>suitable for a 2.0 release where the necessary refactorings can be made.
>
Any reason why we can't write a commons-logging-api pom by hand to be
deployed to ibiblio?

Well, if we find a good place for it in svn and keep it minimal I don't
see why we couldn't. It would have to be handled completely manually though.

My guess is that the use case here is that they want to use
commons-logging-api as a dependency in their (Maven 2 built) project, so
they don't get all the transitive dependencies that the pom for
commons-logging currently has in it.

robert burrell donkin wrote:
Sat, 2006-07-08 at 16:27 +0200, Carlos Sanchez wrote:
>There are a lot of hand made poms in the repo so i don't see that as a problem.
>>
>AFAIK the difference between api and implementation is the
>dependencies section, so it's just a matter of copying it and strip
>all unneded deps (all of them?).

+1

any volunteers?
- robert

I can do it. We only need to agree on a suitable place in SVN where we
can store it.

Simon Kitching wrote:
Thu, 2006-07-13 at 23:58 +0200, Dennis Lundberg wrote:
>robert burrell donkin wrote:
Sat, 2006-07-08 at 16:27 +0200, Carlos Sanchez wrote:
There are a lot of hand made poms in the repo so i don't see that as a problem.

AFAIK the difference between api and implementation is the
dependencies section, so it's just a matter of copying it and strip
all unneded deps (all of them?).
+1

any volunteers?

- robert
>I can do it. We only need to agree on a suitable place in SVN where we
>can store it.
>>

I'm currently working on the two securitymanager-related bugs we
introduced into logging in the last release; these cause problems for
people running code in applets and similar restricted environments. A
unit test that demonstrates the problem has already been committed (and
fails).

that is done, I think we should get a 1.1.1 release out with that
plus the fixed maven poms; having all the dependencies declared
mandatory is rather unpleasant. Plus junit should be scope=test of
course.

I don't think that we can fix the current pom for commons-logging
completely. What we can do is publish a pom especially for
commons-logging-api, that people can use as their dependency.

Regarding the place for the pom.xml, can't we just put it in the trunk
directory? course we need to comment it, so people don't think it can
be used to *build* jcl.

Sounds good. If we call it commons-logging-api.pom then nobody will
think of actually using it to build commons-logging.

And by the way, the new nightly-build system is currently set up to use
maven1; that needs to be fixed to use ant instead I think. AFAIK, the
maven1 project.xml just creates the site.

Yep, Maven is only working K for the site for commons-logging. It can
compile things, but it won't compile everything.

, and can we get rid of all that ${pom.artifactId.substring(8)} stuff?
It's confusing, and I don't see the benefits as this project isn't going
to change its name. Just putting "logging" in there would be so much
clearer.

I don't know the history for that, by I think it has something to do
with meaning to use a common parent that every component could inherit
from. That idea has been rejected, so I see no reason for having these,
other than making it easy to copy-and-paste stuff from other components
project.xml files.

Regards,

Simon

To unsubscribe, e-mail: commons-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-user-help (AT) jakarta (DOT) apache.org